Blog - Latest Enterprise IT News and Information | Inde Technology

How command and control ended up on your allow list

Written by Chris Campbell | Oct 07, 2026

Why command and control?

It’s perhaps an uncomfortable thought exercise for some, but there's not much a threat actor can achieve with just initial access. Whether it's a phished user, purchased VPN credentials or an exploited edge device, they're usually left holding a single host and low-privileged account. Whatever the objective, be it extortion or espionage, they need control over a whole environment to achieve it, and every step in between travels over command and control (C2) channels.

In essence, the channels are how offensive tooling send commands and returns their responses. It's how operators stage tools, pivot between networks, collect output and exfiltrate it, and it's also one of the weakest links in an attack chain. For this reason, it's not uncommon to see multiple channels established within minutes of gaining initial access. Cutting off a channel can be just as effective as removing every malware implant. 

Most organisations would quickly collapse if their users were unable to browser the internet, which is why firewalls typically block unsolicited inbound connections but are far more permissive of anything outbound. It's this fundamental business need that has allowed C2 to thrive in networks for so long, and what has fuelled a cat and mouse game between network security vendors and offensive tooling developers. The history of C2 design mimics this ongoing search for whatever enterprise egress rules tolerate the most, and why we have seen a clear move towards the services that many of us depend on.

A short history of C2

The first botnets ran on IRC. GTBot and Sdbot would herd infected hosts into a channel and wait for the operator to send commands. It was an easy way to reach a lot of machines at once, but compromise of the IRC server would hand over control of an entire botnet.

 In the 2000s C2 moved onto the web. Banking and Remote Access Trojans such as Poison Ivy, SpyEye and Zeus (and its many contemporaries) would poll a static domain over HTTP, which to firewalls at the time would look like regular web traffic. However, the channel was still centralised. Sinkhole the domain it relied upon and you killed the campaign, as neatly as seizing the chat server once had.

 The infamous Zeus control panel (source: Brian Krebs)

The crosshairs of defenders next moved to the fixed domain. Malware like Conficker could generate upwards of 50,000 domains a day, forcing defenders to pre-register or block every single one. GameOver Zeus went a step further and made the bots themselves the infrastructure, relaying commands over peer-to-peer channels with no head left to cut off.

The 2010s layered misdirection on top. Fast flux techniques rotated the IPs behind a domain, bulletproof hosting rented you servers outside of the reach of law enforcement, Tor hidden services masked the backend infrastructure of botnets, and disposable cloud redirectors sat between the malware and the servers that enabled it. The Emotet cybercrime botnet was built up of several hundred servers and compromised more than a million hosts. Its real controllers were hidden behind tiers of proxies, from hijacked web servers to infected home PCs, spread across three separate botnets. An eight-country operation seized it in January 2021, but it was still able to revive itself later that year.

Around 2015, fewer threat actors appeared willing to mask and maintain their own infrastructure, instead opting to use somebody else's, whether that was Discord, Telegram, Dropbox or Google Drive. They all offer free storage, TLS, and domains that many administrators would struggle to block. Taking down the C2 now meant asking a platform to remove offending content, rather than orchestrating a law enforcement seizure of tin you could put your hands on.

A more recent move has been the adoption of decentralised network services. Since late 2023, threat actors have been embedding payload stages and C2 configuration in smart contracts, retrieved through public RPC endpoints with nothing of the adversary's own to seize. Microsoft's July 2026 writeup of an ACR Stealer campaign documented a ClickFix chain where victims retrieved their next stage payload or C2 address from a blockchain contract. Of course, while there's nothing to seize, everything they do on chain is recorded publicly, forever.

Recent examples

In November 2022, IBM X-Force responded to an intrusion at a European retailer's self-checkout. Initial access involved a Raspberry Pi Zero being plugged straight into a till, running the P4wnP1 USB attack platform. The malware found on the device was a JavaScript Discord bot with a hardcoded API key, guild ID and channel ID. This bot watched a temp folder, and any .dat file that landed in it got chunked into base64-encoded, encrypted messages and posted to the Discord channel. The first sign of compromise was a network alert for gaming traffic on a point-of-sale segment.

In September 2026, Cisco Talos released a report on UAT-11587, who they assess with high confidence to be a China-nexus actor. Since September the year prior, they'd been deploying a Rust backdoor against government and policy targets across 8 Asian countries, affecting roughly 350 endpoints across 16 environments. Once the backdoor gained execution it authenticated to Microsoft Graph using the OAuth client-credentials flow, against an Entra ID application the attacker registered. A JSON heartbeat was uploaded to the attacker's OneDrive every minute and their Outlook mailbox polled for tasking every 10 seconds. Commands were identified by the subject prefix “command_req_” and responses by “command_res_”. To gain initial access, the actor leaned on Cloudflare Pages and R2 to stage its five-stage infection chain, so they still had some exposure to disruption if the specific domains associated with these services were ever identified.

A backdoor called SesameOp was disclosed by Microsoft in November 2025 that adopted similar tactics within AI infrastructure. The implant used the OpenAI Assistants API purely as a message relay, never touching the models. For every compromised system they created an OpenAI Assistant with the base64 value of the hostname as its identifier, then used “SLEEP”, “Payload” and “Result” as selector values on the description field to tell the implant what to do. Microsoft discovered this during an incident response engagement, where the operators were found to have been running out of hijacked Visual Studio utilities for months.

Many ransomware groups have taken this concept one step further and skipped building bespoke implants and channels altogether, instead using tools that many organisations already use. Between September and November 2025, Huntress observed abuse of the Velociraptor DFIR tool four times:

  • Twice through ToolShell web shells planted in SharePoint.

  • Once through the WSUS vulnerability CVE-2025-59287.

  • Once arriving mid-compromise alongside a Warlock ransom note. 

The operators used Velociraptor to spawn base64-encoded PowerShell, and stand up Visual Studio Code and Clouflare tunnels. In 3 of the 4 cases, Velociraptor's own C2 pointed not to a rented VPS but to a *.workers.dev domain (Cloudflare Workers), the same serverless functions we'll get into later in this post.

Qilin is the RaaS operation that grew out of Agenda and absorbed affiliates from LockBit, RansomHub and ALPHV, and they have a particular liking for RMM tools. MeshAgent, Splashtop, RustDesk, AnyDesk, Atera and even Chrome Remote Desktop have all turned up across Qilin incidents, with no clear favourite. Trend Micro found one Qilin affiliate using Atera to deploy AnyDesk, with ScreenConnect alongside it for redundancy. They even invoked Splashtop's own management service to run their Linux ransomware on Windows hosts through WSL.

 AnyDesk, a favourite of cybercriminals (source: AnyDesk)

A GUI-based remote-access tool is easy for an affiliate of any skill level to pick up and run with, and most companies choose not to block them because they’re using them legitimately themselves.

Endless options

To appreciate the variety of channels that can be abused for phishing, C2, payload delivery and exfiltration, you need not look any further than the LOL projects:

  •  The LOTS Project indexes more than 150 trusted domains. 

  •  LOLFSaaS counts 127 free-tier SaaS platforms. 
  • LOLC2 tracks 53 abused services and 132 C2 projects. 

lolol.farm sits atop of these and indexes more than 35 of living-off-the-land catalogues in its directory. Once you see all of the options you start to look at your egress policies from a completely different perspective.

My projects

Blockchain

In the case of ClickFix dead drops, the chain holds a pointer, and everything downstream of it still needs somewhere to live. I wanted to see how far a public ledger could carry an entire command channel while remaining OPSEC safe (and learning about blockchain development as a bonus). The result has been graphcat. For reasons, there is no current intent to release it publicly.

In graphcat's operation, the chain serves as a message queue. Every agent gets its own topic that only the operator can post to, and anyone can read. Agents poll it over HTTPS, so the host needs no inbound ports opened and never holds a long-lived connection. Results, heartbeats and check-ins flow back over a shared status topic. While anyone can read this, everything on it is encrypted, so knowing the topic ID doesn’t disclose anything usable.

Three cryptographic aspects combine to keep that traffic private and trustworthy:

  • Agent identity: Each agent generates a persistent X25519 keypair on first run.
  • Session keys: An ECDH exchange with the server uses HKDF to produce two AES-256-GCM keys (one for sending and one for receiving). If one agent binary is compromised, only that agent's own messages will leak.
  • Command authenticity: The server signs every command with its Ed25519 key, and agents drop anything that isn't signed or isn't addressed to them.

 The smart contract stores the current configuration:

  • The server's signing key and ECDH key.
  • The status topic.
  • The poll and heartbeat intervals.
  • The file-staging URL.

Agents re-read it every 5 minutes, so rotating a key or changing the cadence is only a contract update rather than a full agent rebuild.

Uploaded and downloaded files are staged as AES-GCM ciphertext on a Blossom server, which is the spec the Nostr community uses to host blobs. Access is authenticated with a Nostr auth event, and the file is deleted once the receiver confirms it has it. As most public Blossom servers only accept media file types, this narrows the available endpoints, but some do still exist.

The credential model is built for easy revocation, with each agent holding only three secrets:

  • Its own private key.

  • A narrow submit key for the status topic.
  • A small fee-paying account to cover transaction costs.

Consensus times and polling put round trips at 5 to 15 seconds, which is perfectly comfortable for individual command tasking but would be hopeless for anything interactive.

The UI, built with PySide6 (so Qt), is inspired by titans of the field like Cobalt Strike, Havoc and AdaptixC2. It offers all the features you’d expect of a C2 framework, such as agent interaction, config and contract management, and file transfers:

 There’s also a built-in function for previewing downloaded file content:

The rust agent implements all commands using direct syscalls. Unfortunately, the blockchain vendor crate is quite a behemoth, so the compiled Windows agent weighs in at about 3.5MB after compression:

Cloudflare Queues

Where I was going into blockchain development with minimal prior knowledge, I already had experience with Cloudflare's security and workspace products and wanted to push further into their serverless stack. With graphcat already being my focus as a full C2 framework, I chose to build upon the popular Mythic C2 framework by making a new Cloudflare C2 profile. While Cloudflare is already listed on LOLC2 for its Tunnels, Workers and Pages products, Queues isn't on the list (yet), which settled my decision. This project has been open sourced on GitHub, and an offer made to the maintainer of Mythic to publish it to the official Mythic repos too.

The profile uses Cloudflare Queues as an asynchronous dead drop, fronted by a single Worker that's the only public endpoint, authenticated by a shared secret header. The flow looks like this:

  • Implants POST encrypted envelopes to the Worker and poll it for replies.

  • The Worker produces everything into one shared in-queue.
  • The Mythic profile container consumes from that queue over the Cloudflare REST API and forwards the blobs to Mythic, so Mythic itself never needs to be exposed to the internet.
  • Each callback gets its own out-queue, created on first check-in, which replies wait in until that implant's next poll.

Queues only guarantee at-least-once delivery, not ordering, which is why larger envelopes are split into numbered parts and reassembled on either side, rather than trusting the queue to keep them straight. The agent's main loop sleeps twice per cycle, so if you set your callback interval to 5 seconds you can expect around 10 seconds of latency on tasking. If the profile is down for long enough, the beacon cycle fails and the agent exits, though the queued messages themselves survive up to the retention period.

If a nosey researcher captured one of the implants, it holds no Cloudflare credentials, so there’s no path to identifying the Mythic backend. The whole channel comfortably runs on the free Workers tier too.

The profile is currently only supported by my fork of the Thanatos agent that’s included in the project repo. After provisioning the secrets, queues, and worker, the Cloudflare profile can be installed in Mythic and pointed at your Cloudflare account:

 

Builds of the agent follow the same process as usual, but you’ll also have the option to select the Cloudflare C2 profile:

 Once livened, you’ll be able to see the queues within your Cloudflare console:

So, what can you do?

There's no simple egress solution to this. As the channels live inside a service your business pays for and needs, trying to block your way out of the problem risks dropping legitimate business needs, and the adversary can always just move to services you’ve kept. Addressing this at the identity and endpoint layers is a far more sustainable approach. CISA's ransomware guide is a solid basis for this:

  • Tier the domain, so a compromised workstation has no path to Tier 0.
  • Treat privilege as scarce, with phishing-resistant MFA everywhere, separate admin accounts, LAPS on local credentials, and Credential Guard and Attack Surface Reduction mitigating LSASS dumping.
  • Segment the network, so lateral movement slows to a speed your monitoring can match, and exfiltration volume becomes more visible.
  • Harden the domain controllers with a current build, minimal roles, no internet access and LSA protection, and keep the interactive login list short.
  • Run a reputable EDR with tamper protection enabled.
  • Allow-list RMM, and alert on any management tooling that IT didn't deploy.
  • Treat WSUS, GPO and Intune as administration infrastructure that can double as a distribution channel.
  • Patch your workstations, Domain Controllers and edge hosts on a tight deadline.
  • Keep backups offline and tested. Treat your backup infrastructure as Tier 0.

Every C2 described in this post only exists to bridge an operator to their target, and the intrusion still requires a credential to authenticate with and a process to run in. By adopting an assumed breach perspective and building layers of defence inside your network perimeter, you make the credentials hard to abuse and can take entire categories of tooling out of their arsenal. It then matters a lot less which service the adversary is abusing any given day, and you can stop chasing your tail with short-lived IOCs and false positives.