Why the inventory you have is not the one attackers use

Most asset registers are built from the inside: the cloud accounts IT knows about, the DNS zone the infrastructure team manages, the hosts somebody remembered to enroll. Attackers build theirs from the outside, from exactly the public sources below. The gap between those two lists is your shadow IT, and it is where the easy findings live: an unpatched admin panel on a forgotten host, a dangling CNAME waiting to be claimed, an expired certificate on something a customer still bookmarks.

CIS Controls v8 puts this first for a reason. Control 1 asks for a detailed inventory of enterprise assets, including ones not under your direct control, because every later control (vulnerability management, secure configuration, monitoring) can only cover what the inventory contains.

Passive discovery sources, and what each is good for

"Passive" here means reading public datasets and resolving names through public DNS, never sweeping IP ranges or connecting to hosts you have not claimed. The sources worth using:

  • Certificate transparency (CT). Public CAs log every certificate they issue to append-only CT logs, and browsers require it. Every hostname someone got a certificate for is in there, including the ones issued by a team you have never heard of. This is the single best source for web-facing shadow IT, and it is near real time.
  • Your own DNS records. MX, NS and SPF includes reveal mail and DNS providers; CNAMEs reveal SaaS platforms; SRV records reveal services (SIP, XMPP, autodiscover) that never appear on a website.
  • DNSSEC zone walking. A zone signed with plain NSEC records can be enumerated by following the chain of names. NSEC3 was designed in RFC 5155 partly to prevent this, so it only works on some zones, but where it works it is complete.
  • Web archives. The Internet Archive's Wayback Machine and the Common Crawl index record URLs that were public at some point. Old hostnames that no longer get certificates often surface here.
  • Links on your own pages. Marketing sites link to status pages, help centres, careers portals and shops, many run by third parties on your subdomains.
  • A short wordlist. Common names such as vpn, staging and mail, resolved against public DNS. Wildcard DNS has to be detected first, or a zone that answers every name floods the inventory.

Attack Surface Scan runs all six for every domain you have verified: CT every 15 minutes, the rest nightly (web archives weekly per domain, and on any manual run), each with its own time limit so a slow source never blocks the others. Only names that resolve and sit under a verified domain are kept. The details are on Asset inventory and discovery.

For a one-off look at what CT alone reveals about a domain, the free attack surface scanner runs in your browser with no signup.

Candidates: related domains need verification

Discovery does not stop at subdomains. A certificate for example.com might also name example-payments.com; an SPF include or a link might point at examplecorp.net. These are often yours (an acquisition, a regional brand, a campaign domain registered on a marketing card) and sometimes not.

The tempting move is to start scanning them. The correct move is to treat them as candidates: observed through public data only, never connected to, until someone proves ownership. Name similarity is evidence, not authorization, and scanning a domain you do not own is somebody else's security incident. In Attack Surface Scan, other registrable domains found in your certificates always become candidates; ones found in NS, MX, SPF, CNAME records or page links become candidates only when the name looks related, and known vendors are classified as dependencies instead. From the inventory, Add and verify starts the normal ownership proof.

That verification step is also a useful organizational forcing function. "Who owns this domain?" is frequently the question that surfaces shadow IT in the first place.

Assets, dependencies and states

An inventory that only lists hostnames is hard to act on. Useful distinctions:

  • Approved: yours and monitored.
  • Candidate: found by discovery, awaiting a decision.
  • Dependency: third-party infrastructure you rely on but do not run, such as a CNAME into a SaaS platform, a CDN or a hosted mail provider. Worth knowing about for vendor risk; not yours to scan.
  • Monitor-only: tracked for inventory and change history without full scanning.
  • Dismissed: not yours or not relevant, and discovery should not re-add it.

A state set by a person should never be overridden by automation. That is the difference between an inventory the team trusts and one it learns to ignore.

Where it runs: cloud and network context

The next question after "what is this host?" is "whose infrastructure is it on?" Every IP a host resolves to can be attributed to its network (ASN and organization) and, where it falls inside a provider's published ranges, to a specific cloud or CDN. AWS, for example, publishes its ranges as a JSON file for exactly this purpose, and Google Cloud, Azure, Cloudflare and others do the same.

That context is what turns an inventory into answers:

  • A host on a cloud provider your company does not have an account with is shadow IT almost by definition, or a vendor you have not recorded.
  • A summary by provider answers the "what runs where" line in asset registers and vendor reviews.
  • A host that moves from your cloud to a residential ISP or an unfamiliar hosting network deserves a look.

Attack Surface Scan attributes IPs using iptoasn.com and the published ranges of AWS, Google Cloud, Microsoft Azure, Cloudflare, Fastly, Oracle Cloud, DigitalOcean and GitHub Pages, and recognizes Akamai and some others by ASN. It does not connect to your cloud accounts: the attribution comes entirely from public data, which is also why it works for accounts you do not know exist.

Change history: the inventory is a timeline

An inventory is only useful if you can tell what changed. Each asset should carry first-seen and last-seen dates, and additions and removals should land in a change feed with who (or what) made them. In Attack Surface Scan those appear as asset.added, asset.removed and candidate.found, marked as made by a person or by the system. On plans with scheduled scans, a discovered asset not seen for 45 days is removed automatically; hosts you exclude stay excluded.

That history is also audit evidence. "How do you learn about infrastructure you did not inventory?" is a question in SOC 2 and ISO 27001 fieldwork, and a dated feed of discovered hosts answers it better than a policy paragraph (see turning monitoring into audit evidence).

A working process for shadow IT

  1. Verify every registrable domain you know you own. Discovery is scoped to them.
  2. Let discovery run for a week, then review new hosts by provider. Unfamiliar networks first.
  3. Resolve each candidate: verify it, or dismiss it with a note.
  4. Find an owner for each surprise. Hosts without an owner are the ones that never get patched. If nobody claims it and it serves nothing, remove the DNS record before the resource behind it disappears.
  5. Watch the feed. New hosts should be a notification, not a quarterly surprise.

Limits worth stating

  • Passive discovery finds hosts that left public traces. A service reachable only by IP address, with no DNS name and no certificate, will not appear.
  • Discovery covers domains you have verified; it does not search the internet for assets that merely belong to your company.
  • It does not read cloud accounts, so it complements (rather than replaces) a cloud asset inventory. See EASM vs CAASM vs CSPM for where each fits.
  • Plan limits apply to hosts monitored per domain (20 on Starter, 100 on Growth; see pricing).

Frequently asked questions

What is shadow IT in external attack surface terms?

Internet-facing infrastructure that belongs to your organization but is missing from the inventory your security program works from: forgotten subdomains, contractor and campaign sites, SaaS subdomains and hosts in cloud accounts IT does not manage. It matters because controls only cover what the inventory contains.

Can I find shadow IT without scanning IP ranges?

Yes, for anything with a DNS name. Certificate transparency, your own DNS records, web archives and page links reveal most internet-facing hosts under your domains. What passive discovery misses is a service reachable only by IP with no name or certificate.

Why not scan domains that look like mine automatically?

Because looking related is not proof of ownership. A domain that resembles yours may belong to a partner, a reseller or an attacker. Treating it as a candidate until ownership is verified keeps you from scanning systems you are not authorized to test.

How do I tell which cloud a forgotten host runs on?

Resolve it and compare the IP address against each provider's published IP ranges and the ASN it belongs to. Attack Surface Scan does this automatically for every IP in the inventory, which is how hosts on unfamiliar providers stand out.

Sources