The obvious assets are usually well understood. Production applications, VPN gateways, public IP ranges, primary domains, and externally facing infrastructure are normally tracked and maintained.
The interesting stuff is often around the edges.
Old staging environments. Development portals that were temporarily exposed. Forgotten subdomains. Legacy VPN concentrators. Admin interfaces. Vendor-hosted systems. Cloud resources created for a project that ended two years ago. DNS records that still point to infrastructure nobody remembers owning.
From an attacker’s perspective, none of that is “shadow IT.” It’s just another target.
A typical external recon process isn’t limited to whatever appears on an asset spreadsheet. We’re looking at the organization’s broader footprint, including things like
DNS and subdomain enumeration
Historical DNS records
Certificate Transparency data
Public cloud exposure
ASN and IP ownership
Third-party infrastructure tied to the organization
Internet-facing services and management interfaces
Technology fingerprints and version information
Old authentication portals
Development and staging environments
Orphaned DNS records and dangling CNAMEs
That last one can get especially interesting.
If a DNS record still references a third-party service that’s been deleted or deprovisioned, the DNS entry may remain even though the underlying resource is gone. Depending on the provider and configuration, that can create conditions for subdomain takeover.
Now an asset nobody thought existed becomes an entry point under a trusted company domain.
The same issue shows up in other ways too.
A forgotten staging environment may be running an older version of the application. It may have weaker authentication. It might expose verbose errors, debug endpoints, API documentation, source maps, internal hostnames, or credentials that would never be exposed in production.
An old VPN gateway may no longer be part of the organization’s normal patching process.
A test S3 bucket or cloud storage container may have been created with broader permissions because it was “temporary.”
A vendor portal may still have accounts belonging to employees who left years ago.
None of those failures are particularly exotic. The risk comes from the fact that nobody is actively looking after the system anymore.
That’s the part I think organizations sometimes miss.
Attack surface management isn’t just knowing what you deployed. It’s knowing what is still reachable.
If I were asking an infrastructure or security team one question about this, it would be
Can you confidently explain what every internet-facing hostname associated with your organization is, who owns it, and why it still needs to exist?
If the answer is “probably,” that’s where I’d start looking.