Malware Analysis: Static, Dynamic, and Code Analysis

Malware analysis is the controlled examination of suspicious software, scripts, documents, memory, or related artifacts to answer a defensive question. The analyst may need to identify a file, explain its behavior, extract configuration, reveal persistence, understand a command channel, determine affected systems, build detection, or guide containment. The goal is not simply to prove that something is malicious. It is to produce reliable evidence at the speed and depth the decision requires.

Analysis usually combines several methods. Static analysis examines properties without intentionally running the sample. Dynamic analysis observes it in a controlled environment. Code analysis uses disassembly, decompilation, debugging, and related techniques to explain functionality that observation alone cannot resolve. Memory, network, document, script, and configuration analysis cross these boundaries.

This guide explains the malware analysis workflow, techniques, safety controls, evidence standards, limitations, outputs, and handoffs. It is for defenders deciding how to analyze a suspicious artifact—not for executing unknown code on an ordinary workstation.

Begin With the Question and Stop Condition

Define what decision the analysis must support before choosing a tool. “Analyze this file” has no boundary. Better questions include: Did this sample execute on the affected host? Which persistence must responders remove? What network destinations and fallback paths require scoping? Can detection distinguish this family from legitimate software? Does the sample contain a destructive function, and under which conditions can it activate?

Record the consumer, deadline, evidence threshold, permitted actions, and stop condition. An incident commander may need a reliable containment answer in 30 minutes. A detection engineer may need stable behavioral features within a day. A reverse engineer may spend longer resolving encryption or a proprietary protocol only when that work changes a response or detection decision.

The adjacent malware-intelligence guide starts where this technical workflow ends: it connects findings to organizational relevance, campaigns, warning, and decisions. Keeping the scopes separate prevents technical curiosity from delaying the operational answer.

Preserve Provenance Before Touching the Sample

Treat the sample as evidence. Record where and when it was acquired, who handled it, the original filename and path, message or case identifiers, relevant host and user context, observed timestamps, file size, cryptographic hashes, and handling restrictions. Preserve the original in controlled storage and analyze a verified working copy. A hash demonstrates byte-level identity between copies; it does not prove origin, intent, or malware family.

Collect surrounding evidence before it disappears: process ancestry, command lines, open connections, DNS observations, authentication activity, files created or modified, registry or service changes, memory captures where authorized, EDR events, email headers, download source, and user-reported actions. A sample without its execution context can answer what the code is capable of while leaving the incident sequence unresolved.

Maintain a case timeline and distinguish acquisition time, file-system timestamps, compilation metadata, first execution, and analyst execution. Malware can forge or inherit timestamps. Label each time by source rather than collapsing them into one apparently precise chronology.

Build a Malware Lab That Contains Failure

Unknown code belongs in an isolated, disposable environment—not on a production endpoint, personal machine, or network that trusts the analyst workstation. Separate acquisition, storage, analysis, and reporting functions. Use restricted access, snapshots or known-good rebuilds, controlled file transfer, dedicated accounts, and logging that survives destruction of the guest environment. Prevent accidental clipboard, shared-folder, removable-media, credential, and management-plane paths back to trusted systems.

Network design should follow the question. Some work requires no connectivity. Behavioral analysis may need simulated services, captured traffic, or tightly controlled egress. Never give a sample unrestricted access merely to “see what it does.” Define DNS, routing, sinkhole, proxy, packet capture, rate limit, and shutdown behavior in advance. Assume the sample may scan, attack third parties, send stolen material, or retrieve another payload.

The laboratory is a control system, not a single virtual machine. Test escape assumptions, hypervisor and analysis-host patching, credential separation, sample retention, backup exclusions, emergency isolation, and evidence export. The official REMnux documentation illustrates the breadth of static, dynamic, memory, network, document, and system-level analysis tasks; tool availability does not replace safe architecture or authorization.

Choose the Smallest Useful Analysis Depth

Use a progressive workflow. First triage identity, format, safety, and context. Next inspect static properties. Execute only when the question and controls justify it. Escalate to unpacking, memory work, debugging, disassembly, or decompilation when simpler evidence cannot resolve important behavior. Revisit earlier steps as new findings change the hypothesis.

Depth is not a maturity score. A fast hash match against a known incident sample may be sufficient to scope hosts. Static configuration extraction may reveal every command server without execution. Dynamic behavior may expose persistence faster than code review. Full reverse engineering may be essential when a dormant destructive path, custom encryption, trigger, or detection invariant must be understood.

The current MITRE ATT&CK Malware Content data component distinguishes static characteristics, behavioral observations, memory artifacts, and threat-intelligence uses. Treat these as complementary evidence families, not interchangeable proof.

Static Malware Analysis: Inspect Without Executing

Begin with file type based on content, not extension. Calculate strong hashes and compare them with authorized internal or external sources. Examine size, headers, sections, permissions, architecture, imports, exports, resources, signatures, certificates, manifests, entropy, strings, embedded files, document objects, scripts, and packaging. Check whether metadata is plausible, internally consistent, and useful—not merely present.

Static triage can reveal URLs, domains, paths, mutexes, service names, commands, user agents, keys, campaign identifiers, debug paths, compilation clues, or suspicious API combinations. It can also expose format errors and packing. Yet every artifact needs interpretation: an imported function is available to the program but may never execute; a string may be encrypted, unused, planted, or part of a library; a valid signature says who signed a file under a certificate, not that every behavior is safe.

Disassembly and decompilation are also static when the analyst is reading code rather than running it. Use them to trace control flow, data transformations, configuration parsing, persistence, privilege use, process injection, protocol construction, and error paths. Preserve offsets, function identifiers, tool versions, and annotations so another analyst can reproduce the claim.

Dynamic Malware Analysis: Observe Controlled Execution

Dynamic analysis records what happens when a sample runs under defined conditions. Establish a clean baseline, start capture before execution, note every analyst action, and preserve clocks and time zones. Observe process and thread activity, command lines, modules, files, configuration changes, services, scheduled tasks, registry or persistence changes, interprocess communication, memory allocations, injected code, user-interface behavior, and network requests.

Vary one condition at a time when the question demands it: arguments, privilege, user interaction, locale, time, operating-system version, document application, network availability, domain membership, or simulated service response. A sample may wait, require a parent process, decrypt only after a server response, target a locale, or exit when expected data is absent. Record the condition that produced each observation.

Non-observation is bounded evidence. “The sample did not create persistence during a ten-minute Windows 11 execution without internet access” is defensible. “The sample has no persistence” is not. NIST SP 800-83 Rev. 1 likewise treats malware analysis as one input to identifying affected systems, behavior, propagation, containment, and removal—not a substitute for environment-wide incident evidence.

Code Analysis and Reverse Engineering: Explain Hidden Logic

Reverse engineering becomes necessary when execution does not reveal why a behavior occurs or how to reproduce it. Identify entry points and meaningful functions, recover data structures, follow arguments and return values, trace configuration and key material, and map branches that control capabilities. Rename functions and variables according to evidence, not early guesses. Keep a list of unresolved assumptions.

Static code analysis can describe all reachable branches but may struggle with packing, virtualization, obfuscation, generated code, or indirect calls. Debugging can expose decrypted memory, resolved APIs, and runtime state but may alter timing or trigger anti-debugging. Combine both. Capture the original packed layer, each unpacked stage, memory region, breakpoint rationale, and the transformation used to extract data.

Do not equate code presence with incident use. A builder may include unused modules; configuration may disable a feature; a branch may be unreachable in the observed version. Label the difference between implemented capability, configured capability, observed behavior, and behavior confirmed on a victim system.

Follow Behavior Across Files, Memory, and Network Traffic

Malware rarely stays inside one file. A document can launch a script; a script can retrieve a loader; a loader can decrypt code into memory; an injected thread can inherit a legitimate process name; a command channel can deliver modules after the first execution. Maintain lineage across stages with hashes, paths, process relationships, memory locations, timestamps, and network transactions.

Memory analysis can recover injected or unpacked code, runtime configuration, keys, sockets, and process relationships that never exist plainly on disk. Network analysis can reveal resolution, protocol, encryption framing, beacon timing, redirects, fallback infrastructure, request fields, and tasking. Decode only what evidence supports and distinguish a visible proxy or cloud service from the ultimate controller.

Malicious documents and scripts require format-aware analysis. Inspect embedded objects, macros, relationships, templates, formulas, metadata, obfuscation, interpreters, and child processes. Do not use the filename or initial file type to define the scope; follow the execution chain until the decision is answered.

Treat Anti-Analysis and Environment Gaps as Uncertainty

Malware can test virtualization artifacts, debuggers, process names, user activity, screen size, files, registry values, domain membership, language, clock behavior, hardware identifiers, or network reachability. It can sleep, delay execution, require a command, unpack only in memory, or behave differently for a chosen victim. Analysis tools can also fail silently or misparse evidence.

Look for checks in code and compare them with runtime branches. Change controlled conditions only when authorized and document the change. If bypassing a check alters code or state, preserve both the original and modified experiment. Never describe a bypassed execution as though it were the sample’s natural behavior.

Use corroboration: victim telemetry, multiple analysis environments, memory evidence, code paths, related samples, and independent sources. A sandbox score, family label, or antivirus name is a lead. Explain the underlying evidence before making a consequential containment, attribution, or eradication claim.

Turn Findings Into Detection and Response

Translate findings by use. For scope, identify prerequisites, execution evidence, affected versions, identities, persistence, lateral paths, and command infrastructure. For containment, identify active control paths, fallback channels, credentials, destructive triggers, dependencies, and safe isolation order. For eradication, specify files, services, tasks, accounts, configuration, implants, and access paths that must be removed or rebuilt.

For detection, prefer durable combinations of behavior and context over one fragile value. Preserve the mapping from analytic finding to required telemetry, query, rule logic, expected legitimate activity, test case, and response. When file or memory features are appropriate, the YARA rule workflow explains feature selection, condition design, negative testing, deployment, and maintenance.

Feed validated results into the incident response lifecycle: update scope, evidence preservation, containment, recovery validation, and lessons. NIST SP 800-61 Rev. 3 frames response as part of continuous cybersecurity risk management; malware analysis should improve future preparation and detection, not terminate with a one-time report.

Write a Reproducible Malware Analysis Report

Lead with the answer: what the artifact is assessed to do, under which tested or code-supported conditions, why the finding matters, and what action is recommended. Then provide sample identifiers, provenance, acquisition and analysis times, handling restrictions, environment, network conditions, tools and versions, methods, and the question that bounded the work.

Separate evidence classes. Mark behavior directly observed in the lab; capability supported by code; activity confirmed in victim telemetry; claims inherited from external reporting; and analyst inference. Include confidence and the main alternatives. List failed experiments, unavailable dependencies, anti-analysis, encrypted or unresolved regions, visibility gaps, and behaviors that were not tested.

Attach structured observables with role, first and last relevant time, source, confidence, handling, and expiry. Preserve packet captures, logs, screenshots where useful, extracted configuration, scripts, hashes, and annotations under case controls. A reader should be able to reproduce the important claim without rerunning unsafe code blindly.

Practical Malware Analysis Workflow

Use this sequence as a decision checklist:

1. Authorize and define the question. Name the consumer, deadline, handling rules, permitted experiments, and stop condition.
2. Preserve the original and context. Hash the sample, record provenance, and collect volatile and surrounding incident evidence.
3. Prepare containment. Verify isolation, credentials, storage, monitoring, network controls, reset, and emergency shutdown.
4. Triage statically. Confirm format, structure, metadata, signatures, strings, resources, imports, packing, and known relationships.
5. Form hypotheses. Predict behaviors and the observations that would support or contradict them.
6. Execute only if justified. Capture process, file, memory, configuration, persistence, and network evidence under stated conditions.
7. Escalate selectively. Unpack, debug, disassemble, decompile, or decode only to resolve a decision-relevant gap.
8. Corroborate with incident data. Test whether lab findings occurred in the real environment and search for affected scope.
9. Translate to action. Provide detection, containment, eradication, recovery, and collection recommendations with owners.
10. Report limits and preserve evidence. Separate observation, capability, and inference; retain reproducible artifacts.
11. Retest and learn. Validate controls against representative samples, variants, and clean software, then update playbooks.

Good malware analysis reduces uncertainty safely. It does not maximize tool output, reverse every function, or treat a sandbox verdict as the conclusion.