Vect and TeamPCP show how stolen build secrets become ransomware access

Sophos says two cybercrime groups, Vect and TeamPCP, have formalized a partnership that links software supply chain attack operations directly to ransomware deployment.

That combination matters because it connects two parts of the intrusion economy that defenders often track separately. TeamPCP specializes in stealing credentials through compromised developer and security tooling. Vect provides ransomware-as-a-service infrastructure. Together, the groups create a clearer path from poisoned updates and CI/CD token theft to hands-on extortion inside victim environments.

Sophos Counter Threat Unit researchers describe the relationship as a meaningful shift in the ransomware threat landscape. The model is not just "one group bought access from another." It is a working pipeline: compromise trusted tools, harvest secrets, pass usable access to ransomware operators, and scale the operation through affiliate recruitment.

What Sophos reported

According to Sophos, Vect first appeared as a ransomware-as-a-service operation at the end of 2025, advertised on a Russian-language cybercrime forum. By early 2026 it was recruiting affiliates, claiming victims, and promoting Vect 2.0.

TeamPCP, also tracked under names including PCPcat, ShellForce, and DeadCatx3, has been tied to a string of supply chain compromises against trusted developer and security tooling. Palo Alto Networks Unit 42 previously documented TeamPCP attacks against tools and packages including Trivy, KICS, LiteLLM, and the Telnyx Python SDK. Those campaigns were designed to extract cloud access tokens, SSH keys, Kubernetes secrets, package credentials, and other portable identity material from developer and CI/CD environments.

Sophos says the two groups announced a formal operational partnership in late March 2026. The purpose is blunt: combine TeamPCP's credential harvesting and data theft with Vect's ransomware deployment capability.

Most importantly, Sophos says at least one verified Vect ransomware deployment has used TeamPCP-sourced credentials. That means the bridge between supply chain compromise and ransomware execution is no longer only a plausible risk. It has already been observed.

Why this model is dangerous

Developer and build systems sit near the keys attackers want. CI/CD runners often hold cloud credentials, deployment tokens, package publishing rights, container registry secrets, SSH material, and access to production infrastructure. Security tools can be even more sensitive because they are deliberately granted broad visibility.

TeamPCP's earlier campaigns showed how attackers can turn trusted tools into collection points. In the Trivy campaign, Unit 42 reported that malicious updates were pushed through compromised GitHub Actions tags. The payloads searched for AWS, Google Cloud, and Azure credentials, Kubernetes material, and other environment secrets. In the Telnyx PyPI compromise, SANS Internet Storm Center noted malicious SDK versions that used platform-specific payloads and steganography inside .wav files.

This is not ordinary malware delivery. It is theft from environments that are already trusted to build, scan, deploy, and secure production systems.

Once those secrets are stolen, ransomware operators do not need to break through the front door. They can log in through valid credentials, use allowed management paths, and move through systems that security teams may treat as normal administrative activity. That is why credential theft from development pipelines has become a ransomware problem, not just a software integrity problem.

The affiliate problem

Sophos also highlights Vect's attempt to scale through broad affiliate recruitment and partnerships with cybercrime communities. SANS ISC previously reported that the TeamPCP, Vect, and BreachForums model would put stolen supply-chain access, ransomware tooling, and a large operator pool into the same ecosystem.

Even if only a fraction of that operator pool is capable, the economics change. Supply chain compromise supplies credentials. Ransomware-as-a-service supplies encryption and extortion tooling. Forums supply distribution, recruiting, reputation, and resale channels.

That is the industrialization point: one team does not need to master every stage. Specialists can divide the work.

Paying may not restore data

There is another risk in the Vect story: the ransomware itself may be technically unreliable.

Sophos warns that organizations affected by Vect should not assume payment will restore data. Third-party researchers have documented encryption flaws in Vect that can make recovery impossible, turning some incidents into permanent data loss rather than negotiable extortion.

For defenders, that changes response priorities. Backup validation, immutable recovery, and rapid containment matter more than negotiation assumptions. If ransomware code destroys the data it claims to hold hostage, the business decision tree becomes much narrower.

Who should act first

The highest-priority group is any organization that used tools or packages associated with TeamPCP's campaigns, including affected Trivy, KICS, LiteLLM, and Telnyx components or CI/CD workflows around the relevant compromise windows.

Security teams should not limit review to developer workstations. The most sensitive exposure is usually inside automation:

1. GitHub Actions and other CI/CD runners
2. Cloud deployment roles and service accounts
3. Container registries and Kubernetes clusters
4. Package publishing credentials
5. Security scanners and build-time secrets
6. SSH keys and infrastructure-as-code pipelines

If a compromised package or action executed in one of those environments, assume it could read the secrets available to that process. Then rotate based on privilege, not convenience.

Immediate response checklist

Start with exposure confirmation:

1. Build an inventory of affected packages, GitHub Actions, CI/CD templates, and internal mirrors.
2. Check whether vulnerable or malicious versions executed in build, scan, test, or deployment pipelines.
3. Review pipeline logs for unexpected outbound connections, archive creation, token enumeration, or unusual process execution.
4. Search for TeamPCP indicators from Sophos, Unit 42, SANS, and package-maintainer advisories.

Then assume secret exposure where execution occurred:

1. Rotate cloud access keys, service-account credentials, and deployment tokens exposed to the runner.
2. Rotate GitHub personal access tokens, deploy keys, package registry tokens, and container registry credentials.
3. Invalidate Kubernetes service account tokens that could have been read from build or cluster contexts.
4. Review IAM usage for new sessions, role assumptions, or API calls from unfamiliar infrastructure.
5. Rebuild affected artifacts from clean dependencies and pinned versions.

Finally, prepare for ransomware follow-on:

1. Hunt for Vect indicators across environments tied to exposed credentials.
2. Review remote access, VPN, and cloud login telemetry for valid-credential access.
3. Validate offline or immutable backups before an incident.
4. Include CI/CD and developer infrastructure in incident response tabletop exercises.

Detection ideas

Useful detection is not only endpoint malware detection. It should include the places where build systems touch production.

text
CI/CD and source control:
- Force-pushed tags or unexpected action revisions
- Package versions present in registries but missing from upstream release history
- Build jobs reading unusually broad environment variables
- Access to /proc/<pid>/mem or runner internals from build scripts
- New outbound connections from CI/CD runners during dependency install or scanner execution

Cloud and Kubernetes:
- New API calls using build-time service accounts
- Kubernetes token use outside normal pipeline timing
- Container registry pushes from unfamiliar hosts
- IAM changes shortly after suspicious build jobs

Ransomware preparation:
- Valid-credential logins from new infrastructure
- Mass file enumeration after developer-token use
- Backup discovery, deletion, or snapshot tampering
- Lateral movement from systems that only should build or scan code

The goal is to catch the handoff. A TeamPCP compromise may look like a build-system incident on day one. A Vect follow-on may look like valid account use days or weeks later.

The bigger lesson

The Vect and TeamPCP partnership shows why software supply chain security cannot stop at package integrity. Integrity checks are necessary, but the prize is often the secrets that build systems expose during normal work.

If those secrets are stolen, the incident becomes an identity, cloud, and ransomware problem. Security teams need to know which tools ran, which credentials they could read, where those credentials were accepted, and whether any downstream access followed.

For now, the practical response is disciplined and urgent: inventory affected tooling, rotate exposed secrets, pin and verify updates, monitor valid-credential use, and treat CI/CD compromise as potential ransomware prepositioning.

References

1. Vect and TeamPCP partner for ransomware campaigns
2. Weaponizing the Protectors: TeamPCP's Multi-Stage Supply Chain Attack on Security Infrastructure
3. TeamPCP Supply Chain Campaign: Update 002
4. Warning Over Industrialized Cyber-Attacks by Ransomware Gang