DARKARRAY

In mid-October a client that looked like an ordinary desktop browser asked the emulated AI server for its environment file, took the monitored cloud credential planted there, and then fetched the site icon the way a browser does after loading a page. It came through a residential proxy: a consumer internet address in Southeast Asia that commercial proxy services rent out, shared by many unrelated users. Minutes later the key was used from a virtual machine on a major public cloud in the same region. The machine was the client itself, not a relay: its Python client reported an operating system kernel built for that cloud. Two different clients ran there, one built on the provider's Python library and one on its Go library, and between them they asked five questions: how much email the account may send, which identity the key belongs to, which users the account has, and, twice, which AI foundation models it can reach. Those are the two quickest ways to cash in a stolen key: sending spam or phishing through the provider's mail service, and using or reselling paid access to hosted AI models, the abuse known as LLMjacking. Nothing was launched or sent, and the calls stopped within half an hour. Unlike the operation in our previous finding, which waited about a day and went after computing power, this one checked the key within minutes and went after email and AI models. For defenders: a key left in an exposed file can be in a checker's hands within minutes, a mail-quota lookup or a model listing from an unfamiliar identity is a reason to rotate the key at once, and the address that read the file, here a rented residential exit, says nothing about who is behind it.

Evidence

First-party capture of the harvesting requests and of the credential issued to that address, matched to the provider's 5 alerts for its use, each naming the call, the source address and the client library. Both addresses classified (residential proxy exit, public-cloud virtual machine) with a third-party IP-intelligence service and public routing data.

Assumptions

That the address using the key got it from the harvester's operator: the key was issued only to the harvesting address, and the proxy exit hides who sent that request. The residential exit is shared by many users and identifies no one. The goals, spam and LLMjacking, are inferred from which calls were made; every call only read information, so no messages or model requests were seen. Two client libraries on one machine may be one operator's toolkit or two tools sharing a host.

Independence

Two independent records: the server's own request log and the credential provider's alerts. The exit and the machine were classified by a third-party IP-intelligence service.

In mid-October a scanner on a major public cloud swept the emulated server for secrets in a fraction of a second: environment files, infrastructure-as-code state and variable files, and a cloud provider's command-line configuration. It took the monitored cloud credential the server plants in such files. The key was never used from that address. About a day later it surfaced at a commercial VPN exit in Europe, where a client built on the provider's own Python library worked it for six hours. It confirmed which identity the key belonged to, listed regions, read service quotas eleven times, tried five times to launch servers, looked up machine images and the parameter that names the latest one, tried to create the default network it found missing, and checked whether a quota increase had been requested. That is the pattern of compute hijacking, renting someone else's cloud for mining or GPU work at their expense. About half a day after the last burst the same client came back once more and tried to buy a reserved block of GPU capacity, which points to GPU work rather than mining. Although the key was planted on a server that imitates AI model APIs, nothing was aimed at AI model services. Between bursts the client's retry settings changed three times, the mark of someone editing a script between runs rather than a fixed bot. The harvesting tool announces itself under a name that a public bot database and third-party abuse reports have recorded on other addresses of the same cloud since 11 October. Unlike the harvester in an earlier finding, which tested keys itself within minutes, this operation separates stealing from spending. For defenders, the address that read an exposed file says little about who will use the key. A quota lookup or a launch attempt from an unfamiliar identity is the signal to act on, and a key found in an exposed file should be rotated at once.

Evidence

First-party capture of the harvesting requests and of the credential issued to that address, matched to the provider's 32 alerts for its use, each naming the call, the source address and the client library. The harvesting tool's self-declared name checked against a public bot database and published abuse reports.

Assumptions

That the address using the key got it from the harvester's operator, directly or by sale: the key was issued only to the harvesting address, but the two may be different operators. The VPN exit is shared by many customers and identifies no one on its own. The purpose of the launch attempts is inferred from the sequence of calls; every call failed, so no workload or instance type was revealed. Reading the changing retry settings as edits between runs is an interpretation; several scripts run by one person would look the same.

Independence

Two independent records: the server's own request log and the credential provider's alerts. The harvesting tool also appears in a public bot database and in third-party abuse reports for other addresses.

The scanners that sweep this site for leaked secrets have started to borrow the names of AI crawlers. Over two weeks from late September, one tool worked from a new rented cloud address almost every day and sent up to about a thousand requests in under a minute each time. It looked for environment files, cloud credential files, repository metadata and debug consoles, and fired published exploits for web frameworks and AI tooling, among them the agent-builder flaw that runs attacker code through an MCP server configuration (CVE-2025-59528). Every request carried a crawler identity from a fixed list of about forty: the crawlers of the major AI labs, of AI search services and of conventional search engines, rotated so that a single address claimed more than a dozen companies within seconds. None of it was genuine. No address sat inside any of the ranges these companies publish for their crawlers, and the network edge verified none of the requests as a known bot. A second, separate tool asked specifically for coding assistants' settings files, model-provider key files and AI gateway configurations. Nothing was served: the site holds no secrets, and every probe was refused or answered not found. For defenders, a crawler name is now a disguise in its own right. Allowlisting by user agent lets this traffic through; the reliable test is the crawler's published address range or a verified-bot check, not the name it gives.

Evidence

Edge request records for this site (path, query string, claimed client, response and the edge's verified-bot classification), checked address by address against every published crawler range held by the operator's AI-lab watch. Exploits identified from request query strings and from the edge firewall's rule matches.

Assumptions

That the eight addresses are one tool. They share the same identity list, transport fingerprint, burst timing, marker requests and exploit set, which is strong, but one tool can be run by more than one operator. Request counts are the edge's sampled estimates. Request bodies are not recorded, so exploit attempts are identified from paths, query strings and firewall matches only. Some of the companies named have no published crawler ranges; for those, the conclusion rests on one address claiming many companies at once.

Independence

Single vantage point: this site's edge records. The range check uses the companies' own published lists.

The emulated server plants a monitored cloud credential in the configuration files that scanners look for. In late September an automated client, presenting itself as a search-engine crawler, fetched those files and received the planted key. Within minutes the same address used the key to ask the cloud provider which identity it belonged to, the standard first check a thief runs to learn whether a stolen key is live and what it can reach. Hours later it came back: it repeated the random-path probe it uses to detect servers that answer everything, worked through a reshuffled list of secret-file names, took the credential planted for that visit and tested it within minutes again. This is a repeating pipeline, not a one-off. Harvesting and validation run together and recur, so a leaked file keeps being re-read and the gap between a key leaking and someone trying it is minutes, not days. For defenders, a key found in an exposed file should be treated as compromised and rotated at once, and an identity lookup from an unfamiliar address is the earliest sign of use.

Evidence

First-party capture of the requests that retrieved the configuration files on both visits, each matched to the provider's alert for that credential's first use: same source address, identity-lookup call, client library identified as Node.js. Network context from the operator's own sensor records.

Assumptions

That harvesting and use were one operator. On both occasions they came from the same address minutes apart, which is strong but not conclusive: a shared or resold address could carry two clients. The crawler identity claimed by the harvester is self-reported and does not match the address, so it is treated as spoofed. Two cycles from one address show that this operator returns, not that it runs on a fixed schedule, and not how common this speed is across operators.

Independence

Two independent records of each event: the server's own request log and the credential provider's alert.

A scanner probing the emulated MCP endpoints completed a full protocol session, the probe of every MCP path, the initialise call, the follow-up notification and the session close an official client sends when it finishes, but spread it across about ten different source addresses in one network block within a single minute, one request per address. The block belongs to Hydra Communications Ltd (AS25369). It is a pattern rather than a one-off: 37 addresses from that network reached the emulated server over eleven days, almost all with a single request each, and the network sensor saw 119 of its addresses in the same period. Rotating the source address on every request keeps each address under per-address rate limits and out of per-address counts. For defenders, this traffic is only visible when it is grouped by network block or by network operator, not by address.

Evidence

First-party capture of the MCP requests (method, path, response status and timing per source address), with the network attribution and the wider address count from the operator's own sensor records.

Assumptions

That the requests belong to one scanner. Same block, same minute, one client identity and requests that together form exactly one protocol session make this strong, but the addresses could in principle be shared by several customers of the same network. Request contents were not analysed.

Independence

Two collectors on one host, one first-party and one vendor-processed. Not independent of each other in vantage point.

An earlier version of this page reported that everything reaching these AI ports was taking inventory and none of it was using the model. That held for the first day of collection and no longer does. Over eleven days the emulated endpoints received 311 chat or generation requests from 11 addresses, out of 108 that spoke a model API at all. The network sensor saw the same shift on a smaller scale: two of 39 AI-aware addresses moved on from listing models to requesting chat, generation or a model pull. Listing is still the common case, and most callers never go further, but the population now contains callers that spend inference capacity rather than count it. The operational distinction stands: a listing request is reconnaissance, and a generation request against an unauthenticated endpoint is someone using your hardware. The difference is that both are now observed here.

Evidence

First-party capture of POST requests to chat, generate and chat-completions paths, own monitoring traffic excluded. Network-sensor figure from the vendor field model_use_paths_requested. No model is ever run; every response is a fixed inert string.

Assumptions

That the own-traffic filter is complete. It combines known operator addresses with the monitoring user agents and cannot see an unlisted operator address, though none of the eleven callers matches either.

Independence

Two collectors on one host, one first-party and one vendor-processed. Not independent of each other in vantage point.

265 of the 311 generation requests, about 85 percent, came from a client identifying itself as AutoGenX-Engine. Its advertised version moved from 5.0 to 6.0, 6.2, 7.5, 8.0 and 8.5 across eight days, and on to 9.0 and 9.1 within a single later day, so it is being revised while in use and the pace is not slowing. Each run asked for the model list and then sent chat requests, hitting both emulated products within milliseconds of each other. Version 5.0 tried both the Ollama-native and the OpenAI-compatible chat path; every later version used only the Ollama-native one, which suggests the developer learned which dialect the targets it cares about actually answer. A separate client from the same address, OpenAI-Exposure-Scanner/6.4-Go, requested the OpenAI model list and one completion, which reads as the discovery half of the same workflow. The same tool name appeared from a second address on the same hosting provider. An independently published AI-honeypot feed had already classified the busier address as a relay customer, with about nine thousand hits in the week before it reached this sensor, and has since reclassified it as an identity prober; both labels fit a client that finds open endpoints and routes work through them. A commercial IP-context service describes the address as datacenter hosting offering anonymous remote-desktop access, the kind of rented Windows machine sold for exactly this sort of use.

Evidence

User-Agent strings and request paths from first-party capture; version sequence from first-seen times per agent string; prior and current classification from the AI Honeypot Observatory feed (CC0); network and hosting context from RDAP and a commercial IP-context service.

Assumptions

That the user agent is honest. It is attacker-controlled and could be copied by an unrelated client, which is why the second address is described as sharing the tool name and not as the same operator. Request bodies were not analysed.

Independence

First-party capture corroborated by one independent publisher's classification made a week earlier from a different vantage point.

An earlier version of this page said each prober spoke only one product's dialect and never tried the other. On five addresses that was true. On a hundred it needs qualifying. Most callers still ask for one product only: 82 used only Ollama-native paths and 17 only OpenAI-compatible ones. But 9 tried both, and they are heavily over-represented among the callers that went on to request generation: 3 of those 9 did, against 8 of the 99 single-dialect callers, and the three include the most active tool in this data. The single-dialect majority looks like scanners written against one product; the dual-dialect minority looks like clients that want any working endpoint and will speak whichever answers. For defenders, a request for the other product's path is still a useful signal on a quiet endpoint, but it no longer separates the cautious prober from the one that will spend your capacity.

Evidence

Per-address classification of first-party requests into Ollama-native (/api/) and OpenAI-compatible (/v1/) paths, excluding MCP paths and own monitoring traffic.

Assumptions

That path prefix identifies the intended product. Some Ollama builds also answer OpenAI-compatible paths, so a dual-dialect caller may be probing one product in two ways.

Independence

Single vantage point.

The emulated server lists a small set of models, one of which is an embedding model: it turns text into vectors and cannot hold a conversation, and its name says as much. 91 of the 311 generation requests named that embedding model anyway, from 6 of the 11 addresses that requested generation. Most came from the tool described above, which sent exactly as many requests to the embedding model as to the coding model, the signature of a loop over the model list that never reads what each entry is. But three other client families on four more addresses did the same, including one that sent a tiny prompt to two of the listed models, one of them the embedding model, within a second of listing them, from a browser user agent with none of the other headers a browser sends. Nobody asks an embedding model to chat by mistake. For defenders this is a cheap and precise signal: a chat or generation request naming an embedding-only model on an exposed endpoint is automated enumeration of what the endpoint will run, not a person using it. Since the server began refusing those requests the way the real product does, the answer to whether the loop notices is no: the dominant tool received the refusal on every one of its embedding-model requests and asked again on each later run, while sending exactly equal numbers of requests to every other listed model. It reads neither what a model is nor what the server says back.

Evidence

Requested model name on first-party chat and generation requests, grouped by user-agent family and by address, own monitoring traffic excluded. Model capabilities from the listing the emulated server returns. Counts cover requests up to 29 September, all of which were answered rather than refused.

Assumptions

That the requested model name is what the caller intended; it is caller-controlled. User-agent families are self-reported and group clients, not operators. Until late September the emulated server answered these requests with text instead of refusing them, so the counts above were all answered; behaviour after a refusal comes from the first day of refusals and one dominant tool, not yet from the other client families.

Independence

Single vantage point.

Two of the probing addresses geolocate to different countries yet sit on the same hosting provider, ran the same number of sessions, requested the same path, and completed the same number of handshakes. They are best read as one operator on two rented addresses rather than two independent parties. This is why the country breakdown on this page is labelled claimed origin and not attribution: with commodity hosting, the country a probe appears to come from is a purchasing decision. Counting distinct countries as distinct actors would have overstated this small population by a quarter. Later data points the same way from a different direction: the callers that went on to use a model arrived from a rented remote-desktop machine and from a residential proxy exit, and neither location says anything about who was operating them.

Evidence

Identical provider, session count, requested path and handshake count across two addresses geolocated to different countries. Later context for model-use callers from RDAP and a commercial IP-context service.

Assumptions

That identical behaviour on one provider implies one operator. Coincidence is possible at this sample size.

Independence

Single vantage point.

Most traffic the network sensor records is vendor-marked spoofable, meaning no handshake completed and the source address is only the sender's claim: across all of it, about one session in a thousand completed a handshake. The AI-aware probes remain the exception. Across 37 addresses doing model-API reconnaissance, 335 of 520 sessions completed a handshake, about two in three; for the two addresses that went on to request generation or a model pull, 31 of 41. On the first day this was reported as 23 of 31 on five addresses, with a caution that a percentage from so small a population moved with every judgement about who counted as one operator. The larger sample confirms the direction and settles the size: AI-aware traffic is mostly real, while the background it sits in mostly is not.

Evidence

Vendor field handshake_validated_sessions summed across the AI-reconnaissance and model-use categories, against total sessions, own monitoring traffic excluded.

Assumptions

That the vendor's handshake validation is accurate. It is not independently verifiable from this vantage point.

Independence

Single vantage point.

An earlier version of this page reported that the separate address running the emulated model APIs had not been found, with five generic requests in its first hours. That was a statement about the first hours only. The first unsolicited model-API request arrived within about a day of the address going live, and it now draws between forty and fifty distinct addresses a day, 386 in total over eleven days. The port that answers like a generic OpenAI-compatible server draws far more callers than the Ollama port, 319 addresses against 76, mostly because it also sits where generic web scanners look. The caution in the earlier entry still applies in reverse: a quiet honeypot was not evidence that nothing was looking, and it took about a day for that to show.

Evidence

First-party capture, own monitoring traffic excluded. The workspace reports the number of excluded own requests alongside the totals.

Assumptions

That the operator-traffic filter is complete. It is a hand-maintained address list plus the monitoring user agent and cannot catch an unlisted operator address.

Independence

First-party, no corroboration sought.