A Stealer Now Takes Your AI Agent's Tokens. Six Reports From One Week, and What Our Feed Already Had.
Gen Threat Labs published an analysis of Warden Stealer on October 8. It is a Rust infostealer sold as a service, and besides the usual browser and crypto-wallet theft it takes AI coding-agent access and refresh tokens, MCP configuration credentials, prompt histories and conversation databases. We checked our own machines the same day we read it: no plaintext credentials in our local MCP configs, and the agent config file is readable only by its owner. Then we went through six research reports from the past ten days and put their indicators into our feed. This post covers what we added, what we already held, and who held it first. In every case that was somebody else.
Warden Stealer: the stealer that reads your agent's config
The target list is what makes Warden worth a post. A developer laptop running an AI coding agent now holds a token that can act on that developer's repositories and cloud accounts, and an MCP config that often carries API keys in plain text. Warden's authors know that, and they built for it.
What to check on your own machines: open each MCP server config your agents load and look for keys written inline. Move them to an environment variable or a secret store, and make sure the config file is readable only by your user. Treat an agent's refresh token like an SSH private key: if a machine is compromised, revoke it, don't just change your password.
What we ingested: 1,305 indicators from Gen's published IOC repository, all read back after the write. That is 1,050 SHA-256 sample hashes at confidence 85 and 256 C2 domains at 80.
What we already held: 154 of the 256 domains were in our index before Gen's report, from ThreatFox community submissions at confidence 70, the earliest on July 29. That is about ten weeks earlier, and the credit belongs to the people who submitted them, not to us. It is also the same gap we wrote about earlier today: the early records sat at 70, in the default CSVs our subscribers pull but below the 80 floor our own edge blocks at. The convergence job we built today only handles IP addresses, so domains like these are the next lane to cover. Six sample hashes were also already held, from MalwareBazaar, from August 28.
MALFEX / Overlord: the membrane held
CloudSEK (September 30) and Checkmarx (October 5) reported a malicious npm campaign that runs from a postinstall script and drops three payloads, including the Overlord RAT. We ingested 43 indicators. Then we asked our own pre-install check about each of the 8 packages: all 8 come back block. They were already on our deny-list from OSV malicious-package records dated September 22 to October 8. The first ones landed before CloudSEK published and the last ones after Checkmarx did, so anyone whose agent calls check-package before an install was covered as each record arrived. The C2 address 104.234.65[.]75 was already held too. The OSV contributors deserve that credit. Our part was carrying their records to the install decision.
Midnight Mimosa: malware that ships in the phone
Bitdefender reported on October 8 that low-cost Android devices built on MediaTek chips arrive with malware already in the firmware, inside system apps like the gallery and browser. It runs ad fraud and turns the phone into a residential proxy for someone else's traffic. We ingested 140 indicators, none held before: 127 sample MD5s at 85, two domains and two IPs from the malware's own infrastructure at 80, four proxyware control domains at 75, and the domains Bitdefender credits to Dr.Web at 70 to 75 because we did not verify them. We left out 85.17.70[.]38, which Bitdefender's own erratum says is a sinkhole. Blocking a sinkhole blinds the researchers who run it. We also left out the Android package names, because our package lane feeds an npm and PyPI deny-list and a name like com.android.browser does not belong there. They are in the record descriptions instead.
For a household or a small office the advice is unglamorous. The cheapest phone on the shelf may be the product being sold, not the thing you bought. If your network blocks on our domain list, these C2s are in it.
AdFection: spyware delivered through a targeted ad
Citizen Lab's Report 195 (October 15) traces a zero-click infection of a device at Al Jazeera to targeted advertising, with a Candiru Windows DLL as the payload. We ingested 11 indicators: the DLL hash, four C2 domains, two validator domains, two profiling domains, and two more hosts from the attack chain. The DLL hash was already in our index from a ThreatFox record that arrived today, four days after Citizen Lab published, so that is corroboration, not an early sighting. We did not ingest the ad-tech vendors' corporate infrastructure the report names. Those are companies, not attacker servers, and a blocklist is the wrong tool for that argument.
CL-UNK-1211: AI-assisted intrusions on government Linux
Unit 42 reported on October 15 an espionage cluster against government Linux servers that used AI tooling during the intrusion. We ingested 31 indicators from the report's IOC section only: 10 SHA-256 hashes, 17 IPs and 4 domains. One hash, a GSocket reverse shell, was already held from a Talos post in June. GSocket is a shared open-source tool, so that match tells you the tool, not the actor.
UAT-6275: nothing to add
Talos published on October 14. All 301 of its indicators (122 hashes, 63 IPs, 85 domains, 31 URLs) were already in our index, because our Talos collector reads their GitHub IOC repository directly. Fourteen of them also appeared in TweetFeed between July and August 2025. That is corroboration, not a lead: it tells you the infrastructure is old, not that anyone saw this campaign coming.
What this adds up to
Added this week: 1,530 indicators across five reports, every one read back by primary key after the write.
Already held before the vendor published: 154 Warden domains, 6 Warden hashes, 8 MALFEX packages and their C2 IP, and the GSocket hash. All of them came from third-party lanes: ThreatFox, OSV, MalwareBazaar and Talos. The AdFection hash and all of UAT-6275 were held too, but only after the reports came out.
Our own lead: none. Every early record belongs to the people who submitted it.
The pattern from this morning's post held again. The community lanes had a lot of this early. The question is what you do with it. For packages the answer already works: check-package turned OSV records into a block before the vendors published. For Warden's domains, the records sat at 70. That is the next thing we are fixing.
The free key that pulls all of it, at any confidence threshold you choose, is at https://analytics.dugganusa.com/stix/register?utm_source=blog&utm_campaign=six-reports-one-week
If this was useful, or if it wasn't, the rating widget below takes ten seconds and is the only way we know.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=a-stealer-now-takes-your-ai-agent-s-tokens-six-reports-from-one-week-and-what-our-feed-already-had
Comments