Extracting Cobalt Strike Beacon Config

When to Use

• You have a suspected Cobalt Strike Beacon (PE, DLL, shellcode, or extracted blob) and need its configuration.
• You want C2 servers, the malleable profile shape, sleep/jitter, watermark, and named pipes.
• You are building network IOCs and attribution leads from a beacon.

Do not use an extracted config alone for hard attribution — watermarks can be shared or cracked. Treat it as one signal among several.

Prerequisites

• The beacon payload (or a memory dump containing it) in neutralized form inside the lab.
• Familiarity with Cobalt Strike's encoded config block (commonly XOR-encoded with 0x2e in older versions, 0x69 in others; varies by version).

Safety & Handling

• Static extraction only; do not run the beacon.
• Defang recovered C2 hosts/URIs before sharing.

Workflow

Step 1: Locate the encoded config block

Beacon stores settings as a packed, XOR-encoded table of TLV-like entries. Brute the single-byte XOR key by scanning for the decoded table's known opening bytes (the first setting index/type/length pattern).

Step 2: Decode and parse settings

Once the key is found, walk the entries. Each has an index (setting type), a type (short/int/string), and a length. The script decodes and maps known indices:

python scripts/analyst.py parse beacon.bin

Step 3: Recover key fields

Pull the high-value settings:

C2 servers / GET-URI / POST-URI    -> network IOCs
User-Agent                         -> detection signal
Sleep time / jitter                -> beacon cadence
Watermark                          -> license/team grouping lead
Pipe name / process-inject targets -> host IOCs
Spawn-to / DNS settings            -> behavior

Step 4: Interpret the malleable profile

The URIs, headers, and transform settings reveal which malleable C2 profile the operator used (e.g. masquerading as a known web service) — useful for network detection.

Step 5: Build IOCs

Emit network IOCs (hosts, URIs, UA), host IOCs (pipe names), and the watermark for tracking.

Validation

• The recovered C2 host(s) and URIs are well-formed and consistent with the profile.
• Sleep/jitter values are plausible and match any observed beaconing intervals.
• The same config reproduces from an independent extractor or memory copy.

Pitfalls

• Hardcoding one XOR key — it varies across versions; brute-force per sample.
• Confusing a watermark match with attribution; cracked/leaked kits share watermarks.
• Stopping at the first C2 when the config lists multiple/backup servers.

References

• See references/api-reference.md for the config parser.
• Cobalt Strike malleable C2 docs and community parser concepts (linked in frontmatter).