The Methodology
Before touching any target, I set up a structured recon pipeline. The goal is to map the entire attack surface before deciding where to dig deeper. This is what my workflow looks like:
- Subdomain enumeration with Amass, Sublist3r, and crt.sh
- Port scanning with naabu/nmap on discovered subdomains
- Technology fingerprinting with Wappalyzer and WhatWeb
- Directory brute-forcing with ffuf and common wordlists
- Screenshots with gowitness for visual triage
This phase typically runs overnight or while I work on other things. The output is a structured list of endpoints organised by technology stack, response codes, and open ports.
Recon in Action
For a recent HackerOne private program, the initial scope was just two domains. After running the pipeline, I had identified 47 subdomains, 12 of which were live and serving content. One in particular stood out: a legacy subdomain running an older version of a PHP CMS with known CVEs.
I triaged the live subdomains by response size, tech stack, and HTTP status. The legacy subdomain had a 200 response, was running PHP 7.2 with a CMS last updated in 2022, and had an admin login panel exposed at /admin.
XSS Discovery
On the legacy CMS, I tested the search functionality and contact form. The search query parameter reflected user input directly in the page without sanitisation. I submitted a simple payload:
<script>alert(document.cookie)</script>
The payload executed immediately. This was a classic reflected XSS, but because the parameter was also stored in the admin review queue, it doubled as stored XSS the administrators would trigger when reviewing submissions.
I documented the full reproduction steps, impact assessment, and a suggested fix (output encoding + Content-Security-Policy headers) in the report.
IDOR and Logic Flaws
While reviewing API endpoints, I noticed user IDs were sequential integers passed in the URL path: /api/v2/users/1234/profile. Changing the ID returned another user's data with no authorisation check. This was a textbook IDOR affecting PII exposure.
The password reset flow had a logic flaw: the reset token was generated using `Math.random()` based on the timestamp at millisecond precision. By creating two reset requests in quick succession, I could predict the token range and brute-force the reset for any account.
Both issues required clear proof of concept and risk assessment. The API IDOR was rated P2 (High), and the password reset flaw was P1 (Critical) after the triage team verified the impact.
Lessons Learned
Three key takeaways from running a recon-first approach:
- Recon is the differentiator. Most hunters jump straight to testing known endpoints. The ones who win spend 80% of their time on recon and 20% on exploitation.
- Documentation matters. A well-written report with clear reproduction steps, impact analysis, and remediation suggestions gets triaged faster and paid higher bounties.
- Legacy subdomains are gold. Older codebases often lack modern security controls and are overlooked by the program's own testing.
HackerOne has been a rewarding platform for sharpening my web security skills. The recon-first methodology consistently uncovers vulnerabilities that automated scanners miss. If you are getting started in bug bounty, focus on building a solid recon pipeline before anything else.