Extracting cobalt strike beacon config

Skill meltedinhex/analyst-ai-pack/skills/extracting-cobalt-strike-beacon-config

An open agent-skills library for malware analysis, reverse engineering, and threat hunting - 118 curated, runnable skills mapped to MITRE ATT&CK, D3FEND, and CAR.

Install

npx -y skills add meltedinhex/analyst-ai-pack --skill extracting-cobalt-strike-beacon-config

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

19 stars19 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Extracts and interprets a Cobalt Strike Beacon configuration: decoding the encoded config block, recovering C2 servers, malleable profile fields, sleep/jitter, watermark, and pipe names to build IOCs and attribution leads. Activates for requests to analyze a Cobalt Strike beacon, extract beacon config, or interpret malleable C2 settings.

The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

3.6 KB, 647 tokens by cl100k_base, as published. Nobody here has run it

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).

Gives 0 of the 12 instructions most project setup skills give in 647 tokens

Counted across 999 of the 1,637 authors here whose files we hold, read 2026-08-06

ask one question at a timein 29 of 999, across 28 files
detect the package manager from lockfilesin 28 of 999, across 9 files
present findings to the userin 25 of 999, across 4 files
explore current repo statein 24 of 999, across 3 files
update the agent skills block in place if it existsin 24 of 999, across 3 files
install husky lint-staged and prettierin 23 of 999, across 4 files
create the lintstagedrc filein 22 of 999, across 3 files
commit all changed filesin 22 of 999, across 3 files
run lint-staged to verify it worksin 22 of 999, across 3 files
initialize huskyin 21 of 999, across 2 files
create the husky pre-commit filein 21 of 999, across 2 files
create a prettierrc file if missingin 21 of 999, across 2 files

Said here and by no other author read

brute-force the XOR key per sample
walk decoded entries to parse settings
recover C2 servers, URIs, User-Agent, sleep, and jitter
recover watermark, pipe names, and spawn-to settings
interpret URIs and headers for malleable profile details
emit network IOCs, host IOCs, and watermark

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.