Mining web archives and analysing logs is a powerful reconnaissance technique every Bug Bounty hunter should master.

Ever missed a six-figure bounty because a forgotten debug endpoint slipped through the cracks? Archive-based recon reveals the hidden treasures developers thought were buried forever. This passive approach generates zero ‘noise’ on the target’s systems, so you can scout vulnerabilities entirely undetected.

In this article, you’ll learn more about the value of archive-based recon, how to wield logs and snapshots, and a few handy commands and tools for uncovering intel that might reveal hidden security flaws.

Popular web archive recon tools
- Wayback Machine and waymore
- GetAllURLs (Gau)

Deep-dive web archive recon techniques
- Parsing archived JavaScript with LinkFinder
- Analysing logs for forgotten endpoints with TruffleHog

Putting it all together: A concise recon workflow

Expanding your toolkit: more passive recon techniques

Best practices for mitigating web archive recon

Web archive reconnaissance involves capturing and analysing historical snapshots and crawled data of a website to unearth information that is no longer visible on the live domain. Ethical hackers can then potentially leverage this info to find and exploit vulnerabilities that still exist on live systems.

This historical data can be gathered from public archives, such as Wayback Machine, CommonCrawl, Archive.today and URLScan, passively – so your traffic stays away from live servers.

So passive recon reliably evades detection and invariably steers ethical hackers away from legal risks and grey areas.

The uninitiated might surmise that a technique that eschews live, up-to-date systems in favour of months’ or years’ old data would have dubious utility.

Each archived screen capture freezes a moment in development time, preserving the so-called “nightmare leftovers”: debug panels, test APIs and credentials that developers forgot to remove.

These remnants often point directly to serious vulnerabilities, so their discovery cuts your reconnaissance time and puts you on a path to potentially high-severity and critical findings.

Web archive recon can reveal invaluable intel about:

 URLs or APIs disabled in production but still accessible, offering hidden attack surfaces

 Hardcoded tokens, credentials or configuration values in old JavaScript or config files

 Admin panels, debug consoles or staging pages that still linger in archives despite having been removed by developers

 Changelogs, README files and developer notes revealing logic or business workflows

The following are the most popular web archive recon tools – and for good reason. They are user-friendly and effective at yielding actionable insights about your targets.

These tools automate large-scale retrieval of historical data, eliminating manual effort and enabling systematic analysis.

 is an archive of snapshots that reveal how websites, and their attack surfaces, have evolved over time.

 collects archived URLs and downloads historical responses from Wayback Machine, 

Some useful information about the capabilities of various API keys, which can be stored in 

 Fetches full HTTP headers, screenshots and inline scripts

 Tags URLs with malware or suspicious content verdicts

 Uncovers shadowed references or removed assets missed by standard archives

Example 1: List all archived URLs (mode U)

This command harvests every archived endpoint in order to build your attack surface list:

Example 2: Download pages and extract JS (mode R)

This command retrieves all JavaScript responses for deep offline analysis:

Example 3: Collect archived URLs within a specific time frame (mode U + date filters)

The following command fetches only archived URLs captured between 1 January 2022 and 1 January 2023. Focusing on a specific development window, such commands can make otherwise lengthy results more manageable:

 aggregates URL lists from multiple archives in seconds, eliminating manual merging. Pulling from Wayback Machine, CommonCrawl, 

 and URLScan, it offers broad coverage. Users can filter results by extension, status code and subdomain. API keys can be stored in 

This command focuses on dynamic pages and scripts where secrets and logic hide: 

 files can expose hidden endpoints or tokens.

Now you know the basics, here are some methods for digging deeper:

Parsing archived JavaScript with LinkFinder

 extracts endpoints from offline JS files. For instance:

LinkFinder is useful because endpoints often reveal hidden API routes.LinkFinder is useful because endpoints often reveal hidden API routes.

Analysing logs for forgotten endpoints with TruffleHog

Archived logs often conceal hidden API routes, panels or tokens. 

 can scan those files and spit out any URLs or high-entropy strings directly to your console.

 to collect every path – including HTML, scripts, APIs and images.

 Test endpoints on the live site to see if they still expose data.

 to verify which assets are still active.

 CLI to reveal new subdomains without touching the target

 for historical DNS records to map past infrastructure

 to gather past registrant information and related domains

 Remove sensitive files, debug consoles and test APIs before deployment – thereby preventing archives from immortalising secrets

 and strict robots.txt rules to deter most crawlers

 Enforce authentication on log storage, rotate keys and sanitise entries to strip IPs, tokens or stack traces – thus minimising leakage

Mastering web archive and log-based reconnaissance gives you a unique window into a target’s forgotten past – unearthing endpoints, secrets and interfaces that live on in historical records.

Combine tools like waymore, gau and trufflehog with techniques such as LinkFinder parsing and methodical offline analysis and you can turn snapshots with nostalgic appeal into fuel for actionable attack paths. Following a structured workflow – harvesting every URL, analysing content offline, extracting hidden parameters and validating findings on live sites – can ensure you leave no stone unturned without running the risks entailed by implementing active recon techniques.

As for security teams, always remember to purge artefacts, steer crawlers away from sensitive sections and lock down your logs.

Whether you’re chasing your next bug or fortifying your own applications, archive-based recon is an indispensable recon method. Sometimes the past really does hold the key to your next high-impact finding in the present.

Recon Series #6: Excavating hidden artifacts with Wayback Machine and other web-archive tools

Headlines generated by a critical signature-spoofing flaw reported to the 

 attest to the rarity, technical sophistication and impact of such cryptographic bypasses.

 likely also covered the story because of the wide deployment of OpenPGP.js and the potential impact on popular downstream applications.

OpenPGP.js is an open source JavaScript implementation of the OpenPGP standard for message encryption and signing. OpenPGP is typically used for end-to-end encrypted email, signing of git commits and software releases, and encrypted file storage, among other things.

Now addressed, the OpenPGP.js vulnerability (CVE-2025-47934) could have enabled attackers to spoof signature verification and therefore dupe victims into trusting malicious messages or software commits. Credit for the discovery goes to Edoardo Geraci and Thomas Rinsma from Codean Labs, who have together netted a €7,500 bounty.

The discovery demonstrates how patience and thoroughness are the highest of virtues when it comes to finding vulnerabilities.

“We could only find this issue by taking the time to properly understand both the software's architecture and the relevant data formats,” Thomas Rinsma told YesWeHack. “It shows that when you search thoroughly, even in such a widely-used (and, presumably, widely reviewed) open source component, critical bugs may be found.”

Bug Bounty Programs allow security researchers to invest as much time as they need in performing reconnaissance and probing targets – whether their efforts take hours, weeks or even months to reach fruition. The fact that Bug Bounty rewards scale up with severity helps to incentivise and reward hunters for the time they invest (albeit high or critical severity issues aren’t necessarily 

 more time-consuming to find than lower severity flaws).

Interestingly, the Codean Labs researchers experimented on this occasion with a time-boxed approach. This “helped us stay focused on the most impactful threats,” said Thomas. “There is an optimal balance somewhere between having enough time to dig deep enough, but also having someone tell you to move on after a while.”

The vulnerability in question was uncovered when the researchers managed to validate a signature that hadn’t actually been signed by passing a maliciously modified message to either the openpgp.verify or openpgp.decrypt functions.

“In order to spoof a message, the attacker needs a single valid message signature (inline or detached) as well as the plaintext data that was legitimately signed, and can then construct an inline-signed message or signed-and-encrypted message with any data of the attacker's choice, which will appear as legitimately signed by affected versions of OpenPGP.js,” reads the relevant 

“In other words, any inline-signed message can be modified to return any other data (while still indicating that the signature was valid), and the same is true for signed+encrypted messages if the attacker can obtain a valid signature and encrypt a new message (of the attacker's choice) together with that signature.”

Discussing the discovery process, Rinsma said: “We followed our standard asset-based methodology, where we take into account the relevant assets and attack surfaces, and analysed the flows between them. This led us to the signature verification logic where we found this flaw. Besides relying on code review, we wrote some one-off scripts to generate PGP payloads to test various edge cases in flows like this.”

For an in-depth analysis of the discovery process and proof-of-concept, read Thomas Rinsma’s 

 that documents his and Edoardo Geraci’s discovery.

The OpenPGP.js team released a fix and advisory just 13 days after receiving the initial vulnerability report (on 6 May), once YesWeHack’s triage team and they themselves had swiftly evaluated the issue.

“The disclosure process through YesWeHack has gone very smoothly,” said Rinsma. “The OpenPGP.js team have been nice to work with. They understood the impact and quickly coordinated with their users.”

In particular, Rinsma singled out Daniel Huigens, a maintainer of OpenPGP.js who oversaw validation and remediation, for praise.

Daniel, who also co-authored the latest version of the OpenPGP standard, told YesWeHack: “I would like to thank Edoardo Geraci and Thomas Rinsma for finding and responsibly disclosing this vulnerability, YesWeHack for hosting the Bug Bounty Program and triaging the report, and (last but not least) the Sovereign Tech Agency for sponsoring the Bug Bounty Program.”

A patch is available for users of affected versions (5.0.1 to 5.11.2 and 6.0.0-alpha.0 to 6.1.0). Should users be unable to upgrade to the patched versions, then they can alternatively follow mitigation advice contained within the advisory.

Again, for more details about this vulnerability, including mitigation advice, please check out Thomas Rinsma’s 

Open source Bug Bounty opportunities from the Sovereign Tech Resilience Program

Offering up to €10,000 for critical issues and €5,000 for high severity bugs, the bounty grid for the 

 is highly competitive. In scope at present are three assets: the high-level API of OpenPGP.js, interoperability issues in OpenPGP.js and the OpenPGP standard.

The program is one of six public Bug Bounty initiatives currently overseen by the 

, an initiative of the Sovereign Tech Agency. The other programs, which all also offer maximum rewards of €10,000, include 

, which is funded by the German government, invests in open digital infrastructure to ensure a resilient and sustainable open source ecosystem. To this end, the Sovereign Tech Agency invests in critical yet underfunded open source projects via the 

, under which otherwise volunteer maintainers of critical free and open source software (FOSS) are remunerated for their contributions.

Want to learn more about the YesWeHack Bug Bounty & Vulnerability Management platform? 

 to schedule a demo with one of our experts.

Critical signature-spoofing vulnerability in OpenPGP.js hits the headlines

, challenged the participants to bypass regex filter and exploit a command injection in Ruby's 

Want to create your own monthly Dojo challenge? Send us a message on X!

 feeds to be notified of upcoming challenges.

Read on to find out how one of the winners managed to solve the challenge.

We would like to thank everyone who participated and reported their solution for this challenge to the Dojo program. There were many great reports for this challenge and you can find the best write-up below:

The Ruby Treasure application is a web-based e-commerce platform built using Ruby. A critical vulnerability has been identified in the web application that allows an attacker to execute arbitrary system commands on the server. The vulnerability exists because the application improperly validates filenames using a regex that checks input line by line, allows special characters like pipe (

) which can be used for command execution, fails to sanitize user input before using it in file operations, and uses the ERB templating system in an unsafe manner.

The exploitation of this vulnerability allows attackers to read any accessible file on the system, including sensitive configuration files and user data. Most critically, it allows complete command execution on the underlying server, potentially leading to full system compromise.

The discovery of this vulnerability required a thorough code analysis during the initial reconnaissance phase. This involved examining the underlying Ruby technology stack, understanding how the application processes user input, and identifying potentially unsafe utility methods. By analyzing the application's validation mechanisms, file handling operations, and template rendering process, it became clear that a combination of Ruby's regex behavior with multiline strings and its special handling of pipe characters in IO operations could be leveraged to bypass security controls. This reconnaissance phase was crucial for developing a successful exploitation strategy that could overcome the input validation while achieving command execution.

The vulnerability begins at the application entry point where user input is processed. The application is designed to serve ERB templates based on user input:

The application first changes its working directory to "/tmp/app/views", which sets the context for all subsequent file operations. This is important because it establishes the base directory from which any path traversal would need to escape to access sensitive files like the flag stored at "

Next, the application defines a validation function intended to restrict the filenames that can be accessed:

This validation function contains a critical flaw. While it appears to limit filenames to alphanumeric characters, underscores, and hyphens (as per the regex pattern 

 anchors differently when processing multiline strings. In Ruby, when a string contains newlines, the regex engine evaluates the pattern against each line separately. The 

 anchor matches the beginning of any line and the 

 anchor matches the end of any line, not just the beginning and end of the entire string.

 method in Ruby will return a match if any line in a multiline string matches the pattern. This means that if any single line of a multiline input satisfies the regex pattern, the entire input will pass validation, even if other lines contain malicious characters.

The application then processes the user input:

Here, the application takes user input (which comes from the input field on the challenge page), URL-decodes it using 

 function, and then attempts to read a file with that name plus the ".erb" extension. If this file reading operation fails, it falls back to reading "

Finally, the application renders the template:

This is where the command execution vulnerability comes into play. The application reads the template file "index.erb", creates an ERB object, and passes the content read earlier as a parameter named "page". The ERB template engine evaluates any Ruby code embedded within 

The vulnerability can be exploited through a two-stage attack. First, the attacker creates a multiline input where one line (in this case, the second line) satisfies the regex validation requirement. This allows the entire multiline input to pass validation despite containing malicious characters in other lines. Second, the attacker includes command injection in the first line utilizing Ruby's IO special character handling.

The specific vulnerability exists because of several factors working together. Unlike JavaScript, Ruby's regex implementation treats 

 anchors as matching the beginning and end of any line in a multiline string, not just the entire string. This means that the validation function only needs one line in a multiline input to match the pattern for the entire input to be considered valid. Additionally, Ruby's IO operations interpret the pipe character (

) at the beginning of a filename as a command to execute, reading the output of that command instead of reading from a file. This creates a perfect storm where an attacker can craft an input that both passes validation and executes arbitrary commands.

The weird regex validation in Ruby was confirmed from the following site, where even when an invalid input is given on first line, the input on second line would give a match.

This was also confirmed from the ruby compiler:

So a payload needed to be crafted for executing the commands on the application and also to bypass the regex validation. On using the pipe (

) on the first line, we were able to get command execution when we had a payload that would pass the regex validation on the second line. On using 

 on the second line, we were able to list all the files in the current directory.

Now all that was needed was to traverse to the directory with a flag and read it, hence the following payload was used to traverse back and read the 

 file with a wildcard. It was confirmed that it was the only 

gave the You've Pwned it modal and the Flag.

The PoC involved putting the following payload on the input field.

The input contains two lines separated by a newline. The first line is 

 function, the regex checks each line separately. The first line fails the validation because it contains characters that aren't allowed by the regex. However, the second line 

 is a simple alphanumeric character that passes the regex validation. Because at least one line in the input satisfies the regex pattern, the entire input passes validation.

After passing validation, the application tries to read a file with the name. In Ruby's IO operations, when a filename begins with the pipe character |, Ruby treats everything after it as a command to execute and reads the output of that command instead of reading from a file. In this case, the command being executed is 

. This command traverses up two directories (from 

 files, including the flag file that contains the sensitive information we're targeting.

The output of this command is then passed to the ERB template engine and displayed to the user, revealing the contents of the flag file and completing the exploit. This combination of regex validation bypass and command injection through Ruby's IO special character handling creates a powerful vulnerability that allows attackers to execute arbitrary commands and read sensitive files.

The Flag as obtained from the application interface is

The impact of this vulnerability is critical. It allows attackers to execute arbitrary commands on the server, which can lead to complete compromise of the application and potentially the entire server. Attackers can access sensitive system files, steal confidential data, install malware, and potentially pivot to other systems in the network.

Dojo challenge #41 - Ruby treasure winners & writeup

Google dorking is a comparatively simple yet invaluable reconnaissance technique for ethical hackers to learn.

Suitably customised ‘dorks’ (Google searches that reveal sensitive information about targets) can uncover hidden admin panels, misconfigured subdomains and exposed credentials within minutes – all without sending a single direct scan. Master common Google dorking operators like 

 and this passive recon technique can provide intel that paves the way to finding hitherto overlooked vulnerabilities.

The power of Google dorking (aka Google hacking) was creatively demonstrated, for instance, by 

research about leveraging dorks to find zero-days

 from Suraj Khetani of Unit 42, which was a 

contender for PortSwigger’s web hacking techniques awards for 2017

This article will elaborate on the value of dorking to Bug Bounty hunters, and explain how to conduct dorking queries in a multitude of effective ways.

Why Google dorking is an essential skill for Bug Bounty hunters

Core Google dorking operators for passive reconnaissance

Basic Google dorking queries: hands-on examples

Best practices for preventing Google dorking attackss

Next steps: from passive recon to exploit development

Google dorking (aka Google hacking) leverages specialised search operators to uncover publicly indexed resources such as files, directories and login pages that organisations never intended to expose. Unlike active scanning techniques like web crawling or DNS brute-forcing, dorking is entirely passive – meaning that no trace of your activities is left on your target’s systems.

For Bug Bounty hunters, mastering Google dorking means covering more ground with less effort and identifying vulnerabilities other hunters might miss.

This recon method empowers ethical hackers to quickly gather high-quality, publicly available intelligence about target applications. Mastering Google search operators can usefully augment recon techniques like 

, and helps uncover exposed assets such as forgotten subdomains, misconfigured directories and sensitive files.

 serves as a particularly invaluable resource for staying up to date with evolving search techniques and attack vectors.

Below is a list of Google search operators commonly used in advanced dorking:

 - Displays Google's cached version of a page

 - Finds files of a specific type (e.g., PDF)

 - Searches within a specific website or domain

 - Finds pages with the term in the title

 - Finds pages with the term in the body text

 - All terms must appear in the body text

 - Filters news by source (used in Google News)

 - Finds pages with the term in anchor text

 - Acts as a wildcard for one or more unknown words

 - Searches for the exact phrase inside quotes

In this section, we'll dive into popular Google dorking techniques that can uncover valuable assets within your Bug Bounty target:

Subdomain enumeration is a key reconnaissance step for mapping an organisation's digital footprint. These searches for related subdomains should cover as much ground as possible in order to get a comprehensive view of your target’s infrastructure.

The simplest query for discovering subdomains is:

 Returns all subdomains of the target domain that Google has crawled and indexed.

 Expands the attack surface by revealing additional entry points that may have been overlooked during initial scoping.

You can also combine multiple operators with double quotation marks to discover subdomains with a specific keyword in the URL:

 Searching for all subdomains associated with google.com that include a specified keyword (‘developer’ in the above example) in the URL. This can either be in the hostname itself or in the endpoint.

 Uncovers development and staging environments, which typically have weaker security controls

 making them prime targets for initial compromise. These environments may contain debugging information, default credentials or unpatched vulnerabilities.

Discovering hidden files within domains can not only expose sensitive file content but also effectively fingerprint an application's programming language, framework or running services that are being used.

The following dork discovers filenames with a specified extension in order to determine the programming language:

 Identifies files with specific extensions across all subdomains, revealing the programming languages and frameworks in use.

 Understanding the technology stack helps researchers focus efforts on language-specific vulnerabilities and common misconfigurations.

Framework and content management system (CMS) detection

We can also look for files that reveal the use of specific frameworks and CMS platforms. The following Google dork identifies WordPress installs by finding google.com subdomains with a php file extension and ‘wp-’ keyword in the URL:

: Searches for content management system indicators within PHP files, specifically targeting WordPress, Drupal, and Joomla installations.

 CMS platforms have well-documented vulnerabilities. Dorks can identify which versions are running and help researchers determine if known CVEs apply to the target system.

Login interfaces represent critical security boundaries and are frequent targets for various attack vectors, with weak credentials or vulnerabilities enabling hackers to mount SQL, NoSQL, LDAP and other injection attacks.

 Locates authentication-related URLs across the target domain.

 Each login portal represents a potential attack vector for credential stuffing or injection attacks. Authentication weaknesses can be leveraged to obtain direct access to your target applications.

A more targeted query might for instance search for all google.com domains with the keyword ‘login’, the extension ‘jsp’, and the keywords ‘username’ and ‘password’ within the webpage, while ignoring URLs containing the keyword ‘assets’, which typically indicates template login files rather than real login pages:

 Identifies Java-based login forms containing username and password fields while filtering out static assets and template files.

 Login portals are prime contenders for compromising the system and this is a more precise, effective way to surface active or legacy login pages.

Exposed credentials, which can lead to immediate system compromise and privilege escalation, are always a high-impact Bug Bounty find. 

be careful not to leak or misuse any credentials uncovered.

The following dork searches for all google.com-related domains with the txt file extension and the password or credentials keyword in the URL, excluding results containing the readme.txt filename:

Recon series #5: A hacker’s guide to Google dorking

We all have to-do lists to triage and decisions to make over which outstanding tasks are most urgent. No one can do everything all at once.

In the world of vulnerability management, prioritisation is particularly tricky given what’s at stake and the lengthening queue of suspected vulnerabilities.

After all, security teams can typically patch only about 10% of known vulnerabilities in their environment each month, according to 

. This begs vital questions about what gets fixed first amid the 

shrinking time-to-exploitation of zero days

A model has emerged in recent years that can answer these questions, as well as offer visibility of the vulnerabilities that might exist and the terrain where they might lurk.

Adoption of this SecOps system, called continuous threat exposure management (CTEM), could lead to a 

, according to Gartner, which coined the CTEM term.

Focused on vulnerability prioritisation and validation, this is the second part of a series exploring the five phases of CTEM. We’ll explain how YesWeHack’s Attack Surface Management (ASM) product facilitates risk-based remediation with automated priority scores, helps to guide validation decisions, and broadens visibility of potential risk exposures by consolidating multiple sources for vulnerability discovery into a single, unified interface.

first part explained the first two steps, scoping and discovery

The YesWeHack Blog

Critical signature-spoofing vulnerability in OpenPGP.js hits the headlines

Recon Series #6: Excavating hidden artifacts with Wayback Machine and other web-archive tools

Critical signature-spoofing vulnerability in OpenPGP.js hits the headlines

Dojo challenge #41 - Ruby treasure winners & writeup

Recon Series #6: Excavating hidden artifacts with Wayback Machine and other web-archive tools

Recon series #5: A hacker’s guide to Google dorking

Vulnerability prioritisation and validation: continuous threat exposure management (CTEM) series #2

‘Airborne’ AirPlay attacks, netting $64k from deleted files, triaging AI slop – ethical hacker news roundup

Recon series #5: A hacker’s guide to Google dorking

Beyond ‘../../’ - a practical guide to path traversal and arbitrary file read attacks

Tackling vulnerabilities at source: How to cut the rising cost of DevSecOps

UK retail cyber-attacks a ‘wake-up call’, SaaS overreliance ‘creating single points of failure’, calls for global regulatory alignment – OffSec roundup for CISOs

Beyond ‘../../’ - a practical guide to path traversal and arbitrary file read attacks

Don't wait for threats to strike

Produits

Chercheurs

Ressources

A propos

Suivez-nous