Anatomy of a Persistent Breach: P2Pinfect Botnet Targeting GKE Clusters

A sophisticated and highly persistent botnet campaign, identified as P2Pinfect, has been targeting Google Kubernetes Engine (GKE) environments. By exploiting misconfigured, publicly exposed Redis instances, threat actors have demonstrated how a single oversight in cloud configuration can facilitate months of undetected lateral movement and network presence.

In several investigated environments, telemetry from FortiCNAPP composite alerts revealed that attackers maintained a foothold for up to six months. This long-term residency highlights a shift toward “low and slow” tactics designed to evade traditional perimeter defenses.

The initial intrusion vector is a well-documented attack surface: unauthenticated or publicly reachable Redis services. Once an entry point is established, the attackers deploy P2Pinfect, a self-propagating malware that utilizes a decentralized, peer-to-peer (P2P) architecture.

Unlike traditional botnets that rely on a centralized Command-and-Control (C2) infrastructure—which can be disrupted through domain sinkholing—P2Pinfect operates via a distributed mesh of peer nodes. This makes the network highly resilient; even if individual nodes are neutralized, the botnet’s collective intelligence remains intact. Once an infection takes hold, the compromised systems communicate with peers over non-standard ports, maintaining persistence without immediately triggering the noisy second-stage payloads often associated with malware.

While researchers have not observed immediate follow-on payloads in every instance, P2Pinfect is designed for dormancy. It is common for these actors to leave a system “quiet” for extended periods before activating ransomware or cryptominers. Furthermore, certain variants incorporate user-mode rootkit functionality to deepen stealth and ensure persistence against system reboots or minor cleanups.

Current telemetry suggests P2Pinfect may operate as a “Botnet-as-a-Service” (BaaS) platform. In this model, operators focus purely on scaling the infection footprint within cloud environments, effectively “renting” the established access to other threat actors who can later deploy their own specific payloads. This explains the observed pattern of consistent beaconing without immediate, overt malicious activity.

Technical Deep Dive: The Infection Chain

Forensic analysis has identified a new shell-based dropper script, deplyoer.sh (MD5: 80676a539765a9e117f20b6b99887eca). The script functions by downloading a UPX-packed Rust binary from a remote staging server, which is then executed using a large Base64-encoded argument to obfuscate its true intent.

A secondary deployment shell script was also identified, responsible for orchestrating communications with multiple peers. During analysis, several peer nodes were independently flagged for conducting active SSH brute-force and exploit attempts, indicating the botnet’s active role in lateral movement.

The payload employs ChaCha20 encryption for data protection; however, technical inspection revealed that both the key and the nonce consist entirely of zero bytes. This renders the encryption mathematically ineffective, serving purely as a layer of obfuscation to bypass signature-based detection. Once the payload is decoded, it reveals a structured manifest of IP:Port combinations used to bootstrap the newly infected system into the P2P mesh.

Evolving Exploitation: Beyond Redis

A significant development in this campaign is the botnet’s ability to pivot beyond Redis vulnerabilities. FortiGuard observed infected Redis nodes actively communicating with peers linked to the exploitation of CVE-2025-11953 (also known as Metro4Shell), a critical Remote Code Execution (RCE) vulnerability in the React Native Metro server.

Between November 2025 and February 2026, threat actors rapidly weaponized Metro4Shell, distributing P2Pinfect binaries via this exploit shortly after public Proof-of-Concept (PoC) code became available. This agility demonstrates a highly mature development lifecycle, where new vulnerabilities are integrated into the automated propagation strategy almost immediately.

Researchers are also investigating the potential use of CVE-2025-49844 (RediShell), a Redis Lua sandbox escape vulnerability, as an initial access vector. While not definitively confirmed, the presence of unpatched, vulnerable systems during the campaign timeline makes this a highly plausible pathway. This aligns with known techniques such as using the SLAVEOF command to force a Redis node to replicate data from an attacker-controlled instance, thereby executing malicious code.

Interestingly, the campaign shows evidence of “threat actor overlap.” Four compromised Redis nodes were found to host cryptominers attributed to the React2Shell campaign in late 2025. This suggests that highly vulnerable cloud environments are often subject to simultaneous, multi-actor exploitation campaigns.

Security Recommendations and Mitigations

To defend against P2Pinfect and similar decentralized threats, organizations should adopt a multi-layered security posture focusing on both configuration hardening and behavioral monitoring:

• Network Hardening: Strictly prohibit public access to Redis instances. Enforce robust authentication mechanisms and utilize private subnets or VPC peering for internal service communication.
• Vulnerability Management: Prioritize the patching of critical vulnerabilities, specifically focusing on the Redis ecosystem and development tools like the Metro server (CVE-2025-11953).
• Egress Filtering: Implement strict outbound traffic rules. Monitor for unusual peer-to-peer communication patterns or traffic over non-standard ports that could indicate botnet beaconing.
• Cloud-Native Observability: Utilize Kubernetes-native security tools and Runtime Security (e.g., Falco or FortiCNAPP) to detect anomalous process executions and unauthorized lateral movement.
• Configuration Auditing: Regularly perform automated audits of Kubernetes manifests and Cloud IAM policies to identify and remediate exposed services before they can be discovered by automated scanners.

The P2Pinfect campaign serves as a stark reminder: in a cloud-native world, the perimeter is defined by your weakest configuration. Proactive management and continuous monitoring are no longer optional—they are the baseline for survival.