Procedures and Methodology · Topic 11 of 11
Malware Forensics
Why and how to analyze malware: challenges, extraction, indicators, safe lab and testbed setup, tools, rules, and static versus dynamic analysis.
- 5 min
- Goals: understand behavior, extract IOCs, support detection and response.
- Static analysis does not run the sample, dynamic analysis does.
- Packing, polymorphism and anti analysis checks make analysis harder.
What it is
Malware forensics is the process of finding malicious software on a system, extracting it safely, and working out what it does and what it changed. The result feeds incident response: how the attacker got in, what was affected, and how to detect and remove it.
The exam asks why analysis is done, how a safe lab is built, which tool category fits a step, and the difference between static and dynamic analysis.
How it works
Why analyze malware
- find out what the malware does and how it spreads
- identify what data was taken or damaged
- extract indicators of compromise (IOCs) to find other infected systems
- build detection signatures and defenses
- understand the attacker's methods and, sometimes, attribution
- support reporting and legal action
Malware analysis challenges
| Challenge | Effect |
|---|---|
| Packing and obfuscation | The real code is hidden until it runs |
| Anti analysis tricks | Malware detects virtual machines or debuggers and behaves differently |
| Polymorphism | The code changes between copies, so hashes and signatures fail |
| Fileless techniques | Little or nothing is written to disk, so memory holds the evidence |
| Time and skill | Deep analysis is slow and needs specialists |
| Risk | Unsafe handling can infect the lab or leak data |
Identifying and extracting malware
Suspects are found through antivirus alerts, odd processes in memory, unusual autostart entries, unexpected network connections and logs. Extract carefully:
- Record where and when it was found.
- Copy it from an image or memory dump rather than the live original, and keep the original in place.
- Compute hashes (SHA-256) and record them.
- Store the sample in a password protected archive, with the file extension changed, so it cannot be run by accident.
- Check the hash against reputation services such as VirusTotal, but do not upload files containing sensitive data.
Malware forensic artifacts and indicators
| Indicator | Examples |
|---|---|
| File system | New executables in temp or user folders, odd names, recently created files |
| Registry | Run keys, new services, changed settings |
| Persistence | Scheduled tasks, services, startup folder, WMI subscriptions |
| Network | Connections to unusual hosts, beaconing at regular intervals, odd DNS |
| Memory | Injected code, hidden processes, unusual parent and child processes |
| Logs | Event 7045 for a new service, 4688 for process creation |
| Hashes | File hashes matching known samples |
Why a controlled lab matters
Running malware on a normal network can infect real systems and alert the attacker. A controlled lab keeps the malware contained, makes results repeatable and protects the examiner. It is isolated physically or logically from production and from the internet.
Preparing the testbed
- Use virtual machines with a clean baseline and take a snapshot, so it can be restored after every run.
- Use a host only or isolated virtual network, with no route to the corporate network.
- Disable shared folders, clipboard sharing and drag and drop between host and guest.
- Install the same software the target ran, to trigger the same behavior.
- Add monitoring tools before running the sample.
- Optionally simulate internet services, so the malware shows its network behavior safely.
Supporting tools
| Purpose | Examples |
|---|---|
| File properties and strings | strings, PE viewers such as PEview, Detect It Easy |
| Disassembly and debugging | IDA, Ghidra, x64dbg |
| Process and registry monitoring | Process Monitor, Process Explorer, Regshot |
| Network monitoring | Wireshark, FakeNet-NG, INetSim |
| Automated sandboxes | Cuckoo Sandbox, CAPE, commercial sandboxes |
| Memory analysis | Volatility |
| Hash and reputation | sha256sum, VirusTotal |
General rules for malware analysis
- Never run malware on production or personal computers.
- Never connect the lab to the real network, or only through a controlled simulation.
- Work on copies, and keep the original sample safe.
- Revert to a clean snapshot after each run.
- Use non persistent, disposable analysis machines where possible.
- Keep analysis tools and VM software updated, since some malware targets hypervisor flaws.
- Handle samples as dangerous, even when "inactive".
Documentation before analysis
Record the state before the first run, because later changes need a baseline.
- sample name, size and hashes, source and time found
- case number, analyst and lab configuration
- baseline snapshot of files, registry and processes
- tool versions and settings
- the planned steps and the goal of the analysis
Types of malware analysis
| Type | Description | Strength | Limit |
|---|---|---|---|
| Static analysis | Examine the sample without running it: hashes, strings, headers, imports, disassembly | Safe, shows structure | Packed or obfuscated code hides detail |
| Dynamic analysis | Run it in the lab and watch behavior: files, registry, processes, network | Shows real actions | Risky, and may not trigger all behavior |
| Memory analysis | Examine a memory image for injected or hidden code | Finds fileless malware | Needs a good capture |
Most investigations start with basic static analysis, then use dynamic analysis, and bring in code level analysis when needed.
A worked example
A server shows an unfamiliar process beaconing every sixty seconds. The investigator captures memory and a disk image, hashes the suspect binary and records a baseline snapshot of an identical virtual machine.
In an isolated lab the sample is run, while Process Monitor, Regshot and Wireshark record a new service, a Run key and DNS requests. The IOCs go to the incident response team.
How the exam asks about this
- "Which analysis runs the sample to watch its behavior?" → Dynamic analysis.
- "Why use a host only network for the testbed?" → To contain the malware and prevent it reaching real systems.
- "What do you do before running a sample?" → Take a clean snapshot and document the baseline.
What to remember for the exam
- Goals: understand behavior, extract IOCs, support detection and response.
- Static analysis does not run the sample, dynamic analysis does.
- Packing, polymorphism and anti analysis checks make analysis harder.
- A lab is isolated, snapshot based, with no shared folders.
- Document and hash the sample before analysis.
Malware can detect a virtual machine or lie dormant. A clean run does not prove a sample is harmless.
Common mistakes
Analyzing on a connected workstation. Containment is the first purpose of the lab.
Skipping the baseline. Without it you cannot tell what the malware changed.
Assuming the hash identifies every copy. Polymorphic samples change, so behavior and IOCs matter too.
Check yourself
What is an IOC?
An observable sign of compromise, such as a file hash, domain or registry key, used to find other infections.
Why take a snapshot of the lab VM?
So the machine can be restored to a clean state after each run.
Which analysis type is safest first?
Static analysis, because the sample is not executed.
Topic 11 of 11 in Procedures and Methodology
Test yourself on Procedures and Methodology
The full EC-Council 312-49 question bank has 900 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by EC-Council. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.