Malware Forensics

What it is and why it matters

When a company is hit by ransomware, a bank customer's phone forwards one-time passwords to a stranger or a server starts talking to an address nobody recognises, someone has to answer three questions. What is this program, what did it do and how did it arrive. Malware forensics answers them from the evidence: the file, the memory it ran in, the logs it triggered and the network traffic it generated.

The work splits into examination of the host and examination of the sample. On the host the examiner looks for persistence entries, dropped files, modified system components, scheduled tasks and the event log and file system records that show when the code arrived and ran. With the sample, static analysis reads the file's structure, strings and imports without running it, and dynamic analysis runs it in an isolated environment to watch its behaviour. Memory analysis bridges the two for code that never lands on disk.

Safety and honesty are the two disciplines that matter most. A sample handled carelessly infects the laboratory. A finding stated carelessly accuses the wrong party. The examiner says what the code does and what the traces show, separates that from what it suggests about who sent it and treats attribution as inference, never as fact.

Types of digital evidence

The Sample and Its Droppings
The executable, script, document or installer that carried the malware, the files it wrote, the configuration it decrypted and any later stages it downloaded, each hashed and kept in a protected container.
Persistence Entries
Run keys and services in the Windows registry, scheduled tasks, WMI event subscriptions, startup folders, LaunchAgents and LaunchDaemons on macOS, cron and systemd units on Linux and accessibility or device administrator grants on Android.
Execution Traces
Prefetch, Amcache, ShimCache and BAM records, Sysmon and process creation events, PowerShell script block logs and the Defender or antivirus operational log that first noticed the threat.
Memory Artefacts
Injected code, hollowed processes, in-memory configuration and command and control addresses, decrypted payloads and the strings a packed sample reveals only when running.
Network Indicators
DNS queries, connections to command and control servers, beacon timing, downloaded payload URLs and proxy and firewall logs that show the first contact and later traffic.
Delivery Artefacts
The phishing email with its headers and attachment, the browser download record, the macro inside a document, the LNK or ISO file that started the chain and the user action that triggered it.
Damage Records
Encrypted files and ransom notes, deleted shadow copies, cleared logs, created accounts, changed permissions and the file system journal entries that date each step.
Mobile Malware Traces
Sideloaded APKs, granted permissions, SMS forwarding records and overlay screens on Android, and configuration profiles and unusual processes on iOS.

Devices and data sources

Disk images of infected workstations and servers
Memory captures taken while the malware was running
The samples themselves, from quarantine folders, email attachments, downloads or recovered from memory
Endpoint detection and antivirus logs and quarantine stores
Sysmon, Windows event logs, auditd and application logs from the affected hosts
Network captures, NetFlow records, DNS logs and proxy logs from the time of infection
Email gateway logs and the original messages that carried the attachment or link
Phones and tablets in banking fraud and spyware cases
Threat intelligence and public sandbox reports used as leads, never as conclusions

How an examination runs

The order matters. Each step protects the one after it.

01
Contain Without Destroying
Isolate the affected host from the network while keeping it powered where memory evidence matters. Do not run cleaning tools, reboot or reinstall until the evidence is preserved and the decision is recorded.
02
Preserve Memory, Disk and Logs
Capture memory first, then image the disk, then collect logs from the host and from network and security systems that saw the traffic. Hash everything.
03
Find the Code
Search persistence locations, execution traces, recent files and memory for the malicious component. Hash every candidate and compare with known-good files and public reputation sources as a lead.
04
Handle the Sample Safely
Move samples in password-protected archives into an isolated laboratory with no route to production networks. Record who handled them and keep the originals untouched.
05
Static Analysis
Read the file format, headers, sections, imports, strings, embedded resources, signatures and compile timestamps. Unpack where needed. Look for configuration, addresses and the capabilities the code can call on.
06
Dynamic and Memory Analysis
Run the sample in an instrumented, isolated environment with simulated network services and record file, registry, process and network behaviour. Compare with the memory capture from the victim machine to confirm what actually happened there.
07
Build the Infection Timeline
Place delivery, execution, persistence, lateral movement, data access and damage on one timeline using the host and network evidence, and mark each step as observed or inferred.
08
Report and Share Indicators
Write up what the malware is, what it did on this system and how it arrived, with indicators for the response team, and keep attribution clearly labelled as assessment.

Tools used in this discipline

Independent profiles: what each tool does, where it stops and what you need to know before using it.

Browse the full tools directory

Terminology

Static Analysis: Examining a file without running it: format, headers, strings, imports, resources and signatures. Safe, but packers and encryption can hide most of the content.
Dynamic Analysis: Running the sample in a controlled environment and recording what it does. It reveals behaviour but only the paths the sample takes in that environment and that run.
Sandbox: An isolated system, usually virtual, instrumented to log behaviour and with network traffic captured or simulated. Many samples detect sandboxes and behave differently.
Indicator of Compromise: A fact that identifies malicious activity, such as a file hash, a domain, an address, a mutex name or a registry key. Used to search other systems.
Persistence: The mechanism by which malware survives a reboot or logoff. The registry, services, scheduled tasks, WMI subscriptions and startup locations are the usual places.
Command and Control: The channel through which malware receives instructions and sends data, often disguised as ordinary web traffic or hidden in DNS.
Packer: A tool that compresses or encrypts an executable so that it unpacks itself in memory. It defeats simple static analysis and is one reason memory capture matters.
Living Off the Land: Using the system's own tools, such as PowerShell, WMI, scheduled tasks or certutil, so that no malicious file is written and detection must rely on behaviour.
YARA: A rule language for describing patterns in files and memory, used to find samples of a family across images and dumps.
Attribution: The assessment of who is behind an attack. Code similarity, infrastructure overlap and timing are evidence of association, not identity, and are reported as assessment.

Challenges and limits

What makes it hard

Fileless and in-memory malware leaves little on disk, so without a memory capture and good logging the evidence may be only the damage
Packing, encryption and anti-analysis checks make samples behave differently in a sandbox than on the victim, or not at all
Attackers use the system's own tools, so the malicious act looks like administration until the context is read
Logs that would show the first step are often not enabled, rolled over or deliberately cleared
A sample that is safe in one environment can spread or destroy data in another, so every handling step needs discipline
Public reputation and sandbox services are useful leads but uploading a sample can tip off an attacker or leak case data
Attribution claims are easy to make and hard to prove, and a wrong one damages people and cases

Keeping the evidence intact

Hash every sample on collection and keep it in a protected container with a handling log
Analyse in an isolated laboratory network that cannot reach production systems or the internet except through controlled channels
Record the environment, tools and versions for every static and dynamic run so that behaviour can be reproduced
Separate observations on the victim system from behaviour seen in the sandbox and label each in the report
Never upload a case sample to a public service without authority and without weighing the disclosure it causes

Standards and legal considerations

NIST SP 800-83 Rev. 1
Guide to Malware Incident Prevention and Handling for Desktops and Laptops. It describes malware types, the handling phases and the forensic considerations during a malware incident.
NIST SP 800-86
The forensic process reference, including the collection of volatile data and the examination of files, logs and network data in an incident.
Read the guide
ISO/IEC 27043:2015
Incident investigation principles and processes, which place malware examination inside a planned investigation rather than ad hoc clean-up.
Read the guide
CERT-In Directions 2022
The Indian reporting requirement for malware, ransomware and other listed incidents within six hours, which shapes what evidence must be ready and when.
Read the guide
SWGDE Best Practices
SWGDE guidance on computer forensic examination and on the use of specialised tools, applied here to samples and memory.
Read the guide

In practice

Ransomware Through a Remote Desktop
A manufacturing company's file server is encrypted overnight. The Security log shows a remote logon with a contractor's account from an external address two days earlier, a scheduled task created an hour before the encryption and shadow copies deleted by a system command. The ransomware executable is recovered from a temp folder, and its configuration, decrypted in the memory capture, names the extensions it skipped.
The OTP Stealer on a Customer's Phone
A bank customer loses money after installing a courier app from a message. The APK is sideloaded, requests SMS and accessibility permissions and contains a hard-coded server address. Its database holds every OTP message received since install and the time each was forwarded, which matches the fraudulent transfers.
A Script That Never Touched the Disk
A workstation beacons to an unknown domain but antivirus finds nothing. PowerShell script block logging recorded a long encoded command, and the memory capture shows the decoded loader inside a legitimate process. No file was ever written, and the examiner explains why disk-only tools missed it.

This page is educational material, not legal advice. Laws and standards change, commence on different dates and are interpreted differently across jurisdictions. Always read the official text linked on this page and take advice from a qualified professional for a real matter.

Learn it at DFRTI

Free pages explain. These courses teach it on real devices with a mentor.

MalwareIncident Response & Malware AnalysisMalware Reverse EngineeringTake malware apart safely with static and dynamic analysis, Ghidra, x64dbg and YARA.AdvancedMalware Analyst

MalwareIncident Response & Malware AnalysisMemory ForensicsCapture RAM and use Volatility 3 to find hidden processes, injected code and connections.IntermediateMalware Analyst

MalwareIncident Response & Malware AnalysisRansomware & Threat ResponseHandle a ransomware attack from first call to recovery, reporting and lessons learnt.IntermediateMalware Analyst

NetworkNetwork & Cloud ForensicsNetwork Traffic AnalysisRead flows, logs and packets to trace intrusions, beaconing and data theft.IntermediateDCNI

Careers that use it

Questions people ask

Is malware forensics the same as reverse engineering?

They overlap. Reverse engineering studies the code in depth to learn how it works. Malware forensics asks what the code did on this system and how it arrived, and uses as much reverse engineering as that question needs. Many cases are answered from logs, memory and behaviour without reading every function.

Can I just run the suspicious file to see what it does?

Only in an isolated, instrumented laboratory with a plan for what to record and how to reset. On any other machine it is both dangerous and destructive to the evidence. Even in the lab, many samples detect the environment and hide their behaviour.

Does finding malware prove the user is innocent?

It proves that malicious code was present and what it could do. Whether it performed the act in question is answered from the timeline, the malware's capabilities and the other evidence. The examiner reports both the possibility and its limits.

Who made the malware?

Usually unknown and often unknowable from the sample alone. Similarities with known families and infrastructure support an assessment, and the report labels it as such. Naming a person or group as fact requires evidence beyond the code.