Cobalt Strike Beacon Config: What It Tells Responders
Extract a Cobalt Strike beacon configuration statically and turn each field — C2, sleep, pipe names, spawn-to, watermark, public key — into a hunt.
TL;DR. A Cobalt Strike beacon carries its whole configuration inside the binary: where it calls home, how often, how it hides, which process it injects into. Decoding it statically turns one sample into a list of concrete hunts across proxy logs, EDR telemetry and other hosts. The PE Parser decodes it in the browser and shows it in a Config tab.
Why the configuration matters
When a beacon turns up during an investigation, the binary itself is the least interesting part: it is a generic implant. What makes it this intrusion is the configuration the operator baked in — the C2 domains, the URIs, the user agent, the named pipes, the process used for post-exploitation jobs. Every one of those values is a pivot you can search for elsewhere, and none of them requires running the sample to obtain.
Where the configuration lives
The beacon stores its settings as a table of numbered entries (type, length, value), XOR-encoded with a single byte: 0x69 in older releases and 0x2e in 4.x. Loaders often add a layer on top — the beacon DLL XOR-encoded with a four-byte key inside a stager, or compressed in an overlay. The PE Parser looks for the table in the file itself, in the layers it unpacks (UPX) and in the executables it carves out of the file, so the configuration is found wherever the beacon sits.
Small stagers are different: they don't contain the beacon, only enough shellcode to download it. For those the tool reports the stager type (reverse_http, reverse_https, reverse_tcp) and what it can read from the shellcode: host, port, URI and user agent.
Reading the fields
| Field | What it means | Where to hunt |
|---|---|---|
| Beacon type | HTTP, HTTPS, DNS, SMB (named pipe) or TCP | Which logs to search first |
| C2 servers | Host names and URIs the beacon contacts | Proxy, DNS and firewall logs; passive DNS |
| Port | Port of the C2 listener | Firewall and netflow |
| Sleep / jitter | Callback interval and its random spread | Beaconing detection in network logs |
| User agent, HTTP POST URI | What the requests look like | Proxy logs, often very distinctive |
| Pipe name | Named pipe used by SMB beacons and post-ex jobs | Named-pipe events on hosts (for example Sysmon events 17 and 18) |
| Spawn to (x86 / x64) | Process started for post-exploitation jobs | Process creation: that process with no arguments, started by an unusual parent |
| Watermark | Number tied to the licence that built the beacon | Clustering samples across incidents |
| Public key (SHA-256) | Hash of the team server's key | Clustering beacons served by the same team server |
A few practical notes:
- The spawn-to process is one of the best host-side hunts. The default is
rundll32.exe; seeingrundll32.exestart without a DLL argument is rarely legitimate. - Sleep and jitter tell you what beaconing looks like on the wire: a 60-second sleep with 20 % jitter means a callback every 48 to 72 seconds.
- The watermark links samples built from the same installation. Leaked and cracked copies share a few common values, so treat a matching watermark as a lead, not attribution.
- The public key hash is often a better clustering key than the watermark: beacons generated by the same team server share it.
Extracting it with the PE Parser
- Drop the file (or a ZIP of the collection) on the PE Parser. Nothing is uploaded or run.
- If a configuration is found, the file gets a high-severity indicator, Malware configuration decoded, and a Config tab appears.
- The tab lists the C2 entries first, then every decoded setting, with the offset where the table was found — click it to open the hex view on those bytes.
- The IOCs tab picks up the C2 URLs and host names, the user agent and the pipe name, ready to export as CSV, a MISP event or a STIX 2.1 bundle (exporting IOCs).
The same tab handles a few other families whose configuration can be read statically: AsyncRAT and its forks (DcRat, VenomRAT), QuasarRAT, njRAT and Remcos.
Limits
- Packed or encrypted loaders. If the beacon is wrapped in a custom crypter, the configuration only appears after that layer is removed, usually dynamically in a sandbox. UPX and simple XOR or compression layers are handled; custom crypters are not.
- Version drift. The format has changed over releases and builders can be modified. The extractor checks the table's structure strictly so it doesn't invent fields; an unusual build may simply not be decoded.
- Decoys. Operators sometimes leave misleading values (fake hosts, a cracked watermark). Confirm with network evidence before acting on a single field.
- Not proof of malice by itself. Red teams use Cobalt Strike legitimately. A decoded configuration tells you what the binary is, not who ran it — check with your red team before escalating.