Attack Surface Sprawl: Why Most SMBs Don't Actually Know What They're Exposing to the Internet

Maybe it was a staging environment spun up for a client demo three years ago. Maybe it was a microsite for a campaign that wrapped up in 2023, still running a CMS that has not been patched since. Maybe it was a developer's proof of concept that quietly acquired a DNS record, a public IP address, and then nothing else. No monitoring. No patch cycle. No owner.

That subdomain still resolves, though. And it is still part of what an attacker sees when they conduct reconnaissance on your business.

That is the result of attack surface sprawl, and it produces one of the most consequential visibility gaps in SMB security. The list of internet-facing assets in your asset register and the list an attacker can enumerate in an afternoon are rarely the same list. The attacker’s list is often longer. 

The forgotten subdomain is only one example of the broader attack surface your organisation may have overlooked.

What Is an External Attack Surface?

The systems and services an attacker can discover or access from the internet collectively make up your external attack surface. It can include:

• Public websites and customer portals
• Web applications and REST APIs
• Cloud-hosted services
• Public IP addresses and open network services
• Login pages and administrative interfaces
• Subdomains and regional domains
• Content management systems
• Development, testing, and staging environments
• Third-party services operating under the company’s domain
• Expired, misconfigured, or poorly maintained digital assets

This environment changes continuously and can expand rapidly. A current inventory can become incomplete as soon as a team deploys a new service, changes a DNS record, launches an API endpoint, or moves an application to a different cloud environment.

Blacklock’s own guidance on continuous offensive security testing (COST) notes that modern attack surfaces can change daily as new APIs, services, cloud configurations, software components, and application releases are introduced. In that environment, security testing based solely on an annual calendar provides only a point-in-time view. This is precisely why testing increasingly needs to respond to changes in the environment rather than wait for the next scheduled engagement.

How Attack Surface Sprawl Develops

Attack surface sprawl occurs when internet-facing assets accumulate faster than an organisation can reliably identify, monitor, and secure them. It rarely results from a single major oversight. Instead, it usually develops through small operational decisions made across different teams.

Shadow IT creates assets outside normal security processes

Shadow IT occurs when employees or departments deploy technology without passing through the organisation’s established IT and security processes.

A team may create a new SaaS account, connect a website plug-in, deploy a cloud workload, or launch a microsite to meet an immediate business need. The service may be useful and legitimate, but security teams might not know that it exists.

This creates several questions:

• Who owns the asset?
• What data does it process?
• Is it still required?
• Has it been configured securely?
• Is it included in vulnerability scanning?
• Who is responsible for applying updates?
• What happens when the employee who created it leaves?

When ownership is unclear, security maintenance often becomes inconsistent.

Staging environments are treated as temporary

Development and staging environments are frequently created under the assumption that they are temporary or low risk. They may nevertheless be reachable from the internet and connected to realistic application data, authentication systems, APIs, or production-like infrastructure.

Because these environments are not always treated as formal production assets, they may have:

• Weaker access controls
• Default or shared credentials
• Debugging features enabled
• Outdated application components
• Incomplete monitoring
• Test accounts with excessive privileges
• Copies of production configuration data
• Delayed patching and remediation

A staging application does not need to appear on the main company website to be discovered. Once it is internet-facing, an attacker can search for it, inspect its technology stack, and test it for weaknesses.

Subdomains accumulate faster than they are retired

Subdomains are easy to create and easy to forget.

A growing organisation might operate addresses such as:

• app.example.com
• api.example.com
• staging.example.com
• partners.example.com
• oldportal.example.com

Some may point to active systems. Others may refer to abandoned applications, expired cloud resources, legacy servers, or services that are no longer managed by the team that originally deployed them.

Unless you continuously enumerate and review these subdomains, the official asset inventory may represent only the best-known portion of the organisation’s exposure.

Why Traditional Asset Inventories Fall Behind

Asset inventory spreadsheets, asset-management tools, and configuration management databases (CMDBs) often serve as the organisation’s record of known systems and owners. Their weakness is that they depend on people and processes accurately recording every change.

‍

These records provide an internal view of the assets the organisation has identified and documented. However, they may not reflect everything currently exposed to the internet.

What Attackers See That Internal Teams May Miss

During external reconnaissance, attackers are not limited to the assets recorded in your internal inventory. They identify what is actually discoverable from the internet.

They can search for subdomains, inspect certificates, identify technologies, enumerate services, analyse response headers, and probe applications for exposed functionality. Forgotten systems may be particularly attractive because they are less likely to be monitored or maintained.

Common forms of exposure include:

• An old content management system that no longer receives updates
• An administrative page accessible without network restrictions
• An expired or incorrectly configured SSL certificate
• A development site indexed by a search engine
• An API endpoint omitted from application documentation
• A service listening on an unnecessary public port
• A subdomain pointing to infrastructure that is no longer controlled
• A login portal running an obsolete framework or plug-in
• An application that was excluded from the last penetration test

The most dangerous asset may therefore be neither the organisation’s main website nor its most important production system. It may be the forgotten asset that provides an easier starting point.

Moving From Periodic Assessments to Continuous Testing

A one-off assessment answers an important question: what vulnerabilities were present in the defined scope when the assessment was performed?

Continuous testing addresses a different question: what is exposed and vulnerable as the environment changes?

A practical approach combines several activities.

1. Discover internet-facing assets

The process should search beyond the organisation’s main website and known production systems. Subdomain enumeration, for instance, can uncover development sites, regional applications, customer portals, APIs, and legacy services that were not included in the original target list.

2. Test applications and infrastructure regularly

Discovery alone does not determine whether an asset is vulnerable. Identified systems should undergo appropriate security testing based on their function and technology. Regular scanning helps uncover newly introduced vulnerabilities, configuration weaknesses, and exposed services before they go unnoticed for extended periods.

Blacklock’s vulnerability scanning service, for example, supports authenticated and unauthenticated DAST for web applications, APIs, and cloud-hosted services, alongside scanning of external infrastructure. Scans can run on demand, on a schedule, or through a CI/CD pipeline.

3. Look for exposure beyond application vulnerabilities

Attack surface testing should account for weaknesses and exposures such as:

• Subdomains that may be absent from internal inventories
• SSL misconfigurations
• Open or exposed network services
• Email breaches
• CMS-specific weaknesses affecting WordPress, Joomla, and Silverstripe
• Other internet-facing assets and security misconfigurations

Blacklock’s multi-tool scan engine is designed to provide a broader view of the external attack surface by combining application and network-layer testing with subdomain enumeration, SSL checks, open-service discovery, email-breach checks, and CMS-specific testing.

4. Assign ownership and remediate findings

Discovery creates value only when the organisation can determine who owns each asset and who is responsible for resolving its vulnerabilities.

When you find an unknown system, the immediate questions should be:

• Which team deployed it?
• Does the organisation still need it?
• What information does it process?
• Can internet access be restricted?
• Should it be patched, reconfigured, or decommissioned?
• Should it be added to recurring scans?

5. Validate fixes and continue monitoring

Attack surface management is not complete when a vulnerability ticket is marked resolved. The organisation needs evidence that the weakness is no longer present.

Blacklock allows teams to retest targeted vulnerabilities after remediation and manage findings, risk acceptance, scan history, and reports within the same platform.

How Blacklock Helps Reduce Attack Surface Blind Spots

Blacklock combines continuous automated testing with on-demand expert-led penetration testing. Its PTaaS model is designed to help organisations discover and manage vulnerabilities across internet-facing assets from a single platform.

For attack surface sprawl, the relevant capabilities include:

Blacklock provides unlimited scheduled and on-demand vulnerability scans within its vulnerability scanning and penetration testing plans, making it practical to include staging environments, secondary applications, and newly discovered assets in routine testing rather than limiting coverage to the most prominent systems.

Blacklock’s web application penetration testing combines automated scanning with expert manual assessment, while its infrastructure penetration testing covers public-facing, cloud, internal, and private infrastructure. Organisations can begin with automated scanning and request manual penetration testing or validation when deeper analysis is required

You Cannot Secure an Asset You Do Not Know Exists

Attack surface sprawl is ultimately a visibility problem.

Security teams may be protecting the organisation’s known production environment while an abandoned subdomain, exposed staging server, misconfigured SSL deployment, or forgotten CMS remains accessible elsewhere.

A point-in-time test is still valuable, particularly when expert manual analysis is required. But it should be supported by continuous discovery and scanning that reflect how quickly applications and infrastructure change. As Blacklock explains in its article on continuous application security testing, development, deployment, and attacker activity do not operate on an annual schedule. Security testing should keep pace.

When you maintain a current view of the external attack surface, you can identify unknown assets sooner, assign ownership, remove unnecessary exposure, and test the systems that remain.

Explore Blacklock’s vulnerability scanning plans or start a 14-day free trial to assess your web applications, APIs, and infrastructure.