P2Pinfect Kubernetes Compromise — Exposed Redis Enables Persistent GKE Botnet Enrollment with Six-Month Dormancy (CVE-2022-0543, CVE-2025-11953, CVE-2025-49844) — Threadlinqs Intelligence
As of 2026-05-30, P2Pinfect Kubernetes Compromise — Exposed Redis Enables Persistent GKE Botnet Enrollment with Six-Month Dormancy (CVE-2022-0543, CVE-2025-11953, CVE-2025-49844) is a high-severity malware threat attributed to P2Pinfect Operator, tracked by Threadlinqs Intelligence with 9 detection rules (Splunk SPL, Microsoft KQL, Sigma) and 31 indicators of compromise.
Threat ID: TL-2026-0537 · Severity: HIGH · CVSS: 8.8 · Status: ACTIVE · Category: MALWARE
Attribution: P2Pinfect Operator · FINANCIAL
FortiGuard Labs documented persistent P2Pinfect botnet presence in Google Kubernetes Engine (GKE) clusters across multiple client environments, with one compromise dormant for six months before
**Campaign overview.** P2Pinfect is a self-replicating, Rust-based botnet first publicly documented by Palo Alto Networks Unit 42 in July 2023 and continuously tracked by Cado Security, Akamai SIRT, and Cisco Talos. The botnet uses a permissioned gossip protocol over a flat peer-to-peer mesh — every infected host can both receive and rebroadcast new binaries — and has historically been used to drop XMRig Monero miners and an opportunistic ransomware module (rsagen). The May 2026 FortiGuard Labs report (Misconfigured, Enrolled and Dormant) is the first public confirmation that the operator is targeting managed-Kubernetes runtime environments at scale, with confirmed long-dwell footholds in multiple Google Kubernetes Engine (GKE) tenants. One environment was compromised for approximately six months before detection — the host had been enrolled, beaconed back to the mesh on its expected jitter, and was never tasked with a second-stage payload, which made it invisible to signature-based EDR controls watching for cryptominer or ransomware behavior.
**Initial access — exposed Redis.** Across all confirmed GKE intrusions Fortinet documents the same root cause: a Redis Deployment exposed to the public Internet through a permissive Service or Ingress, accepting commands without requirepass. The operator drives initial code execution by chaining classical Redis abuse primitives: (1) CONFIG SET dir /var/spool/cron/, CONFIG SET dbfilename root, then SAVE to drop a cron entry; (2) MODULE LOAD of an attacker-supplied shared object delivered via SLAVEOF / replication; and (3) on Debian-derived images, the Debian-specific Lua sandbox escape CVE-2022-0543 (package.loadlib reachable from inside the sandbox) for direct RCE. The Lua escape is preferred because it works against pods that have hardened cron and disabled module loading. Fortinet observed the operator probing for all three primitives in sequence and falling back if any single technique was blocked.
**Implant — the Rust P2Pinfect client.** The dropper is a statically-linked Rust binary, UPX-packed, with the upper-case UPX magic deliberately mangled to defeat naive header scanning (upx -d fails; manual fix-up restores the section table). Unpacked, the binary exposes the canonical P2Pinfect strings (p2pinfect, botnet_v3, gossip_round), a libtor-style Tor bundle for fallback C2, and a randomized 30-day-jitter beacon scheduler. Once running, the client (a) enumerates the host (kubelet token, service-account token mounted at /var/run/secrets/kubernetes.io/serviceaccount/, network interfaces, kernel version, container runtime), (b) opens a listener on a high TCP port (observed 60100-60300 random) for inbound gossip peers, (c) connects out to 3-8 hard-coded bootstrap peers and learns additional peers via gossip, and (d) waits. It does not in itself escalate, drop a miner, or move laterally — those actions are operator-tasked over the mesh and were never observed in the six-month dormant case.
**Persistence and dormancy.** P2Pinfect installs persistence at every layer it can reach: a systemd user-unit if /run/systemd is writable, a crontab -e entry inside the pod, a renamed copy of itself in /tmp/.{random}/ plus an LD_PRELOAD shim hooking getuid(), and — most importantly in the GKE case — an in-cluster persistence path. Where the compromised pod runs with a service account that has create pods or patch deployments RBAC, the implant creates a new Deployment in the kube-system namespace mimicking a benign DaemonSet (commonly node-local-cache or metrics-server-helper) whose pod template re-launches the implant. This survives node reboots, pod evictions, and even cluster autoscaler scale-down events. The six-month dormancy case is a direct consequence of this design: nothing the implant does on a dormant peer touches disk I/O, network egress (beyond expected jitter), or process trees in a way that crosses normal EDR thresholds.
**Expansion to React Native Metro (CVE-2025-11953, Metro4Shell).*
Weaknesses (CWE)
CWE-269, CWE-416, CWE-94, CWE-78, CWE-863, CWE-306
Target sectors: technology, financial, ecommerce, saas, media, healthcare, manufacturing
Target regions: Global, North America, Europe, Asia-Pacific
Detections & IOCs
As of 2026-07-28, this threat has 9 detection rule(s) across Splunk SPL, Microsoft KQL and Sigma, and 31 indicator(s) of compromise. Detection query text and full IOC values are available to authenticated users and programmatically via the Threadlinqs MCP server (Purple tier). View plans.
MALWARE, HIGH, threat intelligence, cybersecurity, CVE-2022-0543, CVE-2025-11953, CVE-2025-49844, T1595, T1590, T1583, T1588, T1587, T1190, T1133, T1059, T1203, T1609