DEV Community

ohmygod
ohmygod

Posted on

The TeamPCP Supply Chain Cascade: How One Compromised Security Scanner Led to 3 Million Daily Downloads of Crypto-Stealing Malware

#security #blockchain #defi #python

The TeamPCP Supply Chain Cascade: How One Compromised Security Scanner Led to 3 Million Daily Downloads of Crypto-Stealing Malware

From Trivy to npm to LiteLLM — a five-day campaign that weaponized the tools developers trust most, targeting Solana validators, Ethereum wallets, and every secret in your CI/CD pipeline.

The Five-Day Kill Chain That Rewrote Supply Chain Threat Models

On March 19, 2026, a threat actor group called TeamPCP compromised Trivy, Aqua Security's vulnerability scanner. Five days later, they had poisoned the real LiteLLM package on PyPI — a library with three million daily downloads — turning it into a multi-stage credential stealer that specifically targeted cryptocurrency wallets, cloud credentials, and Kubernetes clusters.

This wasn't a typosquat. This wasn't a fake package. Every compromised artifact was the real thing, published through real accounts, distributed through real infrastructure.

If you're running DeFi infrastructure, validator nodes, or AI-augmented trading systems, this campaign was designed to steal your keys.

Stage 1: Trivy — Poisoning the Scanner (March 19)

The campaign began when TeamPCP used compromised credentials to publish a malicious Trivy v0.69.4 release. They force-pushed 76 of 77 aquasecurity/trivy-action tags and replaced all seven aquasecurity/setup-trivy tags.

The malicious payloads:

  • Dumped GitHub Actions Runner.Worker memory
  • Scraped common credential locations
  • Encrypted stolen data with AES + RSA
  • Exfiltrated to scan.aquasecurtiy[.]org (a lookalike domain)
  • Fallback: If direct exfil failed, created a public tpcp-docs repo using the victim's GITHUB_TOKEN and uploaded stolen data there

Why This Matters for Crypto

Trivy is the security scanner of choice for blockchain projects. It scans Docker images, Kubernetes manifests, and IaC configurations — exactly where validator keys, RPC credentials, and wallet mnemonics live in environment variables.

Every CI/CD pipeline that ran Trivy between March 19-20 potentially exposed:

  • Solana validator keypairs stored as environment variables
  • Ethereum private keys in .env files
  • Cloud credentials for RPC node infrastructure
  • Kubernetes secrets for DeFi backend services

Stage 2: The npm Worm — Self-Propagating Across Package Registries (March 20-22)

By March 20, TeamPCP had moved to npm. Using stolen tokens from Trivy-compromised CI environments, they published a self-propagating worm across multiple publisher scopes:

  • 28 packages in @EmilGroup
  • 16 packages in @opengov
  • Plus @teale.io/eslint-config, @airtm/uuid-base32, @pypestream/floating-ui-dom

The worm's logic was elegant and terrifying:

  1. Steal npm tokens from the compromised environment
  2. Resolve which packages each token could publish
  3. Bump patch versions (to look like normal updates)
  4. Fetch original READMEs to preserve appearances
  5. Republish with the malicious payload

The Kubernetes Destruction Module

By March 22, the same infrastructure was serving a Kubernetes-focused script that split victims by geography:

  • Iranian systems: Deployed a DaemonSet called host-provisioner-iran, mounted the host root filesystem, and ran a container named kamikaze that deleted the host filesystem and force-rebooted the node
  • Non-Iranian systems: Deployed host-provisioner-std with persistent backdoor logic

This geopolitical dimension — destructive for Iranian targets, persistent access for everyone else — suggests motivations beyond pure financial theft.

The Aqua Security Defacement

On March 22, the GitHub account Argon-DevOps-Mgt used stolen access to deface Aqua Security's internal aquasec-com GitHub organization. 44 repositories were renamed with tpcp-docs- prefixes and the description "TeamPCP Owns Aqua Security."

Stage 3: Checkmarx and OpenVSX (March 23)

The campaign reached another security vendor on March 23:

  • Checkmarx/kics-github-action compromised
  • Checkmarx/ast-github-action compromised
  • OpenVSX extensions ast-results 2.53.0 and cx-dev-assist 1.7.0 poisoned

The KICS payload reused the same fallback pattern: a setup.sh stealer tied to checkmarx[.]zone, falling back to creating docs-tpcp repos with stolen GitHub tokens.

Stage 4: LiteLLM — The Crown Jewel (March 24)

On March 24, TeamPCP published litellm versions 1.82.7 and 1.82.8 to PyPI. This was the most impactful compromise of the entire campaign.

Why LiteLLM Is a Perfect Target for Crypto Theft

LiteLLM is the universal proxy layer for AI applications — it sits between your code and every LLM provider (OpenAI, Anthropic, Google, etc.). In the crypto/DeFi world, it's increasingly used for:

  • AI-powered trading bots that hold API keys for exchanges and wallets
  • Automated audit pipelines (like those using Aderyn, Slither, or custom LLM-based auditors)
  • On-chain monitoring agents connected to RPC providers with authenticated endpoints
  • Smart contract development environments where developers store private keys

Because LiteLLM typically has access to environment variables, API keys, and cloud configurations, compromising it gives attackers a master key to everything in the deployment.

The Three-Layer Payload

Layer 1 — Launcher and Exfiltration:

  • Collected environment variables, SSH keys, cloud credentials
  • Encrypted with AES-256-CBC, key wrapped in RSA
  • Packaged as tpcp.tar.gz
  • Exfiltrated to models[.]litellm[.]cloud (attacker-controlled, distinct from legitimate litellm.ai)

Layer 2 — Deep Reconnaissance:

  • System enumeration (hostname, user, network)
  • SSH keys and Git credentials
  • Cloud provider credentials (AWS, GCP, Azure)
  • Kubernetes configs and service account tokens
  • Terraform, Helm, and CI/CD configurations
  • Cryptocurrency wallets: Bitcoin, Litecoin, Ethereum, and Solana
  • Active credential testing (querying AWS APIs, accessing K8s secrets)

Layer 3 — Persistent Backdoor:

  • Written as sysmon.py, registered as a system service
  • Polled a remote C2 endpoint every 50 minutes
  • Anti-analysis trick: returned a YouTube link to "Bad Apple!!" when accessed from sandboxes
  • Allowed continuous delivery of new payloads to compromised systems

The Exposure Window

The malicious versions were available for approximately 2-3 hours. With three million daily downloads, that's potentially 250,000-375,000 downloads of compromised packages.

The Crypto-Specific Attack Surface

Here's why this campaign is particularly devastating for blockchain teams:

1. Validator Key Exposure

Solana validators and Ethereum staking operators commonly store keypairs in environment variables or files accessible to CI/CD runners. The malware explicitly targeted:

SOLANA_VALIDATOR_IDENTITY
SOLANA_VOTE_KEYPAIR  
SOL_PRIVATE_KEY
ETH_PRIVATE_KEY
MNEMONIC
Enter fullscreen mode Exit fullscreen mode

2. RPC Infrastructure Compromise

DeFi backends connect to RPC providers (Alchemy, Infura, QuickNode) using authenticated URLs. Stolen RPC credentials enable:

  • Transaction monitoring and frontrunning
  • Mempool observation for MEV extraction
  • Infrastructure mapping for targeted attacks

3. Smart Contract Deployment Keys

Development environments often have deployer private keys with upgrade authority. A stolen deployer key means:

  • Protocol upgrades to malicious implementations
  • Treasury drains through admin functions
  • Permanent protocol compromise if upgrade authority isn't behind multisig

4. AI Agent Wallet Access

The rise of AI agents in DeFi means LiteLLM is increasingly deployed alongside systems that hold real funds:

  • Trading bot wallets
  • Automated yield farming agents
  • Liquidation bot hot wallets
  • Cross-chain bridge relayer keys

Detection: Are You Compromised?

Immediate Checks 

# Check if you installed compromised LiteLLM versions
pip show litellm | grep Version
# Compromised: 1.82.7 or 1.82.8

# Check for Trivy compromise
trivy --version
# Compromised: v0.69.4

# Look for TeamPCP artifacts
find / -name "tpcp.tar.gz" 2>/dev/null
find / -name "sysmon.py" -path "*/tmp/*" 2>/dev/null
ls /tmp/pglog /tmp/.pg_state 2>/dev/null

# Check for malicious network connections
grep -r "models.litellm.cloud\|checkmarx.zone\|scan.aquasecurtiy.org" \
  /var/log/ 2>/dev/null
Enter fullscreen mode Exit fullscreen mode

CI/CD Pipeline Audit 

# GitHub Actions: Check for compromised action versions
grep -r "aquasecurity/trivy-action" .github/workflows/
grep -r "Checkmarx/kics-github-action" .github/workflows/

# Check npm lockfile for compromised packages
grep -E "@EmilGroup|@opengov|@teale.io/eslint-config" package-lock.json

# Verify Trivy binary integrity
sha256sum $(which trivy) 
# Compare against official checksums at github.com/aquasecurity/trivy/releases
Enter fullscreen mode Exit fullscreen mode

Solana-Specific Checks 

# Check if validator identity was exposed
# Look for unauthorized transactions from your validator
solana-keygen verify <VALIDATOR_PUBKEY> <KEYPAIR_FILE>

# Review recent vote account changes
solana vote-account <VOTE_PUBKEY> --with-rewards

# Check for unauthorized stake deactivations
solana stakes <VALIDATOR_PUBKEY>
Enter fullscreen mode Exit fullscreen mode

Incident Response Playbook

If any of your systems ran the compromised versions:

Phase 1: Contain (First Hour)

  1. Rotate ALL credentials accessible to the compromised environment
  2. Revoke all API keys: Exchange APIs, RPC provider keys, cloud credentials
  3. Move funds: Transfer from any wallet whose keys were accessible
  4. Kill the persistent backdoor: Stop sysmon.py service, remove the file
  5. Isolate compromised CI/CD runners: Take them offline

Phase 2: Investigate (Hours 2-24)

  1. Audit outbound connections: Look for traffic to TeamPCP domains
  2. Check Kubernetes: Look for unauthorized DaemonSets, privileged pods
  3. Review GitHub: Check for tpcp-docs* repositories in your org
  4. Verify smart contract state: Check if any upgrade authorities were used
  5. Scan for persistence: Look for new cron jobs, systemd services, authorized SSH keys

Phase 3: Rebuild (Days 2-7)

  1. Rebuild from clean state: Don't trust remediation; rebuild CI/CD runners
  2. Pin dependencies: Use hash-pinned versions, not version ranges
  3. Implement SLSA: Require provenance attestation for critical dependencies
  4. Add runtime monitoring: Deploy Falco or similar for anomalous process detection
  5. Separate key management: Move validator and deployer keys to HSMs or air-gapped systems

Architectural Lessons for DeFi Teams

1. Never Store Keys Where CI Can Reach Them 

❌ Environment variables in CI/CD
❌ .env files in repositories
❌ Kubernetes secrets accessible to build pods

✅ Hardware Security Modules (HSMs)
✅ Cloud KMS with strict IAM
✅ Air-gapped signing ceremonies
✅ Multisig for all protocol-critical operations
Enter fullscreen mode Exit fullscreen mode

2. Pin Everything, Verify Everything 

# Don't do this:
- uses: aquasecurity/trivy-action@master

# Do this:
- uses: aquasecurity/trivy-action@7b7aa264d83dc58691451798b4d117714bf598e0
  # v0.69.3 — verified 2026-03-18
Enter fullscreen mode Exit fullscreen mode

3. Segment Your AI Stack

If you're using LiteLLM or similar AI proxies in production:

  • Run them in isolated containers with no access to wallet keys
  • Use separate service accounts with minimal permissions
  • Monitor outbound network connections from AI service containers
  • Never co-locate AI inference with key management

4. Implement Dependency Firewalls

Use tools like Socket, Snyk, or Sonatype to:

  • Block packages with install scripts by default
  • Alert on new native code in dependency updates
  • Quarantine packages that access sensitive directories
  • Monitor for behavioral changes in dependency updates

The Bigger Picture: Supply Chain Attacks Are the New Smart Contract Exploits

In Q1 2026, we've seen a clear shift in how crypto assets are stolen:

Attack Vector Traditional Supply Chain
Target Smart contract bugs Developer infrastructure
Skill required Solidity expertise CI/CD knowledge
Detection On-chain monitoring Nearly invisible
Impact One protocol Thousands of projects
Prevention Audits, formal verification Dependency hygiene, build security

The TeamPCP campaign demonstrated that a single compromised credential can cascade through:

  • Security scanners (Trivy) → package registries (npm, PyPI) → developer tools (LiteLLM, Checkmarx) → production infrastructure (Kubernetes, cloud)

For DeFi teams, the lesson is clear: your smart contracts can be formally verified and triple-audited, but if your CI/CD pipeline installs a compromised dependency, none of that matters.

What Comes Next

TeamPCP's campaign is still under active investigation. The persistent backdoor component (sysmon.py) means compromised systems may receive new payloads at any time. The connection between TeamPCP and LAPSUS$ remains speculative but under investigation.

For the DeFi ecosystem, this is a wake-up call. The next billion-dollar hack won't come from a reentrancy bug — it will come from a compromised npm install or pip install in your deployment pipeline.

Secure your supply chain like you secure your smart contracts. Because your attacker already knows which one is weaker.

This is part of an ongoing series on DeFi security research. Follow for weekly deep dives into vulnerabilities, audit techniques, and security best practices.

Tags: #security #blockchain #defi #supplychain

References

Top comments (0)