TeamPCP’s Kubernetes wiper shows how C2 and cluster trust collapse

At a glance

What this is: This is an analysis of TeamPCP’s evolving payload chain, which combines Kubernetes-native privilege abuse, lateral movement, persistence, and a geopolitically targeted destructive wipe path.

Why it matters: It matters because identity and access boundaries around service accounts, privileged DaemonSets, SSH keys, and Docker APIs can turn one foothold into full cluster or host compromise.

👉 Read Aikido's analysis of TeamPCP's Kubernetes wiper and CanisterWorm variant

Context

Kubernetes wiper malware succeeds when the control plane is treated as a trusted execution layer instead of a tightly governed identity surface. In this case, the first weakness is not just code execution, but the ability to run privileged DaemonSets, reach host filesystems, and pivot through the same orchestration trust that is supposed to keep nodes isolated. For identity teams, the relevant question is how service accounts, node privileges, and host access are constrained before they become a cluster-wide blast radius.

The article also shows how cloud and container compromise becomes an identity problem as soon as attackers can reuse SSH keys, parse authentication logs, or talk to exposed Docker APIs. Those are not separate issues. They are different paths through the same access-governance failure, where machine credentials and operational tooling provide lateral movement once the initial foothold is established.

Key questions

Q: What breaks when a privileged Kubernetes DaemonSet is abused for malware delivery?

A: A privileged DaemonSet can turn cluster scheduling into node-level execution. If it can mount the host filesystem, run with hostPID or hostNetwork, and tolerate all nodes, one deployment can spread code to every machine in the cluster, including control plane nodes. That is how a workload becomes a cluster-wide compromise rather than a single-pod incident.

Q: Why do service accounts and SSH keys create such a large lateral movement risk?

A: Because they are reusable machine identities with no natural friction once stolen. Attackers can move from one host to another by reusing keys, tokens, or mounted credentials, especially when those identities have broad trust and weak rotation. In cloud environments, the problem is not the existence of machine identity, but the lack of scope and lifecycle control.

Q: How do security teams know whether Kubernetes launch controls are actually working?

A: They should test the final rendered workload, not just the upstream request or policy check. If an attacker can still alter securityContext, create additional documents, or bypass prohibited IDs after rendering, the control is not protecting the real execution path. Validation needs to cover the object that Kubernetes will actually admit.

Q: Who is accountable when a cluster compromise leads to destructive host wiping?

A: Accountability usually sits with the team that owns workload governance, platform policy, and exception handling, not just the responders who clean up afterward. If privileged orchestration paths, machine credentials, and exposed management interfaces were left broad, the incident points to a control-design failure that should be visible in risk and audit reporting.

Technical breakdown

How privileged DaemonSets become cluster-wide execution

A DaemonSet schedules a pod on every node in a Kubernetes cluster, including control plane nodes if tolerations and permissions allow it. When that pod runs privileged, with hostNetwork, hostPID, and hostPath mounts, it stops behaving like an ordinary workload and starts acting like node-level code execution. In this case, the payload uses the Kubernetes API itself as the delivery mechanism, then mounts the host root filesystem and executes destructive commands from inside the container. The danger is not Kubernetes alone, but Kubernetes plus excessive trust in workload privileges.

Practical implication: restrict DaemonSet creation, privilege escalation, and hostPath mounts with admission controls and workload policy.

Why SSH keys and exposed Docker APIs are high-value lateral paths

Once the malware leaves the cluster, it shifts to traditional infrastructure movement. It parses SSH logs for successful logins, harvests private keys from home directories, and attempts reuse against nearby hosts. It also checks for unauthenticated Docker APIs on port 2375, which can be used to create a privileged container with the host filesystem bound in. Both paths turn weak identity and weak service exposure into remote execution, because the attacker is no longer guessing passwords, they are reusing trusted access paths that were never meant to be broad.

Practical implication: eliminate exposed Docker daemons, inventory SSH key usage, and segment hosts so one machine cannot authenticate the next.

How destructive payloads hide behind operational camouflage

The payload changes its behaviour based on locale and environment, then disguises persistence as benign infrastructure tooling such as PostgreSQL monitoring. That matters because defenders often whitelist process names, systemd services, and deployment patterns that appear familiar. Here, the attacker is using naming, service registration, and restart loops to blend into normal operations while keeping execution durable. In identity terms, this is persistence built on operational trust rather than just malware installation.

Practical implication: tie service registration, binary placement, and privilege grants to signed approvals and tamper-evident monitoring.

Threat narrative

Attacker objective: The attacker aims to gain durable control of hosts and clusters while selectively destroying Iranian systems and preserving access elsewhere.

1. Entry occurs through a cloud-native foothold that can reach Kubernetes workloads, host systems, or exposed infrastructure services.
2. Credential access and movement expand through SSH key theft, authentication log parsing, and reuse of unauthenticated Docker API access.
3. Impact is delivered through privileged node-level execution that either installs persistent backdoors or wipes the target system and reboots it.

NHI Mgmt Group analysis

Cluster trust is the real target, not just Kubernetes runtime access. This payload shows that once a privileged DaemonSet is allowed to mount host paths, the cluster becomes an identity enforcement failure rather than a scheduling problem. Kubernetes-native compromise becomes catastrophic when workload identity, node privilege, and control-plane reach are not separately governed. The practitioner conclusion is simple: control-plane trust must be treated as an access boundary, not an operational convenience.

Machine identity sprawl creates the lateral movement paths that wipers need. SSH keys, service accounts, Docker sockets, and systemd services all function as non-human identities once they can be reused at scale. The article shows how attackers chain those identities together across hosts, then repurpose them for persistence or destruction. This is exactly the kind of NHI governance gap OWASP-NHI is meant to expose, especially where privilege is static and reuse is normal. The practitioner conclusion is to assume every reusable machine credential can become a propagation channel.

PostgreSQL camouflage is a named concept worth watching: service-name deception. The payload uses plausible service names such as internal-monitor and pgmonitor to hide destructive activity inside routine operations. That tactic weakens detection because operators often trust familiar labels more than they inspect privilege, path, and launch context. The practitioner conclusion is that name-based trust is not control and must be replaced with provenance and policy checks.

Geopolitical targeting does not change the governance lesson. The Iran-specific branch is a reminder that destructive logic can be embedded inside otherwise ordinary cloud-native tooling. The same codebase can install persistence on one target and erase another, which means defenders must model intent as part of threat analysis, not just payload behaviour. The practitioner conclusion is to treat regional targeting logic as an escalation signal, not an edge case.

This is an NHI governance problem as much as a malware problem. The attacker is not inventing new primitives, but abusing existing identity relationships between workloads, nodes, keys, and APIs. That makes lifecycle control, privilege scoping, and offboarding the decisive controls, not just endpoint detection. The practitioner conclusion is to map machine identities to their actual blast radius before an attacker does it for you.

What this signals

Kubernetes-native malware is forcing a shift from workload-centred defense to identity-centred control of infrastructure. When DaemonSets, SSH keys, and service accounts can be chained into the same propagation path, security teams need to treat machine identity inventory, privilege scoping, and exception governance as operational controls rather than documentation exercises.

Service-name deception: attackers increasingly hide destructive tooling behind familiar operational labels, which means detection logic must move beyond process names and into provenance, privilege, and deployment source. That is where policy, not pattern matching, decides whether persistence is blocked or normalised.

For identity programmes, the practical signal is clear: if a compromised workload can still reach host-level execution or reuse machine credentials across zones, the organisation has a lifecycle problem, not just a malware problem. Mapping those paths back to control owners is the fastest way to reduce blast radius.

For practitioners

• Lock down privileged DaemonSets Block privileged DaemonSets by default, especially any workload that requests hostPath: /, hostPID, or hostNetwork. Require explicit approval for node-level agents and verify that each exception has a documented owner and expiry. This reduces the chance that a single pod can rewrite the host filesystem.
• Hunt for exposed machine credentials Search for SSH private keys, shared service accounts, and unauthenticated Docker API exposure across the fleet. Remove 2375 access from all but tightly controlled admin networks, and treat successful SSH logins as potential propagation events when they originate from unusual sources.
• Separate benign tooling from trusted execution Do not allow process names like pgmonitor or internal-monitor to justify trust. Validate binaries by path, signature, and deployment provenance, then alert on systemd services that appear outside approved configuration management. The goal is to detect service-name deception before persistence becomes durable.
• Reduce the blast radius of cluster service accounts Scope Kubernetes service accounts tightly, disable unnecessary automounting, and review which workloads can create or mutate DaemonSets. Pair that with admission policy so an attacker who steals one workload identity cannot turn it into node-level execution.

Key takeaways

• This payload turns Kubernetes trust, SSH reuse, and exposed infrastructure APIs into a single attack path that can wipe or persist across hosts.
• The article shows that a privileged DaemonSet, a stolen key, or an open Docker socket is enough to move from local compromise to cluster-wide impact.
• The control that matters most is blast-radius reduction across workload identity, node privilege, and host access, not just faster detection after deployment.

Key terms

• Privileged DaemonSet: A DaemonSet is a Kubernetes controller that runs one pod per node. When it is privileged and can mount the host filesystem, it becomes a node-level execution vehicle rather than a normal workload, which makes it attractive to attackers seeking cluster-wide control.
• Machine Identity: The digital identity of a machine, device, or workload — such as a server, container, or VM — used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
• Service-name deception: Service-name deception is the practice of naming malicious or unauthorized components to look like routine infrastructure. It works because operators often trust familiar labels such as monitoring or PostgreSQL tooling, even when the deployment path, privileges, and execution context are abnormal.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.

What's in the full article

Aikido's full post covers the operational detail this post intentionally leaves for the source:

• Exact payload logic for the Iran-specific wipe branch, including the DaemonSet spec and host-root mount path
• Indicator-of-compromise list for the ICP canister, Cloudflare delivery domains, service names, and on-host file paths
• Command examples for finding suspicious DaemonSets and verifying whether internal-monitor or pgmonitor persistence exists
• Details of the SSH spread and Docker API abuse paths that show how the malware propagates outside Kubernetes

👉 Aikido's full post covers the attack chain, persistence paths, and host-level indicators of compromise

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It is designed for practitioners who need to govern reusable credentials and reduce blast radius across modern environments.