IronWorm Ate Your AI Keys

Derek: Okay, so get this-someone just dropped a Rust-written worm into thirty-six npm packages, backdated the commits up to thirteen YEARS to make them look ancient, and signed the author as "Claude" Max: As in the AI assistant? Derek: As in the AI assistant. Not a coincidence. Max: Totally organic commit history, Nothing to see here. Derek: BleepingComputer and JFrog both broke this one open. The malware is called IronWorm. Rust binary eBPF rootkit Tor C2 The Works. Max: And it self propagates; once it's in your CI environment, it starts publishing trojanized versions of packages you own. Derek: Right, so your downstream users install what looks like a normal update, and they're already compromised. Max: Oh, and the target list? Eighty-six environment variables. We're talking AWS, GitHub, SSH keys, and the full 2026 AI provider stack, Anthropic, OpenAI, Gemini, the whole row. And here's where it stops being a billing problem and starts being something much worse, especially if those keys are wired into an agent pipeline. Yeah, we'll get into what that access surface actually looks like. We're also going to look at why attribution is basically a nightmare. J. Frog spotted commit naming overlap with Shai-Hulud, but no shared code, and somebody open sourced the whole tool chain in May, which helped nobody good. Super generous of them. And every scanner missed it. No CVE ever. Phoenix Security's data shows the first half of 2026 has already produced 4.5 times the malicious package volume of all of 2025. That's a bad number. We'll start at the beginning. How this thing got in and what the kill chain actually looked like. Max? Derek: A JFrog researcher is scanning NPM publish activity and something looks off. 36 packages all tied to the Arweave and WeaveDB ecosystem, republished inside a single tight window. Same account, Asteroid Dow. Minor version bumps, normal looking. Except every single one ships a 976 KB Linux ELF binary tucked inside a tools directory. A native binary in a JavaScript package. Fired via a pre-install hook so it runs before npm installs any dependency, before you've even agreed to anything. Right in BleepingComputer reported on this this week, JFrog called it IronWorm, Rust-written eBPF rootkit Tor C2. Not a quick weekend project. Dude, the commit trail is where this gets completely unhinged. The Hacker News reported the malicious commits across nine GitHub organizations. Max: Fifty seven of them showed an author name of Claude. Claude.users.noreply.github.com on a security podcast. You cannot make that up. And for anyone half paying attention on a Monday morning, Claude committing to your repo looks like what? An AI assistant your teammates set up. A bot totally automated. Move along. Exactly. You're trained to glaze over Dependabot, Renovate, automated CI noise. Derek: Oh, another Claude commit; carry on. Wait, back up-the time stamps are the other half of this. Phoenix Security documented that those commits were backdated up to thirteen years, specifically to blend into each repo's existing commit history. Thirteen years. GitHub Actions logs showed every push happened in the last few days, but open the commit log, looks like legacy trusted code. So the attacker thought through the full review experience. Max: Not just will this run, but will a tired developer scanning git blame even pause on this? And the answer clearly was no. BleepingComputer noted JFrog called IronWorm a custom carefully built implant from an operation with its own infrastructure. This wasn't off the shelf. So the Binary's novel, the commit cover is novel, the author name is AI-plausible camouflage, which makes me wonder, what's actually inside that 966 kilobytes? Derek: Bytes that made JFrog look twice in the first place. So inside that binary, the nine hundred and seventy six kilobyte one, this is where the engineering gets actually impressive. Wrong word, but you know what I mean. Max: No, I know exactly what you mean. The attackers strip the UPX magic bytes from the packer stub. Standard unpackers look for that signature, find nothing and bounce. JFrog noted IronWorm also encrypts every string with a unique per call site key; not one hard coded key, A different key per usage site. Derek: So you can't just grep for strings and map the binary. You basically can't. Static analysis becomes a slog. And then there's the eBPF rootkit. Okay, walk me through that. eBPF runs at kernel level. The rootkit rewrites what the kernel reports back to user space. You run p s, you run top, clean results. IronWorm just isn't there as far as those tools are concerned. Max: Concerned. And if you try to attach a debugger, it kills the process doing the attaching. Trying to inspect it can crash your shell. Derek: Wait, back up. It actively kills anything trying to look at it? Max: Yeah, anti-debugging trip wires baked into the rootkit. Most end-point security products that work off process level visibility just don't see it. Derek: Wow. JFrog said they checked it against every known InfoStealer and eBPF rootkit framework they could find. Max: You can think of and match none of them. Custom built, start to finish, right, and the propagation piece is where it gets almost elegant in a terrible way. When IronWorm runs inside a CI environment, it requests an OIDC token through npm's trusted publishing workflow, and exchanges it for a short lived publish token. So no stored credentials needed; none; it mints its own. Then it publishes a trojanized version of a package the victim Speaker 3: needs to download and execute. Max: The Victim owns; new Developer installs that package; binary drops; preinstall fires; cycle repeats. Derek: So the attacker does nothing after the initial compromise and the worm just spreads. Max: That's the design. Each new victim becomes a new publisher; the blast radius grows on its own. Derek: And given what it's hunting-which is a different kind of frightening-that credential sweep wasn't random, not even close-the targeting list reads like something Speaker 3: out of a phone book: Max: It's like someone had a very specific Derek: Pacific shopping list in mind. That's where we're going next. So that credential list, let's actually sit with it for a second. BleepingComputer reported 86 environment variables and 20 credential file paths. That's not a generic sweep. That's somebody who knew what a modern AI developer's machine looks like in 2026. Yeah, the Hacker News broke down the full target list from JFrog's research. Anthropic API key, OpenAI API key, Gemini API key, Cohere API key, Mistral API key, Groq API key. key, Perplexity API key, XAI API key, and then Cursor configs on top of that. Every major inference provider. Max: Wow. It's practically a vendor comparison chart. Derek: Right? Someone did their research. But here's where I want to push on this. Because for a lot of people hearing API key theft, the instinct is, oh, that's a billing problem. Someone runs up my OpenAI tab. No, no, no, that's completely wrong if you're running an agent pipeline. Max: pipeline. Derek: Exactly. Walk me through it. So your production agent has an Anthropic key. That key doesn't just call the API; depending on how you've wired the agent, it can make tool calls into your database, your file system, external APIs. An attacker with that key is not stealing tokens; they're stepping into your agent's seat. Oh, that's fascinating. Because the key isn't just auth, it's operational authority. Inference access, plus tool call authority, plus whatever downstream system you're using, plus whatever downstream system you're using, plus whatever downstream system you're using. In systems the agent is credentialed to reach (that's not a billing problem, Derek, that's an agent takeover surface), and this is why the targeting reads less like opportunistic credential theft and more like someone specifically wanted AI pipeline access. Yep, and then... wait, we haven't gotten to the Exodus piece yet. Oh, you're going to love this part. Oh, I already don't love it. JFrog found a dedicated module that targets the Exodus desktop wallet. wallet. It injects a JavaScript hook into the Electron app, kills webSecurity, contextIsolation, nodeIntegration, and then captures the seed mnemonic the moment you unlock your wallet. So it's not just scraping a file, it waits. Max: Mm-hmm. Derek: It sits there and waits for you to type your password. That's a completely different extraction path. Cloud keys, AI provider keys, now live crypto wallet interception? This attacker was thinking across multiple monetization lanes. Max: Simultaneously, which raises an uncomfortable question: Something this purpose built targeting AI infrastructure this specifically-who writes this? That Shai-Hulud lineage, JFrog flag, starts looking a lot more relevant. Derek: So the whodunit question. JFrog flagged something interesting. IronWorm uses the same commit naming patterns as Shai-Hulud. Same names. That's not coincidence territory. Right, but, and this is where attribution gets slippery, JFrog also said they couldn't find a clear connection. No borrowed code they could recognize, no source repo URLs in the binary. Their exact words were, custom, carefully built implant from an operation with its own infrastructure. Structure. Wait, back up. So the commit names match, but the code doesn't overlap. That's either these operators had access to the Shai-Hulud play book before anyone else did, or-or someone studied the public campaigns closely enough to mimic the operational style without copying the code. Which brings us to May twelfth, because, oh man, that date matters: plot twist of the year-TeamPCP open sourced the entire Shai-Hulud worm on GitHub. Not leaked, deliberately released, README literally said "change keys and C2 as needed" with a thousand dollar Monero bounty for whoever ran the best Speaker 3: copy. Derek: Ran the biggest supply chain attack using it. They ran the competition. A malware hackathon. Dude. And GitHub pulled it fast, but not before multiple forks. The clones hit NPM days later. So now the attribution problem is industrial scale. Anyone with a GitHub account in a weekend can deploy Shai-Hulud tradecraft. Exactly. And IronWorm specifically. JFrog says it's its own infrastructure, its own operator. So either this predates the May 12th release, or whoever built it had early access and it already diverged significantly. Particularly, which means trying to pin this on TeamPCP is probably the wrong exercise. The commit pattern overlap could just be the field converging on what works. JFrog called IronWorm Shai-Hulud's rustier cousin. Same bloodline maybe, same family of technique, but its own operator, its own C2, its own infrastructure, and its own mistakes. Wait, mistakes? The eBPF object had debug metadata still in it, recoverable source lines, and the operator hard-coded their own wallet recovery phrase into the skip list. Skip list, they accidentally protected their own wallet from their own stealer? Yeah, JFrog's read, this might not be the final form, could be a rehearsal. So we've got an implant that's custom-built, operator unknown, attribution fog courtesy of an open-source worm release, and JFrog thinks it might still be warming up? That's what makes the defensive side of this so ugly, and that's exactly what we need to get into. Max: So if you're a defender and you just watched that whole OIDC propagation loop play out, your scanner gave you a green check the entire time. No CVE. Nothing. Zero. IronWorm never got one. Phoenix Security tracked 59 supply chain campaigns across NPM, PyPI, VS Code from June 2024 through this month. Every single campaign zero CVEs assigned during active exploitation. Every one. Derek: That number stops me cold, because every scanner in a typical CI pipeline is fundamentally CVE dependent. No CVE means what exactly does a defender have to work with? Max: Okay, so here's the brutal part. Derek: The packages pass Trusted Publishing OIDC validation with legitimate tokens, NPM's own issuance, signed, verified, green. Your only allowed signed packages policy just waved it through. Max: The security theater was technically accurate. Derek: Exactly. And then once it's on disk, the eBPF rootkit is rewriting kernel telemetry before your EDR can even ask the OS what's running. P.S. Top. Clean. Your end point tools use the same lie. Wait, back up! JFrog and daily security review both flag this explicitly: "On systems without kernel lockdown enabled, standard process inspection will not surface an active infection; full reimaging is the reliable remediation path. Right, right. And most CI runners are not running with kernel lockdown enabled. That setting gets disabled the minute someone hits a compatibility snag. So what does actually work? Like genuinely, what would have caught this? A few things. Tarball versus source divergence. The published tarball had a 966 kilobyte ELF binary that is not in the GitHub source tree. A diff check at install time catches that cold. And Phoenix Security flagged that first half of 2026 number 4.5 times. times the malicious package volume of all of 2025. So this is not a one-off quirk in the NPM feed. The rate is accelerating hard. Behavioral detection is the other lever. Watching for a post-install script that drops a binary and immediately opens a Tor connection. Max: Yeah. Derek: That pattern is detectable if you're watching syscalls at install time, not just CVE feeds. And kernel lockdown is the eBPF rootkits kryptonite. Enable it and the process hiding fails. The rootkit stealth layer just stops working, which means every org running CI without kernel lockdown today is one poisoned package away from an invisible infection. And that gap, the CVE scanner seeing nothing, the OS lying to your EDR, that's exactly what we need to talk about Monday morning. What you do about it. So, Monday morning: you installed something from that Arweave ecosystem in the last few weeks. What's first? Rotate everything, and I mean everything, but the order matters: AI keys first, OpenAI, Anthropic, Cursor, because a stolen inference key with tool call authority is an active agent surface right now. Then AWS, GCP, NPM tokens, SSH keys, HashiCorp Vault credentials after that. Why AI keys before cloud keys? Because cloud creds usually sit behind IAM controls, a stolen Anthropic key can be firing agent actions the second the attacker wants. That's a live weapon, not a dormant one. Right. And don't just rotate; audit. JFrog specifically recommends checking your repos for commits from the "Aukri Bit" identity or backdated commits attributed to "claude", "dependabot", "renovate", or "github-actions." Those are the four spoofed Speaker 3: identities. Derek: Aloof author signatures IronWorm used across all nine compromised organizations. That's the whole point of the disguise. Now the infrastructure item, kernel lockdown. We mentioned it last segment, but here's what it actually does for you: SC Media confirmed that on hardened systems with kernel lockdown enabled, the eBPF rootkit's stealth capabilities are reduced. It can't fully rewrite process telemetry the way it does on a default Linux box. So if your CI runners are shipping without kernel lockdown, locked down today. That's the gap to close this week, not next quarter. And if your monitoring stack can't detect eBPF-based process hiding right now, find that out before IronWorm's next wave does it for you. Love that framing. Okay, the single Speaker 4: Yeah Derek: most concrete thing: If you have a CI pipeline publishing to NPM, pull up your trusted publishing OIDC configuration today and verify no unauthorized scopes. Hopes have been added. That's it-that's the one action. Because IronWorm's whole self replication loop runs through a stolen OIDC token exchange, no stored credentials required. Clean OIDC config cuts the self replication chain, and it takes about ten minutes to check. BleepingComputer put the affected package count at thirty six, with roughly thirty two thousand combined monthly downloads, contained before it hit anything bigger. But the operator pulled the packages within a day, which means the clean up Speaker 3: was just getting started. Derek: The Cleanup window is razor thin. J. Frong called this a rehearsal. The debug metadata left in the binary, the hard-coded wallet phrase, those are operator mistakes. The next version won't have them. Rotate the keys, audit the commit history, enable kernel lockdown, check your OIDC scopes. Everything else is noise until those four are done. All right, that's IronWorm: Rust-built, eBPF hidden, and apparently naming its commits after Claude on a security podcast. Still cannot get over that. Speaker 5: The audacity—and the part that stuck with me? JFrog checked it against every known InfoStealer and rootkit framework they could think of, matched none of them. Derek: Wow. Speaker 5: Custom-built soup to nuts. Derek: Which is why the Monday action item isn't review your posture, it's rotate your AI provider keys first. Those eighty six environment variables IronWorm targets turn a stolen Anthropic or OpenAI key into an agent takeover surface, not a billing headache. Exactly. And audit your repos for spoofed commit identities before you trust anything that looks like legacy code. Thirteen-year-old timestamps. Wild. Wild. Okay, if this one saved you from a bad deploy, drop us a review wherever you listen. New episodes every Tuesday. Thanks for riding along on Autonomous Autopsy. See you next week.