PCPJack just automated credential harvesting. To understand what that means, three data points from the last five months are worth naming. VoidLink in January 2026 was the first documented purpose-built framework targeting cloud infrastructure: operator-directed, post-exploitation focused, a signal that adversaries were investing in cloud-native tooling. Then TeamPCP spent the spring running a sustained Trust Chain campaign, compromising developer tools from Trivy to LiteLLM to SAP's enterprise npm packages to Bitwarden CLI, proving at scale that cloud credentials are a high-value, highly monetizable target. PCPJack, documented by SentinelOne on May 7, removed the operator entirely. No targeting decision. No deployment command. An autonomous worm that finds exposed cloud infrastructure on its own, compromises it, sweeps every credential in reach, and propagates to the next host without direction. VoidLink showed the capability was being built. TeamPCP proved cloud credentials were worth the investment. PCPJack removed the operator.
The model works like this. No human targets your organization. No phishing email. No Trust Chain compromise. The worm scans internet-indexed hostnames using publicly available data, finds exposed cloud management interfaces and unpatched web applications, and sweeps every credential in reach: financial services, AI API keys, secrets managers, infrastructure tokens, enterprise communications. Exfiltration completes before most organizations know anything is running. The operations hitting cloud environments right now are not experiments. They are proven, repeatable, and the operators know it.
The credential breadth PCPJack is targeting should end any assumption that this is a developer tooling problem. Stripe. OpenAI. Anthropic. 1Password. HashiCorp Vault. Grafana Cloud. Binance and a dozen other financial services. This is not a CI/CD credential harvest. This is a sweep of everything running in your cloud environment. A fully autonomous credential-targeting cloud worm operating at this scale has not been documented before. VoidLink required an operator. PCPJack does not. That is the line that just moved. And 2026 is only five months old.
TL;DR
PCPJack is a cloud worm that actively evicts TeamPCP from compromised environments and runs its own credential harvest. If TeamPCP had access to your cloud infrastructure this spring, PCPJack may have been there before you detected anything.
The worm propagates autonomously using Common Crawl internet scan data. No human operator selects targets. Exposed Docker, Kubernetes, Redis, and vulnerable web applications are found and compromised without direction.
PCPJack targets 30+ credential types across financial services, AI providers, password managers, cloud infrastructure, and enterprise productivity tools. Stripe, OpenAI, 1Password, and HashiCorp Vault are on the list alongside AWS and Kubernetes secrets.
There is no ransomware and no cryptominer. The monetization model is credential resale, financial fraud, spam infrastructure, and extortion via access to internal communications. There is no ransom demand to negotiate. The credentials are already gone.
A credential-targeting cloud worm at this scale is a new capability class. VoidLink in January 2026 was the first documented cloud-native attack framework. PCPJack in May is the second. The pace of cloud-native threat development this year suggests both will have successors.
Communication Governance stops the exfiltration regardless of which actor is operating. PCPJack requires outbound access to Telegram C2 and attacker-controlled cloud infrastructure to complete the harvest. Deny the outbound path and the tradecraft does not matter.
PCPJack Does Not Need to Break In
PCPJack’s entry points are exposed cloud management services and unpatched web applications. Docker API on port 2375. Kubernetes API without authentication. Redis without a password. RayML dashboards. WordPress sites and Next.js applications running unpatched CVEs. If any of those conditions exist in your cloud environment, PCPJack does not need a phishing email or a zero-day to get in.
SentinelOne documents the worm using Common Crawl parquet files to generate targets. Common Crawl is a legitimate, widely-used internet indexing service. PCPJack uses it as a targeting database, assigning each infected node a window of hostnames to scan. There is no centralized list that can be taken down. Every compromised node becomes a scanner that finds the next node, which finds the next. The worm scales with the number of hosts it owns.
The CVE list in the current toolset includes CVE-2026-1357 in WPVivid Backup (CVSS 9.8), CVE-2025-9501 in W3 Total Cache (CVSS 9.0), CVE-2025-29927 in Next.js (CVSS 8.8), and CVE-2025-55182 in React and Next.js (CVSS 9.0). These are not exotic vulnerabilities requiring a specialist to exploit. They are production applications accessible from the internet that have not been patched. The attack vector is the gap between how long it takes an organization to patch and how long it takes an autonomous worm scanning internet-indexed hostnames to find the unpatched system. The worm avoids scanning the same host twice, keeping its network footprint below the threshold that would trigger repeated-connection alerts.
The Eviction Is the Detail That Changes the Threat Model
Most cloud compromises are discovered by the organization. PCPJack introduces a scenario where a compromise may be discovered by another threat actor first.
SentinelOne documents that PCPJack’s bootstrap script begins by terminating TeamPCP processes, deleting TeamPCP artifacts, and clearing the environment before deploying its own tooling. The researchers assess this could be a former TeamPCP operator with intimate knowledge of the group’s infrastructure and detection footprint. The cleanup code targets specific TeamPCP process names and file paths. That level of specificity is not something you derive from public research. It comes from operational knowledge: someone who ran those tools, or worked alongside someone who did. Whether this is a competitor, a defector, or an insider who went independent, a new player entered the cloud threat ecosystem who knows exactly how TeamPCP operates and built a successor that cleans the slate before setting up shop.
We have covered TeamPCP’s campaign extensively: from the original Trivy and LiteLLM compromise in March through the SAP npm packages, Bitwarden CLI, and VECT 2.0 ransomware bug that defined the spring escalation. PCPJack is not a continuation of that campaign. It is likely a new actor that moved into infrastructure TeamPCP had already compromised and rebuilt the operation with better tools.
There is a second inference here that is more uncomfortable than the eviction itself. For PCPJack to evict TeamPCP, TeamPCP has to still be present when PCPJack arrives. TeamPCP establishes persistence via systemd services and crontabs. PCPJack finds those artifacts present and targets them specifically. These are not fresh infections being caught in the first minutes. There is meaningful dwell time, and PCPJack is exploiting it.
Think through what that means operationally. A second threat actor is finding the compromised host, removing the first actor’s tooling, deploying its own credential framework, completing a full harvest, and exfiltrating. All before the organization that owns the environment detects the original compromise. That is not a close race. That is a cloud detection gap measured in days, possibly weeks. PCPJack’s eviction model only works if the victim is slow to find TeamPCP. The fact that PCPJack built the model suggests the bet is paying off consistently.
PCPJack is also likely using TeamPCP’s presence as a targeting signal, not just a cleanup task. Finding TeamPCP artifacts on a host tells you two things: the host has reachable management interfaces or unpatched applications, and it almost certainly has valuable credentials. PCPJack does not need to do its own reconnaissance on host quality. TeamPCP already did it. The eviction is not spite. It is efficiency.
This changes incident response planning in a specific and uncomfortable way. If you detected and responded to a TeamPCP-related exposure in Q1 and rotated credentials scoped to that event, your rotation covers what TeamPCP collected during the period you can account for. It does not tell you whether PCPJack had already been present, evicted TeamPCP, completed its own harvest, and exfiltrated before your detection. The overlap window is the problem, and it is invisible to standard containment procedures.
The question to add to every post-exposure review is not just “what did the actor we detected collect?” It is “what was the full timeline of access to this environment, and is there any window between initial exposure and our detection where we cannot account for what was running?”
What PCPJack Is After
The credential target list tells you this is a cloud estate problem, not a developer pipeline problem.
The parser module targets over 30 credential categories. Financial services: Stripe, Binance, Coinbase, Kraken, Gemini, Infura, and six others. AI API providers: OpenAI and Anthropic keys. Secrets and password managers: 1Password and HashiCorp Vault tokens. Cloud infrastructure: AWS IMDS credentials, Kubernetes service account tokens, Docker secrets, SSH private keys. Enterprise productivity and communications: Slack, Office 365, Twilio, SendGrid, Mailchimp.
There are no cryptominers in either toolset SentinelOne analyzed. SentinelOne assesses the monetization model as credential resale, financial fraud via stolen financial service access, spam infrastructure built on harvested email credentials, and extortion. The Slack targeting in particular is notable. Slack credentials give an attacker access to internal communications. You do not need to encrypt anything to have extortion leverage over what is in a company’s Slack history. The data is the leverage.
The absence of ransomware changes the recovery calculus in a way many IR playbooks are not built for. There is no ransom demand to anchor a decision. There is no decryptor to negotiate. The harm is the credential harvest, which was completed and exfiltrated before the compromise was known. The response question is not “what do we pay” but “what credentials were taken, what can those credentials reach, and how much of that access is still valid.”
PCPJack operates at two capability levels. The first toolset performs a credential sweep and exits. The second deploys a persistent command-and-control beacon, giving the operator ongoing interactive access to compromised hosts rather than a single collection window. An organization dealing only with the first toolset has a defined exposure event. One dealing with the second has an open session.
2026 Is Establishing a Pattern. Cloud Service Providers Are the Target Class.
VoidLink, documented in January 2026, was the first cloud-native attack framework designed for propagation and credential theft across cloud infrastructure. At the time, it was a notable escalation: a purpose-built tool for cloud environments rather than an adaptation of existing malware. Four months later, PCPJack is a successor that is more modular, more targeted, and capable enough to evict a well-resourced threat actor from infrastructure it already owned.
The pattern matters more than either individual tool. Two cloud-native attack frameworks in five months, both targeting credentials across cloud service providers. The threat actor ecosystem is developing cloud-native capability faster than most organizations are developing cloud-native defenses. PCPJack will not be the last.
For cloud service providers and the enterprises running workloads on them, 2026 is a category shift. The attacker investment in cloud-native tooling is now sustained and compounding. An industry that has treated cloud security as a configuration problem, a patching backlog, or a compliance exercise is not priced in for a threat actor ecosystem that compounds capability every four months. The second half of 2026 will not look like the first.
Four Questions for Your Next Security Review
Does your cloud estate have management interfaces reachable from the internet? Docker on port 2375, unauthenticated Kubernetes, Redis without authentication: PCPJack finds these using Common Crawl data and does not need to know your organization exists. The question is whether an autonomous worm scanning internet-indexed hostnames will find an exposed service in your environment before your next patch cycle. An inventory of what management ports are reachable from the internet is not optional. If you do not have one, you cannot answer this question.
If your environment had TeamPCP exposure in Q1, what is your confidence in the full access timeline? PCPJack specifically evicts TeamPCP before starting its own harvest. Credential rotation scoped to the TeamPCP event covers that actor’s collection window. It does not cover a PCPJack window that may have predated your detection. The post-exposure review question is whether you can account for every period of access, or whether there is a gap where you do not know what was running.
What is the Blast Radius if cloud credentials in your environment were exfiltrated? PCPJack sweeps AWS credentials, Kubernetes tokens, Docker secrets, SSH keys, and access to financial services and communications platforms. Map what each credential class can reach and whether that access remains valid. The answer to “what did they get” is only useful if you also know “what does that access enable from here.”
Can your workloads make outbound connections to Telegram and arbitrary CloudFront infrastructure? PCPJack uses Telegram as its C2 channel and exfiltrates to a CloudFront typosquat. Both are connections your production workloads have no business making. Communication Governance that governs what workloads can communicate with, and denies everything outside that policy by default, stops the exfiltration event regardless of how the worm entered the environment. If your workloads can freely reach Telegram, the harvest completes. If they cannot, PCPJack’s entire tradecraft is irrelevant.
The Bottom Line
PCPJack proves that exposed cloud infrastructure is not one actor’s problem. It is contested territory. The worm that evicts your current compromise and starts a fresh credential harvest does not care who was there before. It cares that the door was open. The Q1 TeamPCP response confirmed something was in. PCPJack is asking whether anything else was in before you looked.
The organizations not in this situation have cloud environments where management interfaces are not exposed, where outbound workload communication is governed by policy rather than allowed by default, and where the Blast Radius of a credential harvest is constrained by architecture. Communication Governance is the structural answer. The Containment Era does not ask whether the worm found you. It asks whether the worm could complete its mission once it did. Deny the outbound path, and the answer is no, regardless of which actor wrote the toolset or which actor gets there next.
For ongoing PCPJack and TeamPCP threat intelligence, the Aviatrix Threat Research Center publishes updates as these campaigns evolve. To map which of your cloud workloads have egress exposure they should not have, the free Workload Attack Path Assessment is built for exactly this scenario.
Frequently Asked Questions
We responded to a TeamPCP exposure in Q1 and rotated credentials. Are we covered? Potentially not fully. PCPJack specifically evicts TeamPCP before starting its own harvest. If PCPJack was present in your environment before you detected and contained the TeamPCP event, your credential rotation covered what TeamPCP collected. It does not cover what PCPJack may have collected in an earlier window. The overlap timeline is worth investigating as a distinct question from the TeamPCP response.
PCPJack targets crypto wallets and financial accounts. We do not hold cryptocurrency. Does this apply to us? Yes. Cryptocurrency wallets are one target category among more than thirty. PCPJack also harvests AWS credentials, Kubernetes service account tokens, Docker secrets, SSH keys, Slack tokens, GitHub access, 1Password credentials, and HashiCorp Vault tokens. If your cloud environment runs any of these, your environment is in scope regardless of cryptocurrency holdings.
We do not run Docker or Kubernetes. Are we exposed? PCPJack also targets internet-accessible web applications. The current CVE list includes WPVivid Backup (CVSS 9.8), W3 Total Cache (CVSS 9.0), and Next.js (CVSS 8.8). If your environment runs any of these applications and they have not been patched, PCPJack has entry points that do not require container infrastructure.
There is no ransom demand. How do we frame the business impact for the board? The harm is the credential access itself, not a ransom event. Frame it as unauthorized access to every system those credentials can reach, for as long as those credentials remain valid. The board question is not “what did we pay” but “what can an external actor do right now with what they collected, and have we closed that access.” The urgency is credential validity, not a payment deadline.
What does Communication Governance actually stop in a PCPJack scenario? PCPJack requires two outbound network events to cause harm: a connection to Telegram C2 for command and exfiltration, and a connection to attacker-controlled cloud infrastructure for payload delivery and data upload. Communication Governance that restricts what workloads can communicate with to an approved list, and denies everything else by default, prevents both events from completing. The worm can run in your environment and collect nothing useful if the outbound path does not exist.
