What Attackers Can See From the Internet

An attacker can usually see more of your organization than your asset inventory does. That gap is the real problem, and it is where external exposure work should start.

Nobody has to break in to learn this. Most of it is public, by design or by accident: certificate logs, DNS records, scanner indexes, code repositories, vendor-hosted pages, staff profiles. An attacker joins these into a map before sending a single malicious packet. A defender who has not built the same map is working from a picture the attacker has already moved past.

The map matters because exploitation is where intrusions most often begin. Mandiant’s M-Trends 2026, drawn from its 2025 investigations, found exploits were the top initial infection vector for the sixth year running, at 32% of intrusions. Verizon’s 2026 Data Breach Investigations Report, covering November 2024 to October 2025, puts vulnerability exploitation at 31% of breaches and ahead of stolen credentials as the leading way in. The two reports use different samples and methods. They still point the same way.

Where the outside view comes from

Five sources do most of the work. None needs access to your network.

Two of these deserve a closer look because the consequences are different from ordinary web exposure.

Dangling DNS. When a team retires a cloud resource but leaves the DNS record pointing at it, an attacker may be able to claim that resource name and serve content under your domain. The page looks like yours because, as far as browsers and users can tell, it is. Nothing in your perimeter tooling will flag it, because nothing inside the perimeter changed.

The edge. VPN gateways, firewalls and routers sit on the boundary, run vendor-controlled firmware, and usually cannot host an endpoint agent. Mandiant notes that edge and core devices of this kind typically lack standard EDR telemetry. Its 2025 cases included BRICKSTORM, a backdoor deployed in memory on network appliances that routinely survives standard remediation and reboots. Mandiant also estimates that the mean time to exploit a vulnerability has fallen to about minus seven days, meaning exploitation routinely happens before a patch exists. If that estimate holds for your technology stack, patching speed cannot be the only control. Exposure has to be reduced, and logging has to exist on devices that cannot run agents.

US federal policy now treats these devices as a category of their own. CISA’s Binding Operational Directive 23-02 requires agencies to take management interfaces for routers, switches, firewalls, VPN concentrators, proxies, load balancers and out-of-band server management off the public internet, or place them behind zero trust access controls enforced by a policy enforcement point separate from the interface itself. BOD 26-02, issued in February 2026, targets edge devices that no longer receive security updates. Both bind federal agencies only. They still make a useful benchmark for anyone else.

The patching picture explains the urgency. Verizon’s report, as summarized by Help Net Security, says only 26% of CISA Known Exploited Vulnerabilities were fully remediated across about 13,000 organizations, with a median of 43 days to patch, up from 32 the year before.

Visible is not exploitable, and exploitable is not important

An external scan returns thousands of findings. Most will not matter. Three questions sort them.

1. Is it ours? Ownership comes first. An asset nobody owns is the worst kind, because nobody patches it, monitors it or retires it. Assign an owner or take it down.

2. Can it be used? Is it reachable, vulnerable, misconfigured or weakly authenticated, and is exploitation of this exact weakness being seen in the wild? CISA’s Known Exploited Vulnerabilities catalog and current threat intelligence answer the second half. A severity score alone does not.

3. What does it connect to? An exposed test server with no data is a nuisance. The same server holding a cloud credential, or trusted by a production system, is an entry point. Attack path analysis answers this question. Outside-in discovery tools usually cannot.

Here is a hypothetical composite. An agency builds a campaign microsite on a cloud platform. A year after launch it still resolves under a company subdomain, runs an outdated plug-in, and appears in no register. The site holds nothing valuable. Its hosting account, though, uses an access key that also reaches a storage bucket of customer exports. Question one fails, question two is likely to fail, and question three decides whether it is a clean-up task or an incident. A raw findings list would have ranked it below dozens of louder issues.

What defenders should change

• Start outside, then reconcile. Seed discovery from root domains, brand names, known IP ranges, cloud accounts and acquired companies. Compare the result with the asset register. The difference is your finding list, and its size is a metric worth reporting.

• Give every external asset an owner and an end date. Campaign sites, test environments and proofs of concept should expire unless someone renews them.

• Set a hard rule for management interfaces. No public admin consoles. Where remote administration is needed, put an access layer in front that authenticates the user before the interface is reachable.

• Run edge devices as their own program. Shorter patch targets, end-of-support tracking, log forwarding to the SIEM, and retention long enough to investigate. Mandiant warns that standard 90-day retention can leave organizations blind to how a long intrusion began.

• Scan on change, not on a calendar. New assets appear with each deployment, DNS change and acquisition. Tie discovery to those events, and confirm every fix by rescanning from outside.

• Let exploitation evidence set the order. Reachability, active exploitation and what the asset connects to should rank the queue. A CVSS score is one input.

What an outside-in view cannot tell you

It sees what is reachable, not what is inside. It cannot show you SaaS misconfiguration behind a login, over-privileged identities, or what a compromised host could touch next. Shared hosting and content delivery networks can attach someone else’s asset to your name, and scanner data goes stale. Version banners can also mislead: vendors sometimes backport fixes without changing the version string, so a banner match is a lead to verify, not proof. Some exposure is intended, such as login pages and public APIs. The job is to know which exposure you chose.

Pair external discovery with vulnerability validation and attack path analysis. Each fills in what the others cannot see.

A thirty-minute check

Pick one root domain. List the hostnames that appear for it in public certificate logs. Match each against your asset register. For every name you cannot match, ask the three questions above, and record how many have no owner. If that number surprises you, it is the first finding, and it took no special access to produce.

Sources

1. Google Cloud / Mandiant. M-Trends 2026: Data, Insights, and Strategies From the Frontlines (23 March 2026)

2. Verizon. 2026 Data Breach Investigations Report

3. Help Net Security. Verizon DBIR: Vulnerability exploitation is the dominant initial access vector

4. CISA. BOD 23-02: Mitigating the Risk from Internet-Exposed Management Interfaces

5. CISA. BOD 26-02: Mitigating Risk From End-of-Support Edge Devices