🛰️ Reconnaissance Methodology

Reconnaissance Methodology

Reconnaissance is inventory work. The goal is not to find a vulnerability — it is to end up with a defensible list of everything that carries the organisation's name and faces the internet: hostnames, addresses, services, technologies, certificates and the humans responsible for each one. Attackers do this because they are looking for the one asset nobody remembered. Defenders do it because the asset nobody remembered is theirs.

Almost every finding in a real engagement traces back to something that was not on anybody's list: a staging host from a project that shipped two years ago, an old marketing subdomain still pointed at a decommissioned cloud bucket, a forgotten admin panel on a non-standard port. None of those are clever exploits. They are inventory failures.

Passive versus active — where the line actually sits

The distinction is not "safe versus dangerous". It is whose systems receive your packets.

• Passive reconnaissance queries third parties that already hold information about the target. The target's own servers see nothing. You are talking to a registry, a certificate transparency log, a search engine, an archive.
• Active reconnaissance sends traffic to infrastructure the target controls. Their web server, their authoritative nameserver, their firewall, their WAF — all of them can and usually do log it, with your source address attached.

Two nuances that trip people up. First, resolving a name through a public resolver is normally passive, but a query for a record that is not cached will be forwarded to the target's authoritative nameserver, and their DNS logs will show it — attributed to the resolver, not to you, but it is still traffic they caused to receive. Second, passive does not mean lawful. Scraping, harvesting personal data, or aggregating information about individuals can breach data-protection law and platform terms regardless of how quiet it was. Quiet is not the same as permitted.

Passive sources, and what each is actually good for

Why certificate transparency changed subdomain enumeration

Certificate Transparency (RFC 6962; version 2 is specified in RFC 9162) has publicly trusted certificate authorities submit every certificate they issue to public, append-only logs. Chrome has required CT compliance for certificates issued since 30 April 2018, and other major browsers followed, so in practice a publicly trusted certificate that is not logged will not be accepted by browsers. That means the subjectAltName list of essentially every public certificate is a matter of public record.

The consequence for recon: you no longer have to guess subdomains. vpn-test.example.com, jira-internal.example.com and kubernetes-dashboard.example.com will be in the logs the moment somebody requests a certificate for them — even if those names never appear in public DNS. Brute-force wordlists still have a place for names that never got a certificate, but CT is the first stop. The one blind spot is wildcards: a certificate for *.example.com discloses exactly one name. Search certificate transparency →

Active reconnaissance, and what it costs you

• Resolution of candidates. Take the CT hostname list and find out which names still resolve, and to what. Names that resolve to a cloud provider's address but return a "no such bucket / no such app" error are potential subdomain takeovers — a dangling CNAME is one of the most common high-severity findings in bug bounty.
• Port and service scanning. A TCP connect scan completes the handshake, so it is reliable and unambiguously logged. Every closed-port attempt may hit an IDS threshold; every open-port connection lands in an application log.
• Banner grabbing. Reading the greeting a service sends on connect (SSH version string, SMTP 220 banner, HTTP Server header). Cheap, and often the fastest route to a version number.
• Web fingerprinting. Response headers, cookie names, error page wording, framework-specific paths and JavaScript bundles identify the stack without any exploitation.

The output: an attack-surface inventory

Findings that stay in a terminal scrollback are not results. The deliverable is a table, and every row should be answerable by a human owner:

A worked order of operations using the tools on this page

Steps 1–6 are passive. Step 7 sits on the boundary — resolution reaches the target's authoritative nameservers, even though the request goes via a resolver. From step 8 on you are sending traffic to the target: do not go past that line without authorisation.

1. Scope first. Write down the domains, addresses and applications you are permitted to touch, and the source of that permission, before running anything.
2. Registration and ownership. WHOIS / RDAP → for registrar, dates, nameservers and lock status.
3. Full DNS picture. Run a DNS audit → to pull every record type at once, then read the TXT records for suppliers and the MX records for the mail provider.
4. Hostnames from CT. Certificate transparency search →. Deduplicate, and keep the wildcard entries as a note that names are hidden.
5. Network context. Prefix and origin ASN → tells you whether an address belongs to the organisation, a hosting provider or a CDN. This changes who owns the risk and who you would need to notify.
6. Public leakage. Build search-engine queries → for indexed files and exposed paths, and generate look-alike domains → to check whether somebody is impersonating the brand.
7. Resolve the candidates. DNS lookup → each hostname from step 4. Note dangling CNAMEs pointing at unclaimed third-party resources.
8. Reachable services. Port scan → one authorised host at a time, and measure TCP latency → if you need to tell a filtered port from a slow one. For a thorough scan on your own network, build the nmap command → and run it from your own machine.
9. Web layer. Header and redirect analysis →, technology fingerprint →, and WAF / CDN detection → so you know whether you are looking at the origin or an edge.
10. Find the contact. security.txt lookup →. Do this early — you may need it sooner than you expect.
11. Obvious exposures. Sensitive path check → for .git, .env, backups and status endpoints. Actively probing, authorised targets only.
12. Keep it alive. Batch certificate expiry → over the final hostname list turns a one-off exercise into monitoring. For a fast first pass over a single domain, the recon sweep → runs most of the passive steps in one request.

Scoping: "it resolved to their IP" is not authorisation

The most common way a well-intentioned researcher gets into trouble is scope drift. Guard against it:

• A shared address is not the target's address. Scanning a CDN or shared-hosting IP means scanning infrastructure belonging to a provider and, potentially, hundreds of unrelated tenants. The provider's acceptable-use policy governs, and the target cannot waive it on their behalf.
• Cloud addresses are recycled. An address that answered for the target this morning may belong to a different customer this afternoon. Re-resolve before every session; test names, not stale addresses.
• Wildcard scope has edges. *.example.com in a bug bounty policy routinely includes CNAMEs pointing at third-party SaaS. The organisation can authorise testing of its own systems; it cannot authorise testing of its vendor's.
• Related domains are not in scope by default. A brand-protection domain, an acquisition, or a country variant is a separate asset with separate ownership until somebody puts it in writing.
• Volume is part of scope. A scan aggressive enough to degrade a service turns a permitted test into an availability incident. Agree rates and hours.

Passive recon on a target you have no relationship with is generally unremarkable; the moment you send packets to their infrastructure you need permission. Details are in Authorisation, Ethics & Disclosure.