A Practical Guide to Malware Analysis

When a suspicious file lands on an analyst's desk, the goal is not curiosity — it is answers that other people can act on. What does this sample do? How does it persist? What does it talk to? How do we detect it everywhere else in the estate, and how do we make sure it never runs again? Malware analysis is the systematic process of extracting those answers, and it follows a progression from cheap, fast techniques to expensive, deep ones. You escalate only as far as the situation demands, and you do all of it inside an environment built to contain a live threat.

Safety first — the isolated sandbox

Before any of the analysis techniques matter, the environment does. You are about to run hostile code, so it must execute somewhere it can do no harm and phone nowhere it should not. In practice that means a dedicated virtual machine with no access to production, snapshots so you can revert to a clean state after each run, and carefully controlled networking — either fully isolated or routed through a simulated internet so the sample believes it has reached its command-and-control server while you observe. Analysts also assume the malware is watching: many samples detect virtualisation or analysis tooling and change behaviour, so the sandbox has to be hardened against these checks. Getting this wrong turns an analysis exercise into an incident.

Triage

Triage is the fast first pass that decides how much effort a sample deserves. You compute cryptographic hashes and check them against threat-intelligence sources and prior sightings; a known-bad hash may answer the whole question in seconds. You identify the file type, inspect basic metadata, and note whether the file is packed or obfuscated. The output of triage is a decision: is this a commodity sample already well-documented, or something novel that warrants deeper work?

Static analysis — examining without executing

Static analysis inspects the file at rest. Extracting printable strings often reveals URLs, file paths, registry keys, and error messages that hint at capability. Parsing the file structure — for a Windows executable, its PE headers, sections, and imported functions — shows which system APIs the code intends to call, which is a strong signal of behaviour: imports for network sockets, process injection, or cryptography tell a story. The recurring obstacle is packing: malware is frequently compressed or encrypted so that meaningful strings and imports only appear once it unpacks itself in memory, which is precisely why static analysis alone is rarely enough.

The static/dynamic pincer

Static and dynamic analysis are complementary, not competing. Static gives you a map of what the code could do without ever running it; dynamic shows what it actually does but only along the path it happened to take. Used together, each covers the other's blind spot.

Dynamic analysis — watching it run

Dynamic analysis executes the sample in the sandbox and records what it does. Instrumentation captures the filesystem changes it makes, the registry keys it creates for persistence, the processes it spawns or injects into, and — often the most valuable part — the network traffic it generates. A sample reaching out to a specific domain or beaconing on an interval hands you concrete indicators of compromise immediately. Because the malware only exercises the branches its logic chooses, analysts sometimes nudge it: simulating the date, user interaction, or network responses it is waiting for.

Behavioural analysis and reverse engineering

Behavioural analysis steps back from individual events to characterise intent and pattern: is this a downloader that stages a second payload, ransomware enumerating and encrypting files, or an information-stealer harvesting credentials? Mapping observed actions to a framework such as MITRE ATT&CK turns a pile of events into a coherent narrative of tactics and techniques. When the answers still are not clear — or the sample is heavily obfuscated, novel, or important — analysts escalate to reverse engineering: disassembling and, where possible, decompiling the code to read its logic directly. This is the slowest and most skilled tier, but it is the only way to fully understand encryption routines, custom protocols, or dormant capabilities that never triggered during dynamic runs.

You reverse-engineer only as deep as the decision requires. The goal is actionable understanding, not a line-by-line translation of every sample that crosses your desk.

Producing IOCs and YARA rules

Analysis that stays in the analyst's head is wasted. The deliverables are what let the rest of the organisation act. Indicators of compromise — hashes, domains, IP addresses, file paths, registry keys — feed straight into detection and blocking. YARA rules generalise beyond a single hash: by describing distinctive strings or byte patterns, a well-written rule catches an entire malware family, including variants you have never seen. And the report ties it together for both technical responders and decision-makers, so the effort spent understanding one sample hardens the whole environment against it.