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 behaviour.
• 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 behavioural findings enter the detection backlog with unusually strong provenance — you know the behaviour occurred in your environment, because you just analysed the thing that did it. Indicators go to intelligence with a decay policy 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.