An investigator from Google's Mandiant infiltrated TeamPCP, a group behind repeated supply chain attacks. WIRED reported the story on September 18 in an exclusive interview with Austin Larsen of the Google Threat Intelligence Group (GTIG). The information gathered reportedly led to requests that AWS, Microsoft and others revoke stolen credentials. When access stolen from development tools fuels the next intrusion, fixing the distributed software is not enough; the stolen keys still have to be dealt with.
Turning infiltration intel into revoked keys
The infiltrator was not Larsen himself but an anonymous analyst. According to WIRED, Google contacted the providers of services that accept credentials before notifying affected companies individually. The analyst was later removed from the group's internal chat, so not everything could be monitored on an ongoing basis. WIRED's exclusive report
This response matters because of what TeamPCP targeted. In an analysis Google published on July 31, the company said TeamPCP, which it tracks as UNC6780, targeted PyPI for Python, npm for JavaScript and Docker Hub, which distributes containers, among others, between February and May 2026. It ran credential-stealing programs such as SANDCLOCK from tampered packages to collect high-value secrets.
CI/CD, which automates building, testing and distributing software, is handed access rights so it can run its tasks. If attackers steal credentials there, they can turn the malicious distribution of a program into another intrusion. Google explains that TeamPCP monetized what it stole by selling it directly and by partnering with groups that carry out extortion through ransomware and data theft. Google's analysis
In other words, incident response requires two things: removing the malicious artifacts and making the leaked access unusable. Finishing only the former does not remove the keys in the attackers' hands. Google's revocation requests cannot be equated with full recovery for every victim organization or a complete stop to the attacks, but they matter because they targeted the permissions that could be used in the next intrusion.
Why attacks continued even after keys were rotated
The post-incident report Trivy's developers published on March 30 records the concrete difficulty of renewing credentials. It began on February 27, when secrets were stolen through a vulnerable workflow that used GitHub Actions' pull_request_target. The attacker used the access obtained to continue stealing from other repositories and organizations it could reach.
Even after the Trivy side revoked credentials on March 1, another intrusion path remained and was used in the malicious distribution on March 19.
The "other path" here does not mean a newly discovered unknown vulnerability. According to the report's timeline, after the credentials of an automation account were revoked, another compromised user extracted secrets in a different repository. The activity on March 19 reportedly used the same token observed at that time.
| Date (2026) | Event disclosed by the developers | Effect on credentials and distribution |
|---|---|---|
| March 1 | Trivy revoked the credentials of an automation account it had confirmed as compromised | Theft of secrets through another user remained possible |
| March 19 | Trivy's release process was run using stolen credentials | Malicious Trivy was distributed |
| March 24 | Malicious code in LiteLLM PyPI packages 1.82.7 and 1.82.8 | The company believes Trivy, used in its CI/CD, was the entry point |
The table arranges the events by date from Trivy's post-incident report, "Timeline of events" and LiteLLM's official explanation. The route from Trivy to LiteLLM is LiteLLM's own view and does not indicate that the same token was used at both companies.
The Trivy team also cited as a lesson that service accounts with strong cross-organization permissions had not been sufficiently isolated. Rotating one user's keys does not end containment if the attacker remains as another user. This shows the need to know which accounts can operate on which organizations.
However, it would also be wrong to treat every user of the same tool as a victim. LiteLLM says its official Proxy Docker image was not affected because it pins its dependencies and does not rely on the problematic PyPI packages. What determines whether you were hit is not just the product name but what you pulled in and through which route.
Two arrested, investigation continues
On August 27, the Australian Federal Police (AFP) announced that it had arrested a 21-year-old and a 23-year-old man in Western Australia the previous day and charged them with 14 offenses in total. The announcement was a joint one involving the FBI and Western Australia Police, and the two are suspected of being key participants in TeamPCP. The announcement describes the investigation stage and does not mean a conviction.
Authorities estimate that the malicious code may have compromised more than 1,000 organizations worldwide, leading to the theft of over 500,000 credentials and the exfiltration of at least 300GB of data. This is not a figure for 1,000 confirmed company intrusions, and the affected include organizations other than companies. AFP's joint announcement
The investigation began in April after information from multiple private-sector threat research firms. The AFP called that information essential to the investigation, but it is continuing to analyze seized data and pursue the case, and has not ruled out further arrests and charges. Reading this as Google alone solving the case goes further than the authorities' account.
In his own post on August 27, Larsen also described TeamPCP as a community of individually skilled people. The charges against the two men and the disappearance of the group's access and attack capabilities must be verified separately.
What development teams should review: distribution paths and access rights
In the remediation described in Trivy's report, the team revoked GitHub and distribution-destination tokens across the board and did not issue new tokens until all existing access had been revoked. This avoided renewing keys while a compromised path remained. It also pinned GitHub Actions to specific commit SHAs and took measures so that releases at the relevant distribution destinations can no longer be modified afterward.
Revoking credentials and pinning distributed code protect different things. The former stops operations using stolen keys, while the latter reduces the risk that the code or artifacts you use change unintentionally. Pinning does not guarantee the safety of the pinned code itself, so neither is sufficient alone.
In its March 30 update, LiteLLM also said it published clean versions from CI/CD v2, which strengthened environment isolation and separation of the release process. That was a recovery measure at the time. What should be checked in the post-recovery design is how far the permissions given to tools used for scanning reach, up to the publication of the product.
Google's July mitigation document recommends not only an SBOM (software bill of materials) but also an ABOM, which tracks third-party development tools and pipelines. Knowing only the components built into an app could leave external tools that run during builds and scans unnoticed. The proposal is to capture attack paths including the development environment.
The document also recommends that npm and pnpm users wait at least 24 hours after a new package is published before pulling it in. This creates a grace period for malicious versions to be discovered and removed, and does not guarantee safety after the wait. Measures at the point of intake need to be combined with knowing which permissions to revoke after a compromise.
When the next malicious package comes to light, can you trace the environments that ran it and link them to the services they could access? If you already know the scope of your response, investigation and revocation after a breach notice become easier to carry through, from accounts inside the organization to external services.