TeamPCP CanisterWorm: selective destruction and persistence in Kubernetes environments

Days ago, security researchers have unveiled a campaign that mixes lateral motion techniques in cloud-native environments with a deliberately destructive payload oriented towards Iranian systems. The finding, documented by the firm Aikido, assigns the operation to the group known as TeamPCP and relates it to previous activities that committed open source tools and NPM packages under the informal name "CanisterWorm."

The threat combines two sides: In Kubernetes environments it takes advantage of native mechanisms to spread and persist; outside Kubernetes, it activates a mass erasing mechanism that can leave machines useless if it detects certain tracks of the system.

According to technical analysis, malware first tries to determine whether the computer corresponds to Iran by reviewing the time and regional zone settings. If you detect these signals and Kubernetes exists in the machine, you deploy a DaemonSet within the system space that sets up the host file system and starts privileged containers. Each of these containers runs a minimum image (Alpine) with a binary that erases the main inputs of the host disk and forces a reboot, a maneuver that can, in practice, leave nodes and irreparable applications.

On the other hand, when the system is not identified as Iranian but does have Kubernetes, the same propagation infrastructure is reused to install a persistent component: a backdoor written in Python that is left in the file system and recorded as a system service to survive reworks. This double strategy - to delete where it is considered "objective" and to set back where it is not - confirms the selective and oriented nature of the campaign.

The actor is not limited to Kubernetes: Aikido also documents variants that dispense with the DaemonSet-based lateral movement and resort to more traditional SSH propagation mechanisms. In these cases, malware scans authentication records for valid credentials, reuses compromised private keys and establishes outgoing SSH connections with options that avoid host footprint checks (e.g. using StritHostKeyChecking = no). Another channel of expansion identified is the use of exposed Docker APIs (usually port 2375 without TLS), which allow to boot privileged containers and mount the host as volume, which reproduces the destructive effect outside the Kubernetes ecosystem.

There are specific indicators to be monitored: among them, activity in the outgoing network towards the command and control infrastructure already associated with CanisterWorm, the appearance of DaemonSet with suspicious names such as "Host-proviser-Iran" or "Host-proviser-std" in the namespace kube-system, Alpine containers marked "kamikaze," temporary files left on type / tmp / pglog routes and connections to APis Docker in port 2375 to hosts of the local subnetwork. Aikido also points to a specific canister used as C2; its report provides more technical details and IOCs artifacts for response equipment: Aikido report.

To contextualize what this campaign takes advantage of, it is important to remember how some key elements of Kubernetes and Docker work. The DaemonSet are Kubernetes objects that ensure that a pod is executed in each node, so, in the hands of a privileged attacker, they are an effective way to run code in all the hosts of a cluster; the official documentation explains its design and risks: DaemonSet in Kubernetes' documentation. On the other hand, the use of hostPath volumes to mount the host file system into a container allows the process within the container to directly manipulate system files: Hostel in Kubernetes.

On the side of containers and runtimes, exposing the Docker API without authentication (usually through port 2375) is a known and dangerous practice: that API allows to manage containers and mount the host from the network if it is not protected. Docker's official guides include security recommendations to mitigate these scenarios: Docker engine safety.

What can teams and administrators do right now? First, audit permits and access at cluster level: review who can create DaemonSet or modify the namespace kube-system, and apply strict RBAC controls to prevent unauthorized processes from creating objects with high privileges. It is essential to block unauthenticated access to the container runtime API and to segment the network so that a committed host cannot invoke administrative APIs in the subnetwork. Monitor the creation of unusual resources (names, Alpine images executed with privileges, /) and establish alerts on outgoing SSH connections with options that disable print checks are practical and high impact countermeasures.

In addition, basic hygiene practices remain essential: rotation and protection of private keys, disable password-free sudo, apply updates and patches to the supply chain tools used (if the actor has already shown interest in open source projects, protect these flows is critical) and store audit records outside the reach of individual nodes to facilitate post-commitment research.

This campaign is a reminder that security in cloud-native environments is no longer just a matter of applying patches: it is necessary to design defenses that take into account orchestration mechanisms, the exhibition of APIs of runtime and the possibility that an opponent combines techniques of persistence and destruction. For those who want to deepen technical analysis and indicators, the Aikido report provides a detailed breakdown: read Aikido's report.

If you manage critical infrastructure or Kubernetes clusters, act with priority: review the RBAC rules, close and make sure that Docker's APIs are not accessible without protection, monitor logs and alerts for abnormal behavior, and prepare a response plan that provides for the possibility of mass data erasing. The combination of political intent and automated techniques shown by this campaign increases the risk and requires a coordinated response between managers, security teams and service providers.