Reverse engineering a binary answers how it works: the algorithm, the protocol, the author’s habits, the whole implementation. Triage answers a narrower and more urgent question. Given this file recovered from this host, what does the rest of the investigation need to know in the next hour? Which other machines does it point at, what does it touch on disk, what does it talk to, and does it match anything already seen?
Those are different jobs with different products. Reverse engineering produces understanding. Triage produces indicators, scope, and a decision about where to look next, and it is the one that runs while an incident is still open.
The idea
Static analysis observes an artifact that cannot lie but also cannot speak, since packing and obfuscation leave the interesting parts unreadable. Dynamic analysis makes the sample speak, at the cost that the sample chooses what to say: it can detect the observation and behave differently. Neither is authoritative alone, and the report has to say which one produced each claim.
The two approaches, as NIST frames them
NIST states the split cleanly: “incident handlers can study the behavior of malware by analyzing it either actively (executing the malware) or forensically (examining the infected host for evidence of malware).”
It also states the tradeoff. “Forensic approaches are safer to perform on an infected host because they can examine the host without allowing the malware to continue executing. However, sometimes it is significantly faster and easier to analyze malware by monitoring it during execution.”
That is the whole tension in two sentences. Static examination touches nothing and risks nothing, and it tells you only what the file will reveal without running: strings, imports, embedded resources, section structure, signatures, and the metadata surrounding it on the host. Execution reveals behavior directly and rapidly, and it requires deliberately running hostile code.
Containing the execution
NIST’s guidance on where to run it is specific. “Active approaches are best performed on malware test systems instead of production hosts, to minimize possible damage caused by allowing the malware to execute,” and the ideal is “acquiring a malware sample from an infected host and placing the malware on an isolated test system.”
The recommended construction is a virtualized guest with a clean host observing it: “test systems often have a virtualized OS image; copies of these builds can be infected, isolating any infection within the virtualized OS, and the infected image can be replaced with a known good image after the analysis is complete.” NIST adds the reason the host stays clean: “on such test systems, the host OS is kept uninfected so it can be used to monitor the execution of the malware within the virtualized OS.”
The observation point is outside the thing being observed. That is the same principle as isolation generally, and it is why a snapshot-and-revert workflow built on virtual machines became the standard sandbox architecture rather than a dedicated physical machine that has to be rebuilt after every sample.
Where dynamic analysis lies
The flaw is in the same publication, in a footnote that deserves more prominence than it gets: “some malware can detect the presence of a virtualized environment and change their behavior accordingly.”
ATT&CK catalogues this as a named technique. “Adversaries may employ various means to detect and avoid virtualization and analysis environments,” and on detecting one, “they may alter their malware to disengage from the victim or conceal the core functions of the implant.” The checks are cheap and varied: “checking for security monitoring tools” or “other system artifacts associated with analysis or virtualization,” and looking “for legitimate user activity to help determine if it is in an analysis environment.”
The timing variant is the most quietly effective, because it defeats a sandbox without detecting anything at all: “additional methods include use of sleep timers or loops within malware code to avoid operating within a temporary sandbox.” An automated sandbox runs a sample for a bounded interval. A sample that does nothing for longer than that interval produces a clean report.
The consequence for a report is unambiguous. A sandbox result is a record of what the sample did under those conditions, at that time, in that environment. It is evidence of behavior observed and never evidence of the absence of behavior. “The sandbox observed no network activity” is a defensible sentence. “The sample does not communicate with a server” is not, and the difference is exactly the kind of overreach an opposing expert is paid to find.
The same problem runs the other way too. Sandbox environments are recognizably artificial, so a sample that behaves differently when it detects one is telling you something real: evasion capability is itself a finding, and the checks it performs are indicators worth extracting.
What static analysis is good for
Static work carries the parts of triage that survive contact with an adversary, because it examines a fixed artifact. A hash identifies the exact file and links it to prior sightings and to the copy preserved in evidence. Embedded strings, imports, certificates, and resources describe capability. Compilation artifacts and packaging suggest lineage. Most usefully in an intrusion, the file’s placement on disk, its arrival time, and the artifacts that recorded its execution connect the sample to the rest of the timeline without ever running it.
Its limit is that the interesting content is often not readable. Packed and obfuscated samples present a small unpacking stub and an encrypted blob, so the strings and imports visible statically describe the stub rather than the payload. NIST notes the broader reason this matters operationally: customization “greatly increases the variety of malware that antivirus software and other security controls need to detect and block,” and “largely signature-based security controls, such as antivirus software, cannot keep up with them.” A negative result from a scanner is very weak evidence, and a triage process that treats a clean scan as an answer will miss the sample that was built for this victim.
Triage is not attribution
A sample’s language, timestamps, infrastructure, and code reuse are all attacker-controlled, and every one of them has been deliberately falsified in known cases. Triage supports statements about the artifact and its behavior in an environment. Statements about who wrote it belong to a different discipline with a different evidentiary standard, described in attribution.
Where it fits
In practice triage is an interleaved loop rather than a choice between two methods. Static examination first, because it is free and safe. Execution in an isolated environment when static work stalls or when behavior is the question. Then back to the host, because the sample’s traces there, the persistence entries, the parent process, the files it wrote, are evidence that the sample actually ran on this machine rather than merely being capable of it. The sandbox tells you what the code can do. Only the host tells you what happened.
Related Notes
- Classes of Malware for what the categories mean before triage sorts a sample into one.
- Virtualization: VMs and Containers for the snapshot-and-revert machinery behind every sandbox.
- Sandboxing and Isolation for observing from outside the thing observed.
- Memory Analysis and Process Reconstruction for recovering an unpacked payload from a running process instead of the file.
- The Windows Registry as Evidence for the host-side traces that prove execution.
- Attribution and State Responsibility for the standard that claims about authorship have to meet.
Sources
- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-83r1.pdf for active versus forensic analysis, isolated test systems, the clean monitoring host, virtualization detection, and the limits of signature-based detection.
- https://attack.mitre.org/techniques/T1497/ for virtualization and sandbox evasion, the checks used, and sleep-timer evasion of temporary sandboxes.