A sophisticated cyber threat actor, identified as TeamPCP, has escalated its operations from stealthy credential theft to outright destructive attacks with the deployment of a new Kubernetes wiper. This malware specifically targets systems configured for Iran, a significant geopolitical pivot that intensifies the campaign’s malicious intent and expands its potential impact. TeamPCP, previously known for exploiting misconfigured cloud-native infrastructure like Docker APIs and CI/CD pipelines since late 2025, has now pivoted to a destructive approach.
Previously, TeamPCP focused on establishing persistence within victim environments by planting backdoors and exfiltrating access credentials. This latest evolution, however, dramatically alters the threat landscape. The new payload is engineered to detect if an infected system belongs to an Iranian environment. Upon confirmation, it initiates a complete system wipe. For systems not identified as Iranian, the malware reverts to deploying its familiar CanisterWorm backdoor, indicating a dual-purpose strategy in its campaign.
Researchers at Aikido have pinpointed this new payload as a direct continuation of the CanisterWorm campaign. They note the shared Internet Computer Protocol (ICP) canister command-and-control (C2) infrastructure, specifically tracing it to tdtqy-oyaaa-aaaae-af2dq-cai[.]raw[.]icp0[.]io. Evidence of this connection includes identical backdoor code, the consistent use of /tmp/pglog as a drop path, and the employment of Kubernetes-native lateral movement techniques utilizing DaemonSets. These commonalities strongly suggest TeamPCP is evolving its toolkit, now incorporating destructive capabilities into its repertoire.
Inside the Wiper: How TeamPCP’s “kamikaze” Payload Works
The destructive capability of this threat is primarily housed within a Python script, kube.py, which is downloaded and executed by a shell stager named kamikaze.sh. This stager is designed to delete itself after execution, making forensic analysis more challenging. The core logic within kube.py dictates the malware’s behavior based on two critical factors: whether the host is running within a Kubernetes cluster and whether its configuration indicates an Iranian target. The malware determines an Iranian target by examining system timezone and locale settings, specifically looking for indicators like Asia/Tehran, Iran, or fa_IR.
For Iranian systems identified within a Kubernetes cluster, the payload deploys a specific DaemonSet named host-provisioner-iran. This DaemonSet contains a container labeled kamikaze, which is configured to mount the host’s root filesystem. Once mounted, it proceeds to delete all files and directories at the top level of the filesystem, effectively rendering the system inoperable. The DaemonSet’s configuration includes tolerations that ensure it is scheduled on every node within the cluster, including control plane nodes. Consequently, a single deployment can lead to the complete incapacitation of the entire cluster.
In contrast, for Iranian systems not operating within Kubernetes, the malware executes a more direct destructive command: rm -rf / --no-preserve-root. This command is designed to wipe the entire filesystem. If the malware lacks the necessary root privileges to perform a full system wipe, it will attempt to leverage passwordless sudo access before proceeding with the command. If even that fails, it will still attempt to execute the wipe command, which at a minimum, will destroy all files and data owned by the current user.
A more advanced variant of the TeamPCP payload has also been observed, which removes the dependency on Kubernetes entirely. This version incorporates self-spreading capabilities. It achieves this by parsing SSH authentication logs to identify previously connected machines, subsequently stealing private SSH keys. Furthermore, it actively scans the local subnet for exposed Docker APIs, particularly those listening on port 2375. Both of these spreading mechanisms serve to deliver the same dual-purpose payload: complete destruction for Iranian targets and the silent installation of the CanisterWorm backdoor for all other identified systems.
The delivery mechanism for the initial payload involves rotating Cloudflare tunnel domains. This strategy makes it more difficult for security teams to block the malware at the network level through static IP or domain blocking. This evolving tactic highlights the adaptive nature of the threat actor and the need for continuous monitoring and updated security measures.
Security professionals are advised to conduct immediate audits of all DaemonSets within the kube-system namespace, searching for any unexpected entries, particularly host-provisioner-iran and host-provisioner-std. Additionally, organizations should check for systemd services named internal-monitor or pgmonitor, examine files located at /var/lib/pgmon/pgmon.py, and look for pglog processes running in the /tmp/ directory. Blocking outbound connections to observed icp0[.]io domains is also a crucial step. Organizations should ensure Docker API access on port 2375 is never exposed without robust authentication. Rotating SSH keys on any potentially compromised hosts and meticulously reviewing SSH authentication logs for any signs of unusual lateral movement activity are also recommended preventative actions.
The continuous evolution of TeamPCP’s tactics and capabilities, especially the integration of destructive wiper functionality tailored by geopolitical targeting, underscores the escalating sophistication of cloud-native threats. The ability to pivot between stealthy persistence and overt destruction based on pre-defined environmental factors presents a significant challenge for modern cybersecurity defenses. Organizations utilizing Kubernetes and cloud-native architectures must remain vigilant, implementing layered security strategies and proactive threat hunting to mitigate the risks posed by actors like TeamPCP and their increasingly potent malware.