| name | reconnaissance-planning |
| description | Strategic reconnaissance planning for external attack surface management. Use when starting a new engagement, choosing initial scan strategy, or deciding how to expand coverage after initial results. |
Reconnaissance Planning
When to Use
- Starting a new ASM engagement against a target
- Deciding scan strategy after initial enumeration
- Expanding coverage when initial results are sparse
- Pivoting approach based on discovered infrastructure
Phased Approach
Phase 1: Passive Discovery (Low Noise)
Start with passive techniques to map the target without generating traffic.
Subdomain Enumeration:
run_bbot_scan(targets=["target.com"], presets=["subdomain-enum"], flags=["passive"])
This queries certificate transparency logs, DNS databases, archive.org, and OSINT sources without touching the target directly.
What to look for after Phase 1:
- Total number of discovered subdomains (establishes scale)
- Naming conventions (numbered patterns like
app01, srv02 suggest more exist)
- Cloud providers visible in DNS (CNAME to AWS, Azure, GCP)
- Mail infrastructure (MX records, SPF/DKIM)
- Development/staging indicators in subdomain names
Phase 2: Active Enumeration (Moderate Noise)
Probe discovered assets to understand what's running.
Web service detection + technology fingerprinting:
run_bbot_scan(targets=["target.com"], presets=["subdomain-enum", "web-basic"])
Port scanning on key IPs:
run_bbot_scan(targets=["10.0.0.1"], modules=["portscan"], config=["modules.portscan.ports=top_1000"])
What to look for after Phase 2:
- HTTP services on non-standard ports
- Technology stack patterns (is everything Rails? Is there one random PHP app?)
- Login pages, admin panels, API documentation
- SSL certificate details (org names, SANs with more domains)
- Default pages or error pages revealing server versions
Phase 3: Targeted Deep Scanning (Focused)
Focus on high-value targets identified in Phase 2.
Vulnerability scanning on interesting hosts:
run_bbot_scan(targets=["api.target.com"], presets=["nuclei"])
Web spidering on complex applications:
run_bbot_scan(targets=["app.target.com"], presets=["spider"], config=["web.spider_distance=2", "web.spider_depth=3"])
Screenshot collection for visual triage:
run_bbot_scan(targets=["target.com"], modules=["gowitness"], presets=["subdomain-enum"])
Cloud resource enumeration:
run_bbot_scan(targets=["target.com"], presets=["cloud-enum"])
Phase 4: Expansion & Synthesis
- Cross-reference findings across phases using graph queries
- Look for patterns: shared infrastructure, common technologies, consistent misconfigurations
- Identify assets that warrant manual investigation
- Build the final areas-of-interest list
Decision Tree: Choosing Scan Strategy
Is this a new target with no prior data?
├── YES → Start with Phase 1 (passive subdomain-enum)
└── NO → Do you have subdomains but no service info?
├── YES → Run web-basic + tech-detect
└── NO → Do you have services but no vuln data?
├── YES → Run nuclei on interesting hosts
└── NO → Focus on graph analysis and synthesis
Scale Considerations
| Target Size | Approach |
|---|
| Single domain | kitchen-sink preset covers everything |
| Small org (< 50 subdomains) | Full phased approach, thorough coverage |
| Medium org (50-500 subdomains) | Passive first, then targeted active scans on high-value assets |
| Large org (500+ subdomains) | Passive + selective active, prioritize by naming/business context |
Common Pitfalls
- Going too broad too early: Don't run
kitchen-sink on a large target. You'll drown in data.
- Ignoring the graph: Running scans without querying results between phases wastes cycles.
- Scanning out of scope: Always use
--whitelist or --strict-scope for targets with clear boundaries.
- Missing API keys: Many passive modules (Shodan, SecurityTrails, etc.) need API keys configured in bbot.yml. Check if they're set before relying on passive results.