📰 Originally published on SecurityElites — the canonical, fully-updated version of this article.
🎯 ETHICAL HACKING COURSE
FREE
Part of the Free Ethical Hacking Course — 100 Days
Day 35 of 100 · 35% complete
⚠️ Authorised Engagements Only: C2 frameworks are professional red team tools used in authorised penetration tests and adversary simulations. Deploying C2 infrastructure against systems you don’t have explicit written authorisation to test is illegal under computer fraud laws in every jurisdiction. This material is educational — covering how C2 works and how defenders detect it. All lab exercises use isolated environments.
Every Advanced Persistent Threat simulation, every CRTO exam, every mature red team engagement operates through a C2 framework. If you don’t understand how command and control works — architecturally, not just conceptually — you can’t do red team work at a professional level, and you can’t hunt APT-style intrusions as a defender.
Here’s the dual value of this material: understanding C2 from the offensive side teaches you exactly what defenders need to detect. Malleable C2 profiles exist because network-based detection exists — you can’t understand one without the other. The red teams who get caught on engagements are the ones who skipped this content and ran default configurations. The threat hunters who find APT C2 infrastructure are the ones who know what beacon timing patterns look like.
Day 35 covers the architecture, the major frameworks, how traffic blending works, and — critically — how defenders detect and disrupt C2 channels. This is the material that separates operators who understand their tools from operators who just use them.
Which C2 framework are you most interested in learning?
Cobalt Strike — industry standard Sliver — open source alternative Havoc — newer framework Build my own custom implant
🎯 What You’ll Master in Day 35
C2 architecture: team server, listener, beacon/implant — how the callback loop works
Cobalt Strike vs Sliver vs Havoc — differences that matter for real engagements
Malleable C2 profiles — how traffic blending defeats network-based detection
C2 infrastructure setup with redirectors — why the team server never touches targets directly
Detection methods: JA3 fingerprinting, DNS analysis, EDR telemetry, beacon timing
⏱️ Day 35 · 3 exercises · Red team architecture understanding ### ✅ Prerequisites - Payload obfuscation from Day 34 — C2 implants need obfuscation to survive initial delivery; these skills combine - AV evasion from Day 33 — C2 beacons must bypass endpoint detection to maintain persistence - Windows Active Directory basics from Day 23 — C2 post-exploitation targets AD environments in most enterprise engagements ### 📋 C2 Frameworks Day 35 Contents 1. C2 Architecture — Team Server, Listener, Beacon 2. C2 Channel Types — HTTP/S, DNS, SMB 3. Major C2 Frameworks — Cobalt Strike, Sliver, Havoc 4. Malleable C2 — Traffic Blending and Profile Design 5. Red Team Infrastructure — Redirectors and Operational Security 6. Defender Detection Methods — What Actually Gets C2 Caught ## 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 CALLBACK LOOP — SIMPLIFIED FLOWCopy
The beacon lifecycle on a compromised host
- Beacon deployed → injects into process memory (e.g. explorer.exe)
- Beacon sleeps for [sleep_interval] seconds ± [jitter]%
- Beacon wakes → makes HTTPS callback to listener URL
- Listener checks task queue → sends staged task if present
- Beacon executes task → collects output
- Beacon sends result in next callback → returns to sleep
Timing configuration (Cobalt Strike example)
sleep 60 30 # 60 second sleep, 30% jitter
Callbacks arrive every 42-78 seconds (unpredictable pattern)
Why this defeats connection-based detection
No persistent open socket — only brief HTTPS requests
Callback looks like normal web browsing traffic
Jitter prevents statistical timing fingerprinting
securityelites.com
C2 Infrastructure — Redirector Architecture
TEAM SERVER
Private VPS
192.168.x.x
Cobalt Strike / Sliver
← HTTPS
operator control
REDIRECTOR
Cloud VPS
185.x.x.x
Nginx + mod_rewrite
← HTTPS
beacon callbacks
TARGET
Compromised host
10.x.x.x
Beacon in memory
Key:
If defenders identify and block the redirector IP, team server is unaffected. Spin up a new redirector in minutes.
📸 C2 redirector architecture showing the separation between team server and compromised target. The redirector acts as a disposable intermediary — all beacon callbacks hit the redirector IP, which forwards them to the team server. If incident response identifies the redirector IP from network logs, blocking it doesn’t expose or disrupt the team server. Professional red teams use at least two redirectors per engagement, hosted in different cloud regions, with the team server on a separate private network never directly reachable from the internet.
📖 Read the complete guide on SecurityElites
This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on SecurityElites →
This article was originally written and published by the SecurityElites team. For more cybersecurity tutorials, ethical hacking guides, and CTF walk-throughs, visit SecurityElites.
Top comments (0)