# TheTimeMachine: mining the Wayback Machine for forgotten endpoints

> TheTimeMachine is a Python script that pulls archived URLs for a domain from the Wayback Machine and turns them into a working list of stale endpoints, exposed backup files, GET parameters, embedded JWTs and subdomains, with optional pattern scans for XSS, SQLi, LFI, redirects and JIRA misconfiguration. It is aimed at bug bounty hunters, red teamers and OSINT researchers, and it works entirely against archive data rather than by scanning live sites.

**anmolksachan/TheTimeMachine** — Weaponizing WaybackUrls for Recon, BugBounties , OSINT, Sensitive Endpoints and what not

- Repository: https://github.com/anmolksachan/TheTimeMachine
- Website: https://anmolksachan.medium.com/the-time-machine-weaponizing-waybackurls-for-recon-bugbounties-osint-sensitive-endpoints-and-40889a03feeb
- Stars: 552 · Forks: 81
- Language: Python
- License: GPL-3.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/anmolksachan-thetimemachine

## What the tool actually collects, and from where

The core idea is narrow and worth stating plainly. TheTimeMachine does not scan a live site. It queries the Internet Archive for URLs previously captured for a domain, and then works on that list offline. The documentation describes it as digging through the past of a web application by scraping archived URLs, and as a tool for finding sensitive, forgotten or deprecated endpoints.

The collection modes are listed as separate flags. Archived URL fetching pulls historical URLs from the Wayback Machine. Backup file detection looks for `.zip`, `.bak`, `.sql`, `.tar.gz`, `.old` and other file types. A separate historical backups step looks for older copies of the backup files already identified. GET parameter mapping records every GET parameter and where it appears, which the docs position as useful for fuzzing automation. JWT detection finds and decodes tokens embedded in archived URLs. Directory listing detection finds open indexed directories, and subdomain enumeration pulls subdomains seen in the archived data.

That last distinction, archived URLs versus subdomains seen in archived data, is the reason the tool is more useful than a plain Wayback query. A host that was decommissioned, a staging box, or an admin path that no longer appears in navigation is often still sitting in the archive index, and the archive has no login requirement, no rate limit conversation and no honeypot behaviour.

The project ships as a single script named thetimemachine.py alongside core/ and db/ directories, an extensions.txt file and a requirements.txt. The tests and the web console are not present in the tree, so the entry point is the command line.

## Installing the script and its Python dependencies

The documentation states it is tested on Python 3 across Ubuntu, Kali and Windows, and installation is three steps from a clone:

```bash
git clone https://github.com/anmolksachan/TheTimeMachine
```

```bash
cd TheTimeMachine
```

```bash
pip3 install -r requirements.txt
```

The requirements file is short and gives you a clear picture of what the tool does with your terminal and the network. It pins colorama at 0.4.4, requires numpy at 1.26.0 or newer, requests at 2.31.0 or newer, rich at 13.6.0 or newer and termcolor at 2.4.0 or newer, and lists PyJwt without a version constraint.

Two of those are worth pausing on. The rich and colorama and termcolor combination is a console rendering stack, which is why the tool prints coloured sections rather than plain log lines, and that is a real difference from piping the output into another program. The PyJwt entry without a version bound is also worth noting, since it is the library used to decode the tokens the JWT mode finds, and an unpinned dependency is a dependency whose behaviour can change under you on a fresh install.

The requests entry handles the Wayback queries, and the fact that the tool talks to the Internet Archive rather than to the target means it needs outbound network access to the archive and not to the site you are investigating.

## Running the tool and the flags that do the work

The invocation is one script, one target and a set of flags:

```bash
python3 thetimemachine.py <target.com> [OPTIONS]
```

The documentation adds a constraint that saves time on the first run: do not use `http://` or `https://` in the domain, just pass `domain.com` or `sub.domain.com`.

The individual modes are separate flags rather than a pipeline you have to sequence yourself. Fetching the archive URL list is one run, looking for exposed backup files is another, and detecting open directory listings is a third:

```bash
python3 thetimemachine.py example.com --fetch
```

```bash
python3 thetimemachine.py example.com --backups
```

```bash
python3 thetimemachine.py example.com --listings
```

Parameter mapping, JWT extraction and the pattern scan work the same way:

```bash
python3 thetimemachine.py example.com --parameters
```

```bash
python3 thetimemachine.py example.com --jwt
```

```bash
python3 thetimemachine.py example.com --attack xss
```

Since each run is independent, the natural workflow is to fetch once, read the URL list, and then run the narrower modes against it, rather than launching everything at once against a domain with a large archive.

## The attack mode names in the option table and the usage line disagree

This is the detail that will cost you an afternoon if nobody points it out. The option table in the documentation lists the pattern scan as `--attack [type]` with the types given as xss, sqli, lfi, redirect, jira, wp and custom. The usage line the tool prints lists a different set:

```bash
usage: thetimemachine.py [-h] [--fetch] [--jwt] [--backups] [--subdomains] [--listings] [--attack {xss,sqli,lfi,redirect,jira,wp,fuzz}] [--menu]
                         [--parameters]
                         target
```

So the table offers a `custom` type and the parser offers `fuzz`. The feature list also mentions custom payload lists under the heading of using your own fuzz list or signatures for custom scans, and the section on adding your own payloads says you can fully customise the payloads for XSS, SQLi and fuzzing by editing the respective `.txt` files inside the repository.

The repository listing includes an extensions.txt file at the top level, and the documented way to change behaviour is to edit the payload text files in place rather than to pass a path on the command line. That is a meaningful difference from tools that accept a wordlist argument, and it means two people running the tool from different clones will get different scan results.

The usage line also reveals a `--menu` flag that the option table does not describe, so interactive mode exists even though the documentation focuses on the flag-driven form.

Treat the printed usage string as the authority on what the current build accepts, because the option table is documentation that was written at a different time from the argument parser.

## Where results land on disk

Output is written into a per-domain directory under content/, and the documented layout looks like this:

```
content/
└── example.com/
    ├── example.com_URLs.txt
    ├── example.com_xss.txt
    ├── example.com_sqli.txt
    ├── example.com_parameters.txt
    ├── example.com_subdomain.txt
    └── ...
```

The naming convention is consistent, one file per mode per domain, with the domain as the prefix. That is a sensible layout for a reconnaissance tool, because the next step is usually to take a file of parameters and feed it into a separate fuzzer, and a stable filename makes that hand-off mechanical rather than a copy and paste.

The separate top-level db/ directory in the repository tree suggests the tool keeps some state of its own alongside the text output, but the documentation does not describe what is stored in it, how it is keyed, or whether a second run merges with the first. If you care about reproducibility of a scan, the text files under content/ are the part you can rely on, and the docs do not tell you how to reset the database.

A practical consequence of writing plain text files is that the results survive the tool. You can grep them, diff them against a later run, or hand them to another scanner without depending on TheTimeMachine being installed.

## Why archive data is the right source, and where it misleads you

The value of this approach is that the archive contains what the site looked like before anyone hardened it. Modern applications route everything through a login and hide old admin panels, but the archive captured the state before that cleanup, and the parameters and endpoints from that era frequently still exist in some form.

The limit is the same fact seen from the other side. Every finding here is a statement about a snapshot. A URL in the archive may have been fixed the week after it was captured, may have been behind authentication at the time it was captured, or may never have existed outside a development environment. The pattern scans in particular match on strings, so a signature that matched in the archive is a candidate for you to verify by hand, not a finding you can report.

There is also the scope question, and it is the one that matters most. The tool queries the Internet Archive for a domain you name. The archive holds snapshots of other people's infrastructure, and the archived URLs you retrieve may point at third-party hosts that were linked from the target, which means the scan surfaces paths outside the scope you were given. Subdomain extraction in particular tends to widen the target area rather than narrow it, and it does so without asking.

The documentation's own framing helps here. The author describes the tool as a means to find leads to dig into manually, and mentions a Hall of Fame result on several vulnerability disclosure programmes and bug bounty programmes. A leads generator is a reasonable expectation to set, and treating its output as verified findings is where the disappointment comes from.

Compare that with scanning a live host directly, which gives current state but requires touching the target, generates traffic that a target can see, and finds only what is exposed right now. The archive route trades currency for stealth and history, and you cannot have both from one tool.

## Licence, releases and the gap between the version numbers

The project is released under GPL-3.0, with the licence file at the repository root. The GPL obligations matter in a specific way for a tool like this: if you modify it and distribute the modified version, you have to pass those changes on under the same terms, which is different from the permissive licences most reconnaissance scripts carry. If you intend to fold parts of it into an internal toolkit, the copyleft question is the one to settle, and that is a matter for whoever handles licensing at your organisation rather than a reading of a licence identifier.

The version story is the confusing part. The release list shows a 2.0 tag named TheTimeMachinev2.0 dated 2022-01-23 and a 1.0 tag dated 2022-01-25, so the numbered tags are older than the README would suggest, and the README headline describes the project as version 3.0. The repository is not archived and the last push was on 2026-10-13, so there is current work in the tree that is not captured by any of those tags.

That gap has a concrete consequence for a team. If you clone the default branch you get whatever the current tree holds, which the documentation calls version 3.0, but there is no tagged 3.0 release to pin to, so a reproducible deployment has to pin a commit hash rather than a version. The project also accepts custom payload lists in the repository, which means your checkout is part of your configuration, and losing it changes your scan behaviour.

Before adopting this, decide how you will pin it. A commit hash plus your own copy of the payload text files is the only way to make a scan repeatable, because the tags predate the current code and the payload files are edited in place.

## Conclusion

TheTimeMachine fits a bug bounty hunter or OSINT researcher who wants a first pass over what a domain used to expose, and it earns its place in a workflow precisely because it reads the archive rather than touching the live target. It does not fit anyone who needs to confirm a vulnerability on a running application, since every finding here comes from a snapshot and needs manual verification, and the newest tagged release is still 2.0 from 2022-01-23 even though the last push was on 2026-10-13. Before you run it, read the option table against the usage line it prints, because the two disagree on the attack type names, and confirm that the target domain sits in your scope and that its vulnerability disclosure programme permits archive-based enumeration.

## FAQ

### What is TheTimeMachine and what does it do?

TheTimeMachine is a Python script that pulls archived URLs for a domain from the Wayback Machine and works on that list offline. It fetches historical URLs, looks for exposed backup and config files, maps GET parameters, detects JWTs embedded in archived URLs, finds open directory listings and enumerates subdomains seen in the archive.

### How do I install and run TheTimeMachine?

Clone the repository, change into the TheTimeMachine directory and run `pip3 install -r requirements.txt`, which installs colorama, numpy, requests, rich, termcolor and PyJwt. Then run `python3 thetimemachine.py <target.com> [OPTIONS]`, passing the domain without an `http://` or `https://` prefix.

### Which attack types does the --attack flag accept?

The option table lists xss, sqli, lfi, redirect, jira, wp and custom, while the usage line the tool prints lists xss, sqli, lfi, redirect, jira, wp and fuzz. The printed usage line reflects what the current argument parser accepts, and the two lists do not match.

### Where does TheTimeMachine save its results?

Results are saved under the `content/` directory in a folder named for the target domain, with one text file per mode, such as example.com_URLs.txt, example.com_xss.txt, example.com_parameters.txt and example.com_subdomain.txt.

### Can I use my own payloads with TheTimeMachine?

Yes. The documentation says you can fully customise the payloads for XSS, SQLi and fuzzing by editing the respective `.txt` files inside the repository, and the repository includes an extensions.txt file at the top level. Because the payloads live in the checkout, a scan is only reproducible if you keep a copy of the files you used.

### Does TheTimeMachine scan live websites?

No. It queries the Wayback Machine for archived URLs of the target domain and works on that archived data, so its findings describe what the archive captured rather than the current state of the site. The results are leads for manual verification.

## Sources

- [anmolksachan/TheTimeMachine on GitHub](https://github.com/anmolksachan/TheTimeMachine)
- [License: GPL-3.0](https://github.com/anmolksachan/TheTimeMachine/blob/main/LICENSE)
- [Project website](https://anmolksachan.medium.com/the-time-machine-weaponizing-waybackurls-for-recon-bugbounties-osint-sensitive-endpoints-and-40889a03feeb)
- [README](https://github.com/anmolksachan/TheTimeMachine/blob/main/README.md)
- [Releases](https://github.com/anmolksachan/TheTimeMachine/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/anmolksachan-thetimemachine