Turn one domain into a defensible map of an organization's internet-facing estate plus the owner behind it. The techniques live in other skills; what this workflow contributes is the order, the inventory, and the stopping rule. Two failure modes to avoid from the start: enumerating for hours and producing 400 hostnames with no attribution, dates or priority, which is not a map; and drifting active without noticing, because one probe "just to check if it's up" ends the passive claim. Decide the passive boundary before step 2, not during it.

Each stage feeds the next, and the sequence is cheapest-and-quietest first:

Run stages 1–5 as a loop, not a line. Every stage produces new selectors that belong back at stage 1 or 2. Stop looping when the stopping rule in step 7 is met.

State in writing: the subject (which domains and netblocks, and which adjacent ones are explicitly excluded), the objective, the jurisdictions involved, and the passive boundary — specifically whether DNS resolution, wordlist brute-forcing and any HTTP contact with the target are permitted. Read ../../ETHICS.md. If being noticed matters, set up attribution hygiene with before querying anything.

Done when subject, objective, out-of-bounds list, jurisdiction and passive boundary are written down, and you know which of the three grey activities you may perform.

Run on every in-scope apex. You want registrar, dates and status, nameservers, the full record set, and the mail and SaaS fingerprints TXT, MX, DKIM and CAA give up. Where registration is redacted, pull historical WHOIS in the same pass.

Done when every apex has a registration record with a retrieval timestamp, a complete record set, and a list of named third-party vendors extracted from its DNS.

Run . Certificate Transparency and passive DNS first, because they are free, historical and invisible. Feed it the organization names from step 2 as well as the domains — a certificate-subject search finds sibling and acquired domains nobody put in the brief.

Done when you have a deduplicated candidate hostname list with the source and first-seen date recorded per name, and any newly discovered apex domains have been pushed back through step 2.

Classify each candidate: resolves to an address, resolves to a third-party CNAME, or does not resolve. Build the inventory now rather than at the end — retrofitting provenance onto a list you already collected is how findings lose their timestamps. The schema and per-row fields are in reference/asset-inventory.md.

Done when every candidate is in one of the three buckets with a resolution timestamp, every resolving host has an IP and an ASN, and every third-party CNAME is attributed to a named vendor.

Run over the addresses and netblocks from step 4. Query scan platforms only — no port scanning, no service probing. Use the certificate and favicon pivots to catch hosts that share the target's infrastructure without sharing its DNS, and note anything that looks unintentionally exposed.

Done when each in-scope IP has its observed ports and services with scan dates, each netblock has an owner from its RIR record, and any infrastructure found only through cert or favicon pivots has been added to the inventory and attribution-graded.

Three sources, in this order:

If imagery matters — a logo reused across a network of sites, a stock photo posing as an office — run . Shared images tie sites together when DNS and registration do not.

Then assemble the tech stack from what you now hold: headers and cookies in archived copies and scan records, certificate issuers, CNAME targets, JavaScript and asset paths, CSP directives, favicon hashes, and the SaaS fingerprints from step 2. Where you need a live page, read a third-party scan of it instead of fetching it.

Done when archived and indexed content is reviewed for the top-priority hostnames, code exposure is documented or ruled out, new hostnames have gone back through step 4, and the stack is documented per host with the artifact each conclusion rests on and versions marked claimed rather than verified.

Completeness is a judgement, so make it against criteria:

A failing criterion tells you exactly which stage to re-enter.

Done when all five pass, or the remaining gaps are written up as stated limitations rather than left implicit.

If the registrant, certificate subject, RIR reassignment or tenant label resolves to a legal entity rather than an individual, the domain work is finished and a corporate investigation starts: hand the entity name and jurisdiction to , take registry and beneficial-ownership questions to , and send recovered emails to . Do not attempt corporate structure from DNS artifacts — DNS shows operators, not shareholders.

Done when every owner-side selector is routed to the right skill or recorded as a dead end with the reason.

Run . Lead with the asset inventory, then the attribution chain, then anything that appears unintentionally exposed, then the limitations from step 7. Done when every claim traces to an inventory row with a source and timestamp, and every finding carries a confidence grade.

Grade the inventory and the attribution separately. A host can be a confirmed live service and an unconfirmed asset of your target at once, and conflating the two is the most common reporting error in domain recon.

Per-technique criteria in the technique skills override these where more specific.

Engagement: a client is acquiring and wants its internet-facing estate before signing. Scope: the apex plus any domain the registrant demonstrably controls. Boundary: resolution allowed, no brute-forcing, no HTTP contact.

Step 2: five-year-old registration, registrant redacted but country , a Microsoft 365 tenant, and TXT tokens for a support desk, an identity provider and a GitHub organization. That GitHub org name is the highest-value item in the entire record set and it cost one lookup.

Step 3 returns 74 candidates, and a certificate-subject search surfaces , which is not in the brief. Back through step 2: same M365 tenant label in its MX, so same operator. Included, client notified.

Step 4: 31 resolve, nine of those to third-party CNAMEs — relationships, not assets. sits in a small Dutch hosting netblock distinct from everything else, which makes it the lead of the engagement.

Step 5: that UAT host had 443 and 3306 observed open five weeks earlier. Also eleven hosts sharing a favicon hash, which looked like a hidden estate until the hash turned out to belong to a stock CMS theme — the dead end, and exactly the kind that inflates a report if you skip the check.

Step 6: a public repo in the GitHub org holds a CI config naming two internal hostnames absent from DNS. They do not resolve; they still matter, because the acquirer inherits those systems.

Step 7: third consecutive source adds nothing, accounted for, every vendor chased. Complete, with one stated gap — the apex wildcard cert means subdomains issued after it are invisible to CT. Step 8: Dutch registrant country plus the sibling domain plus the group name in the cert subject point at a holding structure, so it goes to .

Passive collection from third-party datasets is lawful research in most jurisdictions; the boundary is traffic to the target and access to non-public systems. Registrant data recovered from historical WHOIS is personal data under GDPR even though it was once public, so you need a lawful basis and must minimize. Scan-platform and archive terms restrict bulk redistribution — cite findings, do not republish datasets. A discovered exposure authorizes a report to the operator or the relevant CERT and nothing else. And in due diligence, confirm you hold the client's written authority for the scope you are running: "our client is buying them" is not authorization from the target.