Passive reconnaissance and OSINT

Objective 2.1 in this course covers active and passive reconnaissance — CompTIA describes it as gathering information using open-source intelligence (OSINT), network sniffing and protocol scanning. This lesson takes the passive half; lesson 8 takes the active half.

Why this matters

Reconnaissance and Enumeration is 21% of PT0-003 — the second largest domain, and the one where the work actually starts.

Passive reconnaissance is also where the engagement's shape gets set. What you find here decides what you scan, what you attack, and often what the report's headline finding turns out to be. A tester who rushes this and goes straight to scanning ends up testing the assets the client remembered to tell them about, which are by definition the ones the client is already thinking about.

The lesson

What passive means, and where it stops being passive

The definition that matters: passive reconnaissance does not touch the target's systems. You are reading records that already exist, held by third parties who publish them.

The boundary is blurrier than it looks, and exam questions live exactly on it:

• Reading a search engine's cached copy of a page — passive.
• Loading that page from the client's own web server — active. You are now in their access log.
• Querying a public DNS resolver for records — usually treated as passive, since you are asking a third party.
• Querying the client's own authoritative name server directly — active.
• Browsing a certificate transparency log — passive.
• Connecting to a host to read its certificate — active.

Why it matters practically: passive work generates no evidence on the client's side, so it can often be done before the testing window opens if the authorisation permits. Active work belongs inside the window, in your activity log, and inside the scope.

Public records, certificate transparency and job adverts

The richest sources are ones the organisation publishes deliberately without thinking of them as disclosure.

• Certificate transparency logs. Every publicly-trusted certificate is logged, and the names on it are searchable. This is the single most productive source for finding hosts nobody remembered: staging environments, admin interfaces, internal-sounding names that resolve publicly.
• DNS and registration records. Name servers, mail servers, ownership and address ranges.
• Search engines, using operators to restrict to a domain and file type. Documents published years ago and forgotten are a recurring find.
• Job adverts, which are an infrastructure inventory written by the organisation and published on purpose. A posting asking for experience with a specific product, version and cloud platform has told you the stack.
• Code repositories, where credentials and internal hostnames leak in commit history far more often than in current files.
• Breach corpora, relevant because they tell you which of the organisation's addresses appear in past breaches — which is what makes the credential stuffing in lesson 25 plausible.

Building an organisation's footprint without touching it

The goal is an inventory you can hand to the scoping conversation: here is what appears to belong to you, and here is why I think so.

Work outward in layers. Start from what you were given — a domain, a company name. Expand to sibling and historical domains, then to the names on their certificates, then to the address ranges those names resolve into, then to who owns those ranges.

Two disciplines make the output usable:

• Record confidence separately from the finding. "This host is named in a certificate for your domain" is fact. "Therefore you own it" is inference, and it is wrong often enough to matter — shared hosting, CDNs and acquisitions all break it.
• Expect to find things the client does not know about. That is frequently the most valuable output of the whole engagement, and it belongs in the report whether or not it ends up in scope.

Anything you find that is not in scope gets reported as existing, and is not touched. Lesson 3's rule applies: the interest is the pressure the rule exists to resist.

People as an attack surface, and the ethics of naming them

Staff names, roles, email formats and public posts are all legitimate OSINT, and the email format alone enables most of Domain 4's authentication work.

This course puts two conditions on it, and they are professional rather than squeamish:

1. Collect roles and patterns, not dossiers. What the engagement needs is "the format is first.last@, and here are the departments with external-facing staff". It does not need someone's personal life, and material like that in a report is a liability to the client and to the individual.
2. Name people in a report only where the finding requires it. A finding about an exposed personal account needs the account. A finding about email format does not need the twelve people you confirmed it against.

Remember that these are the client's employees, and the report will be read by their management. A document that reads like a file on named individuals will damage the relationship even when every fact in it is accurate and public.

Recording provenance so a finding can be defended later

Every passive finding should carry where it came from and when.

This matters more than it sounds, because passive sources change under you. Certificate logs get new entries, DNS changes, cached pages are re-crawled, repositories get cleaned. A finding you cannot re-demonstrate is a finding you will lose an argument about — and "it was there last Tuesday" is not evidence.

So for each item: the source, the exact query or URL, the timestamp, and the raw result saved. It costs seconds at the time and it is the difference between a defensible report and an assertion.

It also feeds the activity log from lesson 3. When the client asks what you did before the window opened, this is the answer.

What to take into the exam

• Passive means not touching the target's systems; know which side of that line each technique sits on.
• Certificate transparency is the highest-yield source for unknown hosts.
• Job adverts and repositories are self-published infrastructure inventories.
• Separate fact from inference about ownership — a name on a certificate is not proof of ownership.
• Out-of-scope discoveries are reported, not tested.
• Provenance and timestamps, because passive sources change.