IOC Extraction & Reporting

The End Product Is a Report

Reverse engineering malware is only half the job. The other half is extracting IOCs and writing them up so defenders can act.

Indicators of Compromise (IOCs)

Type	Examples
Hashes	SHA-256 of the sample and dropped files
Network	C2 domains, IPs, URLs, ports
Host	mutex names, registry keys, file paths, service names
Behavioral	injection, scheduled task creation, specific API chains

Atomic IOCs are fixed values (a hash, a domain). Behavioral IOCs are patterns (a process spawning whoami then connecting out).

The Extraction Loop

For each finding, extract the actionable value:

• A Run-key string → the registry path is an IOC.
• A C2 URL → the domain is an IOC.
• A mutex name → the mutex is an IOC.

Collect them into a machine-readable list (STIX/OpenIOC/MISP) and a human-readable report.

Writing the Report

A good report answers:

1. What is it? — family, type, capability.
2. What does it do? — the behavior narrative.
3. How does it persist? — mechanism and location.
4. How does it communicate? — C2 endpoints and protocol.
5. How to detect? — IOCs and detection rules.
6. How to remove? — cleanup steps.

Be precise, cite evidence (addresses, strings, APIs), and mark anything uncertain.

Why It Matters

Your report becomes another analyst’s starting point, a detection engineer’s rule, and an incident responder’s checklist. Extraction is what makes reverse engineering useful.

Takeaway

Analysis without IOCs is a story with no action. Extract the values that let others defend.

Lab 17: IOC Extraction → IOC Extraction