The fallout from TeamPCP's supply chain attack campaign continues to widen as more organizations disclose breaches tied to compromised developer packages. Complicating enterprise incident response, rival threat actors ShinyHunters and Lapsus$ are publicly claiming credit for some of the same breaches — creating attribution confusion and hindering victims' ability to accurately scope their exposure.
TeamPCP: The Supply Chain Attacker
TeamPCP is a threat group that gained notoriety in early 2026 for a sophisticated supply chain campaign targeting developer tooling and cloud infrastructure. The group's known tradecraft includes:
| Technique | Description |
|---|---|
| Malicious PyPI packages | Trojaned Python packages including backdoored telnyx versions |
| Steganography | Malware hidden within WAV audio files embedded in packages |
| Cloud credential harvesting | Targeting AWS, Azure, and GCP credentials in developer environments |
| CI/CD pipeline compromise | Using stolen credentials to access build systems and inject malicious code |
| npm supply chain attacks | Compromised npm accounts used to push malicious JavaScript packages |
The group's campaign infected developer machines across multiple organizations, with the stolen credentials and persistent access then used for downstream cloud and infrastructure intrusions.
Hacker Infighting Muddies Attribution
As enterprises begin disclosing their breach notifications, ShinyHunters and Lapsus$ have stepped forward to claim some of the same compromises that TeamPCP is believed to have facilitated — either by purchasing access from TeamPCP, independently exploiting the same victims, or simply opportunistically claiming credit for visibility.
This creates a challenging attribution problem:
- Multiple actors, one entry point — TeamPCP's supply chain access may have been sold or shared, meaning several groups exploited the same initial compromise
- Competing claims — ShinyHunters and Lapsus$ public posts on breach forums and Telegram create conflicting narratives
- Data overlap — some stolen data appears in both TeamPCP-linked and ShinyHunters-linked leak posts, suggesting data was traded or sold between groups
- Defenders cannot scope impact accurately — without knowing which actor performed what action post-access, incident response teams cannot be confident they have fully remediated the breach
According to Dark Reading's reporting, this "murky situation for enterprises" is not accidental — creating confusion around attribution is a deliberate tactic that delays response and increases the likelihood of ransom payment or ongoing undetected access.
Organizations Disclosing TeamPCP-Linked Breaches
Several high-profile organizations have disclosed incidents tied to the TeamPCP campaign:
| Organization | Nature of Breach |
|---|---|
| European Commission | AWS cloud account compromised via TeamPCP — data from 30 EU entities exposed |
| Mercor | AI hiring platform; LiteLLM supply chain attack linked to TeamPCP pipeline access |
| Cisco | Source code stolen in a developer environment breach attributed to TeamPCP-linked activity |
| Multiple unnamed enterprises | CI/CD pipeline compromises via stolen developer credentials |
The full list of victims is expected to grow as forensic investigations conclude and disclosure timelines are met.
ShinyHunters and Lapsus$ Involvement
ShinyHunters is a prolific data theft group known for massive breach campaigns against technology companies, having previously hit Snowflake customers, Santander, and AT&T. Lapsus$ is a younger, primarily financially-motivated group known for social engineering and insider-assisted breaches.
Both groups have historically:
- Purchased initial access from other threat actors on dark web access marketplaces
- Taken credit for breaches they did not fully execute to enhance their reputation
- Engaged in public attention-seeking via Telegram channels and breach forums
Their involvement in TeamPCP's victim pool — whether through purchased access, independent exploitation, or reputational opportunism — means affected organizations should assume multiple independent actors may have had access to their systems.
Implications for Enterprise Incident Response
Organizations that believe they may have been affected by TeamPCP's supply chain campaign should:
1. Assume Multiple Actors
If TeamPCP had access to your environment via a compromised developer package or CI/CD pipeline, treat the investigation as if multiple threat groups may have had access — not just one.
2. Audit Developer Toolchain
# Audit Python packages for known malicious versions
pip-audit --fix
# Check npm package integrity
npm audit --audit-level=critical
# Review installed package versions against known malicious hashes
# Reference: TeamPCP malicious telnyx package hashes3. Rotate All Developer Credentials
Any secrets, API keys, or cloud credentials that may have been accessible from a compromised developer machine should be treated as fully compromised:
- AWS IAM access keys
- Azure service principal credentials
- GitHub personal access tokens and deploy keys
- API keys for third-party services (OpenAI, Anthropic, Stripe, etc.)
- Docker registry credentials
- SSH private keys
4. Review CI/CD Pipeline Integrity
# Audit GitHub Actions workflow files for unexpected changes
git log --all --full-history -- .github/workflows/
# Check for unauthorized additions to CI/CD secrets
# Review all repository secrets and environment secrets5. Engage Threat Intelligence
Given the overlapping claims from multiple threat groups, organizations should engage a threat intelligence provider or MDR service that can correlate indicators across TeamPCP, ShinyHunters, and Lapsus$ activity to provide a clearer picture of what actually occurred.
Attribution Complexity: A Tactical Advantage for Attackers
The infighting and overlapping credit claims between TeamPCP, ShinyHunters, and Lapsus$ illustrate a broader trend: threat actor ecosystem fragmentation as a force multiplier. When defenders cannot definitively attribute an intrusion to a single actor, they risk:
- Incomplete remediation — removing one actor's access while another maintains persistence
- Missed indicators — each group has distinct tooling and TTPs; focusing on one group's IOCs may miss the others
- Regulatory and legal complications — breach notification requirements may differ depending on the nature of the attacker and their likely objectives
Security teams must resist the temptation to close investigations once a single attribution is made, and instead pursue full persistence validation across all potentially affected systems.
Source: Dark Reading — April 3, 2026