Article-At-A-Glance
- TeamPCP, a financially motivated cloud threat actor active since December 2025, has deployed a Kubernetes wiper payload specifically designed to destroy Iranian systems.
- The attack leverages CanisterWorm, a self-propagating worm that checks for Iranian timezone and locale settings before executing destructive commands including rm -rf / –no-preserve-root.
- The same infrastructure used in TeamPCP’s earlier Trivy supply chain attack was repurposed this past weekend to deliver the new wiper payload — meaning access was already established before anyone noticed.
- Aikido Security researcher Charlie Eriksen broke down exactly how the kamikaze container wipes Kubernetes nodes — and what happens to non-Iranian hosts instead.
- If your CI/CD pipeline uses Trivy, you need to audit it right now — the window between attack and detection was dangerously short.
A cybercrime group just crossed a line that most financially motivated hackers never do — they built a geopolitical weapon inside a worm.
Over the weekend of March 22, 2026, researchers at Aikido Security uncovered a new payload deployed by a group called TeamPCP. The payload does something unusual: it checks whether the infected system belongs to a user in Iran, and if it does, it wipes everything. This is not ransomware. This is not credential theft. This is deliberate, targeted destruction — and it came from a group that, until recently, was mostly known for stealing SSH keys and extorting companies on Telegram. Aikido Security, which has been tracking this group closely, published a detailed breakdown of the attack authored by researcher Charlie Eriksen.
A Financially Motivated Group Just Crossed Into Cyberwarfare
Most cybercriminals follow money. TeamPCP built its reputation doing exactly that — compromising cloud environments, grabbing credentials, and squeezing victims for payment. What happened this weekend was different. The group deployed destructive malware that serves no financial purpose against its targets. Iranian Kubernetes clusters don’t pay ransoms after they’ve been wiped. This was damage for the sake of damage.
TeamPCP Deployed a Wiper, Not Just Ransomware
The new payload is a shell script that carries two very different outcomes depending on where it lands. For Iranian systems, it wipes. For non-Iranian systems, it installs the CanisterWorm backdoor for ongoing access and data theft. The dual-purpose design shows this wasn’t accidental. Someone deliberately coded geopolitical targeting into what was previously a financially motivated toolset.
Eriksen’s analysis made the distinction clear: “Iranian nodes get wiped and force-rebooted via a container named ‘kamikaze.’ Non-Iranian nodes get the CanisterWorm backdoor.” That single line tells you everything about how calculated this pivot was.
- The wiper payload is delivered via the same ICP canister infrastructure used in the earlier CanisterWorm campaign
- Detection of Iranian systems happens through timezone and locale checks baked into the shell script
- The destructive branch executes before any backdoor is installed, meaning there is no recovery window
- The kamikaze container targets every Kubernetes node in the cluster, not just the entry point
CanisterWorm Targets Iran’s Timezone and Farsi Language Settings
The identification logic is blunt but effective. The script checks the system’s configured timezone against Iranian values and looks for Farsi locale settings. If either condition matches, the wiper branch executes. It doesn’t need network geolocation or IP lookups — it reads system configuration, which is harder to spoof in a live enterprise environment. This approach also means cloud workloads running in Iranian data centers or operated by Iranian companies are squarely in the crosshairs, even if their infrastructure is hosted elsewhere.
The Malicious Payload Was Only Active for a Short Window Over the Weekend
The attack window was tight. TeamPCP pushed the new payload over the weekend, and Aikido’s team caught it quickly — but the gap between deployment and detection is exactly the kind of exposure that causes real damage in production Kubernetes environments. The speed of the attack reflects a group that has spent months refining its delivery infrastructure, not building it from scratch.
Who Is TeamPCP?
TeamPCP is a cloud-native threat actor that first appeared in documented form in December 2025. They are not sophisticated in the way nation-state groups are sophisticated — they don’t write custom exploits or chain zero-days. Instead, they are extremely efficient at finding and exploiting misconfigured cloud infrastructure at scale. Their tooling is built specifically for cloud environments, and their lateral movement playbook is consistent and well-rehearsed.
The group operates openly enough to brag about their attacks in a Telegram group, where they claim to have stolen data from major corporations including a large multinational pharmaceutical company. That level of public visibility is unusual and suggests a group that feels relatively untouchable, or one that is deliberately building a reputation.
Origins: Active Since December 2025
TeamPCP’s documented activity starts in December 2025, when they began running a self-propagating worm against exposed cloud infrastructure. Their initial focus was purely financial — get in, steal credentials, extort the victim, move on. The Kubernetes wiper targeting Iran represents a meaningful tactical shift that emerged in March 2026, roughly three months into their known operational timeline.
Their Primary Attack Surface: Cloud Infrastructure Over End-User Devices
Unlike most malware campaigns that start with phishing emails or endpoint compromises, TeamPCP goes straight for the infrastructure layer. They scan for exposed Docker APIs, misconfigured Kubernetes clusters, Redis servers, and vulnerable CI/CD tooling. End-user devices are not their entry point — cloud control planes are. This makes traditional endpoint detection largely irrelevant against their initial access techniques.
How They Monetize: Credential Theft and Telegram Extortion
TeamPCP’s financial model is straightforward. Once inside a network, they siphon authentication credentials including SSH keys, cloud tokens, and Kubernetes service account tokens. They then use Telegram to contact victims directly, threatening to expose stolen data unless payment is made. The pharmaceutical company breach they publicly claimed is one example of this pattern playing out at enterprise scale.
How CanisterWorm Spreads Through Cloud Environments
CanisterWorm is a self-propagating worm, which means once it’s inside one part of your infrastructure, it actively tries to spread to everything else it can reach. It doesn’t wait for a second command from its operators. It scans, exploits, and replicates autonomously. The propagation logic covers several distinct attack surfaces, and the breadth of that coverage is what makes it particularly dangerous in hybrid cloud environments.
Understanding how it moves is the first step to stopping it. The worm chains together multiple initial access techniques, meaning closing one vector doesn’t guarantee safety if others remain open.
1. Exposed Docker APIs on Port 2375
Port 2375 is the default unauthenticated Docker daemon port, and it remains one of the most consistently abused entry points in cloud attacks. CanisterWorm scans for hosts with this port open and, when found, uses the Docker API directly to deploy malicious containers without needing any credentials. No exploit required — just a misconfiguration that should have been locked down years ago. The worm deploys its payload container through the same API that legitimate tools use to manage containers, making it blend into normal traffic patterns.
2. Kubernetes Cluster Misconfigurations
Kubernetes clusters with unauthenticated API servers or overly permissive role bindings are the second major entry point. CanisterWorm specifically looks for clusters where the API server is reachable without authentication — a configuration mistake that is far more common in development and staging environments than it should be. Once it has API access, it can create pods, deploy DaemonSets across every node, and establish persistence that survives individual pod restarts. The DaemonSet deployment technique is particularly consistent with TeamPCP’s known playbook, and it ensures the worm runs on every node in the cluster simultaneously.
3. Redis Servers and the React2Shell Vulnerability
Exposed Redis instances running without authentication give CanisterWorm another reliable foothold. The worm uses Redis’s config rewrite capability to overwrite SSH authorized keys, then connects directly to the host as root. Alongside Redis abuse, TeamPCP exploits the React2Shell vulnerability — a flaw in React-based web application shells that allows remote command execution. Together, these two vectors cover a wide range of common cloud-native application stacks, particularly those running on containerized microservice architectures.
4. SSH Lateral Movement via Stolen Keys
Once CanisterWorm has a foothold, it doesn’t stay contained. The worm reads SSH private keys from compromised hosts and uses them to attempt connections to every IP address in adjacent subnets. This subnet spraying technique is methodical — it works through known network ranges looking for any host that accepts the stolen key. In cloud environments where developers share SSH keys across multiple systems, a single compromised developer workstation can give the worm access to dozens of servers in seconds.
The lateral movement phase also harvests cloud credentials stored in environment variables, instance metadata endpoints, and Kubernetes secret stores. By the time the worm finishes its first lateral pass, it typically has enough credentials to authenticate to cloud provider APIs directly — at which point the blast radius expands well beyond the original entry point.
What CanisterWorm Does Once Inside an Iranian System
The behavior split between Iranian and non-Iranian systems is the most operationally significant aspect of this payload. The same binary, delivered through the same infrastructure, produces two completely different outcomes depending on a single conditional check. For security teams, this means the threat profile of CanisterWorm depends entirely on where your workloads are running and how your systems are localized.
How the Malware Identifies Iranian Systems
The identification logic uses two system-level checks. First, it reads the system timezone and compares it against Asia/Tehran — the standard timezone identifier for Iran. Second, it checks for Farsi locale settings, specifically looking for fa_IR locale configurations. If either condition returns true, the script routes execution into the wiper branch. This approach is reliable in enterprise environments because timezone and locale settings are typically configured at the OS level during provisioning and rarely changed afterward. A cloud workload running inside Iran, or configured by an Iranian operator, will almost certainly have at least one of these conditions set.
The “Kamikaze” Container: Wiping Every Kubernetes Node
When the wiper branch executes on a Kubernetes environment, it deploys a container named kamikaze as a DaemonSet. The DaemonSet deployment method is critical here — it guarantees the kamikaze container runs on every single node in the cluster, not just the one where the worm initially landed. There is no partial wipe. Every node gets hit simultaneously.
The kamikaze container executes destructive commands against the node’s filesystem and then force-reboots the system. Because it runs at the node level rather than inside a normal pod’s restricted namespace, it has the access required to cause damage that persists after the reboot. The cluster does not recover on its own. Manual intervention from a backup — if one exists — is the only path forward.
Non-Kubernetes Iranian Hosts Get rm -rf / –no-preserve-root
Iranian hosts that are not running Kubernetes get a simpler but equally destructive treatment. The script executes rm -rf / –no-preserve-root, which recursively deletes every file on the system starting from the root directory. The –no-preserve-root flag is required to override the default safety protection that normally prevents this command from running against the root filesystem. Its presence in the script confirms the destructive intent is deliberate and specific — this is not an accidental misconfiguration.
On a Linux system, this command is unrecoverable without an external backup. The operating system itself is deleted mid-execution, which typically causes the process to fail partway through — but by that point, enough critical system files are gone that the host cannot function. The only recovery path is a full OS reinstall from external media or a pre-existing snapshot.
What Happens to Non-Iranian Systems
Systems that fail the Iranian locale and timezone checks get the CanisterWorm backdoor instead of the wiper. The backdoor establishes persistent access, connects back to TeamPCP’s command and control infrastructure hosted on the Internet Computer Protocol (ICP) blockchain, and begins exfiltrating credentials. The ICP-based C2 is notable because blockchain-hosted infrastructure is significantly harder to take down than traditional domain-based command and control — there is no registrar to contact, no hosting provider to notify, and no DNS record to sinkhole.
Non-Iranian victims essentially become long-term intelligence and financial targets. Their credentials get harvested, their cloud environments get mapped, and they eventually receive a Telegram message from TeamPCP demanding payment. The wiper and the backdoor are two ends of the same payload — destruction for Iran, exploitation for everyone else.
The Trivy Supply Chain Connection
The weekend wiper attack didn’t come out of nowhere. It was built on access that TeamPCP had already established through a separate supply chain attack targeting Trivy, a widely used open-source vulnerability scanner maintained by Aqua Security. Understanding the Trivy compromise is essential to understanding how TeamPCP was able to move so quickly from deployment to widespread infection.
TeamPCP’s Prior Attack on Aqua Security’s Trivy Tool
In the attack documented before the weekend wiper event, TeamPCP managed to publish malicious versions of packages associated with the Trivy ecosystem on NPM. These malicious packages were designed to execute CanisterWorm on any system that installed them. Because Trivy is deeply integrated into CI/CD pipelines across the industry — used to scan container images for vulnerabilities during the build process — a compromised Trivy-adjacent package has an enormous potential reach.
- Malicious NPM packages siphoned SSH keys from compromised build environments
- Cloud credentials stored in CI/CD environment variables were exfiltrated
- Kubernetes service account tokens were harvested from pipeline runners
- Cryptocurrency wallet files were targeted alongside enterprise credentials
Wiz researchers who analyzed the Trivy supply chain attack noted that the malicious packages specifically targeted the kinds of credentials that live inside build pipelines — the exact credentials needed to move laterally into cloud infrastructure. This was not random package poisoning. TeamPCP was building an inventory of cloud access tokens that they could use in follow-on attacks.
The scale of potential exposure from the Trivy compromise is significant. Trivy is one of the most widely deployed container security tools in the industry, integrated into GitHub Actions workflows, GitLab CI pipelines, Jenkins jobs, and countless internal build systems. Any organization that ran a Trivy scan during the window when malicious packages were live needs to treat their CI/CD credentials as compromised.
How Access From the First Attack Enabled This Weekend’s Wiper
The connection between the Trivy supply chain attack and the Iran-targeted wiper is the ICP canister infrastructure. Both attacks used the same Internet Computer Protocol canister as their command and control backbone. This means TeamPCP didn’t need to rebuild their delivery infrastructure for the wiper campaign — they simply pushed a new payload through existing channels to hosts that were already beaconing back to their C2.
Systems compromised during the Trivy attack were essentially pre-positioned for whatever TeamPCP wanted to do next. When the wiper payload was ready, it was distributed to the existing botnet of compromised build systems and cloud environments. The time from payload development to widespread deployment was compressed dramatically because the hard work of initial access had already been done weeks earlier.
Attack Timeline: From Trivy Compromise to Kubernetes Wiper
December 2025 — TeamPCP begins targeting exposed Docker APIs, Kubernetes clusters, and Redis servers with CanisterWorm. Credential theft and Telegram extortion campaigns begin.
March 20, 2026 — TeamPCP deploys malicious NPM packages tied to the Trivy ecosystem. SSH keys, cloud credentials, and Kubernetes tokens are harvested from CI/CD pipelines at scale.
March 22, 2026 — A new shell script payload is pushed through the same ICP canister C2 infrastructure. Iranian systems receive the kamikaze wiper. Non-Iranian systems receive the CanisterWorm backdoor.
March 22, 2026 — Aikido Security researcher Charlie Eriksen publishes analysis of the wiper payload, identifying the dual-branch logic and the kamikaze container deployment mechanism.
The timeline makes one thing clear: the Trivy attack was not an endpoint in itself. It was preparation. TeamPCP used the credential harvest from the supply chain attack to expand their access footprint, then leveraged that footprint to deploy a destructive payload at speed. Security teams that dismissed the Trivy compromise as a credential theft incident missed the fact that it was also laying groundwork for something significantly more damaging.
What Security Teams Need to Do Right Now
The combination of the Trivy supply chain attack and the Iran-targeted wiper isn’t just a threat to Iranian organizations — it’s a signal to every team running Kubernetes in production. If TeamPCP already has credentials from your CI/CD pipeline, they have the ability to deploy whatever payload they want to your infrastructure. The wiper was aimed at Iran this time. Next time, the targeting logic could be different.
Audit Every Trivy Integration in Your CI/CD Pipeline
Start here. If your pipeline runs Trivy scans — whether through GitHub Actions, GitLab CI, Jenkins, or any internal build system — you need to check exactly which packages were installed and when. Pull your pipeline logs from the window between March 20 and March 22, 2026, and look for any Trivy-adjacent NPM package installations that weren’t explicitly pinned to a verified hash.
Rotate every credential that your CI/CD environment had access to during that window. That means SSH keys, cloud provider API tokens, Kubernetes service account tokens, and any secrets stored as environment variables in your pipeline configuration. Don’t wait to confirm whether your specific pipeline was affected. Treat the credentials as compromised and rotate them proactively. The cost of rotating credentials is far lower than the cost of a wiper payload reaching your production cluster.
Lock Down Exposed Docker APIs and Kubernetes Control Planes
Port 2375 should not be reachable from the internet under any circumstances. Run a quick scan of your external attack surface specifically looking for exposed Docker daemon ports. For Kubernetes, audit your API server’s network policy and confirm that unauthenticated access is disabled. Check every cluster role binding for overly permissive configurations — particularly any binding that grants cluster-admin to service accounts used by CI/CD tools. Enable audit logging on your Kubernetes API server if it isn’t already running, and set up alerts for DaemonSet creation events from unexpected sources.
Indicators of Compromise to Hunt For
When hunting for signs of TeamPCP activity in your environment, these are the specific indicators Eriksen’s analysis and related research have identified:
- Any container named kamikaze in your Kubernetes cluster — this is the wiper’s DaemonSet container name
- DaemonSet objects created outside of your normal deployment pipelines, especially with hostPID: true or privileged: true settings
- Outbound connections to ICP (Internet Computer Protocol) blockchain endpoints from workloads that have no business communicating with blockchain infrastructure
- Unexpected SSH key additions in ~/.ssh/authorized_keys across multiple hosts
- Redis configuration rewrites that modified dir or dbfilename settings to SSH key paths
- NPM package installations in your pipeline logs that reference packages with unusually high version numbers or recent publish dates not matching your dependency history
- Processes executing rm -rf with the –no-preserve-root flag in any system logs
If you find the kamikaze container or the DaemonSet indicators, your cluster has been actively targeted. Take the affected nodes offline immediately, preserve forensic snapshots if your infrastructure allows it, and begin restoring from the most recent clean backup. Do not attempt to remediate in place — the extent of filesystem damage from the wiper makes in-place recovery unreliable.
TeamPCP Has Turned Opportunistic Crime Into a Geopolitical Weapon
What makes the Iran-targeted wiper significant isn’t just the technical sophistication — it’s the shift in intent. TeamPCP built their operation on financial motivation. They were cloud criminals with a consistent playbook: get in, steal credentials, get paid. The kamikaze container changes that story. Someone inside this group, or someone directing this group, made a deliberate decision to build a geopolitically targeted destructive payload and ship it through existing criminal infrastructure. That’s a different category of threat entirely.
The precedent this sets matters beyond TeamPCP specifically. It demonstrates that financially motivated cloud threat actors can pivot to destructive, geopolitically targeted attacks without rebuilding their entire operation from scratch. The supply chain access, the botnet of compromised build systems, the ICP-based C2 — all of it was already in place from the financial crime operation. The wiper was just a new payload pushed through existing infrastructure. Any cloud-native threat actor with a similar level of access could make the same pivot. Security teams need to treat persistent cloud access as a potential weapon, not just a credential theft risk.
Frequently Asked Questions
The CanisterWorm and Iran-targeted wiper story raises a lot of specific technical questions. Here are direct answers to the most common ones based on what Aikido Security’s analysis and related research have confirmed.
What is CanisterWorm and how does it work?
CanisterWorm is a self-propagating worm designed to spread through cloud infrastructure. It targets exposed Docker APIs on port 2375, misconfigured Kubernetes clusters, unauthenticated Redis servers, and systems vulnerable to the React2Shell flaw. Once it gains a foothold, it harvests SSH keys, cloud credentials, and Kubernetes tokens, then uses those credentials to spread laterally through adjacent subnets.
The worm’s command and control infrastructure runs on the Internet Computer Protocol blockchain, which makes it resistant to traditional takedown methods. ICP canisters can’t be pulled by a domain registrar or a hosting provider — they persist on a decentralized network. The most recent payload variant adds a geopolitical targeting layer: Iranian systems get wiped, non-Iranian systems get the backdoor implant for ongoing access and data theft.
Why is TeamPCP targeting Iran specifically?
The honest answer is that the exact motivation hasn’t been confirmed publicly. TeamPCP has not explained the targeting, and no evidence has emerged linking them to any state sponsor that would have a clear interest in attacking Iranian infrastructure. What is clear is that the targeting is intentional and technically specific — the timezone and locale checks in the script are not accidental. Whether this reflects a political stance by the group’s operators, a contract from an unknown third party, or an attempt to establish credibility in certain circles remains an open question.
How do I know if my Kubernetes cluster was compromised by TeamPCP?
The most definitive indicator is the presence of a DaemonSet or container named kamikaze in your cluster. Run kubectl get daemonsets –all-namespaces and kubectl get pods –all-namespaces and look for anything you don’t recognize. Beyond the name-based indicator, look for DaemonSets created with privileged container settings or hostPID: true that weren’t deployed through your normal GitOps or CI/CD pipeline.
Also check your Kubernetes audit logs for API server requests that created pods or DaemonSets outside of normal working hours or from unexpected source IPs. If your cluster doesn’t have audit logging enabled, that’s a gap you need to close immediately — it’s impossible to investigate a compromise without that data. For non-Kubernetes hosts, look for new entries in ~/.ssh/authorized_keys and check Redis configuration files for unauthorized changes to the dir and dbfilename settings.
What is the React2Shell vulnerability and how does TeamPCP exploit it?
React2Shell is a vulnerability affecting React-based web application shells that allows an attacker to execute commands on the underlying host remotely. It affects applications that expose a web-based terminal or shell interface built on React without proper input sanitization or access controls.
TeamPCP uses React2Shell as one of several initial access vectors in CanisterWorm’s propagation logic. The worm scans for internet-exposed instances of vulnerable React shell applications and sends crafted input that triggers remote command execution. From that initial command execution, it deploys the full worm payload. Because React-based shell interfaces are common in cloud management tools and developer dashboards, this vulnerability gives CanisterWorm access to a wide range of cloud-native targets that might otherwise be hardened against Docker API and Kubernetes-based attacks.
Is TeamPCP a state-sponsored threat actor?
Based on everything that has been publicly confirmed, TeamPCP does not appear to be a state-sponsored group. Their operational behavior — public Telegram bragging, financial extortion of victims, credential theft for profit — is consistent with financially motivated cybercrime, not the disciplined operational security typically associated with state-sponsored threat actors.
That said, the Iran-targeted wiper complicates a clean classification. State-sponsored groups routinely use criminal infrastructure as cover, and the deliberate geopolitical targeting of Iranian systems is unusual for a group whose entire prior history was financially motivated. It’s possible that TeamPCP has ties to a state actor that aren’t publicly visible, that they accepted a contract for the wiper component, or that the targeting reflects the personal political motivations of the group’s operators rather than any formal state direction.
Charlie Eriksen’s analysis at Aikido Security did not attribute the Iran targeting to state sponsorship, and no other researcher has made that attribution publicly as of the time of writing. The most accurate characterization remains: financially motivated cloud threat actor with unexplained geopolitical targeting behavior in their most recent payload.
Aikido Security continues to monitor TeamPCP’s infrastructure and publish analysis of new payloads as they emerge — if you run cloud infrastructure and want to stay ahead of threats like CanisterWorm, following their research output is one of the most direct ways to stay informed.
