Reverse Engineering Basics: Static and Dynamic Malware Analysis

Reverse engineering a binary means working out what it does without source code. In security work the goal is almost never full comprehension — it is answering specific questions: what does this sample do, what does it talk to, what did it leave behind, and what indicators can I hunt for across the estate.

Static analysis

Static analysis examines the file without running it, which makes it safe and fast.

Start with the cheap signals. The file hash checked against reputation services often identifies a known sample in seconds — though note that submitting a hash discloses that you have it, and uploading the file discloses the file, which matters for targeted samples and internal tooling.

Extracting printable strings frequently yields URLs, domain names, file paths, registry keys, error messages, and command fragments. It is crude and it is the highest return per minute of any technique.

The file header tells you the format, the target architecture, the compile timestamp, and the sections. The import table — which library functions the program calls — is especially informative: imports for network functions, cryptographic functions, process injection, or registry manipulation describe capability before you read a single instruction. A binary with almost no imports and one high-entropy section is packed, and unpacking is the next step rather than the analysis.

Disassembly and decompilation come last, turning machine code back into assembly or approximate source. This is where real understanding happens and where the time goes.

Dynamic analysis

Dynamic analysis runs the sample and observes. It answers questions static analysis struggles with — what a packed binary unpacks to, what a downloader fetches, what configuration it decrypts at runtime.

The observations that matter are process activity (what it spawns, what it injects into), filesystem changes, registry or configuration changes, and network behaviour (what it resolves, what it connects to, what it sends). Automated sandboxes produce all of this in minutes and are the right first step; manual debugging follows when the sandbox output is insufficient.

The trade-off is that you only observe what the sample chooses to do in that environment, on that run. A sample waiting for a date, for a specific domain membership, or for a command from a server that is now offline will look inert.

Doing it safely

This is the part that must not be improvised. Analyse in an isolated virtual machine with no route to production and no shared folders, using snapshots so the environment reverts cleanly between runs.

Control the network deliberately: fully isolated, or through a simulated internet that answers DNS and HTTP locally so you see what the sample asks for without letting it reach anything real. Where genuine internet access is needed to retrieve a second stage, route it so it cannot be traced back to your organization — a connection from your corporate address tells the operator they have a victim who is looking.

Assume escape is possible. Hypervisor escapes exist, so the analysis host should not be a machine you care about or one holding credentials to anything.

And treat the sample as evidence as well as as a specimen. Hash it on acquisition, record where it came from and when, and preserve the original — the chain of custody and volatility considerations under order of volatility apply here too, because the memory of an infected host frequently contains the unpacked code the disk never held.

Anti-analysis tricks

Samples resist inspection, and recognizing the resistance is part of the skill.

Packing and obfuscation defeat strings and imports until unpacked. Anti-debugging checks detect an attached debugger and alter behaviour or exit. Virtual machine and sandbox detection looks for artefacts of the analysis environment — specific drivers, MAC address ranges, small disks, few running processes, no user activity — and many samples simply do nothing when they see them.

Time-based evasion sleeps past a sandbox's observation window or waits for a trigger date. Environmental keying is the hardest: the payload is encrypted with a key derived from something on the target network, such as a domain name, so it cannot be decrypted anywhere else at all.

Fileless techniques sidestep the whole discipline by leaving no binary to analyse, which is why memory captures and command-line logging matter as much as sample analysis — the territory covered under fileless malware and persistence.

What to produce

The output is not a report about the binary; it is things the organization can act on. Network indicators to block and hunt for, file and registry artefacts to search the estate for, behavioural patterns to build detections around, and a plain statement of capability so responders know what was at risk.

Behavioural detections outlive indicators by a wide margin — a hash changes with every build, while the sequence of actions usually does not — which is the same reasoning behind behaviour-based EDR.

Exam angles

Distinguish static analysis (examining without executing: hashes, strings, headers, imports, disassembly) from dynamic analysis (executing and observing behaviour). Know isolated virtual environments with snapshots and controlled network access as the safety requirement. Recognize packing, anti-debugging, sandbox detection and time delays as anti-analysis techniques. And know that the deliverable is indicators and behavioural detections, not a description of the code.