TeamPCP Deploys Destructive CanisterWorm Gets Iran-Focused

The threat actor TeamPCP has escalated its operations, deploying a new destructive payload named CanisterWorm. This malware, detailed in a recent report, targets Iran-focused entities and functions as a Kubernetes wiper, moving far beyond typical credential theft or backdoor installations. Analysis confirms its highly destructive capabilities. Researchers note this represents a significant shift in TeamPCP’s tactics, as outlined in the comprehensive

The group, tracked as a cloud-native attacker since late 2025, has deployed a Kubernetes wiper that specifically targets systems configured for Iran — a geopolitical targeting tactic that marks a clear and serious escalation in the campaign’s intent and reach.

TeamPCP first drew attention for exploiting misconfigured Docker APIs, Kubernetes clusters, and CI/CD pipelines. Their earlier campaigns focused on persistence — planting backdoors and quietly stealing access credentials.

This new payload changes the game entirely. Once deployed, it checks whether the infected system belongs to an Iranian environment and, if confirmed, proceeds to wipe it completely.

For non-Iranian systems, it falls back to installing the familiar CanisterWorm backdoor seen in previous operations.

Aikido researchers identified this new payload as a direct continuation of the CanisterWorm campaign, noting it shares the same Internet Computer Protocol (ICP) canister command-and-control infrastructure: tdtqy-oyaaa-aaaae-af2dq-cai[.]raw[.]icp0[.]io.

The same backdoor code, the same /tmp/pglog drop path, and the same Kubernetes-native lateral movement via DaemonSets confirm this is TeamPCP evolving its toolkit — now with destructive intent baked in.

The payload is delivered through rotating Cloudflare tunnel domains, making it harder to block at the network level. Initially, it pointed to a single file called kamikaze.sh.

Later versions split the logic into two separate files — a shell stager that downloads and executes kube.py, then deletes itself.

This Python script holds the core decision logic that determines what the malware does next, entirely based on the target’s environment and location.

What makes this threat especially dangerous is how deliberate and calculated it is.

The malware does not strike randomly — it makes precise decisions based on two checks, hitting Iranian systems with full destruction while staying quietly persistent everywhere else.

Inside the Wiper: How “kamikaze” Works

The core of this attack is a four-path decision tree that routes behavior based on two variables: whether the host is inside a Kubernetes cluster, and whether it is configured for Iran.

The Iran detection reads the system timezone and locale settings. If the machine uses Asia/Tehran, Iran, or fa_IR, it is flagged for destruction.

For Iranian systems running inside Kubernetes, the payload deploys a DaemonSet named host-provisioner-iran with a container inside it called kamikaze.

It mounts the host root filesystem, deletes everything at the top level, and forces a reboot. Since the DaemonSet carries tolerations that schedule it across every node — including the control plane — a single deployment command is enough to brick the entire cluster.

For Iranian systems without Kubernetes, the approach is direct: the script runs rm -rf / --no-preserve-root, wiping the entire filesystem.

If it lacks root privileges, it tries passwordless sudo first, then attempts the command anyway — destroying everything owned by the current user at minimum.

A third and more capable variant of the payload, discovered shortly after, dropped the Kubernetes dependency entirely and added self-spreading features.

It parses 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 spread paths deliver the same payload — destruction for Iranian targets and silent backdoor installation for everyone else.

Security teams should immediately audit all DaemonSets in the kube-system namespace for unexpected entries — specifically host-provisioner-iran and host-provisioner-std.

Check for systemd services named internal-monitor or pgmonitor, files at /var/lib/pgmon/pgmon.py, and pglog processes in /tmp/. Block outbound connections to icp0[.]io domains.

Close Docker API access on port 2375, ensure it is never exposed without authentication, and rotate SSH keys on any potentially compromised host. Review SSH authentication logs carefully for any signs of unusual lateral movement activity.

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.