Exposure management

Your attack surface is what you forgot to decommission

The staging host from a launch two years ago. The subdomain still pointing at a service you stopped paying for. Nobody monitors them, because nobody remembers they exist — which is precisely why they are still reachable.

Written by a network security engineer · last reviewed 20 August 2026

Why their list is better than yours

Your inventory is a record of what you meant to deploy. It is maintained by people with other priorities, updated when someone remembers, and it has no mechanism for noticing what was never removed.

An attacker does not consult it. They enumerate from the outside — certificate transparency logs, passive DNS, search engines, brute-forced subdomain lists, cloud IP ranges — and build their own. Their list is generated fresh from what is actually reachable today. Yours is a document.

That asymmetry is the whole problem, and it is why "we have an asset register" does not close it.

Dangling DNS and subdomain takeover

The mechanism most worth understanding, because it turns a forgotten record into someone else's foothold on your domain.

1. You point promo.example.com at a hosted service — a static host, an app platform, a storage bucket, a helpdesk.
2. Later the project ends. Someone deletes the service. Nobody deletes the DNS record.
3. The record still resolves to the provider, but the provider no longer has a tenant claiming that name.
4. Someone else registers that name on the same provider, and now serves content on your subdomain.

The result is a page on your real domain, under your real certificate story, controlled by someone else. It is a good phishing platform, it can receive cookies scoped to the parent domain in some configurations, and it inherits whatever trust your brand has.

How to enumerate your own exposure

Do this the way a stranger would, on a schedule:

• Certificate transparency logs — every publicly trusted certificate is logged. This is the highest-yield source, and it surfaces hostnames nobody documented, because someone had to request a certificate for them.
• Passive DNS — historical records, including ones that no longer resolve but did.
• Your own DNS zones — the authoritative list of what you publish, which is the one you compare everything else against.
• Cloud accounts — public IPs, load balancers, buckets and functions, per account and per region. The forgotten region is a recurring theme.
• Port and service checks on what you found, to see what is actually listening rather than what should be.

Then reconcile: anything reachable that is not in your inventory is either an asset you forgot or one you never knew about. Both are findings.

Scan only what you own

This is a legal boundary, not a best practice.

Enumerating and probing infrastructure you do not control can constitute unauthorised access depending on jurisdiction, and "I was only checking" is not a defence anyone wants to test. It is also easy to do accidentally — a subdomain can point at a third party's infrastructure, and scanning it means scanning them.

Attack Surface Monitor will not probe a domain until ownership has been verified, by DNS TXT record or an HTTP token. That gate is deliberate and cannot be skipped. It is the difference between a monitoring tool and a scanner.

Attack Surface Monitor

Self-hosted discovery and exposure monitoring. Enumerates your verified domains from the outside, tracks what changes, and flags dangling records and newly exposed services. Single Go binary, SQLite, embedded UI. Findings stay on your infrastructure — which matters, because a complete map of your exposure is exactly the document you least want in someone else's cloud.

Run it

Grab the tarball and SHA256SUMS from the releases page, then:

sha256sum -c SHA256SUMS
tar -xzf asm-free-*-linux-amd64.tar.gz
./asm
# dashboard on http://127.0.0.1:8423 — verify your first domain

Honest limits

• Ownership verification is required. If you cannot prove control of a domain, the tool will not scan it — including domains you genuinely own but cannot edit DNS for.
• It sees what is reachable, not what is safe. A discovered host is an input to a risk decision, not a verdict.
• Discovery is never complete. Any enumeration finds a subset; treat a clean run as "nothing new found", never as "nothing exists".
• It does not exploit anything, and it will not tell you whether a finding is vulnerable — only that it is there. Pair it with CVE prioritisation.