What Is Malware Analysis?

Malware analysis is the examination of malicious software to establish what it does, how it works and what it indicates. In incident response it answers practical questions: what did this steal, how does it persist, and what should we search the estate for?

It is a specialist skill, and the initial triage that produces most of the operational value is considerably more accessible than full reverse engineering.

Static and dynamic

Static analysis examines the file without running it — strings, structure, embedded resources, imported functions, similarity to known families. Safe, fast, and defeated by packing and obfuscation, which most modern samples use.

Dynamic analysis runs the sample in an isolated environment and observes behaviour: files created, registry changes, processes spawned, network connections attempted. It cuts through obfuscation, because the code must do what it does in order to work.

What the analysis is for

Indicators to search on: file hashes, command and control addresses, registry keys, filenames, scheduled task names. Those convert one infected machine into an estate-wide question that can be answered.

Capability assessment: does it steal credentials, does it move laterally, does it stage data for exfiltration, is it ransomware waiting on a command. That determines the urgency and the scope of the response.

And persistence mechanisms, which determine what has to be removed for eradication to be real.

Evasion, and why sandboxes are not enough

Samples routinely check whether they are being analysed — looking for virtualisation artefacts, analysis tooling, small disk sizes, absent user activity or too little elapsed time — and behave benignly when they find it.

Others require a command from their operator before doing anything, or only activate under conditions the sandbox does not reproduce. A clean sandbox report is weak evidence of a clean sample.

Containment of the analysis itself

Analysis environments need genuine isolation. Malware that reaches the corporate network from a poorly contained lab has happened, and the sample does not know it is being studied.

Practical requirements: no network path to production, controlled or simulated internet access, snapshot-based reset between samples, and awareness that some samples attempt to escape virtualisation.

When to do it, and when not to

During an incident, triage to obtain indicators is almost always worthwhile and can be done in under an hour. Deep analysis usually is not — it takes days and the response cannot wait.

For widely reported families, published analysis already exists and searching for it is faster than reproducing it. Original analysis matters for targeted or novel samples, where nobody else has looked.

Sharing what the analysis produced

Indicators and technique observations derived from a sample are valuable to peers facing the same adversary, and sector sharing communities exist for that exchange. Contributing is usually the condition of receiving.

The care needed is about what accompanies the indicators. Addresses, hashes and technique descriptions are shareable; internal hostnames, affected account names, customer data and anything describing your specific exposure are not. Agreeing that boundary in advance keeps the decision out of the incident.

Where to start

Establish whether anyone can safely obtain basic indicators from a sample within an hour, and whether an isolated environment exists to do it in. That capability is what turns one infected machine into an answerable question.

See fileless malware. GuardsArm delivers incident response.