Threat Actor Profile: TeamPCP (UNC6780)

When automated cloud pipelines and devops workflows encounter self-propagating credential harvesters, the operation can frequently be traced back to TeamPCP—also tracked under aliases such as PCPCat, ShellForce, DeadCatx3, SHADOW-WATER-058, and UNC6780. First emerging as a financially motivated threat group in late 2025, this cloud-native threat actor rapidly transitioned from opportunistic cloud extortion to highly sophisticated software supply chain compromises targeting build environments.

Shift to CI/CD & Supply Chain Operations

TeamPCP initially established a footprint through direct cloud infrastructure attacks, focusing on cryptocurrency hijacking, storage bucket extortion, and local ransomware execution inside misconfigured cloud instances. However, by early 2026, the group underwent a noticeable tactical evolution. Rather than targeting cloud workloads at runtime, TeamPCP shifted upstream into Continuous Integration and Continuous Delivery (CI/CD) pipelines.

The centerpiece of this pivot involved compromising developer workflows and open-source utility ecosystems. In notable campaigns, TeamPCP compromised extensions and wrapper scripts associated with security utilities like the Trivy container scanner. By injecting malicious logic into build-time steps, the threat actor ensured their payloads executed automatically within build containers, GitHub Actions runners, and internal build servers whenever automated container scanning routines were triggered.

Worm-Driven Mechanics & Credential Harvesting

What sets TeamPCP apart from typical cloud access brokers is their heavy reliance on worm-driven propagation mechanics within cloud and DevOps ecosystems. Once execution is achieved inside a build pipeline container, the payload deploys automated discovery tools to scan the execution environment for sensitive context, including:

• Cloud IAM Credentials: AWS access keys, GCP service account keys, and Azure service principal secrets present in environment variables or mounted secret stores.
• Source Control Tokens: GitHub, GitLab, and Bitbucket Personal Access Tokens (PATs) and SSH keys cached in build runners.
• Registry & Package Credentials: Tokens for Docker Hub, AWS ECR, npm, PyPI, and private artifact repositories.

After acquiring these secrets, TeamPCP’s automated tooling leverages the stolen tokens to pivot horizontally. The worm logic systematically enumerates connected source code repositories, injects the malicious build step into pipeline configuration files (such as .github/workflows or Jenkinsfiles across adjacent repos), and pushes the modified code back to central repositories. This creates an exponential, self-propagating compromise footprint across an organization’s entire software delivery lifecycle.

Monetization and Ransomware Partnerships

While TeamPCP handles initial access, credential harvesting, and supply chain expansion directly, they utilize multiple monetization channels rather than relying on a single revenue model:

1. Direct Extortion: Holding stolen source code, proprietary build artifacts, and cloud infrastructure access keys for ransom under threat of public disclosure or cloud environment destruction.
2. Access Brokering: Selling validated high-privilege cloud credentials and compromised CI/CD administrative access to third-party threat groups.
3. Ransomware Syndication: Partnering directly with established ransomware-as-a-service (RaaS) groups, notably Vect and CipherForce. TeamPCP provides these syndicates with pre-established root or administrative access to corporate cloud tenants, enabling rapid downstream deployment of enterprise encryption payloads.

Defense & Detection Guidance

Detecting TeamPCP activity requires focusing heavily on pipeline integrity and secrets management rather than traditional endpoint security controls alone:

• Audit Pipeline Configurations: Monitor repository commit logs and pull requests for unsolicited modifications to CI/CD configuration files, especially those adding unverified external actions, dependencies, or security scanner wrappers.
• Enforce Ephemeral Build Runners: Ensure build execution environments are strictly isolated, ephemeral, and barred from committing code directly back to main branches without mandatory pull-request reviews.
• Restrict Pipeline Secret Scope: Limit pipeline access tokens to the minimum required permissions. Prevent automated build runners from accessing cloud provider IAM keys capable of administrative infrastructure changes.
• Verify Third-Party Action Hashes: Pin third-party CI/CD actions and container security scanner implementations to explicit commit SHA hashes rather than mutable version tags.