DEV Community

ohmygod
ohmygod

Posted on

The TeamPCP Supply Chain Campaign: How Compromised Security Tools Are Draining Crypto Wallets — A DeFi Developer's Defense Playbook

The TeamPCP Supply Chain Campaign: How Compromised Security Tools Are Draining Crypto Wallets

A DeFi Developer's Defense Playbook

March 26, 2026


If you run Solana validators, develop DeFi protocols, or use Trivy / LiteLLM in your CI/CD pipeline, stop and read this now.

Between March 19 and March 24, 2026, a threat actor group called TeamPCP executed the most sophisticated supply chain attack on developer security tooling in history. They compromised Trivy (the most popular open-source vulnerability scanner), LiteLLM (a widely-used LLM proxy library), Checkmarx KICS, and 47+ npm packages — turning trusted tools into credential-harvesting weapons.

The kicker for crypto developers: the malware specifically searches for Solana validator keypairs, RPC authentication credentials, and cryptocurrency wallet files.

This isn't theoretical. The attackers claim to have exfiltrated hundreds of gigabytes of data and over 500,000 credentials.


The Five-Day Kill Chain

Day 1 (March 19): Trivy Goes Rogue

TeamPCP used credentials stolen from a previous, incompletely-remediated Trivy incident (late February 2026) to:

  1. Publish a malicious trivy v0.69.4 binary to GitHub Releases, Docker Hub, GHCR, and ECR
  2. Force-push 76 of 77 version tags in aquasecurity/trivy-action to malicious commits
  3. Replace all 7 tags in aquasecurity/setup-trivy

Any CI/CD workflow referencing trivy-action@v0.28.0 (or any version tag) silently began running attacker-controlled code. The original commit metadata — author names, timestamps, commit messages — was preserved, making the poisoning nearly invisible in Git history.

What the Malware Steals

The three-step payload is surgically designed for maximum credential extraction:

Step 1 — Collection:
The malware reads directly from GitHub Actions Runner memory (/proc/<pid>/mem), bypassing GitHub's log-masking entirely. It harvests:

  • SSH keys and cloud credentials (AWS, GCP, Azure)
  • Kubernetes tokens and Docker registry secrets
  • Database passwords and TLS private keys
  • Solana keypairs (validator-keypair.json, vote-account-keypair.json, identity.json)
  • Solana RPC credentials (rpcuser, rpcpassword)
  • Cryptocurrency wallet files from standard paths (~/.config/solana, /home/sol, /opt/solana)

Step 2 — Encryption:
Stolen data is encrypted with AES-256-CBC + RSA-4096 hybrid encryption, making network-layer inspection useless.

Step 3 — Exfiltration:
Data is sent to a typosquatted domain (scan.aquasecurtiy[.]org — note the misspelling). Fallback: if a GitHub token is available, the malware creates a public tpcp-docs repository and stages the data there.

Day 2–3 (March 20–23): CanisterWorm and Lateral Expansion

Using stolen npm tokens, TeamPCP launched CanisterWorm — a self-propagating npm supply chain worm that:

  • Compromised 28 packages in @EmilGroup scope, 16 in @opengov, plus others
  • Automatically resolved which packages each stolen token could publish
  • Bumped patch versions, preserved original READMEs, and republished with malicious payloads
  • 28 packages were compromised in under 60 seconds

By March 22, the same infrastructure was serving Kubernetes-targeted payloads that:

  • On Iranian systems: Deployed a kamikaze container that wiped the host filesystem and force-rebooted
  • On all other systems: Installed persistent backdoors

The campaign also hit Checkmarx KICS GitHub Action and two OpenVSX extensions on March 23.

Day 5 (March 24): LiteLLM PyPI Compromise

The real LiteLLM package on PyPI — not a typosquat — was published with malicious versions 1.82.7 and 1.82.8. These were available for approximately 5 hours (10:39–16:00 UTC).

Version 1.82.8 was particularly dangerous: it included a .pth file that executed the malicious payload every time the Python interpreter started, even if LiteLLM was never imported.


Why DeFi Developers Should Be Terrified

This attack is a paradigm shift for crypto security. Here's why:

1. The Malware Specifically Targets Crypto Assets

This isn't a generic credential stealer that happens to find crypto. The malware has hardcoded paths for Solana configuration directories and specifically searches for validator keypairs. If you're a Solana validator running Trivy scans in your infrastructure, your validator keys may be compromised.

2. CI/CD Pipelines Are the New Attack Surface

Most DeFi teams run security scanners in CI/CD. If your GitHub Actions workflow used trivy-action with a version tag (not a SHA pin) between March 19–20, every secret accessible to that workflow was exfiltrated. That includes:

  • Deployer private keys stored as GitHub Secrets
  • RPC endpoint credentials
  • Multisig signer keys for automated operations
  • Treasury management credentials

3. The Blast Radius Is Enormous

Trivy has over 20,000 dependent repositories. LiteLLM is used by thousands of AI-integrated applications, many of which are DeFi bots, MEV searchers, and AI-powered trading systems that hold significant crypto assets.

4. Persistent Backdoors Mean Ongoing Risk

The malware deployed a systemd service (sysmon.py) that polls an Internet Computer (ICP) blockchain canister every 50 minutes for C2 instructions. This decentralized command infrastructure is resistant to takedown — you can't just block a domain.


Immediate Actions: The DeFi Developer Checklist

Are You Affected?

Run these checks now:

# Check if you have compromised Trivy versions
trivy --version  # Affected: v0.69.4. Safe: v0.69.3

# Check GitHub Actions workflows for unpinned Trivy references
grep -r "trivy-action@v" .github/workflows/
grep -r "setup-trivy@v" .github/workflows/
# Any version tag reference = potentially compromised

# Check for LiteLLM compromise
pip show litellm | grep Version
# Affected: 1.82.7, 1.82.8

# Check for persistent backdoor on Linux systems
systemctl status sysmon.py 2>/dev/null
systemctl status pgmon 2>/dev/null
ls -la /etc/systemd/system/sysmon* 2>/dev/null

# Check for exfiltration repository
# Search your GitHub org for repositories named "tpcp-docs"

# Check for compromised npm packages
npm ls 2>/dev/null | grep -E "@EmilGroup|@opengov|@teale.io|@airtm|@pypestream"
Enter fullscreen mode Exit fullscreen mode

If You're Affected: Emergency Response

1. Rotate EVERYTHING immediately:

# Solana validator keys
solana-keygen new -o ~/new-validator-keypair.json
# Then follow validator key rotation procedure

# Rotate all GitHub Secrets
# Rotate AWS/GCP/Azure credentials
# Rotate database passwords
# Rotate Docker registry tokens
# Rotate npm tokens
Enter fullscreen mode Exit fullscreen mode

2. Block known IOCs at the network level:

scan.aquasecurtiy[.]org
45.148.10.212
checkmarx[.]zone
Enter fullscreen mode Exit fullscreen mode

3. Check for the ICP-based backdoor:

# The backdoor polls an ICP canister every 50 minutes
# Check for suspicious systemd services
systemctl list-units --type=service | grep -E "sysmon|pgmon|host-provisioner"

# Check for suspicious cron jobs
crontab -l
ls /etc/cron.d/
Enter fullscreen mode Exit fullscreen mode

Long-Term Defense: Hardening Your DeFi Development Pipeline

1. Pin GitHub Actions to Full SHA Hashes

This is the single most important defense. Version tags can be force-pushed; SHA hashes cannot.

# ❌ VULNERABLE - Tag can be poisoned
- uses: aquasecurity/trivy-action@v0.28.0

# ✅ SAFE - SHA hash is immutable
- uses: aquasecurity/trivy-action@a312e5bc8e8964cf7b82cbeb0a798a9a0b1cebdd
Enter fullscreen mode Exit fullscreen mode

Every DeFi team should audit all GitHub Actions workflows and pin every action to a full commit SHA today.

2. Isolate Secrets from CI/CD Scanning

Never give your security scanner access to deployment keys:

# Use separate jobs with minimal permissions
jobs:
  scan:
    # This job has NO access to deployment secrets
    permissions:
      contents: read
      security-events: write
    steps:
      - uses: actions/checkout@<sha>
      - name: Run scanner
        # Scanner runs in an environment without sensitive secrets

  deploy:
    needs: scan
    # Only this job has deployment secrets
    environment: production
    steps:
      - name: Deploy
        env:
          DEPLOYER_KEY: ${{ secrets.DEPLOYER_KEY }}
Enter fullscreen mode Exit fullscreen mode

3. Use Hardware Security Modules for Validator Keys

Solana validator keys should never exist as plain files on systems that run CI/CD pipelines:

# Use a hardware wallet or HSM for validator identity
# Solana supports remote signing via:
# - YubiHSM2
# - AWS CloudHSM
# - Google Cloud KMS
# Never store validator-keypair.json on a CI runner
Enter fullscreen mode Exit fullscreen mode

4. Implement Dependency Lockfiles and Verification

# Python: Pin exact versions with hashes
pip install litellm==1.82.6 \
  --hash=sha256:<known-good-hash>

# Node: Use npm ci (not npm install) with lockfile
npm ci --ignore-scripts  # Prevents postinstall hook execution

# Verify package integrity
pip-audit  # Scan for known vulnerable packages
npm audit --audit-level=critical
Enter fullscreen mode Exit fullscreen mode

5. Network Segmentation for Crypto Infrastructure

┌─────────────────────────────────────────────┐
│  Zone 1: CI/CD (No crypto keys)             │
│  - Build servers                            │
│  - Security scanners (Trivy, etc.)          │
│  - Test environments                        │
│  Outbound: Restricted to package registries │
└─────────────────────────────────────────────┘
         │ (artifact transfer only)
┌─────────────────────────────────────────────┐
│  Zone 2: Deployment (Limited crypto keys)   │
│  - Contract deployer (single-use keys)      │
│  - Upgrade proposer (multisig participant)  │
│  Outbound: Restricted to RPC endpoints      │
└─────────────────────────────────────────────┘
         │ (governance proposals only)
┌─────────────────────────────────────────────┐
│  Zone 3: Treasury (HSM-protected)           │
│  - Multisig signers (hardware wallets)      │
│  - Validator keys (HSM)                     │
│  - Cold storage                             │
│  Outbound: NONE                             │
└─────────────────────────────────────────────┘
Enter fullscreen mode Exit fullscreen mode

6. Monitor for Supply Chain Indicators

Add these to your security monitoring:

# Detect suspicious GitHub Actions behavior
- alert: GHActionMemoryAccess
  condition: process.file.path matches "/proc/*/mem"
  context: "Malware reads Runner memory to bypass log masking"

# Detect Solana key access from unexpected processes
- alert: SolanaKeyAccess  
  condition: file.path matches "*/solana/*.json"
    AND process.name NOT IN ["solana", "solana-validator", "solana-keygen"]

# Detect ICP canister communication (backdoor C2)
- alert: ICPCanisterC2
  condition: dns.query matches "*.icp0.io" OR "*.ic0.app"
    AND source NOT IN [known_web3_services]
Enter fullscreen mode Exit fullscreen mode

The Bigger Picture: Supply Chain Attacks Are DeFi's Blind Spot

The DeFi security community has spent years perfecting smart contract auditing. We have fuzzers, formal verification, invariant testing, and bug bounties. But we've largely ignored the development pipeline itself.

Consider this attack chain:

  1. Attacker compromises a security scanner → steals deployer keys from CI/CD
  2. Uses deployer keys to upgrade a protocol's contracts
  3. Drains the protocol's TVL

This is not a smart contract vulnerability. No audit would catch it. No fuzzer would find it. The contract code is perfect — but the keys that control it were stolen from a build server.

The Numbers Tell the Story

In Q1 2026:

  • $137M+ lost across 15 DeFi protocols
  • Private key compromise was the #1 root cause (Step Finance: $27–40M, Resolv: $25M)
  • Zero of the top exploits this quarter were found by security scanners

The industry's security investment is misallocated. We spend millions on smart contract audits while leaving deployer keys in GitHub Secrets that any compromised Action can read.


Practical Takeaways

Priority Action Time Required
🔴 NOW Check if you used Trivy v0.69.4 or LiteLLM 1.82.7/8 5 minutes
🔴 NOW Search for tpcp-docs repos in your GitHub org 2 minutes
🔴 NOW Check for sysmon.py / pgmon systemd services 2 minutes
🟠 TODAY Pin all GitHub Actions to SHA hashes 1 hour
🟠 TODAY Rotate any secrets accessible from affected CI runners 2 hours
🟡 THIS WEEK Separate CI/CD scanning from deployment secrets 4 hours
🟡 THIS WEEK Implement dependency hash verification 2 hours
🟢 THIS MONTH Move validator/deployer keys to HSM 1–2 days
🟢 THIS MONTH Implement network segmentation for crypto infra 2–3 days

IOCs and References

Indicators of Compromise:

  • Domain: scan.aquasecurtiy[.]org (typosquatted)
  • Domain: checkmarx[.]zone
  • IP: 45.148.10.212
  • CVE: CVE-2026-33634 (CVSS 9.4)
  • Malicious Trivy: v0.69.4
  • Malicious LiteLLM: 1.82.7, 1.82.8
  • Persistence: sysmon.py / pgmon systemd services
  • Exfiltration repo pattern: tpcp-docs
  • GitHub account: Argon-DevOps-Mgt

Safe Versions:

  • Trivy: v0.69.3
  • trivy-action: v0.35.0
  • setup-trivy: v0.2.6
  • LiteLLM: ≤ 1.82.6 or ≥ 1.82.9

References:


This analysis is part of the DreamWork Security research series. We publish weekly deep-dives into DeFi exploits, vulnerability patterns, and defense strategies. Follow for the next installment.

Disclaimer: This article is for educational and defensive purposes only. All information is sourced from public security advisories and incident reports.

Top comments (0)