In May we reconstructed a single agentic walk through our MCP deception and called it isolated, closing on an open question — whether it would generalize was what the next year of captures would tell. It took five weeks. On June 3 a client on a China Telecom address ran the same playbook against the same lure. Here is the full session.
The session
The client arrived at 08:01 UTC, opening on the Ollama endpoint (port 11434) — and on two of our sensors at once. It pulled the model inventory and the version banner:
GET /api/tags
GET /api/versionOn the second sensor it went further, trying to bend the model-pull endpoint into reading a local file:
POST /api/pull {"name": "../etc/passwd"}A path-traversal poke at the inference API. The lure absorbed it and gave nothing useful back.
Twelve minutes later the client moved to the application gateway on port 8000 and walked it methodically:
/ /api /api/status /api/health /api/mcp /api/tools
/admin /login /dashboard /api/admin /health
/.well-known/mcp.json /docs /admin/login /debug/config /api/v2/This is the discovery list we have now seen three times: confirm the platform, find the admin surface, find the MCP manifest, ask the application for its own configuration (/debug/config).
Then, briefly, the SSH service on port 22 — six authentication attempts, each presenting an SSH public-key fingerprint in the password field rather than a password. It is a credential variation we track on its own; here it is notable only as one more surface the same client touched on its way through. The client banner was SSH-2.0-OpenSSH_10.2p1 Debian-6.
And finally the MCP server. Three tool calls in twelve seconds:
execute_command id; hostname; uname -a; cat /etc/os-release | head -5
read_file /etc/passwd
execute_command sudo -l 2>&1; docker ps 2>&1; ls -la /home/<service-account>/The third call is the one that matters. Our fabricated /etc/passwd named a service account carrying sudo and docker group membership. The client read that response and, ten seconds later, built its next command from it — enumerate that exact account’s sudo rights, its container access, its home directory. The parameter was in no wordlist. It came from the file the client had just read.
Shorter than May’s thirty-call walk, and blunter. But the defining trait is identical: a value lifted from one response and turned into the next request. Different network, different continent, same reflex. The whole visit lasted about fourteen minutes.
The earlier probe, revisited
The May post named a second qualifying session only in passing — “a 22-second, nine-call probe from a DigitalOcean IP.” With a third capture in hand it is worth a closer look, because it was not idle. On May 1 that client connected to the MCP server and went straight for the custom tools — the configuration key-value store and the identity tool — querying them by name for an AWS access key, an AWS secret, a JWT signing key, and a Vault address. No filesystem wandering; it asked the config store for credentials directly. It returned later in the month to probe the gateway’s key-management and billing endpoints, the spend-and-quota surface that motivates most of the LLM-jacking traffic we see. Read alongside the other two, it is the same objective — credentials and compute — reached by the most direct route the lure offered.
What three sessions say
Three clients, three networks — DigitalOcean, Google Cloud, China Telecom — across five weeks. Each took the same path: model, then gateway, then MCP. Each went for the same things: credentials, lateral movement, compute. None needed a vulnerability — only a reachable endpoint and tools that would answer.
The discipline is unchanged. This is a convergent technique, not an attribution: different networks, different clients, no shared infrastructure, and the custom tool names they called are ours, learned by reading the manifest we advertise. The sample is still small — three sessions, one of them deep. What changed is narrow and worth stating plainly: in May the depth was isolated; it is no longer. For a protocol barely a year into wide deployment, the finding is not how deep any one client went, but that the shape is stable and repeating.
Detection guidance is unchanged from the first post: treat an exposed MCP endpoint as exposed remote execution, alert when a value from one tool response reappears as a parameter to another, and watch for the burst-and-pause cadence these clients share. We will keep counting. The next data point will say whether five weeks was a coincidence or a cadence.
Indicators
- Source (new)
1.71.186.7, China Telecom (Chinanet, Shanxi). 2026-06-03, ~14 minutes across two sensors. Ollama enumeration and an/api/pullpath-traversal attempt (../etc/passwd); gateway enumeration on:8000; an SSH public-key-fingerprint auth attempt (bannerSSH-2.0-OpenSSH_10.2p1 Debian-6); three MCP tool calls. UAcurl/8.19.0.- Source (earlier)
64.227.57.91, DigitalOcean. Config-store and identity-tool queries for AWS and Vault credentials on 2026-05-01; returned later in May for gateway key-management and billing endpoints.- Source (documented)
35.222.46.242, Google Cloud — the May 9 deep session, reconstructed previously.- Shared shape
- Ollama enumeration → gateway enumeration (including
/debug/configand/.well-known/mcp.json) → MCP tool invocation (execute_command,read_file, and custom config-store / identity tools). - External rep
- All three are cloud or broadband hosts; treat as historical and disposable. Correlate on behavior, not on the addresses.
Built on a research fork of Beelzebub, the open-source AI-native deception runtime by Beelzebub.AI. The fork, its deception design, and the instrumentation are our own.