Design Partner Program
Hayrok/Resources/Blog/Research Notes
HAYROK LABS RESEARCH NOTE · HL-RN-2026-09 External attack surface validation

How to continuously validate your external attack surface.

Attackers scan your perimeter every day. So should your proof.

Discovery tells you what is exposed. Validation tells you what an attacker can actually use, and what it leads to inside. This note shows how to do both, continuously, including for AI endpoints.

Hayrok Labs Nov 2, 2026 @Melly 9 min read
THE VERDICT AGENTS.EXAMPLE.COM NO OWNER
01
Found in certificate logs
not in the asset inventory
02
MCP handshake, no auth
HTTP 200 · expected 401 or 403
03
Reaches customer data
tools read the support ticket DB
ACTION Assign an owner, enforce authentication, then retest from the outside.
TL;DR
01
Exploits now open 31% of breaches, and scanners already complete real MCP handshakes against internet-facing AI servers.
02
Discovery tells you what is exposed. Validation tells you what an attacker can use and what it leads to inside.
03
Further down: three checks you can run against your own domains today, covering certificate transparency discovery, KEV matching and an MCP authentication test.

External attack surface management is good at one thing: telling you what is exposed. It is much quieter on what is exploitable, and almost silent on what a foothold there would reach inside. That gap is where this note lives. Continuous external attack surface validation means four things: discover every internet-facing asset, attribute it to an owner, prove from the outside whether it can be exploited, and trace what it connects to. The perimeter is a moving target, so it gets re-proven on every change, every newly exploited vulnerability and every new class of exposed service, AI infrastructure included.

Key findings

BREACHES OPENED BY EXPLOITS
31%
Vulnerability exploitation is now the most common way in, per the 2026 Verizon DBIR. The front door is the main door.
NEWLY EXPLOITED, 1H 2026
~1/3 of 495
Were in content management systems. Exploitation of AI products rose too.
MCP SCANNING, JULY 2026
49 IPs
Distributed scanners completing real MCP protocol handshakes, not just port checks.
EXPOSED MCP SERVICES
12,520
Internet-accessible, most of them without authentication.
The perimeter changes faster than any quarterly scan. Attackers know it, and their scanners run every day.

Why discovery alone is not enough

An inventory is a great start. On its own, it leaves four blind spots.

Inventory without proof

A list of thousands of assets and open ports does not say which ones an attacker can actually use.

Shadow assets

Marketing sites, acquired domains, test environments and developer tunnels appear without a ticket and without an owner.

New service classes

Remote MCP servers, model endpoints and agent gateways ship fast, often with authentication off by default.

No inside view

An exposed host matters most when it connects to something valuable. Discovery tools stop at the edge.

Where external risk actually sits

Discovery fills the right-hand column. Validation tells you which of those assets belong in the top right, where an attacker can use them and nobody is watching.

KNOWN TO YOU UNKNOWN TO YOU
EXPLOITABLE
Patch queue
An owner knows. Fix it on your SLA and retest.
The danger zone
No owner, no monitoring, and an attacker can use it today.
NOT EXPLOITABLE
Monitor
Revalidate on change and on every new KEV listing.
Attribute and assign
Harmless today, unowned tomorrow. Give it an owner.

The method: six steps to continuous external validation

01

Discover continuously

Combine DNS, certificate transparency logs, cloud provider APIs, registered IP ranges, subsidiaries and SaaS tenants. Include AI endpoints such as remote MCP servers and model APIs.
02

Attribute and assign

Tie every asset to a business owner. The asset nobody owns is the one nobody patches.
03

Fingerprint and match

Identify each service and version, then match it against exploited vulnerability intelligence, such as KEV listings, and known exposure classes.
04

Validate from the outside

Prove exploitability with safe, governed checks: a non-destructive trigger, a test that authentication is enforced, a version-specific response. Record a verdict for each exposure.
05

Trace the inside reach

For every exploitable asset, follow its connections inward to see whether a foothold there sits on a path to a crown jewel.
06

Revalidate on change

Rerun validation when DNS or cloud changes, when a new exploited vulnerability is published and when a new exposure class appears.

Worked example: three checks on your own perimeter

Let's run the method against a domain you own. One ground rule before we start: only test assets you are authorized to test.

Check 1: find what certificates say you run

Every public TLS certificate is logged in certificate transparency. That makes it one of the fastest ways to find hosts nobody put in the inventory.

bash · crt.sh
curl -s 'https://crt.sh/?q=%25.example.com&output=json' |
  jq -r '.[].name_value' | tr '[:upper:]' '[:lower:]' |
  sed 's/^\*\.//' | sort -u > ct-hosts.txt

comm -23 ct-hosts.txt inventory-hosts.txt   # hosts with certificates but no owner

The output of that last line is your shadow surface: staging apps, old campaign sites and developer tunnels.

Check 2: match your services against exploited vulnerabilities

CISA publishes the Known Exploited Vulnerabilities catalog as JSON. Match it against the products your fingerprinting found.

bash · jq
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json |
  jq -r '.vulnerabilities[]
         | select(.vendorProject | test("Ivanti|Fortinet|Citrix|Palo Alto"; "i"))
         | [.cveID, .vendorProject, .product, .dateAdded] | @tsv'

A match is a candidate, not a verdict. It goes through the five-gate test from How to Validate Whether a Vulnerability Is Actually Exploitable before anyone gets paged.

Check 3: does your MCP server require authentication?

Remote MCP servers speak JSON-RPC over HTTP. An unauthenticated initialize request should be refused.

bash · curl
curl -s -o /dev/null -w '%{http_code}\n' https://agents.example.com/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize",
       "params":{"protocolVersion":"2025-06-18","capabilities":{},
                 "clientInfo":{"name":"auth-check","version":"1.0"}}}'
# expect 401 or 403
401 or 403
Authentication is enforced. Record the pass and move on.
200
Anyone on the internet can open a session and list the server's tools. That is the same handshake the scanners were completing.

The verdict record

JSON
{
  "asset": "agents.example.com",
  "owner": null,
  "exposure": "MCP server accepts unauthenticated initialize",
  "verdict": "exploitable_with_reach",
  "reach": "tools include read access to the support ticket database",
  "quadrant": "unknown_and_exploitable",
  "action": "assign owner, enforce auth, retest"
}

No owner, open to the internet, and connected to customer data. That is the top right corner of the grid above, and it is exactly where continuous validation pays for itself.

How to measure the outcome

Five numbers that tell you whether your perimeter is getting smaller or just better documented.

Unowned asset count
Internet-facing assets with no attributed owner.
Validated external exposures
Exposures proven exploitable from the internet, split by whether they reach a crown jewel.
Time to validate new KEVs
Hours from a KEV listing to a verdict across all matching external assets.
Time to close
Days from a validated external exposure to a passing retest.
Surface drift
New internet-facing assets per week that appeared without a change ticket.

How Hayrok approaches external attack surface validation

Find it, prove it, and follow it inside.

SurfaceIQ
Continuously discovers and attributes internet-facing assets, including cloud resources and AI endpoints.
Validates exposures from the outside with safe, governed checks.
Stores each verdict under an Evidence Contract.
AGIE
Connects every exploitable external asset to the internal attack graph, so you see which edge exposure leads to a crown jewel and which leads nowhere.

When a new exploited vulnerability lands, Hayrok matches it to your surface and validates the affected assets first. Learn more on Internet Exposure.

FAQ

What is external attack surface validation?

It is the continuous practice of discovering internet-facing assets, proving from the outside which ones are exploitable and tracing what each one can reach inside.

How is it different from external attack surface management?

EASM discovers and inventories exposure. Validation proves exploitability and reach, so teams fix what attackers can actually use.

Should MCP servers and AI endpoints be part of the external attack surface?

Yes. Remote MCP servers and model APIs are internet-facing services. Scanners already probe for them, and many run without authentication.

How often should the external attack surface be validated?

Continuously for discovery, and on every change or new exploited vulnerability for validation. Quarterly scans miss most changes.

Is external validation safe for production systems?

Yes, with non-destructive checks, approved scope and rate limits. No check should change data or persist.

See what the internet can reach

We will map your external surface, validate the exposures that matter and show which ones lead inside.

KEEP READING