C2 Frameworks 2026 — Cobalt Strike, Sliver, Empire & Red Team C2 Architecture | Hacking Course Day35

C2 Architecture — Team Server, Listener, Beacon

The fundamental model is a callback loop. You deploy an implant on a compromised host. That implant wakes up on a configured interval, connects to your listener on the team server, retrieves any queued tasks, executes them, and sends results back. Then it sleeps until the next interval. No persistent connection that network monitoring can track as an open socket — just brief, infrequent callbacks that look like any other HTTPS request.

The three components you need to understand before touching any specific framework:

Team server — your backend. Operators connect to it via a client. It stores the payload configuration, manages listeners, receives callbacks, and queues tasks. It never directly connects to target systems after the initial deployment.

Listener — a service on the team server that a specific implant variant knows to call back to. Different listeners use different protocols (HTTP, HTTPS, DNS, SMB). You deploy different implant variants against different targets depending on what communication channels are available through the target’s network controls.

Beacon/Implant — the payload running on the compromised host. It’s dormant between callbacks, has minimal on-disk footprint (often runs entirely in process memory), and only activates during brief callback windows.

C2 Channel Types — HTTP/S, DNS, SMB

Different network environments allow different egress channels. Before choosing a C2 channel for a target environment, you need to know what’s allowed out. Most corporate environments permit HTTPS to any destination — but not DNS to arbitrary resolvers, and not SMB outside the local network.

The channel hierarchy for restricted environments: HTTPS works almost everywhere. DNS C2 works when HTTPS is restricted because DNS queries to the internet are almost never blocked (breaking DNS breaks everything). SMB C2 works inside network segments where you need to move laterally through hosts that don’t have internet access — the SMB beacon communicates through an internet-connected beacon acting as a relay.

Major C2 Frameworks — Cobalt Strike, Sliver, Havoc

Three frameworks dominate professional red team operations in 2026. Know the tradeoffs before you touch any of them.

Cobalt Strike — industry standard, $5,000+/year. I’ve run it on client engagements and the feature maturity shows: Aggressor Script for automation, a deep malleable C2 profile library, beacon sleep obfuscation, built-in lateral movement. The problem you run into immediately on mature environments: its default signatures are in every major EDR’s detection database because threat actors use cracked versions constantly. You need real profile customisation time before running it against a CrowdStrike-protected fleet, or it’s over in minutes.

Sliver — my recommendation for most learning environments and budget-conscious engagements. Free, open-source, maintained by BishopFox, written in Go. You get HTTP/S, DNS, mTLS, and WireGuard channels — more protocol flexibility than most operators need. The tradeoff: EDRs increasingly recognise the Go binary signature. Use it to learn C2 operations properly; for production engagements against hardened targets, profile it against your target’s specific EDR first.

Havoc — newer, written in C and Go, with a modern UI and shellcode-focused implant design. Lower detection rate than Cobalt Strike defaults in some EDR environments because its signatures are newer and less widely distributed in threat intelligence. Active development, growing community.

Malleable C2 — Traffic Blending and Profile Design

Default Cobalt Strike beacon traffic has distinctive patterns that every mature SOC knows. The HTTP request URI, the Sec-WebSocket headers, the response structure — all fingerprinted and in detection databases. Running default Cobalt Strike against a SOC with CrowdStrike is not an engagement, it’s a test of your incident response partner’s alerting speed.

Malleable C2 profiles transform that traffic. A profile that mimics Microsoft update traffic sets the URI to /updates/, uses Microsoft-looking User-Agent strings, structures the POST body to look like Windows telemetry, and returns responses structured like Microsoft CDN responses. Network analysis sees familiar traffic patterns. The malicious content is encoded in headers and body fields that look legitimate at a glance but carry C2 data.

Red Team Infrastructure — Redirectors and OpSec

Operational security for C2 infrastructure starts with one rule: the team server never directly touches target systems. Every callback goes through at least one redirector. The redirector is a cheap cloud VPS running Nginx or Apache with forwarding rules. When incident response burns the redirector IP, your team server is intact and a new redirector is operational in fifteen minutes.

The redirector configuration is where most red teams get the detail wrong. A basic port-forward redirector passes all traffic including traffic from defender scanners — which will probe your redirector and find Cobalt Strike listening. Proper redirectors use mod_rewrite or Nginx rules that only forward requests matching specific URI patterns and specific User-Agent strings. Everything else gets a 404 or a redirect to a legitimate website.

Defender Detection Methods — What Actually Gets C2 Caught

Every red team operator needs to understand the defensive detection stack — not just to avoid it, but because understanding it is the actual value you deliver to clients. The question isn’t “did I maintain access?” It’s “did the SOC detect my C2 infrastructure, and if not, what does that tell us about their detection coverage?”

I walk through this section with clients at every debrief. Here are the four main detection methods and what each tells you about the client’s defensive maturity: