Malware Analysis & Reverse Engineering

Malware analysis answers a question the rest of the investigation depends on: what could this actually do. Not what its family typically does, not what a vendor write-up says — what this sample, in this environment, was capable of.

Most of the value arrives early. Full reverse engineering is expensive and rarely the fastest route to the answer an incident needs.

Triage first

Before opening a disassembler, establish what cheap analysis already tells you:

• File properties — type, size, compile timestamp, signatures. Timestamps are forgeable but inconsistency is itself informative.
• Strings — URLs, paths, commands, error messages. Frequently sufficient to identify capability and infrastructure outright.
• Packing and entropy — high entropy with few imports means packed, and the import table becomes meaningless until unpacked.
• Imports — the API surface bounds capability. Networking, crypto, process injection and persistence APIs each imply a class of behavior.
• Similarity — fuzzy hashing and import hashing against known samples. If this is a known family, published analysis may answer the question in minutes.

Triage often ends the exercise. If strings yield a C2 domain and the imports show file encryption, you have what response needs and deep analysis is a lower priority than scoping.

Detonation safety and OPSEC

Dynamic analysis means running it, which needs discipline:

• Isolated network, no path to production, no shared credentials, no domain-joined analysis host.
• Snapshot before, revert after. Every time, including “quick looks”.
• Expect anti-analysis. Sandbox detection, timing checks, and dormancy are standard — a sample doing nothing may be detecting you rather than being benign.

The OPSEC point is the one most often missed, and it belongs alongside collection tradecraft:

Public sandboxes are public

Uploading a sample to a public multi-scanner or sandbox makes it searchable. Adversaries monitor these services for their own tooling. An upload can tell an active intruder that they are detected, and samples frequently contain victim-identifying data — internal paths, hostnames, embedded configuration, filenames — which discloses who is investigating. During a live incident, prefer private analysis, and treat “just check the hash” as a decision with consequences rather than a free action.

Hash lookups are lower-risk than uploads but not zero — a first-ever query for an adversary’s unique hash is itself a signal on some platforms.

Unpacking and RE workflow

When deeper analysis is warranted, the standard progression: identify the packer, unpack (usually dynamically — run until the real payload is in memory, then dump), rebuild imports, then work statically on the unpacked binary.

Time-box it. Reverse engineering can absorb unlimited effort, and during an incident the question is rarely “how does this work in full” but “what does response need to know”. Prioritise capability and indicators; leave completeness for afterwards, if at all.

Capability assessment

The output response actually needs, expressed as what the sample can do in your environment:

Question	Why response needs it
Does it spread, and how?	Determines scoping and containment urgency
Does it persist, and where?	Determines whether rebuild is sufficient
Does it steal credentials?	Triggers identity containment
Does it exfiltrate, and what?	Drives notification obligations
Does it destroy or encrypt?	Changes recovery strategy entirely
What does it talk to?	Blocking, and infrastructure pivoting

Answer against the environment, not the family. Ransomware whose encryption routine requires privileges the account didn’t hold is a different incident from one that ran as domain admin.

Extracting signatures that outlive the sample

Indicators age at very different rates, and this is where malware analysis pays forward into detection:

• Hashes — precise, worthless after a recompile. Hours to days.
• Network infrastructure — domains and IPs rotate. Days to weeks.
• Behaviour — process lineage, injection technique, persistence mechanism, C2 pattern. Months to years, because changing it costs the adversary real work.

Push analysis toward the durable end. A rule matching a hash catches one sample; a rule matching the persistence mechanism catches the family and often its neighbours.

The handoff should be explicit: durable behavioral findings enter the detection backlog with unusually strong provenance — you know the behavior occurred in your environment, because you just analyzed the thing that did it. Indicators go to intelligence with a decay policy attached.

How it looks in practice

The lab is built once and reverted endlessly: a hypervisor where snapshot-and-revert is the default workflow, a Windows analysis image (FLARE VM is the standard kit) with REMnux beside it for Linux and network tooling, on a segment whose only route out is a simulated internet — INetSim or a controlled proxy, never the corporate LAN. Samples go through a private sandbox first (CAPE self-hosted, or a commercial service whose terms keep submissions private), with public multi-scanners reserved for samples already burned. Static work happens in Ghidra unless the team carries IDA history. The outputs are as standardized as the lab: a capability assessment against the table above, YARA rules pitched at the behavioral end of the durability spectrum, and indicators handed to intelligence with an explicit decay date attached.

Where this connects

Samples arrive from forensics, particularly memory, where injected code that never touched disk is recoverable. Capability assessment drives response decisions. Behavioural signatures become detections. And the vulnerability the sample exploited is an AppSec finding with a proven exploit attached — the most persuasive kind.