The Attack Surface You Forgot: Scanning Your Own Infrastructure
Attackers scan your perimeter every day. Most organizations scan their own once a year. Here is what external recon on yourself reveals, and why continuous beats annual.
Attackers already have your asset inventory
Every internet-facing system you own is being scanned right now. Shodan, Censys, and a thousand botnets index your perimeter continuously, without asking. The only party that usually lacks an up-to-date view of your external attack surface is you.
This is the uncomfortable premise of attack surface management: reconnaissance on your own infrastructure, done the way an attacker would do it, on a schedule an attacker would keep. No credentials, no agent, no assumptions from the CMDB. Just what the internet can see.
The gap between what the CMDB says you expose and what you actually expose is where incidents come from.
What external recon on yourself finds
Run honest external reconnaissance against your own domains and IP ranges and a familiar catalog of problems appears. These are not exotic findings. They are the same four or five categories, at every organization, every time.
Exposed services and admin panels
The classics: RDP open to the world, a database port that was "temporarily" exposed for a migration two years ago, Jenkins and Grafana instances with default or weak authentication, an old VPN appliance running firmware from three CVE cycles ago. Management interfaces are the highest-value category because they combine remote access with privilege, and edge devices have been the initial access vector of choice for both ransomware crews and state actors for several years running.
Certificate problems
Expired certificates on production endpoints tell users to ignore TLS warnings, which trains them to ignore all TLS warnings. Misissued or forgotten certificates tell a different story: certificate transparency logs are a public, append-only record of every certificate ever issued for your domains. Attackers mine CT logs to discover your subdomains. You should be reading the same logs to discover certificates you did not know existed, including ones requested by teams or vendors you did not know were acting in your name.
Forgotten subdomains and shadow IT
Marketing spun up promo2023.example.com on a SaaS builder. A developer pointed staging-old.example.com at a personal cloud account. An acquired company's domains were never inventoried. Subdomain enumeration through DNS brute-forcing, CT logs, and passive DNS routinely finds 30-50% more live hosts than the official inventory contains. Each one is an asset with your name on it and, usually, nobody patching it.
Dangling DNS
The quiet one. A CNAME points to a cloud resource that was deleted: an S3 bucket, an Azure app, a Heroku instance. Anyone can register that resource name and now serves content under your subdomain, with your domain's reputation, cookies scoped to your parent domain, and a perfect platform for phishing. Subdomain takeover via dangling DNS is cheap to find, cheap to exploit, and almost always invisible from inside the network because nothing is broken from the inside.
| Finding class | Typical cause | Attacker value |
|---|---|---|
| Exposed admin panel | Firewall change, "temporary" rule | Direct access, often privileged |
| Expired / rogue cert | No cert inventory | Phishing, user desensitization |
| Forgotten subdomain | Shadow IT, M&A, staled projects | Unpatched entry point |
| Dangling DNS | Decommissioned cloud resource | Subdomain takeover |
| Leaked service banner | Default config | Version intel for exploit matching |
Why annual pentests miss this
A penetration test is a point-in-time exercise against a defined scope. Both properties are the problem.
Point-in-time: your perimeter is not static. Cloud infrastructure means anyone with a corporate card can create internet-facing assets in minutes. Firewall rules accumulate. Certificates expire on their own schedule. DNS records outlive the resources they point to. The perimeter you pentested in March is not the perimeter you have in July. Drift is not an anomaly; it is the steady state.
Defined scope: the pentest tests what you told the testers about. The assets that hurt you are precisely the ones nobody told anyone about. Shadow IT is out of scope by definition, because scope is written from the same incomplete inventory that caused the problem.
Annual pentests remain valuable for depth: exploit chaining, business logic, lateral movement. But for breadth and freshness, the model is wrong. The window between "asset became exposed" and "someone on your side noticed" is measured in days for attackers running continuous scans. If your own detection window is measured in months, you lose that race every time.
Continuous scanning vs annual testing
- Cadence: attackers rescan the internet in hours to days. Weekly or daily scanning of your own ranges is the minimum credible answer.
- Discovery first: enumeration (subdomains, CT logs, DNS, IP ranges) must run before assessment. You cannot secure what you have not found.
- Diffing beats snapshots: the most valuable output of scan N is the difference from scan N-1. "New port 9200 open on host X since Tuesday" is an actionable alert. A 400-page report is not.
This is the model behind RedKit, the mlab.sh infrastructure scanning platform: 24+ modules covering reconnaissance, vulnerability detection, and compliance checks, run continuously against your own perimeter so that new exposure surfaces as a change event rather than a pentest finding eleven months later.
Prioritizing what you find
The first full scan of a mature organization's perimeter produces hundreds of findings. Triage them like an attacker would:
- Remote access and management planes first. Exposed RDP, SSH with password auth, VPN appliances, admin panels. These are initial access, not "informational."
- Known-exploited over theoretically-severe. A service version present in CISA KEV outranks a higher-CVSS bug nobody exploits. Cross-reference findings against exploitation data before assigning patch windows.
- Takeover-able before ugly. Dangling DNS and subdomain takeovers are often rated "medium" by tools and are worth more than that. They hand your brand to an attacker.
- Then hygiene. Expired certs, verbose banners, missing headers. Real, but batch them.
And prioritize by ownership, not just severity. A finding with no owner never gets fixed. Half the value of continuous discovery is forcing the question "whose asset is this?" while the answer is still recoverable.
Making it a routine, not a project
Attack surface management fails when it is treated as a one-off cleanup. It works when it becomes a loop:
- Enumerate weekly, scan continuously, alert on diffs.
- Route new-exposure alerts into the same SOC queue as detections, with the same ownership rules.
- Feed confirmed assets back into the inventory so the CMDB converges toward reality.
- Re-scan after every major change window; that is when drift happens.
The tooling matters less than the cadence. An organization running basic enumeration every week will beat one running a best-in-class assessment once a year.
Your perimeter is already being scanned continuously. The only open question is whether you are one of the parties doing it.
