Websites change all the time. Pages get removed, endpoints get renamed, and parameters quietly disappear from the UI. But the internet remembers. Wayback Machine recon is the practice of mining archived copies of a site to find old URLs, parameters and files that may still work on the live server. In this post I’ll show you how to pull archived URLs, clean them up, and turn them into a focused list of things worth testing on your in-scope targets.
Why old URLs still matter
The Wayback Machine, run by the Internet Archive, stores snapshots of web pages going back many years. For a bug bounty hunter, the value is simple: developers remove things from the interface far more often than they remove them from the server. An old endpoint like /api/v1/export?debug=true might be gone from the menus but still answer a request. Archived data is a quiet way to find these forgotten routes. If you want the bigger context first, my post on recon and its importance in bug bounty hunting sets the scene.
Here is what archived URLs often reveal:
- Old API versions that were never fully shut down.
- Parameters the current site no longer shows but still accepts.
- Backup and config files such as
.bak,.oldor.zip. - Staging or test paths that leaked into the archive.
- Document and upload paths that expose a predictable naming pattern.
Wayback Machine recon: pulling the archived URLs
You do not have to click through the archive by hand. A few command-line tools query the same data and hand you a plain list. The two I use most are waybackurls and gau. Both take a domain and print every URL they can find.
echo target.example | waybackurls > wayback.txt
echo target.example | gau > gau.txt
cat wayback.txt gau.txt | sort -u > urls-all.txtgau pulls from several sources, including the Wayback Machine, Common Crawl and others, so running both and merging the results gives you wider coverage. On a large target this list can run into hundreds of thousands of lines, which is exactly why the next step matters.
Cleaning the list so it is usable
A raw archive dump is mostly noise. The same page shows up a hundred times with different tracking parameters, and thousands of images and fonts clutter the view. The tool uro is built to fix this. It removes duplicate URLs that differ only in values, drops useless extensions, and collapses the list to something you can actually read.
cat urls-all.txt | uro > urls-clean.txtAfter that, split the list by what you care about. Grep is enough for most of this work:
grep -iE '\?' urls-clean.txt > urls-with-params.txt
grep -iE '\.(bak|old|zip|tar|gz|sql|config|env)' urls-clean.txt > urls-files.txt
grep -iE '/api/|/v1/|/v2/|/internal/' urls-clean.txt > urls-api.txtNow you have three focused lists instead of one giant file: URLs that take parameters, URLs that point at interesting file types, and URLs that look like API routes.
Checking which archived URLs still live
An archived URL is only useful if the server still answers it today. Run your cleaned lists through httpx to see what responds, and keep an eye on the status codes.
cat urls-api.txt | httpx -mc 200,201,301,302,401,403 -title -o api-live.txtAs with other recon, 401 and 403 responses are worth a closer look. They tell you a route exists but is protected, which is more promising than a flat 404. For the file list, a 200 on something like backup.zip deserves immediate, careful attention, but only after you confirm it is in scope.
Turning parameters into test cases
The list of URLs with parameters is a gift. Each one is a place the application accepts input. Pull out the unique parameter names so you know what the app listens for:
grep -oE '\?[^ ]+' urls-with-params.txt | tr '&?' '\n' | cut -d= -f1 | sort -u > params.txtOld parameters like redirect, url, file, debug or admin are classic starting points for testing. Keep this list handy for the testing phase.
Staying inside the rules
Archived data makes it easy to wander off scope, so slow down here. The Wayback Machine may hold snapshots of subdomains, sister sites or third-party services that are not part of the program you are testing. Before you fire a single request at anything you found, check it against the scope. My guide to OSINT for bug bounty hunters goes deeper on sourcing this kind of public data responsibly.
A few rules I stick to:
- Only send live requests to assets that are clearly in scope.
- If an archived page shows old credentials or tokens, never use them. Report them.
- Respect rate limits when you replay a long list of URLs. Throttle
httpxif needed. - Treat sensitive archived files as proof, not as a licence to download real user data.
Common mistakes
- Skipping the cleanup step. Without
uroyou drown in duplicates and give up before you reach the good URLs. - Assuming archived means dead. Many old endpoints still respond. Always verify with
httpxrather than guessing. - Testing out of scope. The archive mixes in domains you are not allowed to touch. Filter first.
- Reporting raw lists. Finding an old URL is not a bug. Confirm the actual issue, then write it up clearly.
Tips to get more from the archive
Run this process more than once. Archive coverage grows over time, so a target you checked months ago may have new snapshots now. Save your output per target and diff it on your next pass. Combine the parameter list from here with your crawling results for a fuller picture, and feed the live API routes into your content-discovery work. On larger targets, where the archive returns enormous lists, the structured approach in my large scope recon ebook helps you keep it all organised.
Conclusion
Wayback Machine recon lets the past do some of your work for you. Pull archived URLs with waybackurls and gau, clean them with uro, split them into useful lists, and verify what still responds. Keep everything inside scope, never reuse old credentials, and treat the archive as a source of leads rather than a shortcut to exploitation. If you want to practise this flow with me and ask questions live, join my live online classes on bug bounty and recon.
