The inside view of the worst supply-chain spree on record
Reporting by WIRED’s Andy Greenberg, picked up by Ars Technica on Saturday, lays out something that sounds like a spy thriller but happened in a group chat: Google’s security subsidiary Mandiant had an undercover analyst inside TeamPCP’s inner circle for most of the hacking group’s existence. The disclosure came from Austin Larsen of Google’s Threat Intelligence Group in a talk at SentinelOne’s LABScon conference. For anyone who writes software that ships from a package registry, the details are worth more than the intrigue.
TeamPCP ran the worst software supply-chain attack campaign on record. The group tainted hundreds of open-source programs with malware, stole developer accounts to keep the poisoning going, and even shipped a Dune-themed self-spreading worm to automate the process, breaching more than a thousand companies before two of its alleged members were arrested in Australia last month.
Day one, from the inside
The analyst, whose identity Google declined to reveal, was one of roughly a dozen members with access to a core chat the group called CanisterWorm. Larsen said the persona had spent months building trust with one of the actors who was later invited into the group, so Mandiant was watching from almost the beginning. When TeamPCP started its supply-chain frenzy in March, Google already had a seat at the table.
Guardrails matter here, and Larsen was explicit about them. The undercover analyst never touched the hackers’ own tooling and never encouraged an attack. The description Google used was a fly on the wall, saying only enough not to be suspicious. That line is doing a lot of work, and companies with threat intelligence teams will be arguing about it for a while, because the boundary between observing and embedding is a policy question with no settled answer.
What the vantage point actually bought
The mole’s access translated into disruption, and the mechanism is the useful lesson. Google’s team reached a server where TeamPCP stored credentials stolen from victims: usernames, passwords, and access tokens the group planned to use for extortion. With more breached companies than could be individually warned in time, Google flipped the notification problem around. Instead of hunting down victims one by one, it contacted the providers where those credentials could be used, Amazon Web Services and Microsoft among them, and had credentials revoked at the provider level. Hundreds of notification emails went out, and the ransom scheme largely collapsed before it started.
That is a playbook change. Incident response normally flows downstream from the breached company. Here the response happened at the cloud provider, upstream of every victim at once, using intelligence from inside the attacker’s own infrastructure. Expect more of this: Google stood up its Cyber Disruption Unit precisely to move from writing reports to burning down attacker operations.
The same inside visibility caught something stranger. Google learned that someone in TeamPCP’s core circle was using an AI tool to develop a zero-day exploit in a widely used login product, aiming to bypass two-factor authentication. Google got a copy of the code, tested it, found it worked with a few tweaks, and warned the developer, who patched the flaw. A working zero-day written with AI assistance and intercepted before it was ever fired is a rare data point, and it landed in the wild months before most people believed AI-written exploits were a real thing.
Betrayal from inside the criminal economy
The other thread reads like a reminder that criminal ecosystems are ecosystems. TeamPCP partnered with ShinyHunters, the group behind some of the most damaging breaches of the past few years, and then ShinyHunters turned on its supply-chain partners and fed intelligence to Google. Meanwhile Google traced operational security mistakes made by one of the two Australians now charged as leading members, passed identifying details to law enforcement, and the arrests followed. Criminal groups are now watching for moles, for treacherous partners, and for the cloud providers themselves, all at the same time.
What defenders should take from this
Two things, one practical and one uncomfortable. The practical one: your exposure to this class of attack runs through the packages you install and the developer accounts that publish them. TeamPCP’s entire approach relied on poisoned dependencies and hijacked maintainer credentials, which is exactly what lockfile pinning, signature verification, and hardware keys on registry accounts are for. If you maintain an open-source package and have not turned on 2FA yet, you are the soft target this story is about.
The uncomfortable one is that disruption now beats detection. Google did not write a threat report and wait for at-risk companies to act. It revoked credentials at the provider, tipped off a software vendor with a patch deadline, and helped make arrests. For defenders, that means your cloud provider may already know something about the attack hitting you before you do, and it means the intelligence community you trust most may be closer to the attacker than you think.