The Recon Mistake 90% of Hackers Make (And How to Fix It)

Bug Bounty Recon Methodology 🕐 20 min read  |  📊 Intermediate–Advanced

The Recon Mistake 90% of Hackers Make
— And Exactly How to Fix It

Let's be direct: most hackers are doing reconnaissance all wrong. Not because they lack talent or intelligence, but because they've fallen into a trap that the entire community quietly reinforces — the belief that more tools equal better results. After years in the bug bounty trenches, watching countless skilled hunters waste days, sometimes weeks, because of this single fundamental error, I decided to write this definitive guide.

This article breaks down the mistake, explains the psychology behind it, walks through five real-world case studies, and gives you a concrete, battle-tested methodology to replace it — complete with real commands, a working automation script, advanced techniques, and a $4,500 real-world example.

⚡ TL;DR — Key Takeaways

1. Running 5+ recon tools and collecting thousands of subdomains is the wrong approach — it creates data, not intelligence.
2. The real mistake is breadth over depth — scanning everything before understanding anything.
3. A focused 5-step methodology (subdomain discovery → filtering → endpoint discovery → JS analysis → Burp) consistently outperforms shotgun automation.
4. JavaScript files are a goldmine most hunters ignore entirely — they contain API keys, internal endpoints, and hidden parameters.
5. Manual exploration with Burp Suite is non-negotiable for finding logic flaws and broken authorization.
6. GitHub dorking, mobile app analysis, and Shodan/Censys are advanced techniques that separate top hunters from the crowd.

90%

of hunters make this exact recon mistake

3,400

subdomains collected, zero bugs found — the typical result

5

focused subdomains led to a $4,500 critical bounty

70%

of critical bugs are found through manual testing, not automation

---

🚨 The "More Tools = Better Results" Trap

The bug bounty community has a problem it doesn't like to talk about. The culture of "run everything, collect everything" has become so normalized that questioning it feels almost heretical. But the data doesn't lie: more tools do not produce more bugs.

Here's a scenario that probably sounds familiar. A hunter gets a new target — let's call it target.com. The excitement kicks in. They immediately fire up their terminal and unleash a barrage of tools in rapid succession, each one feeding its output into the next:

bash — The Classic "Shotgun" Approach

# Step 1: Fire every subdomain tool at once
subfinder -d target.com -o subdomains.txt
amass enum -d target.com >> subdomains.txt
assetfinder --subs-only target.com >> subdomains.txt
findomain -t target.com -u findomain_results.txt
chaos -d target.com -o chaos_subs.txt

# Step 2: Sort, dedupe, and probe everything
cat *.txt | sort -u | httpx -threads 200 -o live_hosts.txt

# Step 3: Blast nuclei at everything blindly
nuclei -l live_hosts.txt -t ~/nuclei-templates/ -o nuclei_results.txt

# Step 4: Maybe try some directory fuzzing
ffuf -w /usr/share/wordlists/dirb/big.txt -u https://target.com/FUZZ

# Result: 3,400 live subdomains. 12,000 nuclei findings (mostly noise).
# Zero confirmed bugs. Two weeks wasted. Confusion and frustration.

The result? A list of 3,400 live subdomains, a nuclei output file full of false positives and noise, and absolutely no confirmed bugs. The hunter has data — mountains of it — but no understanding. Just automation followed by confusion, followed by moving on to the next target and repeating the cycle.

The two approaches side-by-side: Breadth (5 tools → 3,400 subdomains → zero bugs) vs. Depth (2 tools → 50–200 subdomains → $4,500 bounty)

⚠️ The Core Problem

The typical broken workflow is: subdomains → httpx → nuclei → maybe ffuf → ???
There is no understanding. No analysis. No manual exploration. Just automation followed by confusion. You are treating reconnaissance as a data collection exercise when it should be an intelligence-gathering exercise.

The Illusion of Progress

This "shotgun" approach feels productive. Your terminal is buzzing, files are being created, and the subdomain count is climbing. It creates a powerful illusion of progress. But in reality, you're just collecting hay for a needle you haven't even defined yet. You're drowning in data and starving for insights.

The problem is compounded by the community itself. Twitter threads, YouTube tutorials, and blog posts all celebrate the "I ran 12 tools and found 50,000 subdomains" approach. Nobody posts about the time they spent three days manually exploring five subdomains and found a critical vulnerability. The former is impressive-looking; the latter is what actually pays.

There's also a psychological component. Running automated tools feels safe — if you don't find anything, you can blame the tools. But manual exploration requires you to actually think, to form hypotheses, and to be wrong. That vulnerability is uncomfortable, and many hunters avoid it by hiding behind automation.

---

💡 My Wake-Up Call: A $0 vs. $4,500 Lesson

The moment that changed how I approach recon wasn't a tutorial or a blog post. It was a humbling conversation with another hunter who found a critical bug on a target I had spent two weeks on — using only five subdomains.

Last year, I was hunting on a fintech program — big scope, juicy payouts, fierce competition. I ran my usual "shotgun" approach. After two weeks: zero bugs. Zilch. Meanwhile, another hunter found a critical IDOR vulnerability in the company's partner portal within three days and walked away with a $4,500 bounty. When I asked how, the answer was humbling:

"I only looked at five subdomains. But I actually LOOKED at them. Ran them through Burp, mapped every endpoint, understood the logic. The partner portal had sequential numeric IDs in the API — I just swapped my ID for another user's ID and got full access to their data."

💰 Critical IDOR — Partner Portal Data Exposure $4,500 3 days of focused work

The Anatomy of the Missed Vulnerability

The IDOR was simple but severe. The partner portal used sequential numeric IDs for its users. The API endpoint was /api/v1/partners/{id}. The other hunter simply created two accounts, swapped the ID in the API request, and gained full access to the other partner's data — including financial records, contact information, and transaction history.

I had partner-api.target.com in my massive subdomain list. But I never once logged in or explored it manually. I just threw an automated scanner at it, which found nothing, because the vulnerability was a business logic flaw — not a CVE, not a known template, not something any scanner can detect. You have to actually use the application to find it.

http — The $4,500 IDOR (What the Other Hunter Found)

# Normal request — your own partner account
GET /api/v1/partners/1042 HTTP/1.1
Host: partner-api.target.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Content-Type: application/json

# Response: your own data (200 OK)
{
  "id": 1042,
  "name": "Your Company",
  "revenue": 45000,
  "transactions": [...],
  "contacts": [...]
}

# Modified request — swap ID to another partner's account
GET /api/v1/partners/1041 HTTP/1.1
Host: partner-api.target.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Content-Type: application/json

# Response: ANOTHER COMPANY'S sensitive data (200 OK — no auth check!)
{
  "id": 1041,
  "name": "Competitor Corp",
  "revenue": 128000,
  "transactions": [...],
  "contacts": [...]
}

# This is a classic IDOR. No scanner would ever find this.
# You have to manually explore the application to discover it.

Breadth vs. Depth: A Direct Comparison

Metric	Breadth Approach ❌	Depth Approach ✔
Tools Used	5–10+ tools simultaneously	1–2 focused tools
Subdomains Collected	3,000–10,000+ (overwhelming)	50–200 (manageable)
Targets Investigated	Hundreds, superficially	10–20, deeply
JS Analysis	Skipped entirely	Core part of workflow
Manual Testing	Minimal or none	Burp Suite + DevTools
Typical Outcome	Lots of data, zero bugs	Fewer targets, real findings
Time to First Bug	Weeks (if ever)	Hours to days
Bug Type Found	Only known CVEs (if any)	Logic flaws, IDOR, auth bypasses
False Positive Rate	Very high (scanner noise)	Very low (manual verification)

---

🔎 The 5-Step Focused Recon Methodology

Here is the exact methodology I use today. Each step builds on the last, creating an intelligence pipeline that prioritizes understanding over raw data volume. This is not a collection of tips — it is a complete, ordered workflow.

The 5-step focused recon workflow — each phase feeds intelligence into the next, building a complete picture of the target

1

Focused Subdomain Discovery

Use one or two passive tools with specific, trusted sources. The goal is a manageable list of 50–200 subdomains, not an overwhelming firehose of 10,000 entries you'll never investigate.

2

Intelligent Filtering & Prioritization

Don't probe everything blindly. Use httpx with tech detection, then grep for high-value keywords. You want 10–20 targets worth investigating deeply, not 3,400 hosts to scan superficially.

3

Deep Endpoint Discovery

Most hunters find admin-panel.target.com and immediately try SQL injection — without ever mapping what endpoints exist. Crawl first, attack second. Understand the attack surface before you attack it.

4

JavaScript Analysis — The Goldmine Most Skip

JS files routinely expose API endpoints, hardcoded secrets, internal URLs, and logic flaws. Skipping this step is leaving money on the table. This is where the hidden attack surface lives.

5

Manual Exploration with Burp Suite

This is where the real bugs are found. Proxy everything through Burp Suite and actually use the application. Create accounts, trigger features, and watch the HTTP history. Think like a developer, not a scanner.

---

📍 Step 1: Focused Subdomain Discovery

The first step is to build a manageable, high-quality list of subdomains. The key word here is manageable. You are not trying to find every single subdomain that has ever existed. You are trying to find the subdomains that are most likely to be interesting, most likely to be under-secured, and most likely to yield a finding.

Use subfinder with specific, trusted passive sources. The -sources flag lets you specify which data sources to query, which keeps the output focused and avoids the noise that comes from querying every source simultaneously. For most targets, crtsh and alienvault will give you 80% of what you need.

bash — Step 1: Focused Subdomain Discovery

# Primary: subfinder with specific, trusted passive sources
# -sources limits to crtsh and alienvault — focused, not noisy
subfinder -d target.com -sources crtsh,alienvault -o subs_initial.txt

# Optional: add passive amass for historical DNS data
# -passive flag means no active brute-forcing — just passive lookups
amass enum -passive -d target.com -o amass_passive.txt

# Merge and deduplicate — clean, sorted, unique list
cat subs_initial.txt amass_passive.txt | sort -u | tee all_subs.txt

# Check how many you have — should be 50–200 for most targets
wc -l all_subs.txt

# If you have more than 500, add a second filter pass:
# Remove wildcards, CDN subdomains, and known third-party services
cat all_subs.txt | grep -v -E "cdn\.|cloudfront\.|akamai\.|fastly\." | tee filtered_subs.txt

# Expected result: ~50–200 subdomains. Manageable. Not overwhelming.

💡 Pro Tip: Certificate Transparency Logs

Certificate Transparency (CT) logs are one of the best passive sources for subdomain discovery. Every SSL/TLS certificate issued for a domain is publicly logged. You can query them directly at crt.sh — just search for %.target.com to see all certificates ever issued for any subdomain. This often reveals internal subdomains that companies forgot they had.

---

🔍 Step 2: Intelligent Filtering & Prioritization

Once you have your subdomain list, the next step is to probe which ones are live and, more importantly, which ones are interesting. Not all live subdomains are created equal. A subdomain running a generic marketing page is far less interesting than one running a staging environment, an admin panel, or an internal API.

The httpx tool from ProjectDiscovery is the gold standard for this. The -tech-detect flag fingerprints the technology stack of each live host, which immediately tells you what kind of vulnerabilities to look for. A host running Jenkins is a completely different attack surface than one running a static React app.

bash — Step 2: Intelligent Filtering & Prioritization

# Probe live hosts with tech detection, status codes, and page titles
# -tech-detect fingerprints the tech stack (React, Django, Jenkins, etc.)
# -status-code shows HTTP response codes (200, 301, 403, 500, etc.)
# -title shows the page title — often reveals the purpose of the subdomain
cat all_subs.txt | httpx -silent -tech-detect -status-code -title -o live_detailed.txt

# Filter for HIGH-VALUE keywords — these are your primary targets
cat live_detailed.txt | grep -iE "admin|staging|dev|test|api|internal|vpn|jenkins|gitlab|swagger|grafana|kibana|dashboard|portal|manage|control" | tee high_value.txt

# Separately, look for 403 Forbidden responses — often worth bypassing
cat live_detailed.txt | grep " 403 " | tee forbidden_403.txt

# Look for 500 errors — may indicate backend issues worth investigating
cat live_detailed.txt | grep " 500 " | tee server_errors.txt

# Identify specific high-value technologies
cat live_detailed.txt | grep -iE "Jenkins|GitLab|Grafana|Kibana|Jira|Confluence|Swagger|phpMyAdmin" | tee specific_tech.txt

# Expected result: 10–20 high-value targets. Not 3,400 noise entries.

📄 Real-World Example

How Filtering Found a Forgotten Swagger UI

On a recent engagement, my initial subdomain list had 180 entries. After running httpx with tech detection and filtering for high-value keywords, I was left with 14 targets. One of them — api-docs.target.com — was running a Swagger UI instance that the development team had apparently forgotten about. It was publicly accessible, fully documented, and had no authentication on several endpoints. The Swagger UI revealed an undocumented /admin/users endpoint that allowed me to enumerate all user accounts. That turned into a P2 finding worth $1,800.

Without the filtering step, that subdomain would have been buried in a list of 180 entries and I would have moved on without ever looking at it closely.

---

🕵️ Step 3: Deep Endpoint Discovery

Once you have your 10–20 high-value targets, the next step is to map their attack surface completely. This means discovering every endpoint, every parameter, and every URL pattern that the application exposes. Most hunters skip this step and go straight to attacking — which is like trying to pick a lock without knowing which door you're at.

The combination of gospider for live crawling and gau for historical URL discovery gives you the most complete picture of the application's attack surface. Gospider actively crawls the application and follows links, while gau pulls historical URLs from the Wayback Machine, Common Crawl, and other sources — often revealing endpoints that have been removed from the live site but may still be accessible.

bash — Step 3: Deep Endpoint Discovery

# Crawl the target thoroughly
# -c 10 = 10 concurrent requests (respectful, not aggressive)
# -d 3 = crawl depth of 3 levels (follows links 3 levels deep)
gospider -s "https://admin-panel.target.com" -o gospider_output -c 10 -d 3

# Extract all discovered URLs from crawl output
cat gospider_output/* | grep -Eo "(http|https)://[a-zA-Z0-9./?=_&#-]*" | sort -u | tee endpoints.txt

# Isolate JavaScript files for Step 4 analysis
cat gospider_output/* | grep "\.js" | grep -v "\.json" | sort -u | tee js_urls.txt

# Pull historical URLs from Wayback Machine + Common Crawl
# --blacklist skips static assets we don't care about
echo "admin-panel.target.com" | gau --blacklist png,jpg,gif,css,woff,svg | tee gau_urls.txt

# Combine all discovered URLs into one master list
cat endpoints.txt gau_urls.txt | sort -u | tee all_endpoints.txt

# Look for interesting patterns in the URL list
# These patterns often indicate high-value functionality
cat all_endpoints.txt | grep -iE "/api/|/admin/|/internal/|/v[0-9]/|/user/|/account/|/payment/|/export/"

# Find endpoints with parameters — these are prime testing targets
cat all_endpoints.txt | grep "?" | tee parameterized_urls.txt

# Now you have a complete map of the attack surface.
# You know WHAT exists before you start testing HOW it behaves.

💡 Why Historical URLs Matter

The Wayback Machine and Common Crawl archive URLs that may no longer be linked from the live site but are still accessible on the server. Developers often remove links to old API versions or deprecated endpoints from the frontend, but forget to actually disable the backend routes. I've found multiple critical vulnerabilities in /api/v1/ endpoints that were replaced by /api/v2/ — the old version was still live, still functional, and had weaker authentication.

---

💾 Step 4: JavaScript Analysis — The Unseen Goldmine

This is the step that separates good hunters from great ones. JavaScript files are the most underutilized source of intelligence in bug bounty hunting. They are written by developers, for developers — and they contain a wealth of information that was never meant to be seen by security researchers.

Modern web applications ship enormous amounts of JavaScript to the browser. This code contains API endpoint definitions, authentication logic, business rules, and — critically — sometimes hardcoded secrets that developers forgot to remove before shipping to production. A single JS file can reveal an entire undocumented API, complete with parameter names, expected values, and authentication requirements.

Real output from JS analysis: hardcoded API keys, AWS credentials, and internal API endpoints all found with simple grep commands

bash — Step 4: JavaScript Analysis

# Download all discovered JS files locally for offline analysis
mkdir -p js_files
cat js_urls.txt | while read url; do
    wget -q "$url" -P js_files/
done

# ── HUNT 1: Hardcoded Secrets (HIGHEST VALUE) ──────────────
grep -r -iE "api_key|apikey|api-key|secret|token|password|passwd|aws_access|aws_secret|private_key|client_secret" js_files/ | tee secrets.txt

# ── HUNT 2: AWS Credentials ────────────────────────────────
grep -r -E "AKIA[0-9A-Z]{16}" js_files/ | tee aws_keys.txt

# ── HUNT 3: Undocumented API Endpoints ─────────────────────
grep -r -E '"/(api|v[0-9]|internal|admin|private)[^"]*"' js_files/ | tee api_endpoints.txt

# ── HUNT 4: URL Patterns and Parameters ────────────────────
grep -r -oE '"[a-zA-Z_][a-zA-Z0-9_]*":\s*["\{]' js_files/ | sort -u | tee json_keys.txt

# ── HUNT 5: Internal IP Addresses / Hostnames ──────────────
grep -r -E "(10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.)[0-9.]+" js_files/ | tee internal_ips.txt

# ── HUNT 6: Use LinkFinder for minified/obfuscated JS ──────
# LinkFinder uses AST parsing to extract endpoints from complex JS
python3 linkfinder.py -i "https://target.com/static/js/main.chunk.js" -o cli

# ── HUNT 7: Use SecretFinder for comprehensive secret detection
python3 SecretFinder.py -i "https://target.com/static/js/app.js" -o cli

# What you'll find: AWS keys, Stripe secrets, internal API base URLs,
# undocumented admin endpoints, hidden parameters, internal hostnames.

📄 Real-World Example

Hardcoded Stripe Secret Key in Production JS

On a SaaS target, a simple grep for sk_live_ (the prefix for Stripe live secret keys) in the application's JavaScript bundle returned a hit. A developer had hardcoded the company's live Stripe secret key directly in the frontend JavaScript — meaning anyone who opened the browser's developer tools could see it. The key had full permissions to charge cards, issue refunds, and access customer data.

This was a P1 critical finding. The program paid $3,200 for it. The entire discovery process took about 20 minutes. I never would have found it with a vulnerability scanner — it required opening the JS file and looking at it.

---

🖥️ Step 5: Manual Exploration with Burp Suite

All the previous steps have been building toward this moment. You now have a focused list of 10–20 high-value targets, a complete map of their endpoints, and intelligence gathered from their JavaScript files. Now it's time to actually use the application — and this is where the real bugs are found.

Set up Burp Suite as your proxy and use the application the way a real user would. Create accounts. Log in. Use every feature. Trigger every workflow. Watch the HTTP history as you do this. You are not looking for anything specific yet — you are building a mental model of how the application works, how data flows through it, and where the interesting decisions are being made.

bash — Step 5: Set Up Burp Proxy & Parameter Discovery

# Route all traffic through Burp Suite (running on 127.0.0.1:8080)
export http_proxy=http://127.0.0.1:8080
export https_proxy=http://127.0.0.1:8080

# After manual exploration, use Arjun to find hidden parameters
# Arjun tests thousands of parameter names against each endpoint
arjun -u "https://api.target.com/v1/users" -m GET

# Example output from Arjun:
[+] Parameters found: role, admin, debug, internal, export, format

# Now fuzz the discovered endpoints with ffuf
# Test the 'role' parameter for privilege escalation
ffuf -w /usr/share/wordlists/seclists/Fuzzing/generic-fuzzing.txt \
     -u "https://api.target.com/v1/users?role=FUZZ" \
     -H "Authorization: Bearer YOUR_TOKEN" \
     -mc 200,201,302 \
     -o ffuf_role_results.json

# Test for IDOR by iterating over numeric IDs
ffuf -w <(seq 1 1000) \
     -u "https://api.target.com/v1/users/FUZZ/profile" \
     -H "Authorization: Bearer YOUR_TOKEN" \
     -mc 200 \
     -o ffuf_idor_results.json

# The goal: find endpoints that return data they shouldn't,
# accept parameters they shouldn't, or perform actions they shouldn't.

Thinking Like a Developer, Not a Scanner

The most important mindset shift you can make is to stop thinking like a security tool and start thinking like the developer who built the application. As you use the application, ask yourself these questions:

• What is this feature supposed to do? Understand the intended behavior before looking for unintended behavior.
• Where does the data come from? Is it user-supplied? Is it fetched from an API? Is it stored in a cookie or localStorage?
• What happens if I send unexpected values? What if I send a string where a number is expected? What if I send a negative number? What if I send an array instead of a string?
• Is there a difference between what the UI shows me and what the API returns? The UI might hide certain fields, but the API might still return them. Check the raw response in Burp.
• What would happen if I were a different user? Can I access another user's data by changing an ID? Can I escalate my privileges by changing a role parameter?
• Are there any actions that should require confirmation but don't? Account deletion, fund transfers, and permission changes are classic examples of actions that should have additional verification.

✅ The Key Insight

When you use the application manually and proxy it through Burp Suite, you will find something interesting — and more importantly, you will start to see the application the way a developer sees it. That perspective is exactly how you find the bugs they accidentally left behind. Automated tools can only find what they're programmed to look for. Manual testing can find anything.

---

⚙️ Automating the Right Way: The Focused Recon Script

Here is a complete bash script that implements this focused methodology. It is linear, it is focused, and it prioritizes intelligence gathering over data collection. Save it as focused_recon.sh, make it executable with chmod +x focused_recon.sh, and run it with ./focused_recon.sh target.com.

bash — focused_recon.sh — Complete Automation Script

#!/bin/bash
# ──────────────────────────────────────────────────────────────
# focused_recon.sh — The 5-Step Focused Recon Methodology
# Usage: ./focused_recon.sh target.com
# Requirements: subfinder, amass, httpx, gospider, gau, wget
# ──────────────────────────────────────────────────────────────

TARGET="$1"
OUTPUT_DIR="recon_${TARGET}_$(date +%Y%m%d_%H%M%S)"

if [ -z "$TARGET" ]; then
    echo "Usage: $0 target.com"
    exit 1
fi

mkdir -p "$OUTPUT_DIR"/{subs,live,endpoints,js,secrets}
echo "[*] Starting focused recon on: $TARGET"
echo "[*] Output directory: $OUTPUT_DIR"

# ── STEP 1: Focused Subdomain Discovery ───────────────────
echo "[+] STEP 1: Subdomain Discovery..."
subfinder -d "$TARGET" -sources crtsh,alienvault -silent -o "$OUTPUT_DIR/subs/subfinder.txt"
amass enum -passive -d "$TARGET" -o "$OUTPUT_DIR/subs/amass.txt" 2>/dev/null
cat "$OUTPUT_DIR/subs/"*.txt | sort -u > "$OUTPUT_DIR/subs/all_subs.txt"
echo "    Found: $(wc -l < $OUTPUT_DIR/subs/all_subs.txt) unique subdomains"

# ── STEP 2: Intelligent Filtering ─────────────────────────
echo "[+] STEP 2: Filtering for live and interesting hosts..."
cat "$OUTPUT_DIR/subs/all_subs.txt" | httpx -silent -tech-detect -status-code -title -o "$OUTPUT_DIR/live/all_live.txt"
cat "$OUTPUT_DIR/live/all_live.txt" | grep -iE "admin|staging|dev|test|api|internal|vpn|jenkins|gitlab|swagger|grafana|kibana|portal|dashboard" > "$OUTPUT_DIR/live/interesting.txt"
echo "    Found: $(wc -l < $OUTPUT_DIR/live/interesting.txt) interesting targets"

# ── STEP 3: Deep Endpoint Discovery ───────────────────────
echo "[+] STEP 3: Discovering endpoints on interesting targets..."
while read url; do
    DOMAIN=$(echo "$url" | awk '{print $1}')
    gospider -s "$DOMAIN" -o "$OUTPUT_DIR/endpoints/gospider" -c 10 -d 3 -q
    echo "$DOMAIN" | sed 's|https\?://||' | gau --blacklist png,jpg,gif,css,woff,svg >> "$OUTPUT_DIR/endpoints/gau_urls.txt"
done < "$OUTPUT_DIR/live/interesting.txt"
cat "$OUTPUT_DIR/endpoints/gospider/"* | grep -Eo "(http|https)://[a-zA-Z0-9./?=_&#-]*" > "$OUTPUT_DIR/endpoints/crawl_urls.txt"
cat "$OUTPUT_DIR/endpoints/"*.txt | sort -u > "$OUTPUT_DIR/endpoints/all_endpoints.txt"
cat "$OUTPUT_DIR/endpoints/gospider/"* | grep "\.js" | grep -v "\.json" | sort -u > "$OUTPUT_DIR/js/js_urls.txt"

# ── STEP 4: JavaScript Analysis ───────────────────────────
echo "[+] STEP 4: Analyzing JavaScript files..."
while read jsurl; do
    wget -q "$jsurl" -P "$OUTPUT_DIR/js/files/"
done < "$OUTPUT_DIR/js/js_urls.txt"
grep -r -iE "api_key|apikey|secret|token|password|aws_access|private_key|AKIA[0-9A-Z]{16}" "$OUTPUT_DIR/js/files/" > "$OUTPUT_DIR/secrets/potential_secrets.txt"
grep -r -E '"/(api|v[0-9]|internal|admin)[^"]*"' "$OUTPUT_DIR/js/files/" > "$OUTPUT_DIR/secrets/api_endpoints.txt"

# ── SUMMARY ───────────────────────────────────────────────
echo ""
echo "[✓] Focused recon complete!"
echo "[✓] Subdomains:          $(wc -l < $OUTPUT_DIR/subs/all_subs.txt)"
echo "[✓] Interesting targets: $(wc -l < $OUTPUT_DIR/live/interesting.txt)"
echo "[✓] Total endpoints:     $(wc -l < $OUTPUT_DIR/endpoints/all_endpoints.txt)"
echo "[✓] JS files analyzed:   $(ls $OUTPUT_DIR/js/files/ 2>/dev/null | wc -l)"
echo "[✓] Potential secrets:   $(wc -l < $OUTPUT_DIR/secrets/potential_secrets.txt)"
echo "[✓] Next step: Open Burp Suite and manually explore your interesting targets!"

---

🚀 Advanced Techniques: Beyond the Basics

Once you've mastered the 5-step methodology, these advanced techniques will help you find vulnerabilities that even experienced hunters miss. Each one targets a different blind spot in the typical recon workflow.

1. GitHub Dorking: Finding Leaked Secrets in Source Code

Developers push code to GitHub constantly, and they frequently accidentally include secrets, internal URLs, and configuration files that should never be public. GitHub's search is powerful enough to find these leaks in seconds. The key is knowing what to search for.

github — Dorking Queries for Bug Bounty Recon

# Search within a specific organization's repositories
org:target-company password
org:target-company api_key
org:target-company secret_key
org:target-company "internal.target.com"
org:target-company "staging.target.com"
org:target-company DB_PASSWORD
org:target-company SMTP_PASSWORD

# Search for specific file types that often contain secrets
org:target-company filename:.env
org:target-company filename:config.yml
org:target-company filename:database.yml
org:target-company filename:settings.py
org:target-company filename:wp-config.php

# Search for specific secret patterns across all of GitHub
"target.com" "api_key"
"target.com" "password" filename:.env
"@target.com" password

# Use truffleHog for automated secret scanning of a repo
trufflehog github --org=target-company --token=YOUR_GITHUB_TOKEN

# Use gitleaks for scanning a cloned repository
git clone https://github.com/target-company/their-repo.git
gitleaks detect --source=./their-repo -v

📄 Real-World Example

Database Credentials Found in a Public Repository

A simple GitHub dork — org:target-company filename:database.yml — returned a repository that contained a database.yml file with production database credentials. The file had been committed to the repository two years earlier, and while the developer had since removed it from the main branch, it was still accessible in the Git history. The credentials were still valid and provided direct access to the production PostgreSQL database. This was a P1 critical finding.

2. Mobile App Analysis: The Forgotten Attack Surface

If your target has a mobile app, it is almost certainly a less-secured version of their web application. Mobile APIs are often developed by different teams, under different timelines, with less security review. They frequently have weaker authentication, missing authorization checks, and more verbose error messages.

bash — Mobile App Analysis Workflow

# Step 1: Download the APK (Android) from APKPure or similar
# Or pull it directly from a connected Android device
adb shell pm list packages | grep target
adb shell pm path com.target.app
adb pull /data/app/com.target.app-1.apk ./target.apk

# Step 2: Decompile the APK with jadx
jadx -d ./target_decompiled ./target.apk

# Step 3: Search for hardcoded secrets in the decompiled code
grep -r -iE "api_key|secret|password|token|endpoint" ./target_decompiled/

# Step 4: Find all API endpoints referenced in the app
grep -r -E "https?://[a-zA-Z0-9./\-_]+" ./target_decompiled/ | sort -u

# Step 5: Intercept mobile traffic with Burp Suite
# Configure Android emulator to use Burp as proxy
# Install Burp's CA certificate on the device
# For apps with certificate pinning, use Frida to bypass it
frida -U -f com.target.app -l ssl_pinning_bypass.js --no-pause

# Step 6: Use MobSF for automated static analysis
docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf

3. Shodan & Censys: Finding Forgotten Infrastructure

Shodan and Censys are search engines for internet-connected devices and servers. They continuously scan the entire internet and index everything they find. For bug bounty hunters, they are invaluable for finding infrastructure that doesn't show up in DNS — forgotten servers, exposed databases, and misconfigured services that the target's security team doesn't even know about.

bash — Shodan & Censys Recon Queries

# ── Shodan CLI Queries ─────────────────────────────────────
# Find all servers associated with the target's ASN
shodan search "org:Target Company"

# Find exposed databases (MongoDB, Elasticsearch, Redis)
shodan search "org:Target Company port:27017"  # MongoDB
shodan search "org:Target Company port:9200"   # Elasticsearch
shodan search "org:Target Company port:6379"   # Redis

# Find servers with specific SSL certificate common names
shodan search "ssl.cert.subject.cn:*.target.com"

# Find servers running specific software versions
shodan search "hostname:target.com product:Jenkins"

# ── Censys CLI Queries ─────────────────────────────────────
# Find all hosts with target.com in their TLS certificate
censys search "parsed.names: target.com" --index-type certificates

# Find exposed admin panels
censys search "services.http.response.html_title: admin AND autonomous_system.name: Target"

# ── Using the Shodan API with Python ──────────────────────
python3 -c "
import shodan
api = shodan.Shodan('YOUR_API_KEY')
results = api.search('ssl.cert.subject.cn:*.target.com')
for result in results['matches']:
    print(result['ip_str'], result.get('hostnames', []))
"

4. Parameter Discovery with Arjun

Most endpoints accept more parameters than they advertise. Hidden parameters are a goldmine for finding privilege escalation, debug modes, and undocumented functionality. Arjun is a tool specifically designed to discover hidden HTTP parameters by testing thousands of common parameter names against each endpoint.

bash — Parameter Discovery with Arjun

# Discover hidden GET parameters on a single endpoint
arjun -u "https://api.target.com/v1/users" -m GET

# Discover hidden POST parameters
arjun -u "https://api.target.com/v1/users/update" -m POST

# Run Arjun against a list of endpoints
arjun -i all_endpoints.txt -oJ arjun_results.json

# Example output — these hidden parameters are worth testing:
[+] Parameters found for https://api.target.com/v1/users:
    GET: role, admin, debug, internal, export, format, include_deleted

# Now test the 'role' parameter for privilege escalation
curl -s -H "Authorization: Bearer YOUR_USER_TOKEN" \
     "https://api.target.com/v1/users?role=admin" | python3 -m json.tool

# Test the 'debug' parameter for information disclosure
curl -s -H "Authorization: Bearer YOUR_USER_TOKEN" \
     "https://api.target.com/v1/users?debug=true" | python3 -m json.tool

# Test the 'include_deleted' parameter for data exposure
curl -s -H "Authorization: Bearer YOUR_USER_TOKEN" \
     "https://api.target.com/v1/users?include_deleted=true" | python3 -m json.tool

---

📄 Five More Real-World Examples

Theory is useful, but examples are what make methodology stick. Here are five more real-world cases that illustrate exactly how the focused recon approach finds bugs that the shotgun approach misses.

📄 Example 1 — E-commerce Platform

IDOR in Order Management API — $2,200

The target was a large e-commerce platform. After focused subdomain discovery, I identified api.target.com as a high-value target. Endpoint discovery revealed /api/v2/orders/{id}. Manual testing in Burp showed that the order IDs were sequential integers. By incrementing the ID in the request, I could access any customer's order details — including their shipping address, payment method (last 4 digits), and order history. The authorization check was completely missing on the GET endpoint, even though it was present on the PUT endpoint.

📄 Example 2 — SaaS Platform

Hardcoded AWS Key in React Bundle — $3,200

During JavaScript analysis of a SaaS platform's React application, a grep for AKIA (the prefix for AWS access key IDs) returned a hit in the main JavaScript bundle. The key had been hardcoded by a developer who was testing S3 uploads and forgot to remove it before deploying to production. The key had s3:GetObject, s3:PutObject, and s3:ListBucket permissions on the company's main data bucket, which contained customer data for all of their clients.

📄 Example 3 — Healthcare App

Broken Object Level Authorization in Patient Records — $5,000

A healthcare application had a mobile app that communicated with a separate API backend. After decompiling the APK with jadx, I found references to an API endpoint /api/mobile/v1/patients/{patientId}/records that wasn't documented anywhere in the web application. Intercepting the mobile app's traffic with Burp and testing the endpoint with a different patient's ID returned their full medical records. The mobile API had no BOLA (Broken Object Level Authorization) protection at all.

📄 Example 4 — Financial Services

Exposed Elasticsearch Instance via Shodan — $1,500

A Shodan search for the target company's ASN with port 9200 (Elasticsearch) revealed an Elasticsearch instance that was publicly accessible with no authentication. The instance contained an index with customer transaction data — names, account numbers, and transaction amounts. The server wasn't in the company's DNS records and wouldn't have been found through subdomain enumeration. It was only discoverable through infrastructure scanning.

📄 Example 5 — Developer Tools Platform

GitHub Dork Reveals Production Database Password — P1

A GitHub dork — org:target-company filename:database.yml — returned a repository that a junior developer had accidentally made public. The repository contained a config/database.yml file with the production PostgreSQL database hostname, username, and password. The credentials were still valid. The database contained the full user table, including hashed passwords and API keys for all customers. The developer had made the repository private within hours of creating it, but the file was still accessible in the Git history.

---

🔧 Essential Tool Reference

Every tool in this methodology has a specific, well-defined purpose. The goal is not to use all of them — it is to use the right ones at the right time. Here is a complete reference for the tools mentioned in this article.

subfinder

Fast passive subdomain enumeration using multiple data sources including crt.sh, AlienVault, and more.

Subdomain Discovery

amass

OWASP's comprehensive attack surface mapping tool. Best used in passive mode for focused recon.

Subdomain Discovery

httpx

Fast HTTP toolkit for probing live hosts with tech detection, status codes, and title extraction.

HTTP Probing

gospider

Fast web spider written in Go. Crawls targets and extracts URLs, JS files, and form endpoints.

Web Crawling

gau

Fetches known URLs from Wayback Machine, Common Crawl, and URLScan for historical endpoint discovery.

Historical URLs

LinkFinder

Discovers endpoints in JavaScript files using AST parsing. Works on minified and obfuscated code.

JS Analysis

SecretFinder

Finds sensitive data (API keys, tokens, credentials) in JavaScript files using regex patterns.

Secret Detection

Arjun

HTTP parameter discovery tool. Tests thousands of parameter names to find hidden parameters on any endpoint.

Parameter Discovery

ffuf

Fast web fuzzer written in Go. Use for directory discovery, parameter fuzzing, and IDOR testing.

Fuzzing

truffleHog

Searches Git repositories for high-entropy strings and known secret patterns across commit history.

GitHub Dorking

jadx

Dex to Java decompiler. Decompiles Android APKs into readable Java source code for analysis.

Mobile Analysis

Burp Suite

The industry-standard web application security testing platform. Non-negotiable for manual testing.

Manual Testing

---

🏆 The Takeaway

If you are running ten different recon tools, collecting thousands of subdomains, and not finding bugs — you are making this mistake. The solution is not more tools. It is not better wordlists. It is not even more automation.

It is slowing down and actually understanding what you are looking at.

The hunters who consistently find critical vulnerabilities and earn the highest bounties are not the ones with the most tools or the fastest automation pipelines. They are the ones who take the time to understand their targets deeply — who read the JavaScript, who use the application manually, who think about the business logic, and who ask "what would happen if I tried this?" instead of "what does my scanner say?"

Run fewer commands. But understand every line of their output. Quality over quantity is not a cliché in bug bounty hunting — it is literally the difference between wasting time and getting paid. The next time you start a new target, resist the urge to fire up every tool in your arsenal. Instead, pick two, understand what they find, and then actually look at what you've discovered.

The best tool in your arsenal is not subfinder, not nuclei, not Burp Suite. It is your brain — and the only way to use it effectively is to give it something manageable to work with. Focus is the skill that separates good hunters from great ones.

Essential Tool GitHub Repositories

Tool	Category	Repository
subfinder	Subdomain Discovery	github.com/projectdiscovery/subfinder
amass	Subdomain Discovery	github.com/owasp-amass/amass
httpx	HTTP Probing	github.com/projectdiscovery/httpx
gospider	Web Crawling	github.com/jaeles-project/gospider
ffuf	Fuzzing	github.com/ffuf/ffuf
gau	Historical URLs	github.com/lc/gau
Arjun	Parameter Discovery	github.com/s0md3v/Arjun
LinkFinder	JS Analysis	github.com/GerbenJavado/LinkFinder
SecretFinder	Secret Detection	github.com/m4ll0k/SecretFinder
truffleHog	GitHub Dorking	github.com/trufflesecurity/trufflehog
jadx	Mobile Analysis	github.com/skylot/jadx

Happy hunting. Remember: sometimes the best tool in your arsenal is simply doing less — but understanding it completely.