Disguising Command-and-Control Traffic: Inside Malleable C2 Profiles

Hook

Your network traffic tells a story—and with the right profile, you can write fiction that passes for fact. Malleable C2 profiles are the screenplay for adversary simulation, making malicious traffic indistinguishable from Netflix binges or Slack notifications.

Context

Network defenders have gotten sophisticated. Modern security operations centers deploy behavioral analytics, anomaly detection, and threat intelligence feeds that can spot suspicious command-and-control (C2) patterns from miles away. Default tool configurations—with their predictable user agents, static URI patterns, and recognizable TLS certificates—get flagged almost instantly. The cat-and-mouse game between attackers and defenders has evolved beyond simple evasion into an art form of mimicry.

Cobalt Strike recognized this reality and introduced Malleable C2, a domain-specific language that lets red teamers rewrite how their Beacon payload communicates. Rather than accepting default HTTP headers or URI structures, operators can craft profiles that make C2 traffic look like legitimate applications. HarmJ0y's collection provides battle-tested examples of these profiles—templates that transform generic implant traffic into convincing imitations of everyday network activity. For authorized penetration testers and red teamers, these profiles represent years of offensive tradecraft distilled into reusable configurations.

Technical Insight

At its core, a Malleable C2 profile is a declarative specification written in a custom DSL that controls every aspect of Beacon's network communication. The profile structure separates concerns into distinct blocks: http-get defines how Beacon checks in for tasks, http-post controls how it sends data back, and various metadata transforms determine how information gets encoded on the wire.

Here's a simplified example from a profile that mimics legitimate browser traffic:

http-get {
    set uri "/api/v1/updates /news/feed /content/items";
    
    client {
        header "Accept" "application/json, text/javascript, */*";
        header "Accept-Encoding" "gzip, deflate";
        header "Referer" "https://www.example.com/";
        
        metadata {
            base64url;
            prepend "session=";
            header "Cookie";
        }
    }
    
    server {
        header "Content-Type" "application/json; charset=utf-8";
        header "X-Powered-By" "Express";
        
        output {
            base64;
            prepend "{\"data\":\"";
            append "\",\"status\":\"success\"}";
            print;
        }
    }
}

This profile does several clever things simultaneously. The set uri directive randomizes between multiple endpoints, preventing static signature matching. The client block adds headers that match what a modern single-page application would send. The metadata transform takes Beacon's session identifier, encodes it with base64url (no padding characters that might look suspicious), prepends "session=" to make it look like a session cookie, and stuffs it into the Cookie header where it belongs.

The transformation pipeline is particularly elegant. Functions like base64, base64url, netbios, netbiosu, and mask provide encoding primitives. Prepend and append let you wrap encoded data in legitimate-looking structures. The order matters—transformations execute sequentially, so you build up layers of obfuscation that also happen to look like real application protocols.

The http-post block follows similar patterns but handles data exfiltration. Here's where you might see profiles get creative with chunking data across multiple parameters, splitting payloads between headers and POST bodies, or embedding binary data in multipart form uploads that mimic file uploads:

http-post {
    set uri "/api/v1/telemetry";
    set verb "POST";
    
    client {
        header "Content-Type" "application/x-www-form-urlencoded";
        
        id {
            netbiosu;
            parameter "uid";
        }
        
        output {
            base64url;
            parameter "data";
        }
    }
    
    server {
        output {
            netbios;
            prepend "content=";
            append "&success=true";
            print;
        }
    }
}

Beyond HTTP configuration, profiles control SSL/TLS certificate attributes, DNS beacon behavior, and even SMB named pipe configurations for lateral movement. The http-stager block defines how the initial payload gets delivered, while stage blocks control the executable itself—things like obfuscating function calls, changing memory allocation patterns, or modifying how the payload gets injected into processes.

The profiles in HarmJ0y's repository demonstrate advanced techniques: some mimic popular CDNs with appropriate caching headers, others replicate SaaS application API patterns with OAuth-style bearer tokens in Authorization headers, and several incorporate time-based jitter and sleep patterns that match legitimate application polling intervals. The Amazon profile, for instance, replicates AWS SDK traffic patterns so thoroughly that it includes the x-amz-date header format and appropriate request signing header structures (though without actual cryptographic signing, naturally).

What makes these profiles particularly valuable is their demonstration of defensive evasion strategies—not just at the protocol level, but in understanding what network traffic actually looks like. They encode knowledge about HTTP/2 upgrade patterns, realistic User-Agent rotation, appropriate Accept-Language headers for geolocation, and the subtle details that distinguish machine-generated traffic from human browsing.

Gotcha

The most significant limitation is that these profiles are frozen in time, and detection evolves constantly. A profile that worked flawlessly in 2018 might get flagged immediately in 2024 because defenders have added that specific pattern to their threat intelligence feeds. User agents age poorly—"Mozilla/5.0 (compatible; MSIE 9.0)" screams "outdated tooling" in an era where IE11 is deprecated. You cannot simply download a profile and assume it provides effective evasion without testing against current security tooling.

There's also no validation framework included. Malleable C2 profiles can break your C2 infrastructure silently if misconfigured. Incompatible transform combinations can corrupt data, overly aggressive prepend/append operations can exceed header size limits, and URI patterns that don't match server configurations will cause 404 errors that defeat the whole point. Cobalt Strike's c2lint tool validates syntax but cannot tell you if your profile actually evades the specific EDR, NIDS, or proxy solutions deployed in your target environment. You need a lab environment that mirrors production security controls to test effectively, which many operators lack. The profiles are starting points requiring customization, not turnkey solutions.

Verdict

Use if: You're conducting authorized red team operations or penetration tests with a valid Cobalt Strike license and need proven starting points for customizing C2 traffic signatures. These profiles demonstrate professional tradecraft and save significant research time understanding what realistic traffic mimicry looks like. They're particularly valuable if you're learning Malleable C2 syntax and need working examples that showcase the DSL's capabilities. Security researchers building detection capabilities will also find value in understanding common evasion patterns. Skip if: You don't have Cobalt Strike access, aren't conducting authorized offensive security work, or need ready-to-use configurations without customization effort. These profiles require adaptation to current defensive landscapes and testing against target environment security controls. Blue teamers might find them interesting for threat modeling, but there are better resources specifically focused on detection engineering. If you're exploring C2 frameworks, consider open-source alternatives like Mythic or Sliver that don't require commercial licenses and include more modern traffic obfuscation approaches built-in.