On 25 August a HoneyLabs sensor started seeing an unusual amount of “Claude” traffic. Within two weeks the same client had cycled through more than 42,000 distinct user-agent strings, almost all of them claiming to be an AI crawler. The costume was the point: underneath was a credential scanner aimed straight at cloud metadata endpoints. The disguise held well enough that substring user-agent matching - the most common allow-list logic on the modern web - would have waved it through.
If you operate anything with a public origin - a small SaaS dashboard, a self-hosted AI tool, a side project on a free tier - the lesson is that the AI crawlers you whitelist for SEO or model training are now being impersonated by attackers. The spoofing is good enough to defeat user-agent rules and cheap to run at scale.
What the sensor actually saw
HoneyLabs, a honeypot operator, published its writeup on 8 September. The headline numbers are concrete. A single client generated 42,321 distinct user-agent strings between 2 August and 6 September. The client used 26 different IP addresses, 25 of them on Google Cloud (AS396982), and produced 6,648 unique spellings of “Claude-User” from a generator it appears to maintain. Across HoneyLabs’s full dataset, the same JA4H HTTP fingerprint - ge11nn05en_813e32c09d15 - accounted for 86.8% of all 121,540 requests that claimed to be an AI crawler. The crawler names, in the operator’s words, are “the costume.”
The pattern is not a casual scrape. The total volume was 105,438 requests from this one client in roughly five weeks. The requests clustered on four attack profiles, each designed to probe a specific class of weakness:
ge11nn05en(GET): credential and config files. 158,062 requests. Targets includefile:///root/.aws/credentials,file:///proc/self/environ, and the standard AWS instance metadata address.ge11nn0600(GET): server-side request forgery at cloud metadata. 20,235 requests, including 867 againsthttp://169.254.169.254/latest/meta-data/iam/security-credentials/- the AWS IMDS endpoint that hands back short-lived IAM credentials to anything running on the instance.po11nr0700(POST): GraphQL introspection. 1,205 requests aimed at leaking internal schemas.po11nr0900(POST): JSON-bodied SSRF. 1,724 requests, the classic “post this URL to your server and tell me what comes back” probe.
The breakdown matters because none of these are AI workloads. They are credential-theft probes that happen to be wearing an AI crawler name tag. The point of rotating through 42,321 user-agent strings is to keep looking like a different, legitimate crawler on each request - long enough to slip past rules that whitelist “ClaudeBot” or “GPTBot” or “meta-externalagent.”
The detection problem
Standard defenses fail by design. Substring matching against known crawler names is what most WAFs and Cloudflare rules ship with out of the box. That gives the attacker whatever access your real crawler has, because the attacker is claiming to be the real crawler, just from a different source. Blocking AS396982 - the Google Cloud range the spoofed traffic came from - also blocks Google’s legitimate crawlers, as HoneyLabs notes: “an operator who blocks AS396982 loses the real crawler and keeps the problem.”
The single check that holds, per the HoneyLabs writeup, is forward-confirmed reverse DNS: the IP address must resolve to a hostname under the operator’s claimed domain, and that hostname must resolve back to the same address. Crawlers like Googlebot, Bingbot, and Anthropic’s Claude-User publish the IP ranges and reverse-DNS patterns their infrastructure actually uses. Impersonators can rotate user-agent strings at will; they cannot forge a DNS delegation.
That is a heavier lift than a UA rule, but it is the only one that closes the impersonation path. As a stopgap, HoneyLabs lists four cheap header-level tells:
Metadata-Flavor: GoogleorMetadata: truein the request headers. These are Google Cloud metadata-server request headers; they should never appear in real crawler traffic. Anything sending them is hostile.- A bare IP in the
Hostheader. Real crawlers send a hostname; scanners often paste an IP. - A Firefox user-agent string at version 110 or higher that is missing the
rv:109.0token the real Firefox ships with. The mismatched version markers are a giveaway of a templated UA. - A claimed major crawler that never requests
/robots.txt. Legitimate crawlers do; this client almost never did.
These are not bulletproof. They are cheap, and they catch the specific client HoneyLabs profiled.
What This Means
The deeper problem is that the AI crawler category has become a default trust zone. Operators who want their content indexed by ChatGPT, Claude, Perplexity, and the rest routinely allow-list crawlers like GPTBot, ClaudeBot, OAI-SearchBot, meta-externalagent, and PerplexityBot. That allow-list is now an attack surface. The HoneyLabs writeup is the first public dataset showing it being exploited at scale, but the technique generalises: any time a class of traffic has privileged access because of its name, attackers will eventually put on that name.
For self-hosters, the operational consequence is that the standard “open up the AI crawlers so the models find my content” advice needs a second layer. Usero’s Will Smith documented the same class of issue from the cost side: Meta’s meta-externalagent/1.1 crawler burned through roughly 80% of his Sentry error budget over 14 days because it ran a real headless Chrome, discarded cookies between pages, and prefetched every link on his marketing site. He ended up trusting Cloudflare’s own verifiedBotCategory field and serving bots a static, indexable /integrations page in place of his app routes. That fix is also a defence against impersonation: the impersonator would still have to look enough like the real Meta crawler for Cloudflare to tag it that way, and Cloudflare’s bot classification is harder to spoof than a UA string.
For readers who run their own infrastructure, the immediate checklist is: pull your current WAF and Cloudflare rules and audit them for AI crawler allow-listing. For each entry, ask whether the rule relies on UA substring matching alone, and if so, add a reverse-DNS check for the IPs that rule will accept. Add the four header-level tells above as a first-pass filter even if you keep the UA rules. And, separately: make sure your instance metadata service is on IMDSv2 with hop-limit set to 1, because the most common payoff for the SSRF profile above is exactly the credentials your IMDS hands out.
The Bottom Line
A single client, on Google Cloud, generated more than 42,000 distinct AI crawler user-agent strings over five weeks while running four credential-theft modules against cloud metadata endpoints. The only detection method that survived was reverse DNS, because everything else was beating a costume. If your allow-list trusts a user-agent string, the costume is already winning.