Why Unknown Assets Are the #1 Cause of Security Breaches -- And Why AI Is Making It Worse

The breach that started with a server nobody knew about

It is a pattern that repeats across breach after breach, year after year. A company with a well-funded security team, solid perimeter defences, and a mature patch management programme gets compromised. The post-mortem reveals that the attacker did not brute-force the main application or exploit a zero-day. They found a forgotten staging server. An orphaned subdomain. A test API that a developer deployed two years ago and never decommissioned.

The asset was not in the CMDB. It was not covered by the vulnerability scanner. It was not behind the WAF. Nobody was patching it. Nobody was monitoring it. But it was on the internet, and it had a known vulnerability that was trivial to exploit.

This is not a rare scenario. It is the most common one. Research from multiple cybersecurity vendors and analyst firms converges on the same finding: the majority of successful breaches involve assets that the defending organisation did not know were exposed.

The security team did not fail. They were protecting the assets they knew about, and they were doing it well. The problem is that their inventory was incomplete.

How assets become unknown

No organisation sets out to lose track of its infrastructure. But in practice, it happens constantly, driven by a combination of organisational dynamics and technological convenience.

Cloud makes creation trivial and tracking optional

In a data centre, deploying a new server required procurement, racking, cabling, and network configuration. The process was slow, but it was visible. Everyone knew when a new server appeared because it was a physical event.

In the cloud, creating a publicly accessible virtual machine, storage bucket, or serverless function takes seconds and requires nothing more than API credentials. Development teams, operations teams, and even individual engineers can create internet-facing resources without the security team knowing. Most do so for legitimate reasons -- testing, prototyping, running a demo -- with every intention of cleaning up later. Later rarely comes.

Subdomains accumulate like sediment

Every project, campaign, integration, and experiment leaves a DNS record behind. Over years, an organisation's DNS zone becomes an archaeological record of every initiative it has ever launched. Some of those records point to active, maintained services. Others point to servers that have been decommissioned, cloud instances that have been terminated, or third-party platforms that the organisation no longer uses.

Those orphaned records are not just clutter. A CNAME pointing to an unclaimed cloud resource is a subdomain takeover waiting to happen. An A record pointing to a server running outdated software is an open door.

Mergers and acquisitions import entire unknown surfaces

When your company acquires another, you inherit their attack surface wholesale -- every domain, every server, every misconfiguration. Due diligence focuses on financials, legal exposure, and intellectual property. The acquired company's 200 subdomains, their SSH servers with password authentication enabled, their staging database with a public IP -- these rarely make it into the deal room conversation.

But they are on the internet the day the acquisition closes, and they are now your responsibility.

Third parties extend your perimeter invisibly

Modern organisations rely on dozens or hundreds of third-party services: CDNs, email marketing platforms, CRMs, analytics tools, payment processors, customer support widgets, monitoring services. Many of these operate on or reference your domain. An email provider sends as your domain name. A CDN serves your content on your subdomain. A SaaS platform hosts a portal on a subdomain you configured.

When one of those third-party services has a misconfiguration or vulnerability, it is your domain and your users that are affected. Yet these assets often sit outside the security team's visibility because they are "managed by the vendor."

People leave but their infrastructure stays

A developer sets up a test environment, provisions it with real-ish data, and exposes it to the internet so a remote contractor can access it. The developer changes roles. The contractor's engagement ends. Nobody remembers the test environment exists. Three years later, it is still running, unpatched, with data in it, accessible to anyone who discovers it.

This pattern is so common it has a name: zombie infrastructure. It is nobody's responsibility, it is not in any runbook, and it is the first thing an attacker finds.

Enter AI: The attacker's new reconnaissance engine

Everything described above has been true for years. What has changed -- and what is changing fast -- is the speed, scale, and intelligence with which attackers can find and exploit these forgotten assets.

AI-powered reconnaissance at scale

Traditional attack surface reconnaissance was a manual, time-consuming process. An attacker would enumerate subdomains, scan ports, fingerprint services, and look for vulnerabilities -- one target at a time, with considerable manual effort. Skilled attackers could do this efficiently, but there were limits on how many targets they could investigate.

AI removes those limits.

Large language models and AI-assisted tooling can now automate the entire reconnaissance pipeline: enumerate subdomains, classify services, identify technology stacks, find default credentials, detect misconfigurations, and even suggest exploitation strategies. What used to take a skilled attacker hours or days can now be done in minutes.

More importantly, AI makes this capability available to a much wider pool of attackers. You no longer need deep technical expertise to perform sophisticated reconnaissance. An attacker with moderate skills and access to AI tools can now operate at a level that previously required years of experience.

Automated misconfiguration exploitation

AI-assisted attack tools do not just find misconfigured assets -- they understand context. An AI model can look at a combination of an outdated web server version, a specific set of open ports, and a particular DNS configuration and determine the most likely exploitation path. It can correlate a certificate transparency log entry with a Shodan scan result and a DNS record to identify a forgotten staging server, determine what software it is running, and check for known vulnerabilities -- all in a single automated chain.

This is not science fiction. Offensive security tools with AI capabilities already exist and are being used in both legitimate penetration testing and by malicious actors. The same LLMs that help defenders write security policies also help attackers write exploitation scripts.

The asymmetry problem gets worse

Cybersecurity has always been asymmetric: defenders must protect everything, while attackers only need to find one weakness. AI amplifies this asymmetry. It dramatically reduces the attacker's cost of finding that one weakness, while the defender's job -- maintaining a complete, accurate inventory and securing every asset -- remains just as complex.

When an attacker can use AI to scan thousands of subdomains, cross-reference them with internet scanner databases, identify misconfigurations, and generate exploitation code in the time it takes a security analyst to review a single scan report, the calculus changes fundamentally.

The only viable response is to outpace the attacker's reconnaissance with your own. You need to find your unknown assets before they do, and you need to do it continuously.

The cost of not knowing

The impact of a breach through an unknown asset is often worse than a breach through a known one, for several reasons.

No monitoring means no detection

If an asset is not in your inventory, it is not being monitored. There are no logs flowing to your SIEM, no alerts configured, no anomaly detection watching for unusual behaviour. An attacker who compromises a forgotten server can operate undetected for weeks or months -- plenty of time to move laterally, exfiltrate data, and establish persistent access.

No hardening means easy exploitation

Unknown assets are typically unhardened. They are running the configuration they were deployed with: default settings, default credentials, no security headers, no WAF rules, no rate limiting. They may be running software versions with publicly known vulnerabilities that have had patches available for months or years.

Incident response is slower

When a breach is detected through an unknown asset, the incident response team starts at a disadvantage. They do not know what the asset does, who built it, what data it has access to, or what other systems it connects to. Every answer has to be discovered during the incident, which slows response time and increases the blast radius.

The reputational and regulatory hit is harder

Regulators and customers are less sympathetic when a breach occurs through an asset the organisation did not know about. It suggests a lack of basic security hygiene -- you cannot secure what you cannot see, and you were not even trying to see. Under NIS2 and GDPR, failing to maintain adequate visibility into your own infrastructure is itself a compliance failure, separate from the breach.

Closing the visibility gap

The solution is straightforward in concept, even if it requires discipline in execution: discover everything you have exposed to the internet, monitor it continuously, and fix what is broken.

Start with external discovery, not internal documentation

Do not start by asking teams to report their assets. Start by looking at your organisation from the outside -- the same perspective an attacker has. Use your known domains as seeds and discover everything connected to them through DNS enumeration, certificate transparency, reverse DNS, web crawling, and internet scanner data.

Compare what you find to what you thought you had. The difference is your visibility gap, and it is almost certainly larger than you expect.

Scan continuously, not quarterly

A quarterly scan is a snapshot that is stale the day after it runs. Your attack surface changes every time someone deploys a service, creates a DNS record, spins up a cloud resource, or lets a certificate expire. Continuous scanning -- daily or more frequent -- ensures that changes are detected within hours, not months.

Automate remediation tracking

Discovering a misconfigured asset is only useful if someone fixes it. Integrate your external scanning with your ticketing system so findings are automatically assigned, tracked, and escalated. Define severity-based SLAs and hold teams accountable to them.

Make it part of the process

EASM should not be a side project that the security team runs on their own. Asset discovery results should feed into your CMDB. New asset alerts should trigger an ownership assignment process. Findings should appear in the same dashboards and workflows your team already uses.

Keep pace with the attackers

AI is making attackers faster. Your visibility and response must keep pace. This does not necessarily mean you need AI in your defensive tooling (though it can help). It means you need the baseline: complete, continuous, automated visibility into your external attack surface. Because if you do not know an asset exists, no amount of AI-powered defence will protect it.

How SurfaceScan helps

SurfaceScan exists to close the visibility gap between what you think you have and what you actually have exposed to the internet. It starts with your domains and discovers everything connected to them -- the subdomains you forgot, the staging servers that were never decommissioned, the DNS records pointing to resources you no longer control, the cloud resources that bypassed your change process.

Every discovered asset is assessed for security risks: TLS configuration, email authentication, open ports, security headers, known vulnerabilities, and misconfigurations. Findings are prioritised by severity so your team fixes the most dangerous exposures first.

Continuous scanning means new assets and configuration changes are detected on every scan cycle. You see what an attacker would see -- but you see it first.

Stop guessing what is exposed. Start knowing. surfacescan.dev