Domain OSINT & Footprinting

Overview

This is the footprint before a subdomain enumeration run: who registered the domain, what certificates it has published, which hostnames exist, and which of those are actually serving something, assembled without spraying the target. Assembling that by hand means five browser tabs and a notes file, and the result is stale by the time you act on it.

This produces the profile in one run and leaves a dated PDF you can attach to a scoping document. It is deliberately passive, which is what makes it usable before authorization is in place, on an acquisition target, or on a vendor. That property makes it the right first look for an M&A security review, where you often have a company name and a domain and nothing else. For a deeper hostname hunt with active resolve-and-probe, use Subdomain Enumeration instead.

Only the final probe touches the target, and only over HTTP.

Pipeline

1. Read the target domain.
2. subfinder enumerates subdomains from passive datasets.
3. A certificate transparency harvest adds hostnames seen in issued certificates.
4. DNS and WHOIS/RDAP lookups collect registration, nameserver and record detail.
5. The hostname sets merge and deduplicate.
6. httpx confirms which hosts answer and fingerprints the technology behind each.
7. Everything is assembled into an OSINT PDF report.

Inputs

• Target domain. The organization domain to profile, one per run. The default is the IANA example domain, so an unedited run profiles a domain that exists to be profiled.
• Passive source configuration. Optional provider config with API keys for the subdomain sources. They run token-free by default.
• DNS and RDAP lookups. No key, no local binary, nothing to set. Records come over DNS-over-HTTPS and registration data over RDAP.
• HTTP probe. Ports 80 and 443, one request per host. This is the only step that contacts the target, so everything before it is safe to run on a domain you have no relationship with.

Outputs

• Registration record. Registrar, creation and expiry dates, nameservers, and any contact emails the registry has not redacted.
• DNS record set. A, AAAA, MX, NS, TXT, SOA, CAA and DMARC, as records rather than prose, so the profile is machine-readable.
• Certificate history and related domains. Every certificate a transparency log holds for the domain, its issuers, and the other domains those certificates cover.
• Hostname inventory. The merged, deduplicated subdomain set from the passive sources and the certificate harvest.
• Live host and technology table. Which hosts answer, with status, title, server, resolved IP and the technology behind each.
• OSINT PDF report. All of the above dated and collected into one document you can attach to a scoping note.

Sample output

From a completed run against example.com.

subfinder returns the hostname inventory, which on an established domain is mostly things nobody has looked at in years:

wordpress.example.com
gitlab.example.com
gateway.example.com
apps.example.com
ebs.example.com

The DNS and registration pass returns records rather than prose, so the profile is machine-readable as well as printable:

The MX record here is worth reading. A null MX means the domain publishes that it sends no mail, which is a deliberate configuration and a good sign. Its absence on a domain that does not send mail is the more common finding.

FAQ

Is this safe to run before authorization is in place?

Everything except the final probe reads public datasets instead of contacting the target. The probe itself is one HTTP request per host on ports 80 and 443, which is why this is the run you can point at an acquisition target or a vendor.

What does RDAP give me that a plain WHOIS lookup does not?

Structured records instead of free text, so registrar, dates and nameservers come back parseable rather than needing to be read. It also needs no key and no local binary, so there is nothing to install before the run.

Why do domains I did not ask about show up in the output?

Certificates often cover more than one name, so the transparency harvest surfaces other domains the same organization has certified. On an acquisition target that is frequently how the second and third domain nobody mentioned turn up.

Can I run this from a company name rather than a domain?

You need a domain to start. Resolve the company to its domains first, then run this against each one to build out the profile.

How often is it worth re-running?

Registration and certificate data move slowly, so quarterly is usually enough on a domain you already own. On a vendor or a deal, re-run at each stage, because what changed since the last look is the part worth reading.

Related workflows

• Subdomain Enumeration. Reach for this instead when the passive profile is not enough and you want resolved, probed subdomains rather than a snapshot.
• Attack Surface Discovery by Company Name. Reach for this instead when you are starting from a company name rather than a domain and need to find the domains first.
• Find Origin IPs Behind Cloudflare. Reach for this instead when footprinting stopped at a CDN edge and every host resolves to the same shared ranges.