Pen Testing Recon Methodology

New pen testers want to skip to the exploit. I get it — popping a shell is the fun part, the part that looks like the movies. But in a real engagement, exploitation is maybe ten percent of the work. The other ninety percent is reconnaissance, and if you do recon well, the exploit tends to fall out of it almost for free. Do it badly, and you'll spend three days brute-forcing something that a single DNS query would have handed you.

Here's the recon workflow I actually run, roughly in the order I run it. It maps to the early phases of PTES (the Penetration Testing Execution Standard) and the reconnaissance tactics in MITRE ATT&CK.

Passive first. Always.

Passive reconnaissance means gathering information without sending a single packet to the target's infrastructure. Nothing to detect, nothing to log, nothing that tips your hand. You'd be amazed how much of an engagement can be completed before you touch anything the client controls.

• WHOIS and DNS history — who owns what, and what the records used to point at.
• Certificate transparency logs — every TLS cert ever issued for a domain is public. This leaks subdomains people forgot existed.
• Search engine dorking — targeted queries that surface exposed files, login portals, and error messages.
• Public code and job listings — a job posting for a "Senior Django engineer with AWS and PostgreSQL" just told me your stack.

Subdomain enumeration

The attack surface is almost never the main website. It's the staging server, the forgotten marketing microsite, the admin panel on a subdomain nobody remembered to decommission. Amass is my workhorse here because it combines passive sources with active resolution.

$ amass enum -passive -d target.com -o subs.txt
$ dnsx -l subs.txt -resp-only          # resolve live hosts
$ httpx -l subs.txt -title -tech-detect # what's alive + running

That three-command chain turns a domain name into a live inventory of hosts, their titles, and the technologies they run. From here the interesting targets basically announce themselves: the one running an outdated CMS, the dev instance with debug mode on, the login page with no rate limiting.

Active scanning, carefully

Now I start touching things — with authorization in hand. Nmap for the port and service landscape, then targeted scanning with Nuclei to check live hosts against a huge library of known-vulnerability templates.

$ nmap -sV -sC -p- --min-rate 1000 target.com
$ nuclei -l live_hosts.txt -severity critical,high

The -sC flag runs Nmap's default scripts, which quietly do a surprising amount of enumeration for you. Nuclei's value is coverage — it checks thousands of known issues in the time it would take me to manually check ten.

The web layer

For web apps, Burp Suite becomes the center of gravity. I proxy all traffic through it, map the application, and start looking at how it handles input, authentication, and access control. This is where automated tools stop earning their keep and manual testing takes over — business-logic flaws don't show up in a scanner.

Scanners find what's known. You get paid to find what isn't.

Documentation as you go

The mistake that separates amateurs from professionals isn't tooling — it's notes. Every host, every version number, every interesting response goes into a running log with timestamps. When it's time to write the report, half of it is already done. When the client asks "how did you find this," you have the exact command and output.

Why recon wins engagements

The best exploit is the one you didn't have to invent. Most successful compromises in real engagements come from something mundane that recon surfaced: default credentials, an exposed .git directory, an unpatched service on a forgotten host. If you find that in the recon phase, you're not writing an exploit — you're just walking in. That's what thorough reconnaissance buys you: fewer heroics, more results.

If you want a recon-led assessment of your own attack surface, that's exactly how I start every pen test.

The forgotten-asset problem

Here's a pattern I hit on almost every engagement: the vulnerability isn't in the flagship product the client is proud of and has hardened. It's in the thing they forgot they owned. A staging environment stood up for a demo two years ago and never torn down. A subdomain pointing at a marketing tool that was cancelled but never removed — now vulnerable to subdomain takeover. An S3 bucket from an old campaign, still public. Recon exists to find these ghosts, because attackers absolutely will.

This is why passive certificate-transparency mining is so valuable. Every time anyone issued a TLS certificate for any hostname on the domain — including internal tools somebody quickly HTTPS-enabled and forgot — it's permanently logged in public CT logs. I've found admin panels, VPN gateways, and internal dashboards this way that no amount of guessing would have surfaced. The organization didn't know those hosts were discoverable. They always are.

Scope discipline is part of recon

One thing that separates professional reconnaissance from reckless poking: you constantly cross-check what you find against the agreed scope. Recon surfaces assets, but not every asset you discover is yours to touch. A subdomain might belong to a third-party SaaS provider, not the client. Testing it would be attacking someone who never authorized you. So part of the recon workflow is classification — which of these assets are in scope, which are out, and which need explicit clarification before I go near them. Good recon expands what you can see and sharpens what you're allowed to test. Both matter.