Technical analysis of the PCPJack cloud worm. How it hunts and removes rival malware in Kubernetes and Docker before stealing cloud credentials. Read now.
What a Predatory Cloud Worm Does
PCPJack is a cloud worm designed for container environments. Unlike malware that only installs itself and phones home, a predatory worm treats other infections as competition. Its first job is to find and clear rival malware from the same Kubernetes or Docker host, then use the cleaned surface to steal cloud credentials and keep spreading.
That sequence matters. Credential theft works better when the host is quiet. Other malware may log the same secrets, trigger the same alerts, or rewrite the same startup paths. By removing rivals first, PCPJack reduces noise and collision risk before it harvests tokens, keys, and config that open cloud control planes.
How Rival Hunting Works in Kubernetes and Docker
In Kubernetes and Docker, persistence often lives in a short list of places: running containers, volume mounts, cron-like jobs, host paths shared into pods, and process trees that look like miners or reverse shells. A predatory worm can scan those surfaces for known signatures, suspicious binaries, or high-CPU processes that match common malware patterns, then terminate or delete what it finds.
Operators should assume the worm is opportunistic rather than precise. It may kill legitimate workloads that look similar to miners, or wipe paths that share names with known droppers. The practical takeaway is not only “malware removes malware,” but that host cleanup by an attacker is itself an integrity event. Unexpected process deaths, missing binaries, and sudden free disk after a noisy period can be early signals of a predator, not recovery.
Credential Theft After the Host Is Cleared
Once rivals are gone, the worm turns to cloud credentials. In container hosts those secrets often sit in environment variables, mounted service-account tokens, cloud metadata endpoints reachable from the node or pod network, and local config files used by CLIs or SDKs. A worm that already has host or container access can walk those sources without needing a separate phishing step.
- Inspect pods and nodes for unexpected mounts of cloud config or token directories.
- Treat broad access to the instance metadata service as a blast-radius problem, not a convenience.
- Rotate credentials that lived on any host where rival malware was cleared without a clear admin action.
- Watch for outbound traffic after a spike of process kills or file deletions on worker nodes.
Stealing credentials is the force multiplier. Local footholds die when pods restart; cloud keys and tokens survive restarts and can be used from outside the cluster.
What Defenders Should Do Next
Defend in the same order the worm attacks. First, inventory what should run on each node and alert on unknown containers, hostPath abuse, and privileged pods. Second, make rival-style cleanup hard to hide: central process and file integrity monitoring on workers, not only on control-plane components. Third, shrink credential exposure so a single compromised node does not yield long-lived cloud admin access.
When you find evidence of predatory behavior—other malware removed, then new outbound calls or cloud API use from the node—contain the node, revoke tokens issued from it, and rebuild rather than “cleaning” in place. A worm that already hunts rivals will also resist half measures. Rebuild from known-good images, reissue short-lived credentials, and close the paths that let a container read host secrets in the first place.