The MCP Hunters: Reconnaissance for the AI-Agent Attack Surface

TI-2026-073A · Series: The Agent Frontier (Part A) · TLP:WHITE · 2026-07-10

Assessment (HIGH confidence). On 10 July 2026, a single fixed-line subscriber on a small Ukrainian family ISP made four POST /mcp requests carrying a purpose-built User-Agent, ufa-recon/1.0. Two weeks earlier, three Amazon EC2 hosts had guessed the mcp. subdomain of the same target. These are two shapes of the same emerging behaviour — hunting for exposed Model Context Protocol (MCP) servers, the control plane of AI agents. Every probe failed against an authenticated endpoint. The value of the dossier is not the damage (there was none) but the signature: the AI-agent attack surface is now being enumerated by hand-built tools, and this is what the front edge of it looks like.

1. What happened

Two unrelated-looking events in the web-threats telemetry turn out to point at the same target class.

Vector 1 — the path probe (2026-07-10). IP 91.237.122.51, on AS57993 (netname HLink, Ukraine), issued four POST requests to /mcp between 03:51 and 06:30 UTC. All four returned HTTP 401. Three carried the User-Agent ufa-recon/1.0; one carried Mozilla/5.0 (compatible; ufa-recon/1.0). No other paths, no other hosts — a clean, narrow, deliberate probe.

Vector 2 — the subdomain guess (2026-06-25 → 06-28). The hostname mcp.shuffle-on.com does not exist. It was nonetheless requested by three Amazon EC2 hosts (AS14618): 107.21.189.99 and 13.216.227.78 (classified vhost_enum) and 100.51.194.111 (auth_probe). Each got a 404 from the catch-all router. One of the three, 107.21.189.99, is a confirmed Elastic Load Balancing instance (ec2-107-21-189-99.compute-1.amazonaws.com) with an AbuseIPDB score of 83 across 24 reports — disposable cloud infrastructure, doing recon.

Different origins. Different mechanics. One objective: find a live MCP server.

2. Why anyone hunts /mcp

The Model Context Protocol is the wiring between an AI agent and the tools it can call — filesystems, databases, shells, cloud APIs, internal services. Its Streamable-HTTP transport speaks JSON-RPC over POST to a canonical /mcp endpoint. That design has a reconnaissance consequence: a live server returns a predictable, well-structured response, so a single crafted POST confirms both "a server is here" and "here is what it can do" — often including a full tool manifest — in one round trip.

The prize is unusually large per hit. As Trend Micro and Wiz have documented through 2026, a single unauthenticated MCP server hands an attacker every database, filesystem, and cloud service the agent is wired to — credential theft, lateral movement, in the worst case full cloud compromise. And the exposure is real at scale: 12,000+ MCP services reachable on the public internet, roughly 40% with no authentication at all. A May-2026 academic scan of 39,884 MCP repositories surfaced 106 zero-days, with secrets leaking at rates above 10%.

Against that backdrop, four hand-crafted POST /mcp requests are not noise. They are the cheap end of a very high-payoff hunt.

3. The tool: ufa-recon/1.0

The User-Agent is the most interesting artefact in the whole event.

• It is bespoke. ufa-recon/1.0 matches no known scanner (Nikto, Acunetix, Nuclei, masscan) and appears in no public scanner-UA corpus. It is someone's own tool, versioned 1.0.
• It ships an evasion mode. Three requests announced themselves plainly; one wrapped the same token inside a browser string — Mozilla/5.0 (compatible; ufa-recon/1.0). Carrying both a self-identifying and a browser-shaped variant of the same tool reads as a configurable blend-in toggle, not two tools. (Note for defenders: the Mozilla variant still contains the ufa-recon token, so it remains fingerprintable.)
• It is a singleton. Neither the ufa-recon UA nor the POST /mcp path appears from any other IP across the 8,700+ IP profiles and 140 campaigns in the web-threats corpus. This is a lone-source, low-volume, targeted event — not a botnet sweep.

The ufa token is a lead, not a conclusion. It could be an operator handle, initials, or a reference to the Russian city of Ufa; there is no evidence to choose between them. [INFERRED, LOW] — recorded as an open thread, not an attribution.

4. The network: a village ISP, not a bulletproof host

It would be easy — and wrong — to file "Ukrainian ASN running a custom recon tool" under bulletproof hosting. The registry record refuses that reading.

• AS57993 / HLink is a Provider-Independent assignment (91.237.120.0/22) created in 2012 and held by FOP Khalik Andrey Volodumurovuch — a Ukrainian sole proprietor (FOP = fizychna osoba-pidpryyemets, an individual entrepreneur), not a company.
• The registered address is a village: Novopillya, Kryvyi Rih district, Dnipropetrovsk oblast. The two RIPE contacts — Khalik Andrey (admin-c) and Khalik Yuriy (tech-c) — share a single apartment (Poltavskogo str. 2, ap. 31) and two mobile numbers. This is a family-run rural WISP.
• AbuseIPDB classes the subscriber range as "Fixed Line ISP" with an abuse score of 13 and two reports. There is zero SSH-honeypot history, no Shodan services, no GreyNoise record. Nothing about this network behaves like a criminal host.

Institutional-anchor pass. The chain is complete and mundane: RIPE NCC → Ukrainian Telecommunication Group LLC (the sponsoring LIR, ORG-UTGL1-RIPE, reg-nr 37184109, Kalynivka) → HLink PI holder → subscriber 91.237.122.51. Every link is a documented RIPE object. There is no accountability gap, no hidden shell — the reconnaissance rides ordinary, fully-registered infrastructure. The banality is the finding.

So the attribution boundary is precise: the subscriber line, not the ISP and not the Khalik family. No evidence connects the named operators to the ufa-recon activity beyond the fact that they sold someone internet access. Blocklisting the whole ASN would punish a legitimate village ISP for one customer's four packets.

5. Steelmanning the other reading

The counter-narrative: "A Ukrainian ASN held by a lone individual, running a custom recon tool against AI infrastructure — that's textbook gray-market operator infrastructure, and the family-ISP story is cover."

It is a fair suspicion, and it loses to the record on three points. (1) Longevity and type: a 2012 Provider-Independent assignment sponsored by a mainstream LIR is not how throwaway operator infrastructure is provisioned; bulletproof ranges churn. (2) Reputation: an abuse score of 13 and zero honeypot history is the opposite of a host that rents to abusers. (3) Vector origin: the cloud half of the MCP hunting came from Amazon, not from HLink — if this were a professional operation buying resilient infrastructure, the fixed-line village line is the least resilient possible choice. The simplest explanation survives: a subscriber with a laptop and a hand-rolled tool. The disagreement between "sinister ASN" and "innocent conduit" resolves, on the evidence, toward the conduit.

6. Seven questions

Who? An unattributed operator on a Ukrainian fixed line (path probe) and three disposable AWS hosts (subdomain guess). Same target class; a shared operator is unproven (LOW).

What? Reconnaissance for an exposed MCP server — POST /mcp endpoint confirmation and mcp. hostname enumeration.

When? Subdomain guessing 25–28 June 2026; the /mcp probe on 10 July 2026.

Where? Origin networks in Ukraine (AS57993) and the US (AS14618); target is web infrastructure fronted by an auth proxy.

Why? Because one unauthenticated MCP hit cascades into agent-level access to every connected tool and datastore — the highest-leverage target class of 2026.

How? A bespoke tool (ufa-recon/1.0, with a Mozilla-masquerade mode) issuing JSON-RPC-shaped POSTs, plus vhost enumeration of mcp.* from cloud hosts.

So what? It failed — every probe met a 401/404, never an open 200. The endpoint was authenticated; the hostname didn't exist. This is the control working, captured at the reconnaissance stage.

7. Read between the lines

The most quietly significant fact is that the /mcp probe returned 401, not 404. A 404 says "nothing here." A 401 says "something is here, and it wants credentials." An authenticated MCP endpoint turns the protocol's single-request-confirmation property against the hunter: the deterministic response that would normally leak a tool manifest is replaced by a challenge. The difference between a mapped target and a non-event was one auth layer — which is exactly the layer ~40% of internet-exposed MCP servers are missing.

What if the endpoint had answered 200? Then a four-packet probe from a village fixed line would have walked away with a tool inventory — the shape of every database, shell, and API the agent could reach — and the next visit would not have been reconnaissance.

8. Detection & defence

For anyone running MCP endpoints on the public internet:

1. Authenticate the transport. A 401 in front of /mcp is what turned this event into a non-event. Never expose an unauthenticated MCP server, even "temporarily."
2. Alert on POST /mcp from unknown clients. Treat a POST to /mcp with a non-browser or unrecognised UA as a recon signal, not background noise.
3. Watch hostname enumeration of mcp.*, ai.*, agent.*, llm.*. The subdomain-guess vector never touches your app — it probes DNS/vhost space. Catch-all 404 logging surfaces it.
4. Fingerprint the tool, not just the string. Blocklisting the literal ufa-recon token helps, but the browser-wrapped variant and the next tool will differ — key on behaviour (POST /mcp, low volume, no other paths).
5. Assume the hunt scales. This is a singleton today; the economics (cheap probe, catastrophic payoff) guarantee proliferation. Track ufa-recon-style tooling as an early-warning marker.

9. Sources

• Web-threats IP dossier — 91.237.122.51 (POST /mcp ×4, UA ufa-recon/1.0, 401). LSN web-threats platform, 2026-07-10.
• Web-threats host dossier — www.mcp.shuffle-on.com (nonexistent, 3× AWS vhost_enum/auth_probe).
• RIPE Database — inetnum 91.237.120.0/22, org ORG-FKAV2-RIPE, contacts KA3539-RIPE / KY265-RIPE.
• RIPE Database — organisation ORG-UTGL1-RIPE (Ukrainian Telecommunication Group LLC, LIR).
• AbuseIPDB — 91.237.122.51 (Fixed Line ISP, score 13) and 107.21.189.99 (score 83).
• Shodan InternetDB — 107.21.189.99 (EC2 ELB).
• Trend Micro, Update on Exposed MCP Servers: The Threat Widens to the Cloud (2026).
• Wiz, Understanding Model Context Protocol Security (2026).
• Qualys, MCP Servers: The New Shadow IT for AI in 2026; Adversa AI MCP-security timeline (May–July 2026).

Confidence: HIGH on the observed behaviour, the network attribution, and the institutional chain (direct registry + telemetry evidence, multi-source corroboration). MEDIUM on intent and on the two vectors sharing an operator. LOW on the meaning of the ufa token. Fact is tagged [DOCUMENTED]; hypothesis is tagged [INFERRED].