reverse-skills-max/vendor-new/analyst-ai-pack/skills/building-config-extractors/SKILL.md

name, description, domain, subdomain, tags, version, author, license, mitre_attack, d3fend, references

name	description	domain	subdomain	tags	version	author	license	mitre_attack	d3fend	references
building-config-extractors	Builds reusable malware configuration extractors by applying a declarative JSON spec (offsets, decode layers, field definitions) to a sample to produce structured, defanged config. Activates for requests to build a config extractor, write a reusable family config parser, or run a spec-driven configuration extraction.	cybersecurity	reverse-engineering	reverse-engineering config-extraction automation tooling c2	1.0.0	analyst-ai-pack	Apache-2.0	T1140 T1027 T1071	D3-SDA D3-DA	MITRE ATT&CK T1140 Deobfuscate/Decode Files or Information — https://attack.mitre.org/techniques/T1140/ MWCP / config-extractor framework concepts — https://github.com/Defense-Cyber-Crime-Center/DC3-MWCP

Building Config Extractors

When to Use

• You have reversed a family's config format and want a reusable, declarative extractor instead of one-off scripts.
• You need to apply a spec (offset, XOR/base64 layers, field map) to many samples and emit structured, defanged config.

Do not use a spec built for one variant blindly on another — re-verify offsets/keys per variant. This skill reads samples statically and executes nothing.

Prerequisites

• A reversed understanding of the config (location, decode layers, fields) expressed as a JSON spec.

Safety & Handling

• Read bytes statically; defang recovered endpoints in output.

Workflow

Step 1: Write the extraction spec

Define a JSON spec: blob offset/length (or a marker to search), ordered decode layers (xor with key, base64), and fields (name, offset, length, type: str/u16/u32/ipv4).

Step 2: Run the extractor

python scripts/analyst.py extract sample.bin --spec family.json

Locates the blob, applies decode layers, parses fields, and defangs URL/IP fields.

Step 3: Validate output

Confirm fields are plausible (valid hosts, ports, IDs); adjust the spec as needed.

Step 4: Reuse

Store the spec per family and apply across the corpus.

Validation

• The spec round-trips on a known sample to the expected config.
• Decode layers are applied in order and produce readable output.
• URL/IP fields are defanged in the emitted config.

Pitfalls

• Hardcoding a variant-specific offset that shifts in other builds — prefer markers.
• Wrong field endianness (u16/u32 little vs big) producing garbage ports.
• Forgetting a decode layer (base64 over XOR) and parsing ciphertext as fields.

References

• See references/api-reference.md for the extractor engine.
• ATT&CK T1140 and config-extractor framework concepts (linked in frontmatter).