Summary
- Sophos says Vect and TeamPCP have formed an operational partnership combining supply chain compromise and ransomware deployment.
- The groups are linked to credential harvesting, open source tooling compromise, and at least one verified Vect deployment using TeamPCP-sourced credentials.
- The risk reaches UK and European organisations through dependencies, CI/CD pipelines, developer credentials, and automated software consumption.
Researchers say two cybercrime groups have connected software supply chain compromise with ransomware deployment, creating a more direct route from stolen developer credentials and poisoned tooling to extortion against downstream organisations.
Sophos Counter Threat Unit researchers investigated Vect and TeamPCP and said the groups announced a formal operational partnership in late March 2026. Sophos describes the arrangement as combining TeamPCP’s credential harvesting and data theft capabilities with Vect’s ransomware deployment infrastructure in a campaign involving supply chain attacks and extortion against multiple organisations.
The research says credentials harvested through supply chain compromises enable large-scale ransomware deployment. It also says TeamPCP has shown an ability to repeatedly compromise trusted open source tooling, and that at least one verified Vect ransomware deployment using TeamPCP-sourced credentials has been confirmed.
The operational pattern is important because software supply chain compromise does not need to begin with a direct attack on the final victim. Attackers can compromise a tool, package, extension, build process, or developer account, then use the trust placed in that component to reach many organisations at once. When that access is paired with ransomware infrastructure, the initial compromise can become a route to extortion rather than credential theft alone.
Sophos links TeamPCP to a series of compromises affecting widely used security and AI tooling. Its research describes attacks involving Trivy, Checkmarx components, LiteLLM, the Telnyx Python SDK, and a later Checkmarx Jenkins AST plugin incident. The campaign included malicious packages, stolen credentials, exfiltrated secrets, and abuse of developer and automation workflows.
The UK and European relevance comes from dependency rather than attacker geography. Organisations import software risk through package managers, container images, CI/CD workflows, infrastructure-as-code modules, developer extensions, AI application libraries, and automated updates. A business may never interact with a criminal group directly, but it may run affected software, depend on a supplier that runs it, or hold secrets in environments reachable through stolen developer credentials.
Security tools are uncomfortable targets because they often run inside trusted engineering workflows. Developers and build systems may execute scanners, plug-ins, and automation tools with access to repositories, package registries, cloud credentials, Kubernetes clusters, and deployment infrastructure. A malicious update in that context can expose the machinery used to build and ship many applications rather than a single endpoint.
The ransomware connection changes post-compromise assessment. Credential theft from a developer environment may once have been treated as contained if access could be revoked quickly. If attackers are building an extortion pipeline around supply chain access, response teams need to assume that stolen credentials, tokens, secrets, and build artefacts may be used later, potentially by a different criminal group with different objectives.
Remediation can therefore become evidence-heavy. Removing a malicious package or reverting a compromised version is not enough if secrets have already been harvested. Organisations may need to rotate credentials, inspect build logs, review package provenance, monitor for unusual cloud and Kubernetes activity, validate deployment artefacts, and determine whether supplier or customer environments may have been exposed.
The commercial pressure is also growing. Software vendors and managed service providers may be asked to prove how they control packages, protect CI/CD credentials, review open source updates, and respond to upstream compromise. Customers in regulated sectors will increasingly treat those answers as part of supplier assurance, especially under NIS2, DORA, and wider operational resilience requirements.
Some details depend on researcher assessment and criminal-group statements, which should be handled with care. The technical and operational pattern is still well established: ransomware operators are seeking scalable access, and software supply chains can provide it. Application security, developer identity, secrets management, supplier assurance, and ransomware preparedness now form one connected risk path.
