Your External Attack Surface: What Attackers Look for First
What attackers see before they ever touch your network.
Every organisation has an external attack surface, and almost none of them have an accurate picture of what it actually contains. Old test environments outlive the projects they supported. Marketing spins up subdomains for campaigns that ended three years ago. Cloud accounts created by individual teams sit outside central inventory. Acquired companies bring their own histories of forgotten infrastructure. By the time an attacker arrives, the surface they see is usually larger, messier and more interesting than the one the defender thinks they are protecting.
This article describes how attackers map an organisation from the outside, where they tend to find their first foothold, and the small set of changes that meaningfully reduce risk. The aim is not exhaustive coverage — that is what an engagement is for — but a clear-eyed view of the discovery you should expect to be subjected to, whether you have invited it or not.
How attackers discover exposed assets
Modern attack surface discovery is almost entirely passive in its first phase. Attackers prefer to learn as much as possible before generating any traffic that could attribute their activity. The public internet provides a great deal of information for free.
Common starting points include:
- DNS data. Authoritative and historical DNS records, along with subdomain enumeration, reveal the shape of an organisation's infrastructure. The OWASP Web Security Testing Guide explains that attack surface identification involves discovering all domains, virtual hosts and externally exposed services by enumerating DNS names and subdomains. Tools such as crt.sh, Shodan, Censys and SecurityTrails are routinely used for this purpose.
- Certificate transparency logs. Every TLS certificate issued by a public certificate authority is recorded in public transparency logs. Reviewing these logs helps discover subdomains and services that an organisation may not have intended to expose.
- Cloud metadata. AWS, Azure and GCP all leave fingerprints. S3 bucket names, Azure storage URLs and exposed metadata endpoints reveal cloud footprint and sometimes cloud content.
- Code and credential leaks. Public GitHub, GitLab and Bitbucket repositories regularly contain hardcoded credentials, internal hostnames and configuration files that should never have left private infrastructure.
- Acquired company history. When organisation A buys organisation B, attackers happily look at organisation B's pre-acquisition footprint, much of which is still live.
Active reconnaissance follows. Port scans, service fingerprinting, banner grabbing and targeted enumeration confirm what passive discovery suggested. By the end of this phase, an attacker has a list of live services, technologies, versions and likely owners — often more complete than the asset register the defender is working from.
Common external entry points
The vulnerabilities that lead to real-world compromises are remarkably consistent year-on-year. The technology changes; the patterns do not.
The most reliably exploited categories are:
- Edge devices and VPNs. Citrix, Ivanti, Fortinet, Cisco and Palo Alto appliances continue to dominate the CISA Known Exploited Vulnerabilities catalogue. Exploitation of VPN and edge device vulnerabilities has surged: one study found that such devices accounted for 22 % of ransomware exploitation cases in 2024, up from 3 % the previous year. These internet‑facing devices remain the "soft underbelly" of enterprise defences and are often compromised before defenders are aware of a threat. As a result, unpatched perimeter appliances are the single most common ransomware entry point.
- Exposed administrative interfaces. Login portals for Jenkins, Kubernetes dashboards, database admin tools and management consoles that should never be reachable from the internet.
- Forgotten applications. Marketing microsites, legacy portals, old test environments and one-off integrations that no team currently owns.
- Weak or misconfigured TLS. Self-signed certificates on production endpoints, outdated TLS versions, and certificates issued by long-departed contractors that nobody now controls.
- Authentication weaknesses. Single-factor authentication on internet-facing services, password reset flows that leak account existence, and SSO misconfigurations that allow lateral movement between tenants.
- Cloud misconfigurations. Public S3 buckets, overly permissive storage URLs, exposed Kubernetes API servers, and IAM roles assumable from outside the account.
The pattern is not "zero-day exploits". It is "old issues on assets the defender did not know they had". The 2024 and 2025 high-profile UK ransomware incidents almost all followed this pattern.
High-impact fixes that reduce exposure
You cannot defend what you cannot see, so the first investment is visibility. After that, a small number of changes consistently produce the largest reduction in real-world risk:
- Build and maintain an authoritative external asset inventory. Combine internal sources (DNS, IPAM, cloud APIs) with external sources (certificate transparency, passive DNS, attack surface management tooling). Reconcile regularly.
- Retire what you do not need. Most environments contain services, hostnames and applications that no longer serve a business purpose. Decommission them. Every removed asset is one fewer entry point.
- Patch edge devices first. Treat anything in the CISA KEV catalogue affecting an internet-exposed device as an emergency. The timeline from disclosure to exploitation at scale on edge devices is now routinely measured in hours.
Exploitation of VPN and edge device flaws has surged; in 2024 these vulnerabilities accounted for 22 % of ransomware exploitation cases compared with 3 % the year before. Internet‑facing appliances often remain vulnerable long after patches are available, so apply updates immediately. - Put administrative interfaces behind authenticated access. Management consoles, internal apps and pre-production environments should not be reachable from the public internet. Use a VPN, Zero Trust proxy or IP allow-listing as a minimum.
- Enforce multi-factor authentication everywhere external. Phishing-resistant MFA (WebAuthn / FIDO2) for administrators is the highest-leverage single change available.
- Monitor for change, not just for vulnerabilities. A new subdomain appearing, a new certificate being issued, or a new service responding on a known IP is often the first sign of an issue.
This is unglamorous work. It is also the work that prevents the majority of opportunistic compromises. If you do these six things consistently, your external surface becomes substantially harder than your peers' — and attackers, like everyone else, optimise for effort.
Frequently asked questions
What is external attack surface management (EASM)?
EASM is the continuous discovery and monitoring of an organisation's internet-facing assets from an attacker's perspective. It complements internal asset management by capturing what defenders may not know they have exposed.
How often should we map our external attack surface?
Continuously. The surface changes daily as DNS records, certificates and cloud assets are created and destroyed. A point-in-time map is out of date the day it is produced.
What is the CISA KEV catalogue?
CISA's Known Exploited Vulnerabilities catalogue lists vulnerabilities for which there is evidence of active exploitation in the wild. It is the single most useful free input to vulnerability prioritisation for internet-facing assets.
Should we run our own attack surface tooling or use a service?
Either works. Service-based EASM typically delivers broader passive coverage and curated change alerting; in-house tooling gives more control over data. Most mature programmes combine both.