TeamPCP Profile: Why Developer Tools Are Becoming the Attack Path

Who is TeamPCP?

TeamPCP is a financially motivated ransomware group tied to software supply chain compromise, credential theft, extortion, and abuse of developer infrastructure. The group is also tracked through aliases including ShellForce, PCPcat, TeamPCP, DeadCatx3, Altered Spider, and PersyPCP. The group has also claimed ownership of CipherForce, which it describes as its private locker.

TeamPCP is not just going after traditional enterprise targets. Their activity is focused on the tools developers use every day: open-source packages, GitHub repositories, CI/CD workflows, VS Code extensions, Kubernetes environments, Docker, npm, PyPI, Trivy, KICS, LiteLLM, the Telnyx Python SDK, and other parts of the development workflow. Developer environments often contain sensitive access by default, including source code, API keys, SSH keys, cloud tokens, Kubernetes secrets, package publishing credentials, and build-system permissions. If an attacker compromises one trusted tool, they do not need to break into every company one by one. They can use the software supply chain itself as the path in.

What’s happening right now?

According to Bitsight Threat Intelligence, TeamPCP-related activity increased by 471% in the last month compared to similar groups. TeamPCP’s activity lines up with where cybercrime is moving, as we discussed in the 2026 State of the Underground. Attackers are moving upstream into the software development process. Instead of only trying to phish users or break into networks directly, they are going after the trusted tools, packages, credentials, and workflows that developers already use.

Attackers do not need to break in through the front door. They can slip a compromised package into a project, use a stolen token to publish malware under a trusted name, or rely on a malicious extension to steal local credentials. Once a repository is compromised, internal code, secrets, and business logic can all be exposed. This is a business risk because one compromised dependency, vendor, package, or extension can affect customers, partners, suppliers, and downstream users.

Who is at risk? 

TeamPCP is most relevant to organizations that rely heavily on software development infrastructure and third-party code. That includes software vendors, SaaS companies, cloud-native organizations, open-source maintainers, DevOps teams, platform engineering teams, and companies using GitHub, npm, PyPI, Docker, GitHub Actions, VS Code, or Kubernetes.

Bitsight Threat Intelligence has seen a huge shift towards third party targeted attacks. Threat actors are going after larger blast radius attacks, so a company does not need to be directly targeted by TeamPCP to be in the line of fire. If a vendor, package, extension, or dependency is compromised, the risk can move downstream. That is why this should be treated as a third-party risk issue, a developer security issue, and a business continuity issue.

TeamPCP supply chain activity

More recent reporting also connects TeamPCP to Vect, an emerging Ransomware-as-a-Service operation. The concern is that TeamPCP’s access from supply chain compromise and stolen credentials could help feed Vect ransomware deployment and extortion activity. Recently, TeamPCP has been linked to compromised developer and security tools, including Trivy, KICS, LiteLLM, and the Telnyx Python SDK. The group has used credential-stealing malware to harvest secrets from developer and cloud environments, including SSH keys, Kubernetes credentials, cloud tokens, .env files, package publishing credentials, and other access that can help attackers move deeper into an environment.

The FBI FLASH also lists SANDCLOCK, Mini Shai-Hulud, and Miasma as malware used by TeamPCP. SANDCLOCK is described as a credential-stealing tool, while Mini Shai-Hulud and Miasma are tied to self-replicating supply chain activity across npm and PyPI. This supports the broader pattern: TeamPCP is using stolen credentials and trusted package ecosystems to scale activity across developer environments.

Another major piece of reporting involved claims around thousands of GitHub internal repositories. Public reporting linked the activity to a malicious Visual Studio Code extension installed by a GitHub employee. GitHub reportedly contained the incident, removed affected extensions, isolated the device, and rotated critical secrets.

Recent social media activity also shows TeamPCP’s name being used in connection with the xinference PyPI hijack, where reporting referenced stolen cloud credentials, SSH keys, and .env secrets.

Statement on Vect

TeamPCP and Vect are now reported to be working together, which changes the risk picture. TeamPCP brings the supply chain side of the operation, compromising developer and security tools, stealing credentials, and gaining access through trusted software channels. Vect brings the ransomware side through its Ransomware-as-a-Service operation and extortion model. That combination matters because it connects two parts of the attack chain. TeamPCP can create access at scale through compromised packages, CI/CD pipelines, and stolen credentials. Vect can then use that access to support ransomware deployment and extortion.

There is also an important recovery issue. Vect’s encryptor has reportedly had serious coding flaws. For files larger than 128 KB, researchers found that the ransomware can corrupt data in a way that makes recovery impossible, even if a victim pays and receives a key. That makes clean, disconnected backups even more important.

Earlier TeamPCP messaging tried to separate CipherForce from Vect’s encryption issues, but newer reporting indicates the two groups are now working together. The FBI FLASH confirms TeamPCP’s supply chain activity and broader collaboration with cyber actors, while public reporting from security researchers and media connects TeamPCP specifically to Vect.

TeamPCP’s tactics, techniques, and procedures

TeamPCP’s activity is centered on abusing trusted developer workflows. Tactics tied to the group include compromising open-source packages and developer tools, harvesting credentials from developer and cloud environments, targeting CI/CD pipelines and publishing workflows, moving laterally inside Kubernetes environments, abusing npm and PyPI package ecosystems, using malicious VS Code extensions, exfiltrating private repositories and sensitive development data, using stolen credentials to spread across other packages or environments, using AES-256 and RSA-4096 encryption during exfiltration, and using evasion techniques, including audio steganography, based on internal reporting. TeamPCP combines credential theft, trusted developer tooling, package ecosystem abuse, and cloud-native access. That combination can scale quickly and create risk beyond the first victim.

MITRE ATT&CK mapping

TeamPCP-related activity maps to several MITRE ATT&CK techniques and behaviors, including:

• Escape to Host — T1611
• OS Credential Dumping — T1003
• Subvert Trust Controls — T1553
• Unsecured Credentials — T1552
• Exfiltration Over Web Service — T1567
• Data Destruction — T1485
• Create or Modify System Process — T1543
• Supply Chain Compromise — T1195

Their activity is not limited to one malware payload or one package ecosystem. It touches trust controls, credentials, system processes, Kubernetes environments, and exfiltration paths.

Technical details

TeamPCP-style attacks often start with something that looks legitimate. That could be a trusted package, a VS Code extension, a build workflow, or a developer credential. Once that trust is abused, the attacker can get access to places that are hard to monitor. A malicious package may run during installation. A compromised extension may have access to local files, terminals, authentication tokens, and cloud tooling. A stolen publishing token may allow attackers to push a malicious update under a trusted package name.

The risk is especially high in CI/CD environments because build systems often have access to secrets, deployment workflows, repositories, and production-adjacent infrastructure. If attackers get access there, they may be able to steal credentials, alter builds, publish malicious packages, or move deeper into cloud and Kubernetes environments.

Vulnerability management and resilience suggestions

Organizations should treat developer tooling as part of the attack surface. That includes developer workstations, package publishing accounts, CI/CD systems, repositories, cloud credentials, and build infrastructure.

Practical steps include:

• restricting unapproved IDE extensions
• reviewing installed VS Code extensions
• enforcing least privilege for GitHub, npm, PyPI, Docker, and CI/CD credentials, rotating credentials after suspected compromise
• scanning repositories for hardcoded secrets
• monitoring package updates for suspicious behavior
• using approved dependency lists or internal package mirrors
• hardening Kubernetes access
• auditing cluster secrets
• monitoring dark web, paste, ransomware, and code repository sources for leaked assets

Security teams should treat developer workstations, package publishing accounts, and build systems like sensitive infrastructure. They are not just engineering tools. They are high-value access points.

Strategic implications

For senior leaders, the key takeaway is that TeamPCP is not only a technical threat. Their activity shows how quickly software supply chain compromise can become a business risk. A single compromised package, stolen credential, or malicious extension can expose code, secrets, cloud infrastructure, customers, vendors, and downstream users. It can also create reputational damage if an organization is connected to a compromised tool or dependency. This is why software supply chain security should not sit only with engineering. It should be part of security, vendor risk, GRC, and business continuity planning.

How Bitsight can help

Bitsight Threat Intelligence provides visibility into activity across Telegram, deep and dark web forums, paste sites, GitHub, code repositories, ransomware sources, cyber news, social media, and other open and closed sources. For a threat like TeamPCP, this can help identify early signs of malicious package activity, repository exposure, credential theft, actor claims, copycat activity, and chatter involving vendors or developer tooling.

Bitsight Dark Web Intelligence for Supply Chains helps organizations detect, prioritize, and respond to threats across their third-party vendor ecosystem before they disrupt business operations. For TeamPCP-style activity, this matters because a company may not be directly targeted but can still be exposed through a vendor, software provider, open-source maintainer, package dependency, CI/CD tool, or compromised extension.

Bitsight Security Posture Management helps teams gain a wide view of the attack surface, including exposed assets, services, vendors, and dependencies that may create risk. Its extended attack surface discovery capabilities continuously map an organization's external digital footprint to surface the attacker's point of view and identify the exposures that matter most to the business. Bitsight Beacon, Bitsight's Supply Chain Exposure Management solution, can also help teams identify signs that a vendor or supplier may be exposed, actively compromised, or already breached. Together, these capabilities help organizations move from "we may be at risk" to "these are the assets, vendors, and exposures we should address first."

The bottom line

TeamPCP shows how software supply chain attacks can scale through trust. Developers may install a package because it looks legitimate. A build system may run a workflow automatically. A stolen token may let attackers publish a malicious update under a trusted name.

Bitsight helps organizations move from reactive response to proactive resilience by combining real-time threat intelligence, dark web visibility, third-party risk insights, external attack surface monitoring, supply chain telemetry, security ratings, and expert analysis.

TeamPCP is a reminder that developer tooling is now part of the attack surface. Organizations need visibility into their own environments, their vendor ecosystem, and the threat actors targeting the software supply chain before one trusted tool becomes the entry point.