Cobalt Strike Beacon Concepts

Cobalt Strike is a commercial penetration testing tool that simulates advanced persistent threats (APTs). Its core agent is called a Beacon. A Beacon is a payload that runs on a compromised host and provides command and control (C2) capabilities. Unlike a simple reverse shell, Beacons are designed for stealth, flexibility, and resilience. They communicate with a C2 server using configurable profiles that mimic legitimate traffic (e.g., HTTP, HTTPS, DNS, SMB). Beacons can operate in asynchronous mode (poll-based) or synchronous mode (interactive), but the default and most common mode is asynchronous to avoid detection.

Beacons support several communication protocols:

Cobalt Strike offers two types of Beacon payloads:

Malleable C2 profiles are configuration files that define how the Beacon communicates. They control:

Example Malleable C2 profile snippet:

http-get {
    set uri "/images/logo.png";
    client {
        header "Accept" "image/png";
        metadata {
            base64url;
            prepend "session=";
            header "Cookie";
        }
    }
    server {
        header "Content-Type" "image/png";
        output {
            base64;
            print;
        }
    }
}

This profile configures the Beacon to make GET requests to /images/logo.png, include a base64url-encoded session ID in a Cookie header, and expect a base64-encoded response with Content-Type image/png.

The Beacon's sleep interval determines how often it checks in with the C2 server. Default is 60 seconds. Jitter is a percentage that randomizes the sleep interval to avoid predictable patterns. For example, sleep 60s with jitter 30% means the actual check-in time is between 42s and 78s (60 ± 18s). This makes traffic analysis harder.

Once a Beacon is active, operators interact with it via the Cobalt Strike client. Common commands include:

Beacons can be configured to persist via various mechanisms:

Privilege escalation can be achieved using built-in exploits (e.g., MS16-032, MS17-010) or by leveraging tools like PowerUp.

Defenders detect Beacons by:

Evasion techniques include:

In the Cobalt Strike client, operators can configure Beacons via:

A red team is hired to test a large financial institution's defenses. The team uses Cobalt Strike with a custom Malleable C2 profile that mimics the institution's internal application traffic (e.g., requests to /api/status with specific headers). They deploy stageless Beacons via a phishing campaign. The Beacons use HTTPS with a valid certificate from a trusted CA (purchased for the engagement). The sleep interval is set to 120 seconds with 25% jitter to avoid pattern detection. The team uses DNS beacons as a fallback if HTTP is blocked. During the engagement, they pivot through multiple systems using SMB beacons for lateral movement. The key challenge is to avoid triggering the SOC's alerts. They use sleep masking and process injection to evade memory scanners. The engagement reveals that the institution's network monitoring tools flag anomalous user agents but miss custom headers, highlighting the importance of Malleable C2 profiles.

A penetration tester is assessing a healthcare provider's network. The tester uses Cobalt Strike to simulate an APT. The Beacon is configured to use DNS over HTTPS (DoH) to bypass DNS monitoring. The tester uses a stageless payload to avoid the second-stage download. The Beacon's C2 domain is a subdomain of a legitimate service (e.g., updates.healthcare-org.com) that resolves to the tester's server. The tester uses the spawnto command to inject into a trusted process (e.g., svchost.exe). During the test, the tester dumps hashes using Mimikatz and uses pass-the-hash to move to a domain controller. The Beacon's sleep is set to 5 minutes to minimize traffic. The tester encounters issues with the organization's application whitelisting, which blocks unknown executables. To bypass this, the tester uses PowerShell-based payloads that execute in memory. The test successfully demonstrates that the organization's endpoint protection does not detect in-memory threats.

A common mistake is using default Malleable C2 profiles, which are well-known to defenders. For example, the default HTTP profile uses a User-Agent of 'Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0)' which is outdated and easily flagged. Another issue is setting jitter to 0%, creating a predictable check-in pattern that can be detected by time-based analysis. Additionally, using self-signed certificates for HTTPS triggers warnings in modern browsers and can be flagged by network monitors. Operators must also be careful with DNS beacon sizes; if the encoded data exceeds 255 bytes, it must be split across multiple queries, which can appear anomalous. Finally, failing to use sleep masking leaves the Beacon's memory readable, allowing defenders to dump and analyze the payload.