Reconnaissance

Introduction

Reconnaissance is the foundation of every pentest. Before you touch a target system, you need to understand what you’re looking at. Imagine you are a journalist researching a company — you gather public information without alerting your subject.

Always obtain written, explicit authorization before beginning any reconnaissance. Even passive OSINT can violate terms of service if conducted against systems outside your authorized scope.

The attacker’s perspective at this layer: you know only what’s publicly visible — domain names, IP ranges, employees, technologies, documents left exposed in search engines. Your goal is to build a mental map of the attack surface without generating noise.

Passive OSINT

Purpose of the Test

Passive OSINT (Open Source Intelligence) means gathering information about a target using only publicly available sources — no direct contact with the target’s systems whatsoever. Think of it as reading everything the internet knows about your target before making any direct requests.

Impact

If an attacker can gather useful intelligence without triggering alerts, they can:

• Identify high-value employees for phishing campaigns
• Discover exposed credentials in public repositories
• Map the full technology stack and versions before attacking
• Find forgotten subdomains or staging environments with weaker security

Expected Outcomes

Positive finding: Sensitive information publicly accessible — employee names/roles, internal email formats, leaked credentials on GitHub, infrastructure details in job postings.

Clean result: Minimal surface area, no exposed sensitive data, email formats not guessable, no code repositories with secrets.

Ethical Considerations

• Only query public sources (search engines, DNS records, GitHub, LinkedIn, Shodan)
• Do not impersonate employees or create fake profiles
• Document every source and what you found — the trail matters
• Hard stops: Discovering credentials that appear to be real and active → stop immediately, do not test them, report to client

Testing Flow

flowchart LR
    A["LLM ideation"]
    B["Human review"]
    C["Passive queries only"]
    D["Document findings"]
    A --> B --> C --> D

Manual Testing Steps

1. Confirm written authorization covers OSINT activities
2. Record the in-scope domains and IP ranges
3. Query WHOIS for registrant data (whois example.com)
4. Search LinkedIn for employee names, roles, and technologies
5. Search GitHub for the company name, domain, and related keywords
6. Check Shodan/Censys for exposed services on known IP ranges
7. Use theHarvester to aggregate emails and names
8. Check for exposed documents via search engine operators
9. Document all findings with source URLs and timestamps

AI-Assisted Testing

How AI Helps Here

AI excels at synthesizing large amounts of public data, generating targeted search queries, and helping you structure raw OSINT into an organized picture of the target. AI should never perform the queries itself against live targets — it helps you plan what to look for.

Prompt Template — Search Query Generation

[ROLE] Senior OSINT analyst assistant
[TARGET] Company: Acme Corp, Domain: acme.com, Sector: financial services
[TASK] Generate a structured OSINT collection plan.
  - Public data sources only (no direct target contact)
  - Include: search engine operators, GitHub dork queries, LinkedIn search strategies
  - Prioritize finding: email format, technology stack, exposed subdomains, any public code repos
[OUTPUT FORMAT]
  - Categorized query list by source type
  - What each query aims to find
  - What a "positive finding" looks like for each query
[CONSTRAINTS] Passive sources only. No automated scanning. No credential testing.

Prompt Template — OSINT Findings Synthesis

[ROLE] Senior security analyst
[FINDINGS] Raw OSINT notes: [paste your collected data]
[TASK] Synthesize these findings into a structured recon summary.
  - Identify the most significant exposures
  - Map relationships between findings (e.g., leaked email format + employee names = phishing risk)
  - Prioritize by likely attacker value
[OUTPUT FORMAT]
  - Executive summary (2-3 sentences)
  - Key findings table: finding, source, risk level
  - Recommended follow-up tests for active phase
[CONSTRAINTS] White-hat framing throughout. Flag any findings that require immediate client notification.

AI Hard Stops for This Topic

• [NO] Never ask AI to perform live queries against target systems
• [NO] Discard AI output that suggests accessing non-public systems
• [NO] Never input real credentials discovered into AI prompts
• [YES] Use AI to plan queries, then execute manually and review results yourself
• [YES] Run all AI-suggested search queries through your own judgment before executing

Tools Reference

Resources

• OSINT Framework
• theHarvester
• Shodan

Subdomain Enumeration

Purpose of the Test

Many organizations expose far more attack surface than they realize through forgotten subdomains — old staging environments, legacy APIs, development servers, or acquired company infrastructure. Subdomain enumeration finds these doors before an attacker does.

Impact

Forgotten subdomains often have:

• Older software versions with known CVEs
• Weaker authentication (or none at all)
• Debug modes or verbose error messages left enabled
• Direct database access intended for internal use only

Expected Outcomes

Positive finding: Subdomains resolving to unexpected IPs, wildcard DNS misconfiguration, staging or dev environments accessible publicly, subdomains with admin panels exposed.

Clean result: Only documented subdomains resolve; staging environments require authentication or are IP-restricted.

Ethical Considerations

• Only enumerate subdomains of in-scope domains
• Passive DNS enumeration (certificate logs, public datasets) is lower risk than active brute-forcing
• Confirm subdomain ownership before testing — a subdomain may belong to a third-party SaaS
• Hard stop: If a subdomain appears to be a customer’s separate environment, stop and confirm scope with client

Testing Flow

flowchart LR
    A["LLM ideation"]
    B["Human review"]
    C["Passive cert/DNS queries"]
    D["Limited active wordlist"]
    E["Document"]
    A --> B --> C --> D --> E

Manual Testing Steps

1. Verify the root domain is explicitly in scope
2. Query Certificate Transparency logs: curl https://crt.sh/?q=%.example.com&output=json
3. Use passive DNS datasets (SecurityTrails, Censys)
4. Run amass enum -passive -d example.com for passive enumeration
5. Cross-reference results with known infrastructure
6. For active enumeration (if in scope): subfinder -d example.com
7. For each discovered subdomain: resolve IP, check HTTP response, check TLS cert
8. Flag any subdomain resolving to cloud provider IP that isn’t in the scope documentation

AI-Assisted Testing

Prompt Template — Subdomain Analysis

[ROLE] Security researcher assistant
[INPUT] List of discovered subdomains and their HTTP response codes: [paste list]
[TASK] Analyze this subdomain inventory for security relevance.
  - Identify patterns suggesting staging/dev/admin environments
  - Flag subdomains with unusual response codes (403, 401, 500, 200 on non-standard ports)
  - Identify potential subdomain takeover candidates (NXDOMAIN pointing to cloud services)
[OUTPUT FORMAT]
  - Priority triage: high / medium / low interest per subdomain
  - Reasoning for each priority
  - Suggested next manual verification steps
[CONSTRAINTS] Analysis only — no automated probing suggestions.

AI Hard Stops for This Topic

• [NO] Do not brute-force DNS without explicit written scope permission
• [NO] Never test subdomains that resolve to IPs outside the authorized range
• [NO] Do not test subdomains belonging to third-party SaaS providers
• [YES] Passive CT log queries are always safer than active DNS brute-forcing
• [YES] Confirm each discovered subdomain’s ownership before testing

Tools Reference

Resources

• crt.sh
• Amass
• Subfinder

Tech Stack Fingerprinting

Purpose of the Test

Knowing what software versions are running tells you which CVEs to check. Tech stack fingerprinting is about reading the labels on the jars before opening them.

Impact

Identified technology stack enables:

• Targeted CVE research against specific versions
• Default credential testing for known admin panels
• Version-specific exploit path planning
• Identifying EOL (end-of-life) software still in production

Expected Outcomes

Positive finding: Outdated software versions with known CVEs, version information exposed in HTTP headers, default framework error pages visible, robots.txt revealing internal paths.

Clean result: No version information in headers, generic error pages, no technology indicators in response bodies.

Ethical Considerations

• Fingerprinting via passive observation of responses is low-risk
• Do not send exploit payloads during fingerprinting
• Record every version identified with the evidence source
• Hard stop: If you identify a critical CVE during fingerprinting, stop exploitation, document and report immediately

Testing Flow

flowchart LR
    A["LLM ideation"]
    B["Human review"]
    C["Passive header/response analysis"]
    D["Document versions"]
    E["CVE research"]
    A --> B --> C --> D --> E

Manual Testing Steps

1. Send a basic HTTP request and analyze response headers: curl -I https://example.com
2. Look for: Server, X-Powered-By, X-AspNet-Version, X-Generator
3. Check page source for framework meta tags, JS library filenames with versions
4. Check robots.txt and sitemap.xml for technology clues
5. Run whatweb https://example.com for automated fingerprinting
6. Check error pages by requesting a non-existent resource (/doesnotexist404)
7. Search identified versions against NVD (nvd.nist.gov) for CVEs

AI-Assisted Testing

Prompt Template — CVE Research from Fingerprint

[ROLE] Vulnerability research assistant
[STACK] Identified technologies: Apache 2.4.41, PHP 7.4.3, WordPress 5.8.2
[TASK] Research known CVEs and security issues for this stack.
  - Focus on critical and high severity (CVSS >= 7.0)
  - Identify any authentication bypass or RCE vulnerabilities
  - Suggest non-destructive verification methods for each CVE
[OUTPUT FORMAT]
  - CVE table: ID, CVSS, description, affected versions, patch version
  - Safe detection method per CVE (no exploitation)
  - Remediation recommendation
[CONSTRAINTS] Detection methods only — no exploit code, no weaponized payloads.

AI Hard Stops for This Topic

• [NO] Do not request exploit code from AI
• [NO] Never apply CVE exploits without written scope permission for exploitation testing
• [YES] Use AI for CVE research and detection verification planning only
• [YES] Always verify CVE applicability before escalating to a finding

Tools Reference

Resources

• WhatWeb
• NVD CVE Database
• Wappalyzer

Google Dorking

Purpose of the Test

Google Dorking uses advanced search operators to find information that is technically public but not intentionally indexed — exposed configuration files, database backups, login panels, and sensitive documents.

Impact

Effective dorking can reveal:

• Configuration files containing database credentials
• Exposed admin panels without authentication
• Internal documents indexed by mistake
• API keys and tokens committed to public GitHub repos

Expected Outcomes

Positive finding: Search results returning files like config.php, .env, database dumps, or admin panels publicly accessible without authentication.

Clean result: No sensitive files indexed; robots.txt properly blocking sensitive paths; no internal paths exposed in search results.

Ethical Considerations

• Google dorking itself uses only Google’s public index — no direct target contact
• Do not access any file or URL discovered via dorking without confirming it is in scope
• If you find credentials, do NOT test them — report immediately
• Hard stop: Discovering customer data in indexed files → stop, do not download, report immediately

Testing Flow

flowchart LR
    A["LLM ideation"]
    B["Human review"]
    C["Google queries only"]
    D["Document results (URLs only, no access)"]
    E["Report"]
    A --> B --> C --> D --> E

Manual Testing Steps

1. Confirm domain is in scope before running any dorks
2. Use site: operator to restrict to target domain: site:example.com
3. Search for exposed files: site:example.com filetype:env OR filetype:sql OR filetype:log
4. Search for admin panels: site:example.com inurl:admin OR inurl:login OR inurl:wp-admin
5. Search for sensitive configs: site:example.com "DB_PASSWORD" OR "API_KEY"
6. Check GitHub: org:example-corp "password" OR "secret" OR "api_key"
7. Document URL, search query, and what was found — do not click through to sensitive files
8. Report any discovered credentials immediately without testing them

AI-Assisted Testing

Prompt Template — Dork Generation

[ROLE] OSINT research assistant
[TARGET] Domain: example.com, Industry: healthcare SaaS
[TASK] Generate a targeted list of Google dork queries for this domain.
  - Focus on: exposed configs, admin interfaces, sensitive file types, credentials
  - Include GitHub-specific dorks for the organization
  - Prioritize by likelihood of finding something sensitive
[OUTPUT FORMAT]
  - Categorized dork list with search engine (Google / GitHub / Bing)
  - What each dork is looking for
  - What action to take if results are found (document only vs. report immediately)
[CONSTRAINTS] Search queries only — no instructions to access found content.

AI Hard Stops for This Topic

• [NO] Never ask AI to generate payloads for accessing systems discovered via dorks
• [NO] Do not access any URL discovered via dorking before confirming scope
• [NO] Never download files discovered via dorks (even if they appear to be public)
• [YES] Document the search result URL and finding summary only
• [YES] Report any credential discovery immediately without testing

Tools Reference

Resources

• Google Hacking Database (Exploit-DB)
• GitHub Dorking Guide
• OWASP Google Hacking

Comprehensive Information Targets

What to Look For

Where to Search

Public Datasets (Zero Target Contact)

Active Sources (Target Contact — Requires Authorization)

Stealth Techniques

Stealth Scanning Principles

flowchart LR
    A["Traditional Scanner\n1000 packets/second"] --> B["WAF alerts · IDS triggers · Log entries"]
    C["Stealth Scanner\n1 packet / 10 seconds over 3 hours"] --> D["Blends with legitimate traffic"]

Low-and-Slow Techniques

Active Recon Command Examples (Stealth)

# Nmap stealth scan — 20 packets per second max, random delays
nmap -sS -Pn -T2 --max-rate 20 --min-rate 5 --scan-delay 500ms \
      --max-scan-delay 5s --randomize-hosts -p 1-10000 target.com

# DNS brute-force with randomized timing
for sub in $(cat subdomains.txt); do
  sleep $(shuf -i 1-10 -n 1)  # Random 1-10 second delay
  dig $sub.target.com @8.8.8.8 +short
done

# HTTP probing with browser mimicry
curl -s -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36" \
     -H "Accept-Language: en-US,en;q=0.9" \
     --connect-timeout 5 \
     --retry 1 \
     https://target.com/admin

What Triggers Detection (Avoid These)

Social Engineering Recon

Pretext Development

Before any social interaction, build a believable persona:

Information to Gather Before Phishing

Who to Target in an Organization

Targeting Priority Matrix

High Value + Easy Access  →  EXECUTIVE ASSISTANTS, NEW HIRES
High Value + Hard Access  →  SYSADMINS, FINANCE
Low Value  + Easy Access  →  MARKETING, SALES
Low Value  + Hard Access  →  HR (note: DEVELOPERS are high value for code access)

Phishing Emails

Components of a Believable Phishing Email

Phishing Email Templates by Target

For IT Support Request (Target: General Employee)

Subject: Urgent: Microsoft 365 MFA Re-registration Required

From: IT Security <no-reply@acme-security.com>
To: [Employee]

Dear [First Name],

Our logs indicate your Multi-Factor Authentication (MFA) settings are out of
sync with our new security policies implemented [yesterday/today].

Please re-register your MFA device within 2 hours to avoid interruption:

  [Re-register MFA Device — LINK]

This is an automated security requirement. No further action needed after completion.

IT Security Team
[Real company signature block]

For Executive Assistant (Target: EA to CFO/CEO)

Subject: Urgent document for [CEO Name] signature

From: [Real Vendor Name] <contracts@vendor-partners.com>
To: [EA Name]

Hi [EA Name],

Attached is the revised MSA for [CEO Name]'s signature. The redline changes from
our previous discussion (Section 4.2 and 7.1) have been incorporated.

[CEO Name] mentioned this was time-sensitive. Please have them e-sign below:

  [Review and Sign Document — LINK]

The original executed copy will follow via FedEx.

Best,
Michael Chen | Account Executive | [Real Vendor Name] | (512) 555-0123

For Help Desk Phishing (Target: IT Support)

Subject: VPN connectivity issue — urgent

From: [Employee Name from LinkedIn] <[fake domain]>
To: helpdesk@target.com

Hi Help Desk,

I'm traveling and cannot connect to the VPN. I've tried restarting and
resetting my token. I'm on a deadline for the [Project Name] deliverable.

Error screenshot: [Screenshot of fake error — LINK]

My extension is [real extension if found].

Thanks,
[Real Employee Name] | [Real Title]

Phishing Landing Page Best Practices

Detection Avoidance for Phishing

OPSEC

Reduce Your Digital Footprint

The OPSEC Checklist

Before Any Action:

• Written authorization in hand (scope, duration, methods)
• Emergency stop contact identified
• Burner infrastructure prepared (VPS, VPN, domains)
• Testing environment isolated from personal identity
• Time window selected (avoid simultaneous with real incidents)

During Recon:

• No direct contact with target infrastructure before passive phase complete
• All queries via third-party services (Google cache, Archive.org, CT logs)
• Active scans scheduled during target’s low-monitoring hours (if known)
• Rates limited to blend with legitimate traffic
• User-agents rotated from real browser pools
• No simultaneous scans from same source
• Regular pauses (scan 10 min, wait 60 min)

After Session:

• All logs cleared from infrastructure
• Burner VPS destroyed
• Domains allowed to expire or repurposed
• No findings stored on personal devices (use encrypted, air-gapped storage)

Detection Indicators You Can’t Control

AI Assistance for Reconnaissance (Extended)

AI Prompt Template: Target Profiling

[ROLE] Senior OSINT analyst specializing in corporate reconnaissance
[TARGET] Company: {target_name}, Domain: {domain}, Industry: {industry}
[KNOWN DATA] {paste any existing intel}
[TASK] Generate a comprehensive intelligence collection plan.

Phase 1 — Passive OSINT (no target contact):
- Infrastructure: IP ranges, ASN, cloud providers, CDN, WAF
- Personnel: Key roles (C-suite, IT, Security, HR, Finance), naming patterns
- Technology: Stack fingerprinting sources (job posts, GitHub, Stack Overflow)
- Business: Subsidiaries, acquisitions, vendors, office locations
- Security: SPF/DKIM/DMARC, bug bounty, security.txt, breach history

Phase 2 — Low-Noise Active (requires authorization):
- Subdomain candidates based on naming patterns
- Port ranges most likely to be open (based on industry/stack)
- Service versions to probe for
- Directory structure patterns

For each data point, specify:
- Source to query (exact URL or tool)
- Search query string
- Expected output format
- False positive indicators
- Next step if found

[OUTPUT FORMAT] JSON with phases as keys, each containing array of query objects
[CONSTRAINTS] No automated scanning suggestions. No exploitation.
  Flag any finding requiring client notification.

AI Prompt Template: Phishing Target Selection

[ROLE] Social engineering engagement planner
[TARGET OSINT] {paste employee list, org structure, vendor relationships}
[TASK] Identify optimal phishing targets based on access, click likelihood, and detection risk.

For each candidate:
- Role and department
- Publicly available email (Y/N)
- Social media activity level
- Likely security awareness (based on role/title)
- Access value (what credentials provide)
- Best pretext (IT issue, vendor request, executive urgency)
- Estimated success probability
- Estimated detection risk

Rank by: (success_probability × access_value) / detection_risk

[OUTPUT FORMAT] Table with rankings, recommended pretext per target
[CONSTRAINTS] Educational/authorized testing only.
  No actual phishing without written authorization.

AI Prompt Template: Stealth Scan Planning

[ROLE] Red team infrastructure planner
[TARGET] IP ranges: {ranges}, Timezone: {tz}, Estimated monitoring: {low/medium/high}
[TASK] Generate a stealth scanning schedule that minimizes detection probability.

Parameters:
- Total ports to scan: {count}
- Available time window: {start} to {end} local time
- Maximum packets per minute: {rate}
- Available source IPs: {count}

Output:
- Day-by-day scan schedule with randomization
- Source IP rotation pattern
- Inter-probe delay distribution (mean, min, max)
- Port order randomization strategy
- Fallback if detection suspected

[CONSTRAINTS] All timing assumes authorized testing. Add 40% buffer to all estimates.

AI Prompt Template: Email Realism Analysis

[ROLE] Phishing email quality assurance reviewer
[DRAFT EMAIL] {paste your phishing email draft}
[TARGET CONTEXT] Industry: {industry}, Internal terms: {terms}, Sender names: {names}

[TASK] Analyze this email for realism and detection flags:

1. Red flags (technical): sender domain, SPF/DKIM implications, URL patterns
2. Red flags (behavioral): tone match, urgency level, request plausibility, timing
3. Suggested improvements: specific wording changes, context to add, elements to remove
4. Success likelihood: Low/Medium/High with reasoning

[OUTPUT FORMAT] Score each category 1–10, list specific fixes
[CONSTRAINTS] Educational use only. No actual sending without written authorization.

AI Hard Stops for AI-Assisted Recon

Recon Tools Matrix

Passive OSINT Tools (No Target Contact)

Low-Noise Active Tools (Requires Authorization)

Social Engineering Infrastructure

Legal and Ethical Boundaries (Reinforced)

Key Takeaways

1. Passive first, active last — Exhaust all passive sources before any direct contact.
2. Stealth is deliberate — Low-and-slow beats fast-and-loud every time.
3. Recon is continuous — Revisit findings as target changes over time.
4. People are the weakest link — Social engineering prep is as important as technical recon.
5. Document everything — Every query, source, and finding; your legal protection depends on it.
6. AI assists, doesn’t act — Use AI for planning and synthesis, not execution against live targets.
7. Know when to stop — Credentials found? Stop. Customer data exposed? Stop. Report immediately.