Google's mole inside TeamPCP saw 500,000 stolen credentials and a gang that could barely cash them

Half a million credentials, tens of thousands of dollars

The Australian Federal Police says TeamPCP's malicious code enabled the theft of more than 500,000 credentials from more than 1,000 organisations (AFP, 27 August 2026). Austin Larsen of the Google Threat Intelligence Group (GTIG) estimates the group was pulling in only tens of thousands of dollars in extortion payments (WIRED, 18 September 2026). Take the top of that range, $99,999, and divide by 500,000: the gang realised under 20 US cents per stolen credential. At $10,000 it is 2 cents.

That ratio is the most useful thing to come out of Google's disclosure that a Mandiant persona sat inside TeamPCP's inner circle during its spring 2026 supply chain spree. It says the gang's hard problem was never getting in. It was turning access into money, and that is why it handed its loot to other extortion crews.

This site has touched TeamPCP twice this week. On 16 September we noted that Mandiant tracks TeamPCP intrusions as UNC6780 but that the report we examined did not link them to that Shai-Hulud case (briefing). On 19 September CrowdSec traced the copy of about 170 private repositories to an OAuth token harvested by the May TanStack npm compromise (briefing), one of the attacks WIRED attributes to TeamPCP.

What the source actually is

There is no Google report on the infiltration. The primary source is a conference talk: Larsen presented at SentinelOne's LABScon on 18 September 2026, and the detail in circulation comes from his interview with WIRED's Andy Greenberg published the same day and syndicated by Ars Technica on 20 September. The talk has not been published as a paper or video that we could find. Everything about the persona, the chat and the credential server therefore rests on one Google researcher's account, relayed by a journalist.

Parts of it can be checked against documents Google and the police did publish, which is what the table below does.

The operation's main claims, checked against sources we fetched (WIRED interview; AFP release; GTIG reports of 11 May, 30 July and 8 September 2026)

Claim (Larsen, via WIRED)	Corroborated in a document	Not stated anywhere we found
TeamPCP is UNC6780 and ran a spring 2026 supply chain spree	Yes: GTIG 11 May and 8 September name TeamPCP as UNC6780	Group size beyond about 12 core chat members
A persona was in the core chat from March	No: no Google document mentions a persona	How long it stayed; the exile date
An insider built an AI-assisted 2FA bypass zero-day	Partly: GTIG 11 May describes the exploit, actor unnamed	Which product, which vendor, which CVE
Google got credentials revoked via AWS and Microsoft	No	How many credentials, how many victims notified, the date
Google tipped the FBI after seeing a Drive backup	Partly: AFP says tips from several threat assessment companies	The date of the tip; that Google was one of the firms
The analyst broke no law	No	The guardrails, and which legal regime applied

A US indictment of the 21-year-old also exists. The Department of Justice release (Northern District of California) would not load for us behind a bot check, so we rely only on search result text for it: conspiracy to commit Computer Fraud and Abuse Act violations and obtaining information from a protected computer, over conduct in spring 2026. Treat that as unverified until the release or the indictment itself is read. This briefing does not name the defendants; the AFP release does not either.

Is this the same group, and is it Shai-Hulud?

Yes on the first, not necessarily on the second. GTIG's 11 May report says TeamPCP is tracked as UNC6780 and describes its late March compromises of Trivy, Checkmarx, LiteLLM and BerriAI, with the SANDCLOCK credential stealer lifting AWS keys and GitHub tokens from build environments (GTIG). The FBI's cyber division assistant director calls the arrested men alleged members of TeamPCP in the AFP release. So the group in Larsen's talk, the group Mandiant calls UNC6780 and the group behind the August arrests are the same, on the record.

Shai-Hulud is where names start doing misleading work.

Names in this story and what each actually refers to (WIRED; GTIG 8 September 2026; Aikido; KrebsOnSecurity; The Register)

Name	What it refers to	Does it mean TeamPCP?
Shai-Hulud (September 2025)	An earlier npm worm	Not established: WIRED says TeamPCP's involvement is still unclear
Mini Shai-Hulud	A worm TeamPCP deployed to automate spread	Yes, per WIRED
Shai-Hulud framework	Open-source worm code; GTIG saw a PRC-nexus group drop it	No: the code is public and reused
CanisterWorm (malware)	npm worm seen 20 March 2026 after Trivy	Yes, per Aikido
CanisterWorm (chat)	TeamPCP's core chat, per Larsen	Yes, per Larsen
UNC6780	Mandiant and GTIG tracking name	Yes

The Register's report on the arrests calls Shai-Hulud one of TeamPCP's attacks (The Register). GTIG's 8 September tracker, by contrast, describes a China-nexus espionage group dropping the Shai-Hulud framework onto compromised hosts (GTIG). A detection or an advisory that says Shai-Hulud tells you which code ran. It does not tell you who ran it, and after the source was published in May it tells you less every month.

How the analyst got in, and for how long

Larsen's account of the access is short. A persona had spent many months building trust with one individual who was later invited into TeamPCP, and was brought in with them. In March, as the Trivy compromise and the CanisterWorm npm worm were starting the spree, that persona became one of about 12 members of the core chat. Larsen did not name the analyst and said it was not him.

The persona then gained access to a server where TeamPCP kept stolen usernames, passwords and access tokens. How that access was obtained is not stated.

The period is shorter than the headlines suggest. Around April, a few weeks after partnering with TeamPCP, ShinyHunters began extorting victims with TeamPCP's credentials and keeping the money. TeamPCP responded by shrinking its inner circle, moving its data to a new server and expelling ShinyHunters and several others, including Google's analyst. On that account the inside view lasted from March to some point after April, perhaps weeks rather than months. No end date is given.

What the inside view added

Most of TeamPCP's tradecraft was already public before the talk, from incident responders and from Google's own reports. The insider account adds four things: how the group was organised, how it made money, the link to an AI-built zero-day, and how the leader was identified. Larsen had earlier described TeamPCP to KrebsOnSecurity as a peer community of individually skilled actors, not a structured crew (KrebsOnSecurity).

Outside view before 18 September against the insider account, and whether it changes defensive practice (GTIG reports; WIRED; KrebsOnSecurity)

Outside view	Inside view (Larsen)	Changes what defenders do?
A big haul means a rich crew	Tens of thousands of dollars; loot shared with partners for a percentage	Yes: whoever extorts you may not be who stole from you
2FA zero-day by unnamed criminals (GTIG, May)	Built in TeamPCP's core circle with an AI tool	Somewhat: credential theft plus logic flaws in admin tools
A central credential store was assumed	A server of stolen credentials held for extortion	Yes: stolen secrets sit waiting; revocation speed matters
Attribution by forum research	Leader's own Google account backed up the new server	No: this is about their opsec, not yours
Targeting of popular packages	Not addressed in the insider account	Already actionable from public reporting

On package selection the insider account adds nothing new. The clearest public evidence is TeamPCP's recruitment contest after the third Shai-Hulud version's source was published in May: entrants were scored on weekly and monthly downloads of the packages they compromised, as KrebsOnSecurity reports from Dataminr's research. That is secondary reporting, but it matches the choice of targets: Trivy, Checkmarx tooling and LiteLLM are tools that sit in build pipelines with access to cloud keys.

On which credentials the gang prized, the Google documents are more specific than the talk. GTIG's May report names AWS keys and GitHub tokens taken from build environments. The September tracker says DUSTMAKER, TeamPCP's later stealer, pulls OIDC tokens from the memory of GitHub Actions runners and uses them to publish poisoned packages with valid, signed SLSA Build 3 attestations. Google routing its revocation requests through AWS and Microsoft fits that picture: cloud and code hosting credentials were the loot.

How long TeamPCP sat on access before using it is not stated in the talk coverage or in any Google document we read. What the insider account does show is that the credential store was kept for later extortion and shared with partner crews, so a credential stolen in March could still be used by someone else weeks later.

What Google did with it, and the link to the arrests

Larsen describes three actions. First, instead of contacting each victim, which he said would take too long, Google went to the providers where the stolen credentials worked, including Amazon Web Services and Microsoft, to get them revoked. It then notified victims, sending hundreds of emails in total. No count of revoked credentials or notified organisations has been published.

Second, the chat showed a member developing a zero-day exploit, with an AI tool, that bypassed two-factor authentication in widely used login software. Google obtained the code, confirmed it worked with small changes, and warned the developer, who patched. GTIG's May report describes what appears to be the same case without naming TeamPCP: a Python exploit for a 2FA bypass in a popular open-source, web-based system administration tool, which needs valid credentials first and exploits a hardcoded trust assumption (GTIG). GTIG says it has high confidence an AI model helped build it. Neither source names the product.

Third, attribution. After the expulsion, Larsen says Google learned through an unnamed trusted partner about some contents of TeamPCP's new server, and that it was being backed up to a Google Drive tied to a Gmail address he had linked, through a leaked BreachForums database and a 2019 forum dispute, to the 21-year-old later arrested. Google tipped the FBI. About a month later US law enforcement completed a warrant for the account data.

That makes this operation part of the story The Register reported on 28 August. The AFP says its investigation and the FBI's began in April 2026 after information from multiple cyber threat assessment companies, and that searches in Cottesloe, Hamilton Hill and Mandurah on 26 August led to 14 charges against two men aged 21 and 23 (AFP). The AFP does not name Google. Because Larsen places the Drive tip after the server move, which followed the April rift, it is our inference that Google's tip was not what opened the April investigation, but may have helped identify a suspect. KrebsOnSecurity published its own identification in August and says it knew the 21-year-old's identity from June.

Ethics and legal authority: what is said, and what is not

Larsen's only statement on conduct is that the analyst never took part in illegal hacking or encouraged the group's breaches. In his words they were "a fly on the wall, only saying enough to not be suspicious", and "there are guardrails around what we do". The guardrails themselves have not been published.

Legal and ethical questions the operation raises, and what the public account answers (WIRED; Nextgov; AFP)

Question	Stated	Not stated
Did the persona commit or encourage crime?	Larsen says no	Any independent review or oversight
How was the credential server accessed?	Only that the persona gained access	Method, and whether it involved using stolen credentials
Under which legal authority?	Nothing; Google is a private company, not police	Which country's law the analyst worked under
How did Google learn of the Drive backup?	Via a trusted partner and server contents	Whether Google looked at the account before the warrant
Was data from ShinyHunters used?	ShinyHunters sent a chat log unsolicited	Whether it was passed to police

The Drive question needs asking plainly, without assuming the answer. The account holder was Google's own customer. Larsen says Google learned the backup existed, gave the tip, and law enforcement then obtained the data by warrant. He does not say how Google knew the destination account without looking at it. There may be a simple answer, such as the partner's view of the server's configuration. Google should give it, because the same question applies to every Google Workspace customer.

The operation also sits inside a stated policy shift. Google launched a cyber disruption unit at RSAC in March 2026. GTIG vice president Sandra Joyce said it was not hacking back but made "legal and ethical use of intelligence" (Nextgov). Larsen told WIRED disruption is now one of GTIG's missions. For UK readers, persona work against criminal forums still falls under the Computer Misuse Act 1990 and other laws; nothing in Google's account explains how a similar operation would be lawful here, and none of it is guidance for doing one.

The comforting labels in this story

Signed provenance. GTIG says DUSTMAKER used stolen runner OIDC tokens to publish packages with valid, cryptographically signed SLSA Build 3 attestations that pass automated trust checks by AI coding agents (GTIG). An attestation proves where and how a package was built. It does not prove the build was meant to happen.

Security tooling. The spree started in a vulnerability scanner and a security vendor's tooling. The word "security" in a tool's description is not a reason to give it broad pipeline secrets.

AI utility names. DUSTMAKER created GitHub Actions tasks with names like "Copilot Setup" and then deleted their run logs. A workflow's name is not a control.

Undercover. "Fly on the wall" describes the analyst's intended role. It is not a description of the controls on that role, which remain private.

Method, accusation and commercial interest

Google sells threat intelligence through Google Threat Intelligence and Mandiant. A story of a mole inside a notorious gang is excellent marketing for that business, and the disclosure came at a vendor-run conference. That does not make it untrue: the AFP confirms threat intelligence companies supplied the information that started the investigation, and GTIG's May report documented the zero-day months before the talk. It does mean the most dramatic claims, the persona and the revocations, are the ones nobody outside Google can check.

Google's July mitigation guidance for this class of attack is sound, but it also points readers to Google's Assured Open Source Software, its OSV-Scanner tool and a Wiz framework (GTIG). The controls below are chosen on what the evidence supports and do not depend on any one vendor's product. The two arrested men have been charged, not convicted, and the attribution trail comes from Larsen's account and Krebs's reporting, not from a court.

What a UK engineering team should change

The insider view's lesson is that stolen credentials sit in storage, get shared with partner crews, and are defeated by revocation. Put speed of revocation ahead of everything else, then shrink what a compromised build can steal.

The question that is left

Google says it watched TeamPCP from the inside, drained its credential store through AWS and Microsoft, and handed the FBI its leader. The AFP confirms the arrests and that private firms supplied the tips. Neither says how many of the 500,000 credentials were revoked before someone used them. For a UK team the question is not whether Google was inside. It is this: if one of those credentials was yours, would you have known from the provider's email where it had been taken from, and how long it had been waiting?

Key facts