Notifications
Clear all
Topic starter
09/07/2026 1:41 pm
TL;DR: TeamPCP moved from exploiting exposed cloud services and stealing credentials to compromising GitHub repositories, CI/CD pipelines, and package ecosystems, with public reporting linking the group to more than 59,000 compromised systems in one campaign and 3,800 internal repositories in another, according to Gurucul. The pattern shows that developer identity and pipeline trust now define downstream blast radius more than perimeter controls do.
NHIMG editorial — based on content published by Gurucul: Threat Intelligence Threat Actor Profile - TeamPCP
By the numbers:
- GitHub subsequently confirmed unauthorized access to approximately 3,800 internal repositories.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
Q: What breaks when cloud credentials are exposed in developer environments?
A: Exposed cloud credentials break the assumption that development systems are low-risk staging areas.
Q: Why do developer identities create outsized supply chain risk?
A: Developer identities matter because they can publish, modify, or sign software that others already trust.
Q: How do security teams know when CI/CD access is too broad?
A: CI/CD access is too broad when routine build identities can reach signing, publishing, or repository-modification functions.
Practitioner guidance
- Separate developer secrets from routine runtime paths Move API keys, SSH keys, and cloud credentials out of application files and into tightly scoped secret stores, then verify that build jobs do not inherit more than they need.
- Review publish and signing authority in CI/CD Identify which pipeline identities can modify, sign, or publish artefacts, then strip those rights from routine build steps.
- Harden repository and workstation adjacency Treat developer endpoints as entry points into higher-trust systems and enforce strong session control, device posture checks, and token binding for internal repositories.
What's in the full article
Gurucul's full blog covers the operational detail this post intentionally leaves for the source:
- A timeline of TeamPCP campaigns across cloud services, GitHub repositories, and package ecosystems.
- The specific malware families and underground infrastructure used to support credential theft and propagation.
- Observed indicators of compromise and the group’s collaboration patterns with other criminal actors.
- The reported GitHub internal repository access path and the public claims made by the threat actor.
👉 Read Gurucul’s threat actor profile on TeamPCP’s cloud and supply chain activity →
TeamPCP’s cloud-to-supply-chain shift: what IAM teams need to know?
Explore further
09/07/2026 1:45 pm
Cloud credential exposure is now a supply chain risk, not just a perimeter problem. TeamPCP’s progression shows that exposed cloud services are often the first identity foothold into higher-trust software systems. Once an attacker gets reusable credentials, the operational boundary shifts from one host to the broader development estate. Practitioners should stop treating cloud secrets as isolated artefacts and start treating them as distribution risk.
A few things that frame the scale:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys.
A question worth separating out:
Q: Who is accountable when a compromised repository identity affects downstream users?
A: Accountability sits with the teams that granted the repository, pipeline, or developer credential too much trust for its role. In practice, that means identity owners, platform teams, and security governance functions all need visibility into who can publish, sign, and distribute artefacts. Lifecycle control and access review must include software delivery authority, not just login access.
👉 Read our full editorial: TeamPCP shows how cloud identity abuse scales into supply chain compromise
