Dynamic analysis in a sandbox

A sandbox is an isolated, instrumented machine (almost always a virtual machine) in which you deliberately run a suspicious file and record everything it does: processes started, files written, registry keys changed, network connections. When the run ends, the machine is reverted to a clean snapshot.

This is dynamic analysis: observing behaviour at runtime. It complements static analysis, which examines the file without executing it. For a SOC or CTI analyst, a sandbox is the fastest way to answer "what does this attachment do, and which IOCs can I hunt for?" in minutes, without being a reverse engineer.

A sandbox hooks the operating system (API monitoring, a kernel driver, or introspection from the hypervisor) and captures the network traffic leaving the VM. A typical run lasts 2 to 5 minutes and produces:

Do not stop at the score. A score is an aggregate of signatures, some of them weak; your job is to reconstruct the story and extract what is actionable. Here are the key extracts from a run of a (fictional) Invoice_4471.docm:

PROCESS TREE
WINWORD.EXE (2148)  "C:\Users\admin\Desktop\Invoice_4471.docm"
 └─ powershell.exe (3312)  -nop -w hidden -enc SQBFAFgAIAAoAE4AZQB3AC0ATwBi...
     └─ rundll32.exe (4020)  C:\Users\admin\AppData\Local\Temp\upd.dll,Start

NETWORK
DNS   cdn-update.example            A  203.0.113.45
HTTPS 203.0.113.45:443  SNI=cdn-update.example  GET /s2/upd.dll   (216 KB)
HTTPS 203.0.113.45:443  POST /api/v1/beacon  every ~60 s

FILES
created  C:\Users\admin\AppData\Local\Temp\upd.dll
         SHA-256 fb18cd2a74c578b056a81a207cfe4b93d412c707c7f6751c0d4ea32219da4bf2

REGISTRY
set  HKCU\Software\Microsoft\Windows\CurrentVersion\Run\OneDriveUpdate
     = "rundll32.exe C:\Users\admin\AppData\Local\Temp\upd.dll,Start"

SIGNATURES
[high]   Office application spawns a script interpreter
[high]   PowerShell with encoded command line
[medium] Persistence via Run registry key
[medium] Queries keyboard layout          (T1614.001)
[low]    Checks for VirtualBox registry keys (T1497.001)

This run maps cleanly to ATT&CK: T1204.002, T1059.001, T1027.010, T1105, T1218.011, T1547.001, T1071.001. The full mapping method is in Understanding MITRE ATT&CK.

Malware authors know their samples will end up in sandboxes, so many check their environment first and simply do nothing (or something harmless) if it looks like an analysis machine. ATT&CK tracks these behaviours mainly under T1497 Virtualization/Sandbox Evasion, T1622 Debugger Evasion and T1480 Execution Guardrails.

A few widely used options, each with a different trade-off. Check each provider's current terms, as free offerings and visibility rules change.

A sandbox report is raw material. Turn it into something that protects the whole fleet, from the most fragile to the most durable level of the Pyramid of Pain:

For example, a first YARA rule built from this run:

rule LedgerLoader_Stage2_Training
{
    meta:
        description = "LedgerLoader second stage seen in sandbox run (training example)"
        author = "mlab Academy"
        date = "2026-10-21"
        hash = "fb18cd2a74c578b056a81a207cfe4b93d412c707c7f6751c0d4ea32219da4bf2"
    strings:
        $persist = "OneDriveUpdate" ascii wide
        $uri     = "/api/v1/beacon" ascii
        $stage   = "/s2/upd.dll" ascii
    condition:
        uint16(0) == 0x5A4D and filesize < 500KB and 2 of them
}