TeamPCP Deploys CanisterWorm Kubernetes Wiper in Iran Attacks

Key Takeaways

• The threat group TeamPCP has introduced a new, highly destructive Kubernetes wiper, CanisterWorm, specifically targeting entities within Iran.
• This represents a significant escalation in TeamPCP’s tactics, shifting from credential theft and backdoor installations to complete system destruction.
• CanisterWorm employs a sophisticated decision-making process, wiping Iranian Kubernetes clusters and standalone systems, while installing a persistent backdoor on non-Iranian targets.
• The malware utilizes rotating Cloudflare tunnel domains for delivery and incorporates self-spreading capabilities via SSH and exposed Docker APIs.

TeamPCP Unleashes Destructive Kubernetes Wiper “CanisterWorm” in Iran

The cyber threat group TeamPCP has dramatically escalated its operational scope, deploying a novel and highly destructive payload known as CanisterWorm. This advanced malware functions as a Kubernetes wiper, specifically designed to target Iranian organizations. The shift marks a significant evolution in TeamPCP’s strategy, moving beyond its previous focus on data theft and backdoor persistence to outright system obliteration, as detailed in a recent analytical report.

Since late 2025, TeamPCP has been recognized as a formidable cloud-native attacker. The introduction of this Kubernetes wiper, which precisely targets systems configured for Iran, signifies a grave escalation in the group’s intent and geographical reach. This geopolitical targeting underscores a more aggressive and damaging phase in their campaigns, as outlined in a comprehensive analysis document.

Previously, TeamPCP was known for exploiting vulnerabilities in misconfigured Docker APIs, Kubernetes clusters, and CI/CD pipelines. Their earlier attacks primarily aimed at establishing persistent backdoors and exfiltrating access credentials stealthily. CanisterWorm, however, fundamentally alters this operational paradigm.

Targeted Destruction vs. Silent Persistence

Upon successful deployment, CanisterWorm initiates a critical check to determine if the compromised system operates within an Iranian environment. If this condition is met, the malware proceeds to execute a complete and irreversible wipe of the system. Conversely, for systems not identified as Iranian, CanisterWorm defaults to installing a variant of the familiar CanisterWorm backdoor observed in prior TeamPCP operations, maintaining silent persistence.

Researchers at Aikido identified this new payload as a direct evolution of the ongoing CanisterWorm campaign. This conclusion is supported by shared infrastructure, including the same Internet Computer Protocol (ICP) canister command-and-control (C2) infrastructure at tdtqy-oyaaa-aaaae-af2dq-cai[.]raw[.]icp0[.]io. Further evidence of continuity includes identical backdoor code, the consistent use of /tmp/pglog as a drop path, and the same Kubernetes-native lateral movement techniques via DaemonSets. These elements confirm that TeamPCP is actively enhancing its toolkit, now with a clear and destructive agenda.

Delivery and Execution

CanisterWorm is delivered through a rotating series of Cloudflare tunnel domains, a tactic designed to complicate network-level blocking efforts. Early iterations of the payload consisted of a single file, kamikaze.sh. Subsequent versions introduced a more modular approach, splitting the logic into two distinct files: a shell stager that downloads and executes kube.py before self-deleting. The Python script, kube.py, contains the core decision-making logic, dictating the malware’s subsequent actions based on the target environment and geographical location.

The precise and calculated nature of this threat is particularly alarming. Rather than indiscriminate attacks, CanisterWorm employs deliberate decision trees, ensuring maximum destruction for Iranian targets while maintaining covert persistence in other environments. This dual functionality highlights the sophisticated targeting capabilities of TeamPCP.

Inside the Wiper: How “kamikaze” Works

The malicious core of this attack revolves around a sophisticated four-path decision tree. This tree routes the malware’s behavior based on two primary variables: whether the host is situated within a Kubernetes cluster and if it is configured for Iran. Iranian system detection relies on examining the system’s timezone and locale settings. A match for Asia/Tehran, Iran, or fa_IR flags the system for complete destruction.

Kubernetes-Specific Destruction

For Iranian systems operating within a Kubernetes environment, the payload deploys a DaemonSet named host-provisioner-iran. This DaemonSet contains a container, aptly named kamikaze, which mounts the host’s root filesystem. It then proceeds to delete all top-level files and directories before forcing a system reboot. Critically, because the DaemonSet is configured with tolerations that ensure its scheduling across all nodes, including the control plane, a single deployment command is sufficient to render the entire Kubernetes cluster inoperable.

Standalone System Wipe

On Iranian systems not utilizing Kubernetes, the malware adopts a more direct approach. The script executes rm -rf / --no-preserve-root, initiating a complete wipe of the entire filesystem. If the malware lacks root privileges, it first attempts to gain them via passwordless sudo. Should this fail, it proceeds with the command, ensuring the destruction of all files owned by the current user at a minimum.

Advanced Self-Spreading Capabilities

A more advanced variant of the payload, identified shortly after the initial discovery, removed the Kubernetes dependency and incorporated self-spreading functionalities. This version analyzes SSH authentication logs to identify previously connected machines, steals private SSH keys, and scans the local subnet for exposed Docker APIs on port 2375. Both propagation methods deploy the same conditional payload: destruction for Iranian targets and silent backdoor installation for all other environments.

What You Should Do

• Audit Kubernetes DaemonSets: Immediately review all DaemonSets within the kube-system namespace for any unexpected entries, specifically host-provisioner-iran and host-provisioner-std.
• Check for Persistent Services and Files: Look for systemd services named internal-monitor or pgmonitor, the file /var/lib/pgmon/pgmon.py, and pglog processes running in the /tmp/ directory.
• Block C2 Communications: Implement network rules to block all outbound connections to icp0[.]io domains.
• Secure Docker APIs: Ensure Docker API access on port 2375 is closed to external access and is never exposed without stringent authentication.
• Rotate SSH Keys: Rotate SSH keys on any host suspected of compromise and implement strong key management practices.
• Review SSH Logs: Carefully examine SSH authentication logs for any anomalous lateral movement or login attempts.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.