TeamPCP Campaign: The Evolution of Modern Supply Chain Attacks

In March 2026, the open-source ecosystem was hit by a coordinated wave of supply chain attacks. Four popular developer tools, Trivy, KICS, LiteLLM, and Telnyx, were compromised in quick succession by a group known as TeamPCP. The pace, precision, and post-compromise behavior of these attacks offer a clear signal about how supply chain threats are evolving in 2026.

This post breaks down what happened, connects the dots across the campaign, and explains why defending against this class of attack requires a new way of thinking about supply chain security.

The Campaign: Four Tools, Nine Days, One Group

Between March 19 and March 27, TeamPCP systematically injected credential-harvesting malware into four widely used open-source projects:

1. March 19: Trivy. Aqua Security's ubiquitous vulnerability scanner was compromised through its binary, GitHub Actions workflow, and container images. Trivy is used in CI pipelines across thousands of organizations.
2. March 23: KICS. Checkmarx's Infrastructure-as-Code scanner was hit next, with malicious code injected via its GitHub Action and OpenVSX extension. Like Trivy, KICS sits directly inside developer workflows, meaning the deployed malware ran in privileged contexts.
3. March 24: LiteLLM. Malicious packages were pushed to PyPI targeting LiteLLM, one of the most popular LLM proxy libraries. 
4. March 27: Telnyx. Malicious versions of the Telnyx Python package were published to PyPI, extending the campaign's reach to communications infrastructure.

Across each example, the malware's behavior was consistent: harvest cloud credentials, SSH keys, Kubernetes configuration files, and CI/CD secrets, encrypt them, and exfiltrate them to attacker-controlled infrastructure. Within hours of the first compromise, stolen secrets were already being validated and used.

What Happened After the Theft

The post-compromise activity observed following these attacks illustrates exactly why credential theft at scale is so dangerous. The attack didn't end with the supply chain compromise.

Secret validation was nearly instant. Within hours of the Trivy compromise, stolen credentials were being verified using TruffleHog, an open-source tool that validates secrets by making live API calls to their respective providers. AWS access keys were confirmed active via sts:GetCallerIdentity. Azure application secrets and SaaS tokens were similarly checked. By the time most organizations had even heard about the compromise, their credentials were already confirmed live and queued for use.

Reconnaissance followed within 24 hours. Once secrets were validated, TeamPCP began methodical discovery across victim AWS environments, enumerating IAM users and roles, EC2 instances, Lambda functions, RDS databases, S3 buckets, and Route 53 hosted zones. Critically, they showed particular focus on ECS, mapping clusters and task definitions to find targets for direct container access. AWS Secrets Manager was also enumerated and catalogued for bulk exfiltration.

Lateral movement came next. Using stolen GitHub Personal Access Tokens, the attackers created pull requests containing malicious workflows that executed in the context of targeted repositories, giving access to runtime secrets and environment variables. In AWS, ECS Exec was abused to run Bash commands and Python scripts directly on live containers. Evidence suggests the Nord Stream GitHub tool was used to automate workflow creation at scale.

Data exfiltration was aggressive and named accordingly. TeamPCP used git.clone to pull private repositories at scale, and extracted data from S3 buckets, Secrets Manager, and databases in bulk. Their resource naming conventions, including labels like "pawn" and "massive-exfil,” suggest they weren't trying to stay quiet. 

The whole operation ran primarily from Mullvad VPN exit nodes and virtual private server infrastructure, with little effort made to blend in. This was a high-tempo, low-stealth campaign designed to extract as much value as possible, as fast as possible.

The Evolution of Supply Chain Attacks

The TeamPCP campaign represents a meaningful shift in how sophisticated threat actors are thinking about supply chain as an attack surface.

Security tooling is the new high-value target. Trivy and KICS are open-source security tools that run with elevated permissions inside CI/CD pipelines and access sensitive build secrets. Compromising a vulnerability scanner is a particularly sharp move as it exploits the implicit trust organizations extend to their security infrastructure.

The CI/CD pipeline is a credential goldmine. Modern pipelines accumulate enormous amounts of privilege, from cloud credentials for deployment and GitHub tokens for repository access, to secrets passed as environment variables. Supply chain attackers have recognized that the pipeline itself is often the most privileged identity in an organization, and it's one that developers interact with constantly, making it perfect for introducing malicious packages.

Speed has become a weapon. The interval between compromise and active exploitation in this campaign was measured in hours. Traditional detection approaches that rely on scanning at build time or responding to threat intelligence published after the fact are operating on the wrong timescale. By the time a malicious package is flagged in a feed, the credentials it harvested may already have been used.

The initial steal enables a cascade. What TeamPCP extracted wasn't just immediately useful data, it was a map. The exfiltrated secrets and repository contents contain additional credentials, configuration details, and access paths that enable further compromise. A single poisoned dependency can become the beginning of a much larger intrusion.

Legitimate tools are being weaponized. Every post-compromise action in this campaign used legitimate tools and expected API calls. There were no exotic exploits. This makes behavioral detection critical: the attacker looks like a developer who happens to be doing unusual things very quickly.

How Oligo Helps

Defending against this class of attack requires visibility at two distinct layers: catching vulnerable and malicious packages before and as they run, and detecting the anomalous behavior they trigger at runtime. Oligo addresses both.

Identifying vulnerable and compromised versions

The first line of action is knowing what you're running. Oligo's Runtime Vulnerability Management continuously maps the actual dependencies loaded in your running applications, meaning it surfaces what's genuinely executing in production. When a new compromise is identified, like the affected versions in the Trivy, KICS, LiteLLM, or Telnyx incidents, Oligo can immediately surface which of your running workloads are loading an affected version.

This matters because the gap between "a package is compromised" and "you know you're running it" is exactly the window attackers exploit. Static manifest scanning can tell you what's in your lockfile; Oligo tells you what's actually loaded and running right now.

If you use Oligo CADR, an incident fires automatically the moment a known-compromised package version is detected in your environment with no manual triage required.

Detecting malicious packages at runtime

Known-bad signatures are table stakes. The harder problem is detecting malicious packages that haven't been flagged yet, or packages that behave maliciously only under certain conditions, like the scribejava-core impostor that harvested OAuth credentials only on the 15th of each month.

Oligo's CADR engine profiles every application process using Deep Application Inspection (DAI), building per-library behavioral baselines: what network connections does this package normally make, what filesystem paths does it touch, what syscalls does it invoke? When a package deviates from its established baseline, such as making an outbound connection to an unexpected IP, accessing credential files it has no reason to touch, or spawning subprocesses, CADR fires an alert with full context on what was accessed and where it went.

This is how Oligo catches what signatures miss. The malware deployed in the TeamPCP campaign exfiltrated credentials to attacker-controlled domains, accessed SSH key material and Kubernetes configuration files, and spawned processes to execute base64-encoded payloads. Each of these actions represents a behavioral anomaly detectable at runtime, regardless of whether the package was on a known-malicious list at the time.

What to monitor right now

If you're concerned about exposure from the TeamPCP supply chain campaign, focus your detection efforts on the following behavioral signals in your environment:

• Cloud metadata service credential access: unexpected calls to IMDS endpoints or credential provider paths by application processes
• Lateral movement activity: unusual IAM enumeration, Secrets Manager access patterns, or ECS Exec invocations from workload identities
• Bulk data access: many GetSecretValue, GetObject, or git.clone operations in a short window by a single token or key
• Anomalous process execution: processes not present in a container image executing, particularly those spawned from SSM session contexts
• Workflow log deletions: which can indicate post-execution cleanup in GitHub Actions

Oligo customers can monitor the Detections screen for these indicators directly. Oligo CADR detections for cloud metadata credential access and lateral movement activity are available out of the box.

The Bigger Picture

The TeamPCP campaign is a case study in what modern supply chain attacks look like at scale: targeted at trusted tooling, automated for speed, and designed to turn a single compromised dependency into a sustained foothold across many organizations.

The lesson for security teams is that the window between compromise and exploitation has collapsed, and that the blast radius of a single malicious package is much larger than it used to be given how much privilege now flows through modern CI/CD pipelines.

Static scanning, manifest reviews, and build-time checks remain important, but they're not sufficient on their own. Knowing what's actually running in production, and detecting when it behaves abnormally, is no longer optional. That's the gap Oligo is built to close.