Post cover image

October 25, 2026

Day 1: VAPT Foundations | Passive Reconn and Mapping

By Ishant

8 min read

Day 1: Passive Reconnaissance | 7-Day VAPT / OSCP Foundations Guide

A quick framing note:_ 7 days will get your basics in order and give you a methodology, but it is not OSCP readiness. Think of it as the foundation you build the real 2 to 4 month prep on. Each day has a study list, hands-on practice, and an article angle, so the series writes itself as you learn._

Welcome to Day 1. Today we cover passive reconnaissance, the phase where you map a target without sending a single packet to it. Skip it or rush it, and everything downstream (scanning, exploitation, reporting) suffers. Garbage recon means missed hosts, and missed hosts mean missed findings.

What passive recon actually is

Passive recon means gathering information without sending traffic to the target's own systems. You query third parties instead: DNS resolvers, search engines, certificate logs, Shodan, archive.org, GitHub.

Mode You touch Example Passive Third-party databases only crt.sh, Shodan search, Google dorks, whois Semi-passive Public resolvers, maybe one normal page load DNS via 8.8.8.8 Active The target's infrastructure nmap, dir bruteforce, nikto

The golden rule: if a packet's destination IP belongs to the target, it's active. If it goes to Google, Cloudflare DNS, Shodan, crt.sh or archive.org, it's passive.

Most of a target's useful attack surface can be mapped before you touch it: forgotten staging servers, leaked credentials in GitHub, old backups in the Wayback Machine, email formats, and tech stack versions with known CVEs. Passive recon tells you where the active phase is worth your time.

Stay legal. Reading public data is generally fine, but scope still defines what you may attack. Never log into target services during recon, never use breach data outside a written, authorized test, and if you stumble on PII or private keys, note their existence and report through proper channels rather than downloading or sharing them. Practice on your own domains and bug bounty scopes.

The workflow

Run it in this order, and loop back whenever new data appears:

Scope check → DNS → Subdomains → Certificates → IP/ASN →
Search & archives → Shodan/Censys → People & email →
Code & docs → Cloud & mobile → Synthesis

Recon is a loop, not a checklist. A new subdomain from CT logs sends you back to DNS, which leads to Shodan, which reveals a new ASN, which reveals more domains.

Phase 1: DNS recon

DNS is the one place where the target volunteers its infrastructure map.

dig target.com A +short
dig target.com MX +short
dig target.com TXT +short
dig target.com NS +short
dig target.com SOA +short
dig -x 203.0.113.10 +short          # reverse DNS
dig axfr target.com @ns1.target.com # zone transfer (almost always refused, but try)
# Everything at once with dnsx
echo target.com | dnsx -a -aaaa -cname -mx -txt -ns -soa -srv -resp -silent# Ownership
whois target.com
whois -h whois.cymru.com " -v 203.0.113.10"   # IP → ASN

What each record tells you:

  • MX: the mail provider (Google, M365, Proofpoint).
  • TXT: SPF include: entries are a vendor map, and verification tokens reveal SaaS tools (Atlassian, Zoom, Docusign). A missing SPF is a spoofing finding.
  • CNAME: pointing at a deleted Heroku/S3/Azure resource means subdomain takeover.
  • SOA: the admin email and a serial number. Check the serial weekly, since a bump means something changed.
  • PTR: naming like db-01.dc2.target.com leaks internal structure.

Think differently: old TXT verification tokens reveal vendor history, and DNS history tools (SecurityTrails) show what a domain resolved to years ago. Old IPs sometimes still host old, vulnerable servers.

Phase 2: Subdomain enumeration

This is the highest-ROI passive phase. Forgotten dev, staging, and legacy apps live here.

subfinder -d target.com -all -silent -o subs.txt
amass enum -passive -d target.com -o amass.txt
assetfinder --subs-only target.com | sort -u > assetfinder.txt
curl -s "https://crt.sh/?q=%25.target.com&output=json" | jq -r '.[].name_value' | sed 's/\*\.//g' | sort -u > crt.txt
# Merge, dedupe, resolve via public resolvers
cat subs.txt amass.txt assetfinder.txt crt.txt | sort -u > combined.txt
dnsx -l combined.txt -a -resp -silent -o resolved.txt# Wildcard check
echo "nonexistent-$(date +%s).target.com" | dnsx -a -resp -silent# Offline permutations: dev2-api, old-portal, etc.
alterx -l combined.txt | dnsx -silent

Add free API keys (Shodan, Censys, VirusTotal, SecurityTrails, Chaos) to subfinder's config and -all finally earns its name.

Where to look first: dev-*, staging-*, test-* (weaker auth, verbose errors), jenkins.*, gitlab.*, jira.* (exposed internal tools), vpn.*, remote.* (access portals), and legacy-* or old-* (unpatched, no WAF).

Think differently: acquisitions are gold. A press release naming an acquired company points to domains whose security is often two years behind the parent (check scope first). Also, group your resolved IPs by ASN and look for other domains the same org owns on that ASN.

Phase 3: Certificate Transparency logs

Every publicly trusted TLS certificate is published to append-only public logs. A subdomain that had HTTPS for a single day in 2021 is still searchable. That's why crt.sh finds what subdomain tools miss.

# Newest certs first: find recent deployments
curl -s "https://crt.sh/?q=%25.target.com&output=json" \
  | jq -r '.[] | "\(.not_before) \(.name_value)"' | sort -r | head -40

Tricks worth learning:

  • Date-sort the output. Subdomains first seen this month are new deployments, and new usually means rushed and misconfigured.
  • Read the SAN field, not just the CN. One cert grouping 50 hostnames reveals shared infrastructure.
  • Monitor, don't just query. certspotter can alert you the moment a new cert appears.
  • Join CT with Shodan. Take a cert's fingerprint, search it in Shodan or Censys, and find every IP serving it, including ones with no DNS pointing at them.

Phase 4: IP, ASN and infrastructure

Hostnames are marketing, IPs are reality.

whois -h whois.cymru.com " -v 203.0.113.10"
curl -s ipinfo.io/203.0.113.10
amass intel -org "Target Inc"
amass intel -asn 12345
echo 203.0.113.0/24 | mapcidr -silent   # offline IP math

Also use bgp.he.net for prefixes and BGP history. ASN pivoting is the key move here: take one IP, get its ASN, list every prefix, and reverse-DNS the range offline. You'll find hosts with no forward DNS at all. If the target is on AWS or GCP, their IP ranges are published as JSON, which narrows down where the target could be.

Phase 5: Search engines and archives

Google indexed the target's mistakes years ago, and the Wayback Machine kept pages they deleted.

site:target.com inurl:admin
site:target.com filetype:pdf
site:target.com filetype:env | filetype:log | filetype:bak | filetype:sql
site:target.com "index of /"
"target.com" password | api_key | secret
echo target.com | waybackurls > wayback.txt
echo target.com | gau --subs --blacklist woff,woff2,svg,png,jpg,css -o gau.txt
curl -s "https://urlscan.io/api/v1/search/?q=domain:target.com" | jq -r '.results[].result'\\

The best passive technique in bug bounty: pull app.js from a 2022 snapshot and a 2024 snapshot, then diff them. Endpoints removed from the frontend often still work on the server.

Also try:

  • urlscan.io is free recon someone else paid for. Open a scan and read the Requests tab for API endpoints and third-party domains.
  • Archived robots.txt history reveals hidden paths over time.
  • A subdomain that 404s today but served a Heroku app in 2021 is a takeover candidate with proof of what it pointed to.

Phase 6: Shodan, Censys and FOFA

Someone already scanned the internet. You just read their results.

shodan search --fields ip_str,port,hostnames,org "ssl:target.com"
shodan host 203.0.113.10
shodan search "org:\"Target Inc\" -port:80 -port:443"

Core queries: ssl:target.com, org:"Target Inc", asn:AS12345, http.title:"...", http.favicon.hash:<hash>.

Two pivots to learn cold:

  1. Search the cert, not the domain. ssl:target.com finds IPs with no DNS: dev servers, forgotten cloud instances, and the origin server hiding behind Cloudflare.
  2. The favicon hash. Hash a favicon (murmur3), search http.favicon.hash:, and you find every server running the same app, including the target's forgotten Jenkins on a random VPS.

Negative search is underrated: -port:80 -port:443 shows everything that isn't the website, and the weird stuff lives there. Censys (services.tls.certificates.leaf_data.names) and FOFA (cert="target.com") are great when Shodan misses something.

Phase 7: People and email OSINT

The humans are part of the attack surface.

theHarvester -d target.com -b all -l 500 -f harvest.html
curl -s "https://api.hunter.io/v2/domain-search?domain=target.com&api_key=KEY" \
  | jq '.data.emails[] | "\(.value) \(.type)"'

The email pattern ({first}.{last}@, {f}{last}@) is the real prize. Breach data (haveibeenpwned) tells you which breaches hit the org, and the password culture it implies. In an authorized test that informs spraying wordlists, but never use breach credentials outside written authorization.

Read job postings like architecture documents. "Okta + CrowdStrike + Sentinel engineer" just told you their identity provider, EDR, and SIEM. Other good sources:

  • Ex-employee LinkedIn histories show what the legacy stack was, which is often what it still is.
  • Conference talks sometimes include architecture diagrams.
  • git log on a public company repo shows commit emails that confirm the format.

Phase 8: Code, secrets and metadata

org:targetorg filename:.env
"internal.target.com"
"target.com" "jdbc:"
git clone https://github.com/targetorg/some-public-repo.git
trufflehog filesystem ./some-public-repo --only-verified
gitleaks detect --source ./some-public-repo -v
exiftool document.pdf   # Author, Creator, Producer, CreateDate

--only-verified checks whether a key works against the provider (AWS, GitHub), not the target, so a verified hit is reportable immediately.

Think differently: git log -p shows secrets that were removed later, since the old commit still has the key. Deleted repos often survive in forks. Gists and Pastebin hold configs pasted for debugging. And PDF metadata (j.smith, Word 2016) confirms username formats and outdated software on employee machines.

Phase 9 and 10: Cloud and mobile

Cloud: search GrayHatWarfare for public buckets by keyword, and grep your subdomain list for s3|bucket|storage|assets|backup. Archived JS is the bucket map, because frontend code references S3, Azure Blob, and Firebase URLs by name. Learn the naming convention from one bucket (target-prod-backup), then permute it offline like subdomains.

Mobile: store listings expose permissions, developer emails, and privacy policies. Download APKs from mirrors and analyze them offline:

apktool d app.apk -o app-out
strings app.apk | grep -iE "https?://[a-z0-9.-]*target[a-z0-9.-]*" | sort -u

The app's API base URL often differs from the website's, which gives you a whole second API surface. Old APK versions can have old endpoints that still work.

Phase 11: Synthesis, the part most people skip

Ten phases of raw data is noise until you correlate it:

  1. Merge all hostnames, IPs, netblocks, emails, tech, and cloud assets.
  2. Tag each: web / api / infra / mail / cloud / people / legacy / new.
  3. Attach what Shodan and Censys already know (ports, versions).
  4. Mark confidence. CT log plus DNS resolution is high; a single-source mention needs verification.
  5. Remove duplicates and out-of-scope items. Reverse-IP neighbours are not the target.

Then prioritize: forgotten subdomains with old tech, recent certs, admin panels on odd ports, takeover candidates, public buckets, old API versions in archived JS, and finally everything else by CVE match.

Write the attack narrative, not a list. "Dev subdomain on an old Laravel → old API version in archived JS → S3 bucket with backups → email format from breach data" is a story. Stories get taken seriously. And note the negative space: no SPF, no DMARC, no security.txt, and wildcard DNS say a lot about security culture.

Automation (after you learn the manual way)

Frameworks like recon-ng, SpiderFoot, Maltego CE, and BBOT (bbot -t target.com -p passive) do the typing for you. Learn the phases first, because frameworks miss things and sometimes pull in out-of-scope noise. Always sanity-check their output against your manual DNS and subdomain results.

OPSEC for the operator

  • Use a separate browser profile and a research email for API keys.
  • Keep your VPN on. Even legal activity shouldn't put your home IP in someone's logs.
  • API keys are identity, since Shodan, Censys and VT log queries per key.
  • Never log into the target.
  • Save everything (screenshots, JSON), because passive sources change.
  • Keep one notes folder per target: target.com/recon/{dns,subs,ct,shodan,people,code,report}.md.

Day 1 hands-on checklist

Task Done when DNS deep dive dig + dnsx + whois on 3 domains, findings table filled Subdomain enum subfinder + amass passive + crt.sh merged, wildcard check done CT + infra crt.sh date-sorted, ASN mapped, neighbours listed Archives + dorks 20 dorks, wayback + gau + urlscan, one JS diff Shodan/Censys 15 queries, one favicon-hash pivot People + code theHarvester run, email format found, 3 repos scanned, 5 PDFs through exiftool Synthesis One prioritized recon report on a single target

Honestly, that table is more than one day of work if you do it properly. Do a first pass today and finish it through the week. Your own domains and bug bounty scopes (passive only) are the right targets.

Interview one-liners

  • Passive vs active? Passive queries third parties and never touches the target. Active sends packets to it.
  • How do you find hosts with no DNS? Shodan cert search, favicon hash pivots, and ASN prefix enumeration with reverse DNS.
  • What's your workflow? DNS, subdomains, CT, ASN, archives, Shodan, people, code, cloud, then synthesis. Loop on new data.
  • What do you do with breach data? Analyze password patterns for the report, and never use it outside written authorization.

Takeaways

  1. Passive recon is third-party queries only, so no packets reach the target.
  2. Never rely on one source. Merge, dedupe, and resolve.
  3. CT logs and archives are permanent. Deleted doesn't mean gone.
  4. Search certs and favicons in Shodan to find assets with no DNS.
  5. Correlate, don't collect. One forgotten Jenkins beats 10,000 unread subdomains.

Tomorrow, Day 2: active scanning and enumeration, where the asset list you built today decides where the nmap time goes. To connect just ping me on instagram at @ishant_ix or linkedin at @ishant-g

If this helped, follow me, Every post might be a good knowhow on Red Teaming:>>

Embedded content