Post cover image

August 24, 2026

Basic → Intermediate → Advanced | Authorized Bug Bounty & Security Testing

Scope: Use this workflow only against assets you own or targets explicitly authorized by a bug-bounty/security-testing program. Respect…

By Rakesh Joshi

10 min read

Scope:_ Use this workflow only against assets you own or targets explicitly authorized by a bug-bounty/security-testing program. Respect scope, rate limits, robots.txt/program rules, and avoid destructive testing._

0.Recon Methodology

A mature reconnaissance workflow should progressively move from:

Scope → Passive Recon → DNS → Subdomains → Hosts → HTTP → Ports → URLs → Content → Parameters → Technologies → Historical Assets → Exposure → Validation → Continuous Monitoring

The objective is not simply to collect thousands of assets.

The objective is to build an accurate attack-surface inventory and identify the assets most likely to contain security-relevant weaknesses.

1. Phase 0 — Define Scope

Before running any tool:

  • Read the bug-bounty/security-testing policy.
  • Identify in-scope root domains.
  • Identify in-scope subdomains.
  • Identify excluded assets.
  • Identify excluded vulnerability classes.
  • Check whether automated scanning is allowed.
  • Check allowed request rates.
  • Check whether port scanning is allowed.
  • Check whether authentication testing is allowed.
  • Record third-party services that are explicitly excluded.
  • Record program-specific reporting requirements.

Create a workspace:

mkdir -p recon/{scope,subdomains,dns,hosts,ports,http,urls,content,params,tech,js,history,reports}
cd recon

Create a target file:

echo "example.com" > scope/domains.txt

2. Phase 1 — Passive Recon

Start with information that does not directly interact with the target.

2.1 WHOIS

whois example.com

Look for:

  • Registrar
  • Registration dates
  • Nameservers
  • Organization information
  • Registrar changes
  • Related domains

3. Search Engine Recon

Search for publicly indexed assets.

Useful queries:

site:example.com
site:*.example.com
site:example.com login
site:example.com api
site:example.com admin
site:example.com dev
site:example.com staging
site:example.com filetype:pdf
site:example.com filetype:json
site:example.com filetype:xml

Look for:

  • Login portals
  • API documentation
  • Development environments
  • Staging environments
  • Forgotten applications
  • Public documents
  • Exposed directories
  • Legacy applications

Do not treat search-engine results as proof that an asset is currently live.

4. Certificate Transparency Recon

Certificate Transparency is one of the highest-value passive sources for discovering subdomains.

Useful sources/tools include:

  • crt.sh
  • Censys
  • Certificate Transparency logs
  • SecurityTrails
  • Amass

Example:

curl -s "https://crt.sh/?q=%25.example.com&output=json"

Extract names:

curl -s "https://crt.sh/?q=%25.example.com&output=json" \
  | jq -r '.[].name_value' \
  | sed 's/\*\.//g' \
  | sort -u \
  > subdomains/cert.txt

Checklist:

  • Extract certificate names.
  • Remove wildcard prefixes.
  • Normalize names.
  • Deduplicate.
  • Compare against existing enumeration.

5. Phase 2 — Subdomain Enumeration

Use multiple independent sources.

5.1 Subfinder

subfinder -d example.com -all -recursive -o subdomains/subfinder.txt

For multiple domains:

subfinder -dL scope/domains.txt -all -recursive \
  -o subdomains/subfinder.txt

5.2 Assetfinder

assetfinder --subs-only example.com > subdomains/assetfinder.txt

5.3 Amass

Passive:

amass enum -passive -d example.com \
  -o subdomains/amass.txt

More comprehensive enumeration where permitted:

amass enum -d example.com \
  -o subdomains/amass-active.txt

Use active enumeration only when permitted by the target's rules.

6. Merge Subdomains

Combine all sources:

cat subdomains/*.txt \
  | sed 's/^\*\.//' \
  | sort -u \
  > subdomains/all.txt

Count:

wc -l subdomains/all.txt

7. Subdomain Intelligence

Categorize discovered names.

Search for patterns:

grep -Ei 'dev|development|test|testing|stage|staging|uat|qa|prod|production' \
  subdomains/all.txt

Also search:

grep -Ei 'api|admin|internal|vpn|portal|auth|login|dashboard|mail|git|jenkins|grafana' \
  subdomains/all.txt

Prioritize:

High-interest names

api.example.com
admin.example.com
internal.example.com
dev.example.com
staging.example.com
uat.example.com
test.example.com
auth.example.com

These names are not vulnerabilities by themselves. They are reconnaissance signals.

8. Phase 3 — DNS Resolution

Use dnsx.

dnsx -l subdomains/all.txt \
  -silent \
  -o dns/resolved.txt

Collect records:

dnsx -l subdomains/all.txt \
  -a -aaaa -cname -mx -ns \
  -resp \
  -o dns/records.txt

Check:

  • A records
  • AAAA records
  • CNAME records
  • MX records
  • NS records
  • TXT records

9. CNAME Investigation

Look for interesting third-party CNAMEs:

grep -Ei 'amazonaws|cloudfront|azure|github|heroku|vercel|netlify|fastly|cloudflare' \
  dns/records.txt

Investigate whether the service is:

  • Active
  • Properly configured
  • Owned by the organization
  • Explicitly in scope

Do not attempt to claim or hijack infrastructure unless the program explicitly authorizes that type of testing.

10. DNS Wildcard Detection

Test random names:

dig random-nonexistent-12345.example.com

If arbitrary names resolve, determine whether wildcard DNS exists.

Wildcard DNS can produce false positives during enumeration.

11. Phase 4 — HTTP Discovery

Feed resolved hosts into httpx.

httpx -l dns/resolved.txt \
  -silent \
  -o http/live.txt

Collect useful metadata:

httpx -l dns/resolved.txt \
  -status-code \
  -title \
  -tech-detect \
  -web-server \
  -ip \
  -follow-redirects \
  -silent \
  -o http/httpx.txt

Useful information:

URL
Status code
Title
Technology
Web server
IP
Redirect

12. Build a Live Host Inventory

Example:

httpx -l dns/resolved.txt \
  -silent \
  -status-code \
  -title \
  -tech-detect \
  -o http/inventory.txt

Prioritize:

  • 200 responses
  • 3xx redirects
  • 401 authentication portals
  • 403 restricted applications
  • 500-series responses
  • APIs
  • Admin interfaces
  • Development systems

Do not automatically assume a 403 is vulnerable.

13. Technology Fingerprinting

Use:

httpx -l dns/resolved.txt \
  -tech-detect \
  -silent \
  -o tech/httpx-tech.txt

Look for:

  • Framework
  • CMS
  • JavaScript framework
  • Web server
  • CDN
  • WAF
  • Cloud provider
  • API framework
  • Authentication technology

Examples:

Next.js
React
Angular
Vue
Laravel
Django
Rails
WordPress
Nginx
Apache
CloudFront
Cloudflare

14. Phase 5 — Port Discovery

Only perform port scanning where explicitly permitted.

Naabu

naabu -list dns/resolved.txt \
  -top-ports 100 \
  -o ports/top100.txt

For a broader scan, if permitted:

naabu -list dns/resolved.txt \
  -p 1-65535 \
  -o ports/full.txt

Prioritize:

80
443
8080
8000
8008
8443
8888
3000
5000
9000

Do not assume a non-standard port is an application vulnerability.

15. Nmap Validation

Use Nmap to validate interesting ports:

nmap -sV -Pn -p 80,443,8080,8443 target.example.com

Where permitted, service detection can provide:

Port
State
Service
Version

Avoid aggressive scanning unless explicitly allowed.

16. Phase 6 — URL Discovery

This is one of the most valuable recon phases.

Use:

  • Katana
  • GAU
  • Wayback URL discovery
  • Common Crawl
  • Burp Suite
  • Browser traffic

17. Katana

Basic crawl:

katana -u https://example.com \
  -silent \
  -o urls/katana.txt

For a known list:

katana -list http/live.txt \
  -silent \
  -o urls/katana.txt

Where supported and permitted, increase crawl depth carefully rather than immediately using maximum settings.

Collect:

  • Paths
  • Forms
  • JavaScript
  • Links
  • APIs
  • Query parameters

18. GAU

Gather known URLs:

gau example.com > urls/gau.txt

For multiple domains:

cat scope/domains.txt | gau > urls/gau.txt

19. Wayback URL Discovery

waybackurls example.com > urls/wayback.txt

Historical URLs can reveal:

  • Removed endpoints
  • Legacy APIs
  • Old parameters
  • Previous applications
  • Old JavaScript
  • Deprecated functionality

20. Merge URLs

cat urls/*.txt \
  | sort -u \
  > urls/all.txt

Count:

wc -l urls/all.txt

21. Normalize URLs

Remove unnecessary duplicates.

sort -u urls/all.txt > urls/unique.txt

Extract interesting extensions:

grep -Ei '\.(js|json|xml|txt|conf|config|bak|zip|sql|log|env)(\?|$)' \
  urls/unique.txt

Treat sensitive-looking files as leads, not automatic findings.

22. Phase 7 — JavaScript Recon

JavaScript often exposes the application's actual client-side attack surface.

Find JavaScript:

grep -Ei '\.js(\?|$)' urls/unique.txt \
  > js/files.txt

Download only where permitted.

Inspect for:

  • API endpoints
  • Routes
  • GraphQL endpoints
  • Feature flags
  • Environment names
  • Third-party integrations
  • Public configuration
  • Authentication flows

23. JavaScript Endpoint Extraction

Useful tools:

  • LinkFinder
  • SecretFinder
  • xnLinkFinder
  • ripgrep
  • Burp Suite

Example:

rg -n "https?://|/api/|graphql|swagger|openapi" js/

Search for common route patterns:

rg -n '"/api/|"/v[0-9]+/|/graphql|/admin|/internal' js/

24. Secret Detection

Search JavaScript and public repositories for accidentally exposed credentials.

Useful tools:

  • Gitleaks
  • TruffleHog
  • SecretFinder

Example:

gitleaks detect --source . --no-banner

Important:

A string resembling a secret is not automatically a valid credential.

Validate responsibly without abusing the credential.

25. Phase 8 — API Recon

Identify:

/api/
/api/v1/
/api/v2/
/graphql
/swagger
/swagger.json
/openapi.json
/docs

Search:

grep -Ei 'api|graphql|swagger|openapi' urls/unique.txt

For each API, document:

  • Endpoint
  • HTTP method
  • Authentication
  • Parameters
  • Object identifiers
  • Roles
  • Response format
  • Rate limits
  • Error behavior

26. API Attack-Surface Mapping

Build an endpoint table:

EndpointMethodAuthParameterObjectPriority/api/usersGETYes—UserHigh/api/users/{id}GETYesidUserHigh/api/orders/{id}GETYesidOrderHigh/api/searchGETNoqSearchMedium

Focus security testing on authorization boundaries rather than blindly fuzzing everything.

27. Phase 9 — Parameter Discovery

Extract query parameters:

grep '?' urls/unique.txt

Useful categories:

id
user
user_id
account
account_id
file
path
url
redirect
next
return
callback
query
search
page
sort
filter

Create a parameter inventory.

Then classify:

Object references

id=
user_id=
account_id=
order_id=
document_id=

Navigation

url=
redirect=
next=
return=
callback=

File handling

file=
path=
filename=
download=

Search/input

q=
query=
search=
filter=

28. Phase 10 — Content Discovery

Where allowed, use:

  • ffuf
  • feroxbuster
  • gobuster

Example:

ffuf -u https://example.com/FUZZ \
  -w wordlist.txt \
  -mc 200,204,301,302,307,401,403

Look for:

admin
api
backup
old
test
dev
staging
uploads
static
assets
docs
swagger

Do not use extremely aggressive thread counts against production infrastructure.

29. Virtual Host Discovery

Where explicitly permitted, investigate alternate virtual hosts.

Conceptually:

Host: FUZZ.example.com

Potential discoveries:

internal.example.com
dev.example.com
staging.example.com
legacy.example.com

Be careful with rate limits and false positives caused by wildcard routing.

30. Phase 11 — WAF/CDN Identification

Use:

wafw00f https://example.com

Identify:

  • Cloudflare
  • AWS WAF
  • Akamai
  • Fastly
  • Imperva
  • Other reverse proxies

This is useful for understanding architecture and avoiding misleading scan results.

31. Phase 12 — Historical Attack Surface

Compare:

Current assets vs historical assets

Search:

  • Wayback Machine
  • Certificate Transparency
  • SecurityTrails
  • Common Crawl
  • Passive DNS
  • GitHub
  • Search engines

Look for:

old.example.com
v1.example.com
legacy.example.com
dev.example.com
staging.example.com
api-v1.example.com

Historical infrastructure can expose forgotten attack surfaces.

32. Phase 13 — Cloud Recon

Identify cloud infrastructure from:

  • DNS
  • CNAMEs
  • HTTP headers
  • TLS certificates
  • JavaScript
  • Public documentation

Potential providers:

AWS
Azure
Google Cloud
Cloudflare
Vercel
Netlify
Heroku
DigitalOcean

Document:

Asset
Provider
Service
Relationship
Evidence
Scope

Never attempt unauthorized cloud-resource takeover.

33. Phase 14 — GitHub / Public Repository Recon

Search public repositories associated with the organization.

Look for:

  • API endpoints
  • Subdomains
  • Infrastructure files
  • Docker configurations
  • Terraform
  • CI/CD configurations
  • Old domains
  • Public keys
  • Accidentally committed secrets

Useful tools:

GitHub search
Gitleaks
TruffleHog
GitRob

Do not access private repositories or private data without authorization.

34. Phase 15 — Technology-Specific Recon

Once technologies are identified, branch the workflow.

WordPress

Check:

/wp-content/
/wp-includes/
/wp-json/

GraphQL

Identify:

/graphql
/api/graphql

Swagger/OpenAPI

Identify:

/swagger
/swagger.json
/openapi.json

Next.js

Look for:

/_next/

Laravel

Look for application-specific routes and error behavior.

Django

Identify:

/admin/

Do not assume framework fingerprints imply a vulnerability.

35. Phase 16 — Automated Vulnerability Triage

After the attack surface is mapped, use scanners carefully.

A common tool is Nuclei.

nuclei -l http/live.txt \
  -o reports/nuclei.txt

For specific templates:

nuclei -l http/live.txt \
  -tags exposure \
  -o reports/exposure.txt

Use only templates appropriate to the authorized scope.

The correct workflow is:

Scanner finding → Manual verification → Evidence → Impact assessment

Never report a scanner result without validation.

36. Phase 17 — Prioritize the Attack Surface

Create a scoring system.

Tier 1 — Critical Recon Targets

  • Production API
  • Authentication service
  • Admin application
  • Payment functionality
  • Account management
  • File upload functionality
  • Object-management APIs
  • Internal-facing applications accidentally exposed

Tier 2

  • Staging
  • Development
  • UAT
  • Legacy applications
  • Documentation portals
  • Monitoring dashboards

Tier 3

  • Static assets
  • Marketing pages
  • Public blogs
  • CDN assets

37. High-Value Recon Signals

Pay special attention to:

/api/
admin
internal
staging
dev
uat
legacy
debug
graphql
swagger
openapi
upload
download
redirect
callback
oauth
sso
webhook

These are priority indicators, not vulnerabilities.

38. Phase 18 — Authentication Surface Mapping

Identify:

  • Login
  • Registration
  • Password reset
  • MFA
  • OAuth
  • SSO
  • Session management
  • API tokens
  • Invitation flows
  • Account recovery

Map relationships:

User
 ↓
Authentication
 ↓
Session
 ↓
API
 ↓
Objects
 ↓
Authorization

This becomes especially important for authorization testing.

39. Phase 19 — Authorization Recon

For each important object:

User
Organization
Project
Invoice
Order
Document
Message
File
API key

Record:

  • Object identifier
  • Owning user
  • Organization
  • Role
  • Read operation
  • Update operation
  • Delete operation
  • Administrative operation

This produces an authorization attack-surface map.

40. Phase 20 — File and Upload Surface

Identify:

/upload
/import
/export
/attachments
/media
/documents
/avatar

Record:

  • File type restrictions
  • Content validation
  • Storage location
  • Download endpoint
  • Authorization
  • Filename handling
  • Public/private access
  • Processing pipeline

Test only within the program's permitted boundaries.

41. Phase 21 — Redirect / Callback Surface

Find:

redirect=
url=
next=
return=
callback=
continue=
target=

These deserve review because they frequently participate in authentication and navigation flows.

42. Phase 22 — WebSocket Recon

Look for:

ws://
wss://

Record:

  • WebSocket endpoint
  • Authentication
  • Connection authorization
  • Message format
  • Object identifiers
  • Role restrictions

43. Phase 23 — GraphQL Recon

Map:

Endpoint
Queries
Mutations
Objects
Arguments
Authentication
Authorization

Look for:

users
accounts
organizations
projects
orders
documents

Test authorization boundaries carefully rather than performing destructive mutations.

44. Phase 24 — Build the Final Asset Database

Your final dataset should look approximately like:

Domain
 ├── Subdomain
 │    ├── IP
 │    ├── Ports
 │    ├── HTTP status
 │    ├── Technologies
 │    ├── URLs
 │    ├── Parameters
 │    ├── APIs
 │    ├── JavaScript
 │    └── Historical evidence

Example:

api.example.com
├── IP: 203.0.113.10
├── 443/tcp
├── Nginx
├── API
├── /api/v1/users
├── /api/v1/orders
├── /graphql
└── authentication: OAuth

Beginner

whois
dig
nslookup
crt.sh
Subfinder
httpx

Workflow:

Scope
 ↓
Subfinder
 ↓
DNS
 ↓
httpx
 ↓
Manual inspection

Intermediate

Subfinder
Amass
Assetfinder
dnsx
httpx
Naabu
Nmap
Katana
GAU
Waybackurls
ffuf
Wappalyzer
WAFW00F

Workflow:

Domains
 ↓
Subdomains
 ↓
DNS
 ↓
Live Hosts
 ↓
Ports
 ↓
Technologies
 ↓
URLs
 ↓
Parameters
 ↓
Content

Advanced

Amass
Subfinder
dnsx
httpx
Naabu
Nmap
Katana
GAU
Waybackurls
ffuf
Nuclei
Gitleaks
TruffleHog
LinkFinder
SecretFinder
Burp Suite
Cloud enumeration tools
Passive DNS
Certificate Transparency

Advanced workflow:

┌── Certificate Transparency
                    ├── Passive DNS
                    ├── Search Engines
                    ├── GitHub
Scope ──────────────┼── Amass/Subfinder
                    └── Historical Sources
                            │
                            ▼
                    Subdomain Inventory
                            │
                            ▼
                         DNSx
                            │
                            ▼
                    Live Asset Inventory
                            │
             ┌──────────────┼──────────────┐
             ▼              ▼              ▼
          HTTPx          Naabu           Nmap
             │              │              │
             └──────────────┼──────────────┘
                            ▼
                    Technology Mapping
                            │
             ┌──────────────┼──────────────┐
             ▼              ▼              ▼
          Katana           GAU        Wayback
             │              │              │
             └──────────────┼──────────────┘
                            ▼
                       URL Database
                            │
             ┌──────────────┼──────────────┐
             ▼              ▼              ▼
          JS Recon      API Recon      Content
             │              │              │
             └──────────────┼──────────────┘
                            ▼
                    Parameter Inventory
                            │
                            ▼
                     Nuclei Triage
                            │
                            ▼
                    Manual Validation
                            │
                            ▼
                     Vulnerability

46. One Practical Recon Pipeline

For an authorized program, a compact pipeline can look like:

subfinder -d example.com -all -recursive -silent \
  -o subdomains.txt
dnsx -l subdomains.txt -silent \
  -o resolved.txt
httpx -l resolved.txt \
  -silent \
  -status-code \
  -title \
  -tech-detect \
  -follow-redirects \
  -o http.txt
katana -list resolved.txt \
  -silent \
  -o katana.txt
gau example.com > gau.txt
waybackurls example.com > wayback.txt
cat katana.txt gau.txt wayback.txt \
  | sort -u > urls.txt
nuclei -l http.txt \
  -o nuclei.txt

Treat this as a pipeline skeleton, not a universal one-liner. Each program's scope, rate limits, and allowed automation should determine what you actually run.

47. Daily Recon Checklist

Scope

  • Scope reviewed
  • Exclusions reviewed
  • Rate limits confirmed

Assets

  • New domains
  • New subdomains
  • New IPs
  • New ports
  • New HTTP services

Applications

  • New technologies
  • New APIs
  • New JavaScript
  • New endpoints
  • New parameters

Historical

  • New certificates
  • New historical URLs
  • New legacy hosts
  • New repository references

Security Triage

  • Exposed services reviewed
  • Authentication surfaces reviewed
  • Authorization surfaces mapped
  • Sensitive endpoints reviewed
  • Scanner findings manually validated

48. Advanced Recon Mindset

Do not ask only:

"What subdomains does this company have?"

Ask:

Asset questions

What exists?
What recently appeared?
What disappeared?
What changed?
What is forgotten?

Architecture questions

What talks to what?
Which services share infrastructure?
Where is authentication handled?
Where are APIs hosted?
Which services are third-party?

Application questions

Which endpoints handle objects?
Which endpoints change state?
Which endpoints cross trust boundaries?
Which endpoints handle files?
Which endpoints handle identities?

Historical questions

What did this organization expose six months ago?
Which old API versions still exist?
Did a staging environment become publicly reachable?
Did infrastructure move providers?

49. Recon Quality Metrics

A mature recon operation should measure:

Subdomains discovered
        ↓
DNS-resolved assets
        ↓
Live HTTP services
        ↓
Open ports
        ↓
Unique URLs
        ↓
Unique endpoints
        ↓
Unique parameters
        ↓
Unique technologies
        ↓
High-value assets
        ↓
Validated findings

The goal is not maximum enumeration volume.

The goal is:

Maximum useful attack-surface coverage with minimum unnecessary traffic.

50. Final Recon Checklist

  • Scope documented
  • Root domains collected
  • Passive sources queried
  • Certificate Transparency checked
  • Subfinder completed
  • Amass completed where appropriate
  • Assetfinder completed
  • Subdomains normalized
  • DNS resolved
  • DNS records collected
  • CNAME relationships reviewed
  • Live HTTP services identified
  • HTTP status codes collected
  • Technologies fingerprinted
  • Ports identified where authorized
  • Services validated
  • URLs collected
  • Historical URLs collected
  • JavaScript identified
  • API endpoints identified
  • Swagger/OpenAPI identified
  • GraphQL identified
  • Parameters extracted
  • Content discovery performed where allowed
  • Authentication surfaces mapped
  • Authorization objects mapped
  • File-upload surfaces identified
  • Redirect/callback surfaces identified
  • WebSocket endpoints identified
  • Cloud relationships documented
  • Public repositories reviewed
  • Secrets checked responsibly
  • Nuclei/scanner findings triaged
  • False positives removed
  • High-value assets prioritized
  • Evidence collected
  • Findings manually validated
  • Final attack-surface inventory generated

51. The Complete Mental Model

RECON
                           │
              ┌────────────┴────────────┐
              │                         │
          PASSIVE                    ACTIVE
              │                         │
     ┌────────┼────────┐        ┌───────┼────────┐
     │        │        │        │       │        │
   CT Logs  OSINT   GitHub     DNS    HTTP     Ports
     │        │        │        │       │        │
     └────────┴────────┴────────┴───────┴────────┘
                           │
                           ▼
                    ASSET INVENTORY
                           │
                           ▼
                  APPLICATION MAPPING
                           │
          ┌────────────────┼────────────────┐
          │                │                │
         APIs             JS             Content
          │                │                │
          └────────────────┼────────────────┘
                           ▼
                    PARAMETER MAP
                           │
                           ▼
                 AUTHORIZATION MAP
                           │
                           ▼
                   SECURITY TRIAGE
                           │
                           ▼
                  MANUAL VALIDATION
                           │
                           ▼
                     REPORT / FIX

Core principle: reconnaissance is an iterative process, not a single scan. The strongest workflow continuously correlates DNS + HTTP + ports + URLs + JavaScript + APIs + technologies + historical data + organizational relationships into one attack-surface graph.