TeamPCP: the security scanner as the way in – profile of a supply-chain campaign

Who TeamPCP is.

TeamPCP is a financially motivated group that fits none of the usual boxes: not a state actor, not a classic ransomware crew, not a purely ideological outfit. CrowdStrike tracks it as Altered Spider, Google’s Threat Intelligence Group as UNC6780; the names DeadCatx3, PCPcat and ShellForce circulate in the scene, and the group’s own tool CanisterWorm is often used as a synonym for it. Oligo Security has traced its infrastructure back to 2020; in 2025 the group is said to have compromised more than a thousand software packages within four months.

The business model has drifted over the years. TeamPCP started with automated exploitation of exposed cloud control planes: open Docker APIs, unprotected Kubernetes clusters, forgotten Jupyter instances. That turned into cryptomining, data theft and extortion. From late 2025 came the step that put the group in the headlines: instead of attacking individual systems, TeamPCP compromises the tools developers use to build and test software, and harvests the credentials of everyone who runs those tools.

The March 2026 cascade.

The campaign that Malpedia and the FBI attribute to the group ran across five ecosystems in eight days. The sequence is the actual lesson.

The harvest at every stage is credentials: cloud keys, SSH keys, Kubernetes secrets, Git tokens, publishing tokens for package registries. The credentials of one stage open the next. That is why replacing the compromised package is not enough: the pipeline that ran it once has already handed over its secrets.

Two details say something about the group’s character. The worm behaves differently by geolocation – in Iran as a wiper that destroys Kubernetes clusters, everywhere else as a stealer. And according to Socket, TeamPCP has begun passing compromised access on to the Vect ransomware group. That is the logic of an access broker: the break-in is the product, someone else does the monetising.

Arrests, advisory, open account.

On 2 July 2026 the FBI published a FLASH advisory on the campaign. Its core message: exfiltrated credentials are a persistent risk, because affiliated actors will use them long after the original incident. The advisory names four pieces of malware – CanisterWorm, SANDCLOCK, Mini Shai-Hulud and Miasma – and two concrete traces: repositories named tpcp-docs and docs-tpcp, which the worm creates in victims’ GitHub organisations using stolen credentials.

On 26 August 2026 the Australian Federal Police, working with the FBI, arrested two men aged 21 and 23 in Western Australia; the investigation had begun in April on tips from threat-intelligence firms. Authorities speak of more than a thousand potentially compromised organisations, half a million stolen credentials, at least 300 gigabytes of exfiltrated data and remediation costs in the hundreds of millions. Brian Krebs had identified the alleged leader back in June; he claims to have left the group in March, before the LiteLLM wave. Police have not ruled out further arrests.

Important for context: the second LiteLLM compromise of 21 October 2026 (version 1.107.0, via a never-revoked master key of an agent platform) is not currently attributed to TeamPCP; Socket found no link. That such a prominent project falls twice within seven months is nevertheless part of the same story: the attack path through release pipelines is now known, and it is being copied.

Why this concerns the Mittelstand and critical infrastructure.

The common reaction is: we don’t build AI gateways, this doesn’t affect us. Three reasons why that does not hold.

First, Trivy runs in a surprising number of pipelines that nobody would call software development – as the image scanner in a container platform, as a mandatory step in a compliance tool, as part of a product a service provider operates. Our own pipeline uses Trivy too. Anyone who does not know whether and where has the inventory problem every supply-chain question starts with.

Second, the credentials are the real asset. A cloud key that leaked from a CI runner in March still opens the same tenant in November if nobody rotated it. The FBI calls it a persistent risk; from a DFIR perspective it means the incident does not end with the patch but with proof that every reachable secret was replaced.

Third, this is a supply-chain problem in the NIS2 sense. Article 21 requires measures for supply-chain security and for handling vulnerabilities in one’s own development and procurement. A service provider whose pipeline runs Trivy via floating tags is a supplier with an open risk, and the question of how they handled it belongs in the supplier assessment.

What a SOC needs to see.

The campaign leaves traces in three places: in the pipeline, on the hosts and at the network edge. None of them needs exotic tooling.

The FIM rule on .pth files is the cheapest single measure with the best effort-to-effect ratio: it would have exposed the LiteLLM persistence of March and October alike.

Five actions.

1. Inventory. Where does Trivy, KICS, LiteLLM or the Telnyx SDK run – directly, in images, at service providers? Without that list everything else is guesswork.
2. Rotation. Every secret a pipeline running one of the affected tools could reach between 19 and 27 March or on 21/22 April counts as compromised – even without an alert. Same for hosts with litellm 1.107.0 in October.
3. Pinning. Reference GitHub Actions only by commit SHA, never by tag; lock package versions in lockfiles and verify installs against the lockfile.
4. Search. Search your GitHub organisation for tpcp-docs and docs-tpcp; search site-packages on all Python hosts for cook.pth and sitecustomize.py.
5. Supplier question. Ask every service provider with pipeline access to your environment, in writing, whether and how they were affected and what was rotated. The answer belongs in your NIS2 documentation.

TeamPCP did not need a single zero-day. A sloppily configured workflow, an unrotated token and the trust every pipeline places in a security scanner were enough. The arrests may end the group. Not the method.