⚠️ 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?
🎯 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
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 FLOW
# The beacon lifecycle on a compromised host
1. Beacon deployed → injects into process memory (e.g. explorer.exe)
2. Beacon sleeps for [sleep_interval] seconds ± [jitter]%
3. Beacon wakes → makes HTTPS callback to listener URL
6. 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.
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.
C2 CHANNEL COMPARISON
# HTTPS C2 — most common, hardest to block
Pros: Works in almost every environment, blends with web traffic
Cons: TLS fingerprinting (JA3) can identify framework, DPI inspection
Pros: DNS queries rarely blocked, works when all other egress is filtered
Cons: Very slow (limited data per query), high query volume suspicious
Detection: High-entropy subdomain queries, unusual query frequency patterns
# SMB C2 — for internal lateral movement
Pros: Uses normal Windows named pipes, works on non-internet hosts
Cons: Requires peer connection to internet-connected beacon relay
Detection: Unusual named pipe activity, lateral movement patterns in EDR
# mTLS C2 (Sliver) — mutual TLS authentication
Pros: Both sides authenticate — harder to infiltrate or redirect
Cons: Requires certificate deployment, harder to redirect through proxies
Detection: Certificate fingerprinting, Go binary patterns
🧠 EXERCISE 1 — THINK LIKE A HACKER (20 MIN · NO TOOLS)
Design a C2 Architecture for Three Different Target Environments
⏱️ 20 minutes · Pure analysis — no tools required
C2 decisions are architecture decisions. Before choosing a framework or channel, you analyse the target environment’s egress controls. Work through three scenarios and choose the right C2 approach for each.
SCENARIO A — Financial Services Firm
Network profile: Outbound HTTPS allowed to known domains only (allowlist).
Outbound DNS filtered to internal resolver.
No direct internet access from workstations — all traffic via proxy.
EDR: CrowdStrike Falcon deployed on all endpoints.
Questions:
1. Which C2 channel would you try first? Why?
2. What does “allowlist HTTPS only” mean for your listener domain?
3. How does the proxy requirement change your beacon configuration?
4. What CrowdStrike detection capabilities most threaten your C2 persistence?
SCENARIO B — Healthcare Provider
Network profile: Direct internet access from clinical workstations.
DNS to any resolver permitted.
Outbound ports: 80, 443, 53 open. All others blocked.
AV: Windows Defender only. No dedicated EDR.
Questions:
1. Which C2 channel gives you the most operational flexibility here?
2. Why might DNS C2 be worth considering for a secondary channel?
3. What detection capabilities does this organisation lack that most enterprises have?
4. How does “Windows Defender only” change your payload requirements vs CrowdStrike?
SCENARIO C — Post-Compromise Lateral Movement
You have an initial HTTPS beacon on a DMZ web server.
Target: internal HR workstations with no direct internet access.
The HR segment allows SMB from the DMZ server.
Questions:
1. Which C2 channel type reaches the internet-isolated HR hosts?
2. Describe the relay chain: how do HR host tasks get back to your team server?
3. What network monitoring would detect this communication pattern?
4. What’s the detection signature of SMB C2 in a Sysmon log?
✅ You just made the architectural decisions that determine whether a C2 deployment survives contact with the target’s defences. The financial services scenario is the hardest — the domain allowlist means your listener domain must be credible enough to get allowlisted, or you need to abuse a trusted domain. The healthcare scenario is the easiest — direct internet access with no EDR is the lowest-friction environment. The lateral movement scenario requires you to build relay chains, which is the operational C2 skill that Day 36 (Pivoting and Tunneling) covers in detail.
📸 Write your Scenario A answers and share in #ethical-hacking-course
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.
FRAMEWORK SELECTION — DECISION MATRIX
# When to use Cobalt Strike
→ Client has certification requirements specifying CS
→ Large team needs collaboration features (multiple operators)
→ Mature engagement where profile customisation time is available
→ CRTO exam prep (exam environment uses CS)
# When to use Sliver
→ Budget-constrained engagement or learning environment
→ Need multi-protocol flexibility (DNS C2, WireGuard)
→ Prefer open-source, inspectable codebase
→ Testing against environments with mature CS detection
# When to use Havoc
→ Shellcode-focused delivery requirement
→ Testing against environments where Sliver Go signatures are detected
→ C/C++ implant for lower-level control
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.
metadata → how beacon ID is embedded in the request (header, URI, body)
output → how task results are encoded in the response
set uri → the URI path the beacon calls — choose something plausible
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:
C2 DETECTION METHODS — DEFENDER PERSPECTIVE
# 1. JA3/JA3S TLS fingerprinting
What it detects: C2 framework TLS handshake signatures
Defence: direct syscalls, in-memory execution, sleep obfuscation
securityelites.com
C2 Detection — JA3/JA3S TLS Fingerprinting
Default Cobalt Strike JA3 Hash
72a7c4bb61b9b0000c1a1cc0000… (known, in all major blocklists)
Any NGFW or NDR with threat intel immediately flags this beacon
Custom Profile JA3 Hash
aaa0fb47cb1843a05d7eb3da7fd… (unique to this engagement)
Matches Firefox browser TLS profile — no signature match
How Defenders Use This
Zeek + JA3 plugin hashes every TLS handshake · Known C2 hashes → immediate alert
Custom profiles require behavioural detection (timing, DNS) not signature matching
📸 JA3 TLS fingerprinting — the fastest C2 detection method against operators running default framework configurations. Cobalt Strike’s default JA3 hash is published in threat intelligence feeds and blocklisted in every major network detection platform. A custom malleable C2 profile changes the TLS handshake parameters, generating a unique JA3 hash that doesn’t match any known signature. Defenders counter custom profiles with behavioural analysis — timing patterns, DNS query profiles, and EDR telemetry — which is why operators need multiple detection-evasion techniques operating simultaneously, not just profile customisation.
🌐 EXERCISE 2 — TRYHACKME (25 MIN)
Complete the C2 Frameworks TryHackMe Room
⏱️ 25 minutes · tryhackme.com — free account
TryHackMe has dedicated C2 framework rooms that let you interact with real C2 infrastructure in a controlled environment. Work through the concepts in a guided environment before building your own lab.
Step 1: Find the C2 room on TryHackMe
Go to: tryhackme.com/room/introtoc2
Read: Introduction to Command & Control room
Complete: the first 3 tasks covering architecture concepts
Step 2: If you have a THM subscription, try
tryhackme.com/room/redteamc2
Or search: “red team C2” in THM room search
Step 3: Answer these architecture questions while working through it
What is the difference between a listener and a handler?
What is a stager vs a full implant (stage-0 vs stage-1)?
Why do some operators use a stage-0 stager before deploying full C2?
What is the purpose of a sleep mask in modern beacons?
Step 4: Read the Sliver documentation
Go to: github.com/BishopFox/sliver/wiki
Read: Getting started, Multiplayer, C2 configuration
How many C2 channel types does Sliver support?
Which channel type is best for high-security environments?
Step 5: Research one public red team report that documents C2 usage
Search: “red team report C2 infrastructure site:github.com OR site:specterops.io”
What C2 framework did they use?
What detection method caught them (if they were detected)?
✅ The most important insight from that TryHackMe content is the stager concept. A full C2 implant can be several MB — too large for many initial delivery mechanisms. A stager is a tiny first-stage payload (often less than 4KB) whose only job is to download and execute the full implant in memory. Understanding this explains why initial access payloads look different from post-exploitation C2 tools, and why AV evasion at the delivery stage and persistence stage require different techniques.
📸 Screenshot your TryHackMe task completions. Share in #ethical-hacking-course
securityelites.com
Sliver C2 — Session Management Interface
sliver >
sessions
ID Name Transport RemoteAddress Username OS
——– —————- ——— —————– ——— ——-
1a2b3c PATIENT_HAMSTER https 10.10.14.5:52341 CORP\jsmith windows/amd64
4d5e6f ANGRY_WOLF https 10.10.14.8:48921 CORPdmin windows/amd64
📸 Sliver C2 session management interface showing two active HTTPS beacons on a target network. The session names (PATIENT_HAMSTER, ANGRY_WOLF) are Sliver’s randomly generated identifiers — each beacon gets a unique name at generation time. The ‘use’ command selects an active session for tasking. The whoami output confirms the compromised user’s domain account and — critically — their privilege set. SeDebugPrivilege and SeImpersonatePrivilege both indicate a path to SYSTEM-level privilege escalation via token impersonation techniques covered in Day 31.
⚡ EXERCISE 3 — KALI TERMINAL (20 MIN)
Set Up and Explore Sliver C2 Framework
⏱️ 20 minutes · Kali Linux · isolated lab environment only
Sliver is the open-source C2 framework you can run in your own lab environment right now. This exercise gets you through installation and the core interface — understanding the workflow before using it in a full lab scenario.
# ALL ACTIVITY MUST BE IN AN ISOLATED LAB — YOUR OWN VMs ONLY
Step 1: Install Sliver on Kali
curl https://sliver.sh/install | sudo bash
# Or: download from github.com/BishopFox/sliver/releases
sudo sliver-server
Step 2: Connect to the server
# In a second terminal:
sliver
# You’re now in the Sliver client
Step 3: Explore the interface
help # view all commands
jobs # show active listeners
sessions # show active sessions (none yet)
implants # show generated implants (none yet)
Step 4: Create an HTTPS listener
https -L 0.0.0.0 -l 8443
jobs # confirm listener is running
Step 5: Generate a test implant (do NOT deploy outside lab)
generate -h 127.0.0.1 -l 8443 -o windows -f exe -s /tmp/test.exe
# This generates an EXE configured to beacon to 127.0.0.1:8443
Step 7: Review the multiplayer setup documentation
players # would show connected operators
# Read: what makes Sliver useful for team operations?
✅ You just stood up a working C2 framework server, created a listener, and generated an implant in under 20 minutes — that’s the actual workflow time for initial C2 infrastructure on a real engagement. The key operational habits to build from here: always verify your listener is active before generating implants, always use jitter in production, and always run through a redirector rather than pointing beacons directly at your team server IP. Day 36 covers the pivoting techniques that let you extend C2 reach through network segments that don’t have direct internet access.
📸 Screenshot your Sliver ‘jobs’ output showing the active HTTPS listener. Share in #ethical-hacking-course
📋 C2 Frameworks Reference — Day 35
C2 componentsTeam server + Listener + Beacon/Implant
Beacon loopSleep → Wake → Callback → Receive task → Execute → Send result → Sleep
Sleep configsleep [seconds] [jitter%] — e.g. sleep 60 30
Cobalt StrikeCommercial, $5k+/yr, most mature, high detection rate on defaults
Malleable C2Profile transforms beacon traffic to look like legitimate app traffic
RedirectorDisposable VPS that forwards traffic — team server never in logs
Detection: JA3TLS fingerprint of C2 framework handshake — use custom SSL certs
Detection: timingRegular callback intervals — use high jitter, long sleep, domain rotation
Detection: EDRProcess injection sequence — use direct syscalls, sleep obfuscation
✅ Day 35 Complete — C2 Architecture Understood
Team server, listener, beacon, callback loop, malleable profiles, redirectors, detection methods — the complete C2 architecture picture. Day 36 covers pivoting and tunneling: extending your access through network segments that don’t have direct internet access, and routing C2 traffic through compromised hosts acting as proxies.
🧠 Day 35 Check
You configure a beacon with a 120-second sleep and 50% jitter. A defender is analysing network logs looking for regular callback patterns. What callback timing would they observe, and how does jitter affect their detection?
❓ C2 Frameworks FAQ
What is a C2 framework in ethical hacking?
A Command and Control framework maintains persistent communication with compromised hosts after initial access in authorised red team engagements. The framework has a team server, listener, and beacon/implant that communicate via callback loop. C2 frameworks simulate APT behaviour to test whether defenders can detect and respond to sustained attacks.
What is the difference between Cobalt Strike and Sliver?
Cobalt Strike: commercial ($5k+/yr), most mature features, widely used but highly signatured. Sliver: free, open-source, Go-based, supports HTTP/S/DNS/mTLS/WireGuard, actively maintained by BishopFox. For most learning and budget-conscious engagements, Sliver matches Cobalt Strike’s core capabilities. For enterprise red teams or CRTO exam prep, Cobalt Strike remains the standard.
What is malleable C2?
A profile script that transforms C2 beacon network traffic to look like legitimate application traffic. Profiles define HTTP request URIs, headers, cookies, body structure, and response format — making beacon callbacks appear to come from known-good applications like Windows Update or Microsoft Teams. Defeats network-based detection that looks for known C2 traffic signatures.
Is studying C2 frameworks legal?
Studying C2 frameworks and running them in isolated lab environments is legal and essential for cybersecurity professionals. Deploying against systems without written authorisation is illegal. All exercises in this course use isolated lab environments. C2 knowledge is required for OSCP, CRTO, and professional red team work.
How do defenders detect C2 traffic?
Four main methods: JA3/JA3S TLS fingerprinting (framework-specific handshake patterns), beacon timing analysis (regular callback intervals), DNS anomaly detection (high-entropy subdomain queries at regular intervals for DNS C2), and EDR behavioral detection (process injection sequences, memory-resident shellcode patterns). Multi-method detection is more effective than any single approach.
What certifications cover C2 frameworks?
CRTO (Zero-Point Security) is the most focused — built around Cobalt Strike in an AD lab. CRTE (Altered Security) covers advanced red team operations. OSCP covers fundamentals but not commercial C2 frameworks specifically. For defenders, SANS SEC530 and SEC699 cover C2 detection and threat hunting in depth.
← Previous
Day 34 — Payload Obfuscation
Next →
Day 36 — Pivoting & Tunneling
📚 Further Reading
Day 34 — Payload Obfuscation— The techniques that get C2 beacons past EDR at delivery time — the prerequisite skill for C2 operations in mature environments.
Day 33 — AV Evasion Basics— C2 implants require AV evasion to survive on disk and in memory. The techniques from Day 33 combine directly with beacon configuration on Day 35.
AI-Powered Cyberattacks 2026— How threat actors are using AI to generate polymorphic C2 payloads and automate lateral movement decisions — the evolution of C2 operations beyond manual red team tooling.
Sliver C2 Framework — GitHub— The official Sliver repository with full documentation, release notes, and the wiki covering every C2 channel configuration and implant generation option.
Cobalt Strike — Malleable C2 Documentation— The official malleable C2 profile reference covering every directive, the full profile syntax, and example profiles — the authoritative source for understanding traffic blending.
ME
Mr Elite
Owner, SecurityElites.com
The most valuable C2 lesson I’ve learned isn’t on the offensive side — it’s the debrief conversation. When I show a CISO their SOC’s network logs during the engagement period and point to the beacon callbacks that were there for two weeks without detection, the room goes quiet in a specific way. It’s the moment the abstract risk becomes concrete. That’s the value of red team C2 operations: not the access you gained, but the detection gap you documented. Understanding C2 architecture well enough to operate it professionally also means understanding it well enough to explain exactly what defenders should have seen and why they missed it. That explanation is worth more to a client than the technical finding alone.
1 Comment