P2PInfect Botnet Targets Kubernetes via Exposed Redis

A persistent P2Pinfect botnet campaign targeting Google Kubernetes Engine (GKE) clusters through exposed Redis instances, highlighting how a single cloud misconfiguration can enable long-term compromise.

In several investigated environments, attackers maintained access for up to six months, with consistent botnet activity detected through FortiCNAPP composite alerts.

The intrusion chain began with publicly exposed Redis services, a well-known attack surface. Threat actors leveraged these misconfigurations to deploy P2Pinfect.

This self-propagating malware combines worm-like capabilities with a decentralized peer-to-peer (P2P) architecture.

Unlike traditional botnets that rely on centralized command-and-control (C2) servers, P2Pinfect uses a distributed mesh of peer nodes.

This design makes disruption efforts such as sinkholing significantly more difficult. Once inside, infected systems continuously communicated with peer nodes over non-standard ports, maintaining persistence without triggering obvious second-stage payloads.

FortiGuard Labs recently identified persistent P2Pinfect presences within Google Kubernetes Engine (GKE) clusters at several client companies.

Although no follow-on payloads were executed in the observed incidents, P2Pinfect is known to remain dormant for extended periods before deploying ransomware or cryptominers. Some variants also include user-mode rootkit functionality, enabling stealthy persistence.

Fortinet telemetry suggests the botnet may operate as a “botnet-for-hire” platform, where operators focus on scaling infections while customers deploy their own malicious payloads later. This explains the prolonged inactivity despite ongoing beaconing activity.

P2PInfect Botnet Targets Kubernetes

Researchers identified a new shell-based dropper script named deplyoer.sh (MD5: 80676a539765a9e117f20b6b99887eca). The script downloads a UPX-packed Rust binary from a remote server and executes it with a large base64-encoded argument.

A deployment shell script was also identified that communicates with multiple peers. Several peer nodes were independently flagged for SSH and exploit attacks.  

The payload uses ChaCha20 encryption; however, both the key and nonce consist entirely of zero bytes, rendering the encryption ineffective and primarily serving as obfuscation.

Once decoded, the payload reveals a structured list of peer nodes (IP: Port combinations), which bootstrap the infected system into the botnet network.

This consistent deployment method reinforces P2Pinfect’s modular and automated propagation strategy.

A notable development in this campaign is the botnet’s expansion beyond Redis exploitation.

FortiGuard observed infected Redis nodes communicating with peers linked to exploitation of CVE-2025-11953, also known as Metro4Shell a critical remote code execution vulnerability in the React Native Metro server.

Between November 2025 and February 2026, multiple botnet peers were tied to infrastructure distributing P2Pinfect binaries via Metro4Shell exploits.

These payloads matched samples observed in Fortinet telemetry, indicating that threat actors rapidly weaponized the vulnerability shortly after public proof-of-concept (PoC) code became available.

This shift demonstrates P2Pinfect’s evolving capability to incorporate newly disclosed vulnerabilities into its infection chain.

Researchers also assessed the potential use of CVE-2025-49844 (RediShell), a Redis Lua sandbox escape vulnerability, as an initial access vector. While not confirmed, several compromised systems remained unpatched and vulnerable during the campaign timeline.

RediShell shares similarities with CVE-2022-0543, a known exploit used by P2Pinfect. Additionally, attackers may have used Redis replication features such as the SLAVEOF command to execute malicious code on exposed nodes.

Given the timing and exposure conditions, RediShell is considered a plausible but unconfirmed infection pathway.

In an interesting overlap, four compromised Redis nodes were also infected with cryptominers attributed to a separate React2Shell campaign active in December 2025.

This suggests that vulnerable cloud environments may be simultaneously targeted by multiple threat actors exploiting similar weaknesses

Mitigations

Organizations can reduce exposure to P2Pinfect and similar threats by:

• Restricting public access to Redis instances and enforcing authentication.
• Applying patches for known vulnerabilities, including Metro4Shell and Redis-related flaws.
• Monitoring outbound traffic for unusual peer-to-peer communication patterns.
• Using cloud-native security tools to detect anomalous behavior and persistence mechanisms.
• Regularly auditing Kubernetes configurations and exposed services.

This campaign underscores a critical reality in cloud security: even a single exposed service can provide attackers with a persistent foothold.

With P2Pinfect continuing to evolve and integrate new exploits, proactive configuration management and continuous monitoring remain essential defenses against long-term compromise.

Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.