Attack Surface & Exposure · lesson 05

Continuous attack-surface monitoring

Continuous attack-surface monitoring discovers your internet-facing assets, diffs each scan against the last, and alerts only on proven exposures — the smoke detector that covers the gaps a point-in-time pentest leaves open.

9 min read

Your external attack surface is everything an outsider can reach without credentials: registered domains and their subdomains, the IP ranges behind them, open ports, the services and versions listening on those ports, TLS certificates, and any files or endpoints those services expose to the internet. It is the sum of what an attacker sees when they point their tools at your name — and unlike an internal asset inventory, no one signs off on it before it goes live.

Why the surface never holds still

Every deploy can add a subdomain, open a port, or ship a route that leaks a stack trace.
Shadow IT: a team spins up a marketing site, a staging box, or a SaaS trial on a subdomain nobody is tracking.
Expired resources: a certificate lapses, or a DNS record points at a dangling cloud bucket that someone else can now claim (subdomain takeover).
Third parties and acquisitions hand you assets you never inventoried but are still answerable for.

Why a snapshot test isn't enough

A penetration test is a photograph: skilled people probe a defined scope over a fixed window, then write it up. It is deep and it is valuable — and it describes the surface as it existed that week. It says nothing about the .env a developer pushed to a public repo the following Tuesday, the API key that leaked in a client-side bundle on Thursday, or the debug port a hotfix opened over the weekend. Between two quarterly tests the surface changes hundreds of times, and no one is watching the delta.

What continuous monitoring does

Discover: find assets you didn't hand it — pull new subdomains from Certificate Transparency logs, walk DNS records, expand IP ranges and ASNs.
Enumerate: for each host, resolve it, scan for open ports, and fingerprint the service and version behind each one.
Check for exposure: look for the specific bad things — an open /.git/, a directory listing, an exposed .env, default credentials, an expiring or mismatched certificate.
Diff: compare this run against the previous one and classify every finding as new, resolved, or unchanged.
Alert: notify only on meaningful change, with the evidence attached.

$ surface diff --since last
+ new    api-staging.example.com  :8080  open   (was: NXDOMAIN)
+ new    api-staging.example.com  /.env  200    DB_PASSWORD=... (12 lines)
~ same   www.example.com          :443   cert ok (expires 2026-09-14)
- gone   old-cdn.example.com      :80    connection refused

Proven alerts, or noise

The entire value of monitoring collapses if it cries wolf. An alert that says 'port 8080 is open' forces a human to go investigate; ten of those a day and people stop reading. A useful alert doesn't just observe a symptom — it proves the exposure. It retrieves the file at /.env and parses real variable names out of it. It takes the key it found and makes a benign, read-only call to confirm the key is live rather than revoked. It confirms the directory listing actually renders. Proven findings are rare and unambiguous; unproven ones are the fatigue that eventually gets the whole system muted. Judge any monitoring you build or buy on its false-positive rate, not its finding count.

careful

Retrieving files, fingerprinting services, and verifying that a leaked key is live are intrusive acts. Only run them against assets you own or are explicitly authorised in writing to test. Confirm ownership of every discovered host before scanning it — discovery routinely surfaces domains that merely resemble yours or belong to someone else.

note

Be honest about scope. Monitoring is outside-in: it sees what an anonymous attacker sees from the internet, and only that. It is the smoke detector between pentests — it tells you the moment a new door appears at the perimeter. It is not a substitute for a pentest's depth, for code review, or for the internal security controls behind the firewall.

How to adopt it

Inventory first: write down the domains, brands, IP ranges, and cloud accounts you actually own. Discovery expands this list; it can't start from nothing.
Verify ownership before you scan. Confirm every discovered host is yours or authorised, and never point active checks at look-alike domains that discovery pulled in.
Baseline, then watch the diff. The first scan is inventory; the value comes from what changes against it.
Prioritise by proven impact. A confirmed exposed .env outranks a hundred open-port observations — fix what's proven, triage the rest.
Close the loop. Route proven findings to whoever owns the asset, and re-scan to confirm the exposure is actually resolved, not just acknowledged.