Extracting config from a running sample
Skill meltedinhex/analyst-ai-pack/skills/extracting-config-from-a-running-sample
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.
npx -y skills add meltedinhex/analyst-ai-pack --skill extracting-config-from-a-running-sampleAssembled 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 an embedded malware configuration (C2 hosts, ports, campaign IDs, keys) from a process memory dump by locating decrypted config structures and decoding common obfuscation layers. Activates for requests to extract malware config from a memory dump, recover C2 settings from a running sample, or decode an in-memory configuration block.
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
2.8 KB, 444 tokens by cl100k_base, as published. Nobody here has run it
Extracting Config From a Running Sample
When to Use
- You have a process memory dump of a detonated sample whose config is decrypted in memory.
- You need to recover C2 endpoints, ports, campaign/botnet IDs, mutexes, and keys.
Do not use this to detonate the sample — it consumes a dump already captured in an isolated sandbox. For static-only config decryption, use the dedicated config-decryptor workflow.
Prerequisites
- A process memory dump (
.dmp/raw region) captured after the config was decrypted.
Safety & Handling
- Treat the dump as malicious data; read it inertly and defang recovered endpoints.
Workflow
Step 1: Hunt config indicators
python scripts/analyst.py hunt process.dmp
Scans for URLs, IPv4:port pairs, mutex-like tokens, base64 blobs, and printable key/value candidates in decrypted regions.
Step 2: Decode obfuscation layers
For candidate blobs, try common transforms (single-byte XOR brute force, base64) and re-scan the decoded output for endpoints.
Step 3: Structure and validate the config
Assemble recovered fields into a structured config and sanity-check (valid hosts, plausible ports, consistent campaign IDs).
Step 4: Defang and report
Defang hosts/URLs and document the offsets where the config was recovered.
Validation
- Recovered endpoints are real, parseable hosts/ports — not random byte noise.
- XOR/base64 decode is confirmed by the decoded output containing new endpoints/strings.
- The final config is defanged before sharing.
Pitfalls
- Mistaking unrelated in-memory URLs (browser, OS) for C2 — corroborate with the sample's region.
- Single-byte XOR brute force producing coincidental strings; require multiple corroborating hits.
- Reporting raw, live C2 endpoints without defanging.
References
- See
references/api-reference.mdfor the hunter/decoder. - ATT&CK T1140 and T1027 (linked in frontmatter).