How TeamPCP Turned Developer Tools Into a Route for Data Theft

In March 2026, a group calling themselves TeamPCP infiltrated Aqua Security’s build systems.

They started by hiding credential-stealing code inside Aqua’s Trivy vulnerability scanner. Using the credentials it collected, they compromised other widely used tools, including Checkmarx KICS and LiteLLM.

Two months later, they turned to individual developers, tampering with Nx Console, a VS Code extension that runs on developers’ own machines.

That led to their biggest claim. They say they stole around 3,800 of GitHub’s internal repositories from a single GitHub employee’s device, a figure GitHub called “directionally consistent” with its investigation.

In this blog post, we describe what the group did, why their actions could let them keep using stolen credentials even after victims removed the malicious code, and how some steps in the attack could have been avoided.

TeamPCP appeared at the end of 2025 and is motivated by financial gain. The group claims it isn’t new, just rebranded. Its main communication channel is on Telegram. It launched in November 2025 and had close to 700 members by February 2026.

Figure 1: TeamPCP posting archives of stolen data to its Telegram channel.

TeamPCP’s early cloud attacks gave it computing power and stolen credentials. Its later supply-chain attacks went further, planting malicious code in tools that could read secrets across build pipelines, developer accounts, and cloud environments. The table below shows what it targeted and what data or access was at risk.

GitHub’s incident shows what that access could expose. GitHub said the theft concerned its internal repositories and found no evidence that customer-owned repositories were affected. Investigators also saw credentials stolen in March being used to explore other victim environments. Stolen GitHub repositories were later listed for at least $50,000. For the affected organizations, removing a poisoned package would not undo access already gained with an exposed token.

The March campaign shows how one theft could lead to the next. TeamPCP got into a trusted tool, collected every secret it could reach, sent them out, and then exploited them. The tools and entry points changed, but the same sequence runs through every attack described below.

1. Get into software that already runs

In its cloud campaign, TeamPCP abused exposed management interfaces and applications vulnerable to React2Shell. With Trivy, the route ran through software releases. Aqua Security’s incident account found that credentials left valid after an earlier incident gave the attacker access to its open-source release environment.

The attacker force-pushed malicious commits to existing trivy-action tags and published a poisoned Trivy binary. A workflow using one of those tags could then run the new code without any configuration change. Aqua later confirmed that 76 of 77 tags were affected.

2. Collect credentials within reach

Once the code ran on GitHub-hosted runners, the Trivy payload searched Runner.Worker process memory for values marked as secrets. On self-hosted runners, it checked more than 50 paths for SSH keys, cloud credentials, Kubernetes files, and wallet material. The legitimate scan could continue afterward.

With LiteLLM, Python startup provided another execution path. Version 1.82.8 installed a .pth file that could run the payload when Python started, even without importing LiteLLM. Package analysis identified versions 1.82.7 and 1.82.8 as affected.

3. Encrypt and send the data

The Trivy stealer encrypted the collected material with AES-256-CBC and an RSA-4096 public key, bundled it as tpcp.tar.gz, and attempted an HTTPS upload to scan.aquasecurtiy.org, a lookalike of Aqua’s real domain. If the upload failed and a sufficiently privileged personal access token was available, the payload could create a tpcp-docs repository in the victim’s GitHub account and attach the archive to a release. That fallback would leave a different trail from an upload to the lookalike domain. Both routes depended on the permissions available where the payload ran.

4. Keep access and extend the campaign

On some machines, the malware installed a sysmon.py service that checked for commands every 50 minutes, according to LiteLLM payload analysis. Kubernetes-focused payloads could deploy privileged workloads. CanisterWorm extended the campaign through npm. It used stolen publishing tokens to identify packages the compromised accounts controlled and prepare malicious updates. The attacker ran that publishing tool separately at first, but about an hour later an updated version could spread on its own.

5. Turn stolen access into revenue

That access also had a resale value. TeamPCP has posted leaked material through ShellForce, offered credentials and source code for sale, and partnered with ransomware operators such as Vect. Hijacked servers supplied capacity for cryptomining and proxies. Some stolen tokens were used weeks after the initial theft, which is why prompt credential rotation matters even after a malicious release has been removed.

Here’s how to protect yourself from attacks like these.

1. Review third-party actions before using them in your GitHub workflows. This includes looking at the code at the revision you plan on using and pinning the full commit SHA in your workflow.
2. Limit the credentials your code has access to. Only provide access to a specific secret in a CI/CD job when that secret is needed. Where possible, use short-lived credentials issued through OIDC federation. Avoid running untrusted third-party code in jobs that have access to credentials for interacting with your production systems.
3. Consider delaying package and editor extension updates on your developer machines (similar to how you might delay applying updates to dependencies in a build pipeline). Commit package lock files to version control. You may want to make an exception for applying security fixes promptly; however, note that the malicious version of Nx Console was available on the VS Code Marketplace for about 18 minutes, which was enough time for some people to install it.
4. Mitigate the other attack vectors TeamPCP has used in the attacks described above. This includes limiting public access to Docker APIs, Kubernetes control planes, Ray dashboards, and Redis instances, and patching applications that use React Server Components against the React2Shell vulnerability (CVE-2025-55182).
5. Look for known indicators of compromise. If you find tpcp.tar.gz, a tpcp-docs or docs-tpcp repository that you didn’t intentionally create, sysmon.py, or evidence of communication to scan.aquasecurtiy.org, models.litellm.cloud, or checkmarx.zone, you should consider rotating any credentials that may have been exposed and reviewing logs for evidence those credentials may have been used.

TeamPCP’s encrypted archive uploads give you a concrete reason to check outbound traffic. Pinning revisions helps control which code runs, and tighter permissions limit the secrets it can reach. If malicious code still collects data, the transfer is another place to intervene alongside the build, package, and credential checks above.

That transfer’s importance extends beyond this campaign. Data exfiltration appeared in 96% of the attacks assessed in BlackFog’s first-quarter 2026 ransomware analysis. That figure applies to BlackFog’s dataset and period, rather than TeamPCP alone.

BlackFog’s anti data exfiltration (ADX) technology addresses that part of the chain. It monitors outbound traffic on devices and is designed to block unauthorized transfers before data leaves. That protection belongs alongside build security and credential management.

To see how it would fit your environment, request a BlackFog demo.