TeamPCP shows how cloud identity abuse scales into supply chain compromise

At a glance

What this is: TeamPCP is a financially motivated group that escalated from cloud exploitation into software supply chain compromise and developer credential theft.

Why it matters: IAM, NHI, and PAM teams need to see how exposed cloud identities and developer credentials can become distribution channels for broader compromise.

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.

👉 Read Gurucul’s threat actor profile on TeamPCP’s cloud and supply chain activity

Context

TeamPCP is a cloud and software supply chain threat actor, not just another malware group. The primary identity problem here is that exposed cloud credentials, developer tokens, and CI/CD access can be reused as trusted access paths into software delivery systems.

That matters to NHI governance because service credentials used in cloud and build environments often outlive the human, workstation, or application context that created them. Once those identities are compromised, the attacker can move from initial access to credential harvesting, repository access, and distribution-scale impact.

The article’s starting point is typical of modern cloud-native compromise: opportunistic access to exposed services leads to credential theft, then to trusted pipeline abuse. The difference is the scale of downstream harm once those identities sit inside development infrastructure.

Key questions

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. Once API keys, SSH keys, or environment files are stolen, the attacker can reuse those identities across repositories, cloud control planes, and CI/CD systems. The practical consequence is that a single leak can become a multi-system trust failure, not just a one-host incident.

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. When those credentials are stolen, attackers do not need to break each downstream environment individually. They only need one trusted path into build and release systems to turn routine software delivery into a propagation channel.

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. A strong signal is any pipeline token that can alter artefacts without a separate review step. Teams should verify that routine automation can build software, but cannot independently decide what gets released.

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.

Technical breakdown

Exposed cloud services as the first identity foothold

TeamPCP’s early workflow begins with scanning for internet-facing cloud services and developer workloads, including Kubernetes, Docker APIs, Redis, Ray dashboards, and vulnerable application endpoints. In identity terms, the target is not the server itself but the credentials, configuration files, and runtime trust attached to it. Once an exposed service yields secrets, the attacker can reuse them across cloud control planes, storage, and build systems. The key failure is that the service boundary was reachable before the identity boundary was enforced.

Practical implication: treat externally reachable workloads as identity harvest points and not just infrastructure assets.

Credential theft from developer and build environments

Operation PCPcat shows the next stage clearly: once a server is accessed, the attacker searches for .env files, API tokens, SSH keys, database credentials, and cloud secrets. This is classic NHI abuse because the attacker is extracting non-human identities embedded in developer workflows, then centralising them in C2 for reuse. The important detail is that the value lies in reusable credentials, not in the compromised host itself. That makes lifecycle control, secret minimisation, and context-bound access central to defence.

Practical implication: inventory where developer secrets live, then reduce the number of places where they can be exfiltrated together.

CI/CD compromise and software supply chain propagation

TeamPCP’s later campaigns move into CI/CD pipelines, GitHub repositories, and package ecosystems. This changes the attack from one-off credential theft into trusted distribution abuse, where malicious code is inserted into systems that other organisations already trust. The attacker then gains leverage from the software supply chain itself. For identity teams, the issue is delegated trust: a compromised pipeline identity can sign, publish, or modify artefacts that downstream consumers treat as legitimate.

Practical implication: bind build identities to narrowly scoped, reviewable actions and separate publish rights from routine pipeline execution.

Threat narrative

Attacker objective: The objective is to turn a small number of compromised cloud and developer identities into trusted access that can affect many downstream organisations and software consumers.

1. Entry began with automated scanning of exposed cloud services and vulnerable developer-facing applications, including Kubernetes, Docker, Redis, Ray, and Next.js systems.
2. Escalation followed when the attackers harvested credentials, environment files, API tokens, and SSH keys, then used those non-human identities to reach repositories and CI/CD infrastructure.
3. Impact came from software supply chain abuse, where compromised developer access enabled malware distribution, repository compromise, and broader downstream exposure.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Developer identities have become downstream control points for enterprise compromise. The article shows that API keys, SSH keys, environment files, and pipeline tokens can all act as portable non-human identities. That means the security model must account for where those identities are stored, how long they remain valid, and which systems can reuse them. The practical conclusion is that developer credentials need lifecycle governance, not just vaulting.

Trusted software delivery has become an identity amplification layer. When CI/CD, repositories, and package registries are compromised, the attacker is not merely breaking into a toolchain. They are abusing an existing trust relationship that can propagate malicious code to many consumers at once. That should force security teams to re-evaluate which identities are allowed to publish, sign, and distribute artefacts.

Repository and pipeline access now require blast-radius thinking. TeamPCP’s activity shows why least privilege must be measured against release authority, not just login authority. A build or repository identity with the power to alter artefacts has a different risk profile from one that can only read logs. The governance question is whether the identity can reach production trust, not whether it can authenticate.

GitHub internal repository compromise is a named concept for identity adjacency risk. A workstation compromise became a repository compromise because developer access was chained into trusted internal assets. That is a reminder that identity exposure is increasingly indirect: the attacker does not need to break every control, only the one that links a lower-trust endpoint to a higher-trust development system. Practitioners should map those adjacency paths explicitly.

From our research:

• 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.
• That timing pressure is why practitioners should also review 52 NHI Breaches Analysis for the patterns that repeatedly turn exposed secrets into broad compromise.

What this signals

Ephemeral exposure windows are now part of the control design. When exposed credentials can be attempted in minutes, the governance model must assume that detection, triage, and revocation all happen under severe time pressure. The practical shift for teams is from periodic review to continuous exposure reduction across cloud and developer identities.

The most important programme question is no longer whether a secret exists, but whether it can be found, reused, and propagated before controls react. That is why the distinction between workload identity, developer tokens, and signing authority matters in day-to-day IAM operations.

With 67% of organisations still relying heavily on static credentials according to the 2026 Infrastructure Identity Survey, the structural mismatch is obvious: attacker speed is measured in minutes, while many identity programmes still operate on review cycles measured in weeks or longer.

For practitioners

• 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. The goal is to prevent a single compromised host from exposing multiple reusable identities at once.
• 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. Separate read, build, and release functions so a compromised workflow cannot automatically become a software distribution event.
• 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. The key control gap is the path from a laptop compromise to repository access.
• Shorten the lifetime of exposed cloud credentials Assume exposed credentials will be attempted quickly and rotate or revoke them as soon as they are discovered. The operational objective is to reduce the window in which a leaked key can be reused across cloud and build environments.
• Map package and pipeline trust to real blast radius List every identity that can influence code distribution, then test whether that identity can reach downstream consumers. If it can publish or alter artefacts, treat it as a high-risk production credential rather than a routine automation token.

Key takeaways

• TeamPCP demonstrates how cloud credential theft can evolve into trusted software supply chain compromise.
• The scale of impact is defined by downstream trust paths, not just the number of systems initially breached.
• Teams that control developer credentials, CI/CD authority, and repository access can materially reduce blast radius.

Key terms

• Cloud Identity Foothold: A cloud identity foothold is the first usable access an attacker gains through exposed credentials, tokens, or misconfigured services. In cloud-native environments, that foothold matters more than the host itself because it can be reused across repositories, control planes, and build systems.
• Developer Credential Sprawl: Developer credential sprawl is the uncontrolled spread of keys, tokens, SSH material, and secrets across endpoints, applications, and build pipelines. The risk is not just exposure but reuse, because one stolen credential can unlock multiple trusted workflows.
• Trusted Distribution Abuse: Trusted distribution abuse happens when an attacker compromises a system that other organisations already trust to build, sign, or publish software. The impact scales because the malicious artefact is delivered through a legitimate channel, which bypasses many downstream security checks.
• Pipeline Authority: Pipeline authority is the level of control a CI/CD identity has over build, test, sign, and publish actions. In practice, it defines whether automation can merely assemble software or whether it can also change what is released to users.

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.

👉 Gurucul’s full post includes the campaign timeline, tooling, and repository compromise details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.