Analyzing Malware

Analyzing Malware

The analysis is the easy part. The part that goes wrong is containment: a sample detonated on a machine that can reach production, or an IOC published that burns an active investigation. Get the environment right first.

When to Use

• Triaging a suspicious file, attachment, script, or dropped binary
• Determining a sample's capability, persistence, and command-and-control
• Extracting indicators for hunting and blocking
• Writing YARA or behavioural detection from a specimen
• Supporting an incident with sample-derived intelligence

When NOT to Use

• Writing malware, droppers, loaders, or evasion code — out of scope for

this skill regardless of framing

• Pure RE of a benign binary — use analyzing-binaries
• A raw shellcode blob with no PE/ELF header — use analyzing-binaries
• The sample's network capture — use analyzing-network-traffic
• Sweeping a whole web source tree for planted webshells (not one recovered

sample) — use hunting-web-backdoors

• Writing a YARA signature for the family — use writing-yara-rules
• The wider incident — use responding-to-incidents
• Turning findings into deployed rules — use engineering-detections
• **Pivoting sample IOCs into related infrastructure, actor tracking, or a

finished intel product** — use producing-threat-intelligence

Containment: Do This Before Anything Else

| Control | Requirement | | --- | --- | | Host | Disposable VM or dedicated bare-metal, snapshot taken before execution | | Network | Isolated segment; simulated services (INetSim/FakeNet-NG) by default | | Shares | No host folder sharing, no clipboard sharing, no mounted host drives | | Credentials | No real accounts, no domain join, no password manager | | Handling | Sample stored in a password-protected archive, extension neutered (.bin, .mal) | | Egress | Real internet only with an explicit decision and a plan for attribution leakage |

Live C2 contact tells the operator you are looking. On an active incident, do not resolve the C2 domain, submit the hash publicly, or upload the sample to a multi-scanner service until the incident lead approves it — public submission is a disclosure.

Static Triage — No Execution

# Identity, always first
sha256sum sample && file sample && du -h sample
# Fuzzy and import hashes for clustering against known families
ssdeep sample; tlsh sample   # Debian tlsh-tools ships /usr/bin/tlsh;
                             # built from upstream it is tlsh_unittest
python3 -c "import pefile;print(pefile.PE('sample').get_imphash())"

# Structure
pecheck sample                  # or: rabin2 -I / readelf -h
capa -v sample                  # capability detection mapped to ATT&CK — start here
floss sample                    # deobfuscated + stack strings, better than `strings`

# Packing and embedded content
binwalk -E sample               # entropy
binwalk -Me sample              # extract embedded objects

capa is the highest-value single command in this workflow: it turns a binary into a list of behaviours mapped to MITRE ATT&CK and MBC, which tells you whether deeper analysis is warranted at all.

Document-borne and script-borne samples:

oleid doc.xls && olevba --deobf doc.xls        # OLE macros
oledump.py doc.doc                              # stream-level inspection
msodde doc.docx                                 # DDE payloads
rtfobj doc.rtf                                  # embedded objects in RTF
pdfid file.pdf && pdf-parser -a file.pdf        # /JS /OpenAction /Launch

# Obfuscated scripts: normalize before reading
box-js payload.js
# PowerShell: decode -EncodedCommand, then unwrap the layers
echo '' | base64 -d | iconv -f UTF-16LE -t UTF-8

Most script malware is three layers of encoding around ten lines of logic. Deobfuscate mechanically rather than reading the obfuscated form.

Dynamic Analysis

Snapshot, detonate, observe, revert. Never analyze twice from a dirty state.

Baseline snapshot
  → start Procmon / Sysmon / inotify + tcpdump + INetSim
  → detonate with the right launcher (rundll32, wscript, mshta, Office)
  → observe 3-5 minutes, then interact (click, wait past sleep timers)
  → collect artifacts and memory
  → revert

What to collect and what each answers:

| Artifact | Tool | Answers | | --- | --- | --- | | Process tree | Sysmon E1, Procmon, execsnoop | Injection, LOLBin abuse, child spawns | | File and registry writes | Procmon, inotifywait | Drops, persistence, config | | Network | tcpdump, Wireshark, INetSim logs, mitmproxy | C2 endpoints, beacon interval, protocol | | Memory | DumpIt / procdump, then Volatility | Unpacked payload, injected code, keys | | Persistence | Autoruns, systemctl list-units, cron, LaunchAgents | Survival mechanism |

Recover the unpacked payload from memory rather than fighting the packer:

# After the sample unpacks itself, dump and carve
vol -f mem.raw windows.malfind          # injected/RWX regions
vol -f mem.raw windows.dumpfiles --pid 

Watch for sleep and evasion gates: many samples idle for minutes, check for a domain-joined host, count CPU cores, or look for analysis processes. If nothing happens, patch the check or hook Sleep/NtDelayExecution with Frida before concluding the sample is inert.

Capability Model

Structure findings against ATT&CK rather than as a narrative:

• Initial execution — how it was launched, what it needed
• Defense evasion — packing, injection, AMSI/ETW patching, signed-binary proxying
• Persistence — run keys, services, scheduled tasks, WMI subscriptions, cron, LaunchAgents
• Credential access — LSASS access, browser stores, keylogging
• Discovery — host, domain, and security-product enumeration
• Collection and exfiltration — what is staged, where, and how it leaves
• Command and control — protocol, encoding, jitter, fallback channels, kill date
• Impact — encryption, wiping, resource hijacking

For each, record the concrete evidence (address, API call, artifact) that supports the claim. A capability asserted without evidence is a guess, and guesses in a malware report drive bad response decisions.

Configuration and C2 Extraction

The config is the most valuable output — it feeds blocking, hunting, and attribution.

# Known families: use the community extractors first
python3 -m maco.extract sample          # MACO / CAPE / RATDecoders ecosystems
# Unknown: find the decode routine, then emulate it over the encrypted blob

Typical config contents: C2 URLs and fallbacks, campaign or botnet ID, RC4/AES key, mutex, sleep interval and jitter, install path, kill date. Extract all of them — campaign IDs and mutexes are often better hunting pivots than the C2, which rotates.

IOC and Detection Output

Rank indicators by how long they survive and how specific they are:

Hash            → precise, dies immediately (recompile)
C2 IP/domain    → useful now, rotates in days
Mutex / config  → survives rotation, family-specific
Behaviour/TTP   → survives redevelopment; write these

Write YARA against structure and code, not incidental strings:

rule Family_Loader_ConfigDecode
{
    meta:
        author      = "analyst"
        date        = "2026-07-26"
        description = "Loader config RC4 decode stub"
        hash        = ""
        reference   = ""
    strings:
        // The decode loop's constants, not a filename it happens to drop
        $decode = { 8A 04 0? 32 0? 88 0? 4? 3B ?? 72 }
        $mutex  = "Global\\" ascii
    condition:
        uint16(0) == 0x5A4D and filesize "      # scheme in the path is optional

This strips page boilerplate — roughly 78% fewer tokens on a prose page — and returns the full text rather than a summary, so you can grep it and trust a negative result.

Three things it is not for. Fetch JSON and API responses raw, because readability extraction mangles structured data. Fetch authenticated or JavaScript-rendered pages directly, because it retrieves them anonymously. And never route adversary infrastructure (phishing links, C2, malware hosting), client-owned hosts, or engagement URLs through it — the request leaves your machine to a third party, and for live adversary infrastructure it also tips off the operator.

Some sites block the extractor and return an error blob rather than the page — {"error":"Failed to fetch: 418 I'm a teapot"} from freedesktop.org, for instance. That is the fetch being refused, not the source saying the thing does not exist. Re-fetch the URL directly before drawing any conclusion from it.

References

• analyzing-binaries — disassembly, unpacking, and anti-analysis detail
• responding-to-incidents — scoping and eradication around the sample
• engineering-detections — turning capability into deployed rules
• MITRE ATT&CK and MBC (Malware Behavior Catalog) for classification
• capa, floss, oletools, Volatility 3, YARA as the core toolchain

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: EvilFreelancer
• Source: EvilFreelancer/secs
• License: Apache-2.0

Install and usage instructions live in the source repository linked above.