When SAP’s npm packages showed up in TeamPCP’s target list, it marked a shift. This campaign started with security scanners and AI proxies. Tools developers touch. Tools that sit adjacent to cloud credentials and CI pipelines. SAP’s Cloud Application Programming Model tools are something else. They are the build framework for enterprise ERP systems: the infrastructure behind procurement, finance, and supply chain operations at thousands of large organizations. When those packages are compromised, the credential harvest is not just developer tokens. It is everything those pipelines touch.
We have been tracking this actor since the Trivy intrusion in March. The model has been consistent: compromise a trusted developer tool, collect the credentials it touches, hand them to groups like VECT for ransomware deployment. What has changed is how far up the enterprise stack they are willing to go, how much more sophisticated the evasion has become, and who ends up holding the bill when a ransomware payload cannot actually decrypt what it destroys. TL;DR
TeamPCP targets developer tools based on Trust Chain position and credential density, not the organizations using them. If your developers rely on a tool with elevated CI permissions, that tool is the target surface.
The actor’s evasion methods are improving with each operation. Payloads that once lived in package source code now download at runtime, hidden inside WAV audio files. Static analysis finds nothing because there is nothing to find at install time.
SAP’s enterprise ERP build packages were compromised with memory-reading payloads that bypass CI log masking entirely. The credential harvest reaches production systems, not just developer pipelines.
Dependabot, GitHub’s trusted automation bot, was used as a delivery mechanism in the most recent confirmed operation. The attack required no human error. The automation did the work.
VECT 2.0, the ransomware monetizing stolen credentials, has a documented defect. Files larger than 128KB are destroyed rather than encrypted, according to SC World. Paying does not restore them.
Communication Governance stops the exfiltration event every operation depends on, regardless of which tool is compromised next.
How TeamPCP Operates The model has three phases: compromise a trusted tool in the developer Trust Chain, harvest the credentials that tool has access to, then either use those credentials to reach the next target or hand them to groups like VECT for ransomware deployment. Target selection follows consistent logic. TeamPCP is not looking for the most popular package. They are looking for packages that sit at points of elevated permission in developer workflows. Trivy was a security scanner with CI/CD signing access. LiteLLM was an AI proxy co-located with cloud credentials and AI API keys. Bitwarden CLI is the tool developers use to pull secrets out of their credential vault. Each target sits where credentials concentrate.
The propagation mechanism compounds the exposure. When TeamPCP compromises a tool like Trivy, they collect the CI/CD secrets of every organization whose pipeline ran it. Some of those secrets include publishing credentials for other packages. LiteLLM was not a separate operation. It was downstream of Trivy. The credentials stolen from one target become the access for the next. Arctic Wolf documents this chain across the Q1 operations. Our March 24 post on the LiteLLM compromise covers the full technical path from Trivy to PyPI.
What has changed in recent operations is the evasion sophistication and the target class. Both are worth understanding on their own terms.
SAP Is Not a Developer Tool.
That Is the Point. The four compromised packages, @cap-js/sqlite, @cap-js/postgres, @cap-js/db-service, and mbt, are core components of SAP’s Cloud Application Programming Model. Organizations building on SAP’s enterprise platform use these packages to deploy and manage database-connected business applications: ERP systems, financial reporting, procurement workflows. This is not developer-adjacent infrastructure. This is enterprise operations.
Trend Micro’s analysis documents what the preinstall scripts did: read directly from /proc//maps and /proc//mem on CI runners to extract secrets from process memory. That technique bypasses log masking entirely. If your CI pipeline masks sensitive values in build logs, that control does not apply to secrets read directly from memory before they ever reach a log line. The control you rely on was never in the path.
The SAP compromise is the clearest signal yet that TeamPCP is not limiting themselves to developer tooling. Any tool with elevated CI permissions and access to production credentials is in scope. The enterprise ERP ecosystem was not a target before. It is now.
Bitwarden CLI Is a Different Kind of Target
Every prior compromise in this campaign targeted tooling adjacent to the build pipeline: security scanners, AI proxies, communications SDKs. Bitwarden CLI is the pipeline’s credential store itself.
Developers use @bitwarden/cli in CI/CD automation to retrieve secrets from a Bitwarden vault: API keys, tokens, credentials that should not live in config files. A compromised Bitwarden CLI means the infostealer collects secrets before they are used, not after. The vault becomes the point of collection.
What makes the delivery mechanism more alarming is that no developer made a mistake. GitGuardian documents Dependabot, GitHub’s trusted automated dependency bot, pulling a trojanized checkmarx/kics:latest Docker image during a routine update. Dependabot runs with elevated CI permissions by design. It executed the payload, accessed repository secrets, and propagated the attack with zero human involvement. As the GitGuardian researcher noted: “no one was watching.”
If Dependabot runs in your CI with elevated permissions and no review gate, the delivery mechanism requires no human error. The automation does the work.
Shai-Hulud Uses GitHub Against You
The worm deployed in the Bitwarden attack, Shai-Hulud, does something none of the earlier stealers did: it specifically hunts for AI coding assistants. GitGuardian’s analysis confirms the target list includes Claude Code, Gemini CLI, Codex CLI, Kiro CLI, Aider, and OpenCode.
If any are present on a compromised host, Shai-Hulud injects persistent code into ~/.bashrc and ~/.zshrc, the shell startup files that execute every time a developer opens a terminal. The injection survives a package reinstall. The developer’s coding assistant becomes a persistent execution point for every session that follows.
Shai-Hulud also uses GitHub itself as a fallback C2 server. If the primary infrastructure is taken down, the worm searches public commits for a specific tag where TeamPCP posts updated exfiltration domains. It then creates a new repository under the victim’s own GitHub account to upload encrypted credential blobs, making the activity look like normal developer behavior in audit logs. If you are relying on GitHub audit logs to catch unauthorized exfiltration, this is the scenario where that detection fails.
The Ransomware Has a Bug. That Is the Worst Part.
VECT 2.0, the ransomware operation converting stolen credentials into revenue, has a documented defect. SC World reports that files larger than 128KB are destroyed rather than encrypted.
Ransomware extortion works because the attacker holds the decryption key. VECT 2.0 cannot provide a working key for files over 128KB because those files no longer exist. Paying does not restore them. Most enterprise assets, database files, VM images, backup archives, code repositories, clear that threshold easily.
Organizations facing a VECT 2.0 deployment are not in a ransomware recovery scenario where payment is a viable option. They are in a data destruction event with a ransom demand attached that cannot deliver. The organization that pays and the one that does not are in the same position.
If your IR playbook includes “negotiate and pay” as a recovery path for ransomware events, update it.
The Detection Gap Is Widening
Detection built for what is inside a package cannot see what is downloaded after install. The Telnyx and Bitwarden operations were specifically designed around that gap.
First, the payload is no longer in the package. Trend Micro documents that the Telnyx credential harvester lives on the C&C server, hidden inside WAV audio files, downloaded and decoded at runtime. Static analysis of the package finds nothing because the malicious code is not there. It is fetched after install. The same pattern applies to Shai-Hulud’s GitHub C2 fallback: the instructions live in public commits, not in the package itself.
Second, the SAP campaign introduced direct memory-reading on CI runners, bypassing log masking entirely, as covered above.
Both shifts point in the same direction: detection that relies on inspecting what is in a package at install time is behind where this campaign is operating.
Four Questions for Your Next Security Review
Does your automation have more access than you have explicitly authorized? Dependabot ran the Bitwarden CLI payload with elevated CI permissions because that is the default configuration, not because anyone decided it should. Most organizations have not reviewed what their automated systems can reach and do. The question for your next review: what automated processes in your pipelines hold elevated credentials that no human explicitly recertified in the last quarter? That list is the attack surface.
What happens if the tool your developers use to retrieve secrets is the attack vector? Bitwarden CLI is not a suspicious package. It is a secrets manager. Compromising it means the infostealer collects credentials before your application ever uses them. Every org that stores secrets in a vault and retrieves them via CLI tooling in CI/CD should ask: what is the integrity check on the retrieval mechanism, and when did we last verify it?
Can your architecture contain a compromise that your detection cannot see? WAV steganography, runtime payload downloads, GitHub as C2: the Telnyx and Shai-Hulud techniques are specifically designed to produce nothing for static analysis to find. Detection that depends on inspecting what is in a package will not see what is downloaded and executed after install. The architectural question is whether a workload that successfully executes an invisible payload can complete the exfiltration. If Communication Governance is in place, the tradecraft does not matter.
Does your incident response playbook account for ransomware that cannot decrypt what it destroys? The VECT 2.0 defect closes the “negotiate and pay” recovery option for any file over 128KB. If your playbook’s recovery path assumes functional encryption by the ransomware operator, test that assumption against what SC World documented. Most enterprise data assets do not survive the 128KB threshold. Update the playbook before you need it.
The Bottom Line
TeamPCP has run multiple operations using the same playbook: find a trusted tool in the developer Trust Chain, harvest the credentials it touches, and hand them to ransomware infrastructure that is evolving faster than defenses are. The model is repeatable. The model is profitable. The model is not stopping.
The organizations staying ahead of this have one thing in common: their workloads cannot send credentials to attacker infrastructure. Not because they caught the payload, but because the outbound path was never open. Every compromise in this campaign depended on completing a network-layer exfiltration event. Communication Governance is the kill switch. The Containment Era is not about better alerts. It is about a network architecture where the exfiltration event cannot complete. The payload evolves. The network path requirement does not.
That requirement is not unique to supply chain. Every attack that converts stolen credentials into impact, regardless of how those credentials were obtained, depends on completing the same outbound network event. The entry vector is a tactical choice. The exfiltration step is constant.
For ongoing TeamPCP and Vect threat intelligence, the Aviatrix Threat Research Center and Cloud Threat Command Center publishes updates as the campaign continues. To map where your workloads have egress exposure they should not have, the free Workload Attack Path Assessment is built for this scenario.
Frequently Asked Questions
Is my organization affected if we do not use SAP or AI tooling? The Bitwarden CLI and Checkmarx KICS compromises extend exposure well beyond AI tooling. If your development teams use npm packages in CI/CD, run GitHub Actions with Dependabot enabled, or use Bitwarden CLI for secrets retrieval in pipelines, your environment is in scope.
Does rotating credentials from the LiteLLM or Trivy exposure cover the SAP and Bitwarden compromises? No. Each campaign collected credentials from different hosts and pipelines. Rotation needs to be scoped to the specific environments where each compromised package ran. A blanket rotation tied to LiteLLM does not cover credentials exposed in April.
How do we detect Shai-Hulud on a potentially compromised host? Check ~/.bashrc and ~/.zshrc for unexpected large code blocks, particularly heredoc injections around 3,500 bytes. Search your GitHub organization for a repository named tpcp-docs. Hunt network flow logs for outbound HTTP connections with the header X-Filename: tpcp.tar.gz. On Windows, look for msbuild.exe in the user Startup folder.
What is the single highest-leverage control to implement now? Communication Governance. Every attack in this campaign depended on completing an outbound network event. Governing what workloads can communicate with, and denying everything outside that policy by default, breaks the exfiltration chain regardless of which package delivers the next payload.
