Every red team engagement I’ve run eventually comes down to one question: how do I maintain reliable, flexible communication with a compromised host without getting burned by the client’s detection tools? That’s what a command-and-control (C2) framework solves, and choosing and configuring the right one is one of the most consequential decisions in the entire engagement. I want to walk through what C2 frameworks actually do, how the major players compare, and how I approach setting one up for a realistic assessment.
What a Command-and-Control Framework Is
A C2 framework is the infrastructure and tooling that lets an operator (or an attacker) maintain communication with compromised systems, issue commands, and receive results — all while trying to blend in with legitimate network traffic and avoid detection. It’s the backbone of any red team engagement that goes beyond a single exploit-and-report exercise.
At its core, a C2 framework typically consists of:
- A server (team server) that operators connect to and that manages compromised implants
- An agent or implant deployed on the compromised host that communicates back to the server
- Listeners that define how communication happens (HTTP/S, DNS, SMB, etc.)
- Malleable profiles or traffic shaping that make communication resemble legitimate traffic
Why C2 Frameworks Matter
Getting a single reverse shell is trivial. Maintaining reliable, stealthy, multi-operator command and control across a multi-week engagement against a defended network is a completely different challenge. C2 frameworks solve problems like: what happens when the network blocks your callback domain, how do multiple operators collaborate on the same set of compromised hosts, and how do you make beacon traffic indistinguishable from normal business traffic.
Authorized Use Only
C2 frameworks are exactly the kind of tooling that should never touch a system without explicit written authorization. Every technique here assumes you’re working within a signed red team engagement or a personal lab environment you fully control.
Major C2 Frameworks Compared
Cobalt Strike
Cobalt Strike is the most widely known commercial C2 framework, valued for its mature malleable C2 profile system, team server collaboration features, and its long history of being the “industry standard” that blue teams train to detect. Its maturity is both a strength and a weakness — because it’s so widely used, its default indicators are heavily signatured, meaning effective use almost always requires customization of profiles and careful operational security.
./teamserver <server_ip> <password> <profile.profile>
Sliver
Sliver is a popular open-source C2 framework written in Go, designed with cross-platform support and a strong focus on flexibility. It supports multiple protocols (mTLS, HTTP/S, DNS, WireGuard) and has become a common choice for teams who want a capable, actively maintained alternative without licensing costs.
sliver > generate --http example.com --os windows
Mythic
Mythic is a modular, open-source C2 framework built around a plugin architecture, letting operators mix and match different agents (payload types) and C2 profiles depending on the engagement’s needs. Its web-based UI and Docker-based deployment make it relatively approachable to stand up.
Havoc
Havoc is a newer, actively developed open-source framework that’s gained popularity for being lightweight, modern, and less heavily signatured than more established frameworks — though “less signatured” is a moving target as detection vendors catch up.
Empire
PowerShell Empire (and its successor, the cross-language BC-Security fork) focuses heavily on post-exploitation within Windows environments, with deep PowerShell and C# integration. It’s a strong choice for engagements heavily focused on Windows/Active Directory environments.
Choosing the Right Framework for an Engagement
I base the choice on a few factors:
- Client’s defensive maturity. Highly mature blue teams with strong EDR require heavier customization regardless of framework — an out-of-the-box configuration of any tool will likely be caught.
- Engagement goals. A short assumed-breach engagement might not need the same operational security investment as a long-term, stealthy red team simulation.
- Team collaboration needs. Multi-operator engagements benefit from frameworks with strong team server support.
- Budget and licensing. Open-source frameworks like Sliver, Mythic, and Havoc remove licensing costs, which matters for smaller engagements or training environments.
Setting Up a Basic C2 Infrastructure
While specifics vary by framework, the general infrastructure pattern looks similar across all of them:
1. Provision Redirectors
Never point implant traffic directly at your team server. Use redirectors (often simple reverse proxies running on cloud VPS instances) to forward traffic to the team server while hiding its actual location.
# Example Apache mod_rewrite redirector concept
RewriteEngine On
RewriteRule ^/update/(.*)$ https://teamserver_ip/$1 [P]
2. Configure Malleable Profiles
Traffic shaping profiles define how your implant’s network traffic looks — what headers it sends, what URIs it uses, what timing/jitter it follows. A well-crafted profile makes beacon traffic resemble legitimate software (like a common CDN or analytics service) rather than obviously malicious traffic.
3. Generate and Test Payloads
Generate your implant, then test it against the client’s actual EDR product if a pre-engagement test environment is available — this catches obvious signature-based detections before you burn your access on the real engagement.
4. Establish Listener Diversity
Set up multiple communication channels (HTTP/S, DNS as a fallback) so that if one gets blocked mid-engagement, you have a way to re-establish contact without starting over.
A Practical Walkthrough Example
On a recent-style engagement (in a lab setting), the general flow looked like this:
- Stand up a team server on a cloud VPS, isolated from any personally identifying infrastructure.
- Configure a redirector in front of it, using a domain with an established reputation (not a freshly registered one that trips reputation-based filters).
- Build a malleable profile that mimics a common content delivery network’s traffic pattern.
- Generate a staged payload, test it in an isolated environment against a comparable EDR product.
- Deliver the payload through an authorized initial access vector (e.g., a simulated phishing email as agreed in scope).
- Once the implant checks in, use the C2’s built-in post-exploitation modules to move through the earlier phases: privilege escalation, credential harvesting, and lateral movement.
Common Mistakes and Troubleshooting
- Using default profiles unmodified. Nearly every major C2 framework’s default configuration is signatured by mainstream EDR products — customization isn’t optional for realistic engagements.
- Skipping redirectors. Pointing implants directly at your team server exposes its IP address the moment traffic is inspected, potentially ending the engagement early.
- Ignoring OPSEC around infrastructure registration. Freshly registered domains with no history are far more likely to be flagged by reputation-based filtering than aged, categorized domains.
- Overloading a single channel. Relying on one communication protocol means a single network control (like blocking a specific port or protocol) can end your access entirely.
- Not testing payloads before delivery. Assuming a payload will evade detection without any pre-engagement testing is a common and costly mistake.
Security Risks and Defensive Recommendations
For the blue team side, understanding how C2 frameworks operate directly informs detection strategy:
- Monitor for beaconing patterns — regular, low-and-slow callback intervals to external infrastructure.
- Invest in TLS inspection where feasible to detect malicious traffic hidden inside encrypted channels.
- Use DNS monitoring to catch DNS-based C2 channels, which are often less scrutinized than HTTP/S.
- Deploy EDR with behavioral detection rather than relying solely on known signatures, since C2 frameworks are frequently customized to evade static detection.
- Conduct regular purple team exercises using these same frameworks to validate detection coverage before a real attacker does.
Frequently Asked Questions
1. Do I need a commercial C2 framework to run an effective red team engagement? No — open-source frameworks like Sliver, Mythic, and Havoc are fully capable and widely used in professional engagements.
2. What is a malleable C2 profile? A configuration that shapes how an implant’s network traffic appears, allowing it to mimic legitimate traffic patterns and avoid signature-based detection.
3. Why are redirectors important? They hide the real location of the team server, protecting infrastructure and extending the operational lifespan of the engagement if traffic is inspected.
4. Can C2 frameworks be detected even with heavy customization? Yes — sophisticated EDR products use behavioral detection that can catch malicious activity regardless of network-level customization, which is why operational discipline matters as much as tooling.
5. Is DNS-based C2 still effective? It can be, particularly as a fallback channel, though modern DNS monitoring has significantly improved detection of anomalous query patterns.
6. How do I practice using C2 frameworks legally? Set up a personal lab with an isolated network, your own EDR trial product, and a C2 framework of choice — never test against systems you don’t own or have written authorization for.
7. What’s the biggest operational security mistake teams make with C2 infrastructure? Reusing infrastructure (domains, IPs, profiles) across multiple engagements, which allows defenders or threat intelligence platforms to fingerprint and flag it over time.
Conclusion
Command-and-control frameworks are the backbone of any serious red team engagement, turning a single compromised host into a sustained, collaborative operation that can realistically simulate an advanced adversary. Choosing the right framework depends on the engagement’s goals, the client’s defensive maturity, and your team’s operational needs — but regardless of which one you pick, the fundamentals stay the same: customize your profiles, protect your infrastructure with redirectors, test before you deliver, and always operate strictly within your authorized scope.