FortiGuard Labs reported that P2Pinfect, a resilient peer-to-peer botnet, has been found maintaining persistent presence inside Google Kubernetes Engine (GKE) environments after exposed Redis instances gave attackers an initial foothold. In at least one observed case, the compromise lasted roughly six months while the botnet continued peer communication without immediately dropping a second-stage payload.
That dormancy is the important part. A compromised cloud workload does not have to detonate ransomware on day one to be dangerous. It can sit quietly, communicate with a peer mesh, preserve access, and wait until an operator or customer of the botnet decides to monetize the node.
What Fortinet reported
According to FortiGuard Labs, P2Pinfect was observed in multiple client GKE clusters, with exposed Redis services acting as the original access point. The malware is written in Rust, uses a decentralized peer-to-peer architecture, and has been associated in the wild with crypto-mining and ransomware delivery after periods of dormancy.
Fortinet also described a deployment script used to retrieve a Linux P2Pinfect client, execute it with an encoded peer list, and enroll the host into the botnet mesh. The reporting connects some observed peer infrastructure to exploitation of Metro4Shell, while also assessing RediShell as a plausible but lower-confidence Redis-related vector in vulnerable environments.
Why this matters
For small businesses, MSPs, and government contractors, this is a practical cloud security warning. Internet-exposed Redis, permissive Kubernetes networking, and weak runtime monitoring can turn a normal cloud misconfiguration into durable attacker infrastructure. Even if no data is encrypted and no miner is immediately visible, the organization may still be hosting a botnet node inside its environment.
P2P botnets are harder to disrupt than traditional command-and-control models because there is no single server defenders can block to neutralize the operation. Once a workload is enrolled, it may communicate with many peers across non-standard ports, download platform-specific payloads, and survive infrastructure takedown attempts.
Defensive takeaways
- Find exposed Redis immediately. Redis should not be directly reachable from the public internet unless there is a very specific, hardened business case. Audit cloud security groups, Kubernetes services, load balancers, and firewall rules.
- Patch Redis and related application stacks quickly. Treat Redis sandbox escapes and unauthenticated application RCEs as priority fixes, especially where the service is reachable from cloud workloads.
- Monitor egress, not just ingress. P2Pinfect-style activity may show up as unusual outbound peer connections from workloads that should not be talking to arbitrary external IPs or high-numbered ports.
- Harden Kubernetes runtime boundaries. Use namespace segmentation, least-privilege service accounts, restricted pod security settings, and network policies to limit what a compromised workload can reach.
- Investigate dormant compromise seriously. If a botnet client is found, assume the host is not merely “infected but harmless.” Rotate secrets, review cloud identity activity, inspect images and deployment pipelines, and rebuild affected workloads from trusted sources.
Bulwark Black assessment
The biggest lesson from this report is that cloud exposure and runtime behavior have to be managed together. Vulnerability management tells you what could be exploited. Cloud posture management tells you what is exposed. Runtime telemetry tells you whether the workload is already acting compromised. Organizations that only do one of those three will miss attacks that are quiet, patient, and infrastructure-focused.
For government contractors, this also has compliance implications. A dormant botnet foothold in a cloud environment can still create risk to controlled data, contractor systems, and downstream customers. The right response is not just removing the binary; it is proving how the service was exposed, what the workload could access, what secrets may have been present, and whether any lateral movement occurred.
Start with the simple controls: no public Redis, tight egress rules, fast patching for internet-facing services, and alerts for workload behavior that does not match the application’s purpose. Those basics will prevent more real incidents than another dashboard that nobody checks.
