How does malware analysis work: static, dynamic and safe lab setup?

Malware analysis is the process of examining a suspicious program to learn what it does, how it got in and how to detect or remove it. Static analysis inspects the file without running it. Dynamic analysis runs it in an isolated lab and records behavior. Most teams use both, starting with the cheaper and safer one.

What do analysts want to learn?

The questions are practical. What does it do to a system? Does it steal credentials, encrypt files or open a remote connection? What does it talk to? How does it persist after a reboot? What indicators, such as file hashes, domains and registry keys, can defenders use to find it elsewhere? NIST SP 800-83 Rev. 1 covers malware incident prevention and handling and sets this work in the wider context of responding to an infection.

What does static analysis involve?

You never execute the sample.

• Hashing. Compute a hash and check whether others have seen the same file.
• File type and metadata. Confirm what the file really is, and read compile times and signing information.
• Strings and imports. Readable text and the system functions a program imports hint at purpose, such as networking or file encryption.
• Disassembly and decompilation. Reading the code itself, slow but revealing.
• Packing and obfuscation checks. High entropy sections often mean the real code is hidden.

Static work is safe and repeatable, but obfuscated or encrypted code limits what it reveals.

What does dynamic analysis involve?

You run the sample in a controlled environment and watch.

• Process creation, file and registry changes.
• Network connections, DNS lookups and traffic content.
• Persistence mechanisms and attempts to disable security tools.
• Memory inspection for code that only exists while running.

Many samples detect virtual machines or sandboxes and behave differently, or sleep for a long time before acting. Analysts adjust the lab to look more realistic and wait.

Behavior observed can be mapped to techniques in MITRE ATT&CK, which gives a common vocabulary for reports and detection work.

How do you build a safe lab?

Treat every sample as dangerous.

1. Use a dedicated machine or virtual machines with no shared folders and no clipboard sharing to your main computer.
2. Take a clean snapshot you can restore after each run.
3. Isolate the network. Either no connectivity, or a simulated internet that answers requests without reaching the real one. Test that nothing escapes.
4. Keep samples in password protected archives with a clear name, and store hashes, not the file, in notes.
5. Defang indicators in reports, for example writing a domain with brackets around the dots, so nobody clicks by accident.
6. Never analyze on a work machine connected to the corporate network.
7. Get authorization. Handling malware may be restricted by company policy or local law.

Constructed example: a help desk receives an invoice attachment that an antivirus tool flagged as suspicious. An analyst hashes it, sees no prior reports, extracts strings showing a web address and a scheduled task name, then runs it in a snapshot VM with simulated internet. It writes a file in a startup folder and tries a connection to that address. The team blocks the address, searches endpoints for the file and scheduled task, and shares the indicators internally.

What should you record?

Hashes, filenames, network indicators, files and registry entries created, persistence method, the tools and versions you used, and the timeline. Add what you could not determine. A short, accurate report that responders can act on beats a long one.

Where does this meet software supply chain work?

Some malware arrives as a malicious package or a poisoned dependency rather than an email attachment. Safeguard's dependency scanning gives you an inventory of what you actually install, and the free scan at gold.safeguard.sh/scan covers up to 100 dependencies, so you know which packages to look at first. Deep analysis of an unknown sample is still a specialist job for a lab like the one above.

How to check or apply this

1. Decide whether you need in house analysis or can rely on a response provider.
2. Build the isolated lab and test the isolation before using it.
3. Write a triage checklist: hash, lookup, strings, sandbox run.
4. Agree what gets shared and with whom.
5. Turn findings into detections and block lists, then check that they work.

Quick check

Sources

• NIST SP 800-83 Rev. 1, Guide to Malware Incident Prevention and Handling for Desktops and Laptops
• MITRE ATT&CK
• NIST glossary, malware

Last reviewed: 18 October 2026.