What is Sandboxing?

NIST's glossary, quoting CNSSI 4009-2022, defines sandboxing as "a restricted, controlled execution environment that prevents potentially malicious software, such as mobile code, from accessing any system resources except those for which the software is authorized" (NIST CSRC). That covers browser tabs and mobile apps too. In a SOC the word nearly always means the analysis kind: a disposable virtual machine that runs a sample, watches it and hands back a report. The open-source CAPE sandbox, which grew out of Cuckoo, lists what that report is built from: behavioral instrumentation through API hooking, the files created, modified and deleted during the run, network traffic captured as PCAP, classification from behavioral and network signatures, desktop screenshots, and full memory dumps of the guest.

Where files get detonated

Many detonations happen before an analyst ever sees the file. Email security gateways open attachments and follow links before delivery. Next-generation firewalls and secure web gateways send downloads to a sandbox in line. EDR platforms submit unknown binaries from the endpoint, and SOAR phishing playbooks upload every attachment and URL from a reported email, then attach the verdict to the case. The manual upload, where you drag a file into ANY.RUN, Joe Sandbox or an internal CAPE, is the one where you choose the guest OS, the timeout and who gets to see the result.

How to read a detonation report

Read it in this order and leave the vendor's score for last. The score is the sandbox's opinion of the behavior; the behavior is what you will defend in the case notes.

1. Did it actually run? Check the screenshots, the run length and the guest OS. One process, no children and no traffic can mean the file is benign, broken, built for another OS, or waiting the sandbox out. The report alone can't tell you which.
2. Process tree. Who started whom. WINWORD.EXE starting cmd.exe, powershell.exe or mshta.exe is the shape of a malicious document. A binary started from %TEMP% with a long encoded command line is the shape of a loader.
3. Dropped files. The attachment is what the user received; the dropped files are what would have stayed on the host. Copy the hashes of both.
4. Registry. Writes to autostart locations, which Microsoft's Sysmon documentation names as the reason to watch registry create and delete events, are the persistence attempt. Note the exact key and value.
5. DNS and network. Domains resolved, IPs contacted, ports and HTTP paths. Separate the sample's traffic from the guest's own background traffic before anything goes into a blocklist.
6. Signatures and score. Read which behaviors matched, not just the number.

From the report to your own endpoints

Every section of the report has a counterpart in your own telemetry:

Three details in the Sysmon documentation change what you can expect to find. Event ID 3 is disabled by default, so a host on a minimal configuration has no record of the connection the sandbox saw. Event ID 22 relies on telemetry added in Windows 8.1, so Windows 7 hosts produce none. And Event ID 1 carries the file hash in the algorithms the configuration selects (<HashAlgorithms>), which is what lets you match a sandbox hash against process starts.

Did the file run on your endpoints?

Defender XDR advanced hunting covers up to 30 days of raw data. Start with the hashes from the report. Microsoft's schema reference for both DeviceFileEvents and DeviceProcessEvents says the SHA256 column "is usually not populated" and to use SHA1 when available, so match on both:

// Hashes copied from the detonation report
let ReportSha1 = "<SHA-1 from the report>";
let ReportSha256 = "<SHA-256 from the report>";
union
    (DeviceFileEvents
    | where Timestamp > ago(30d)
    | where SHA1 == ReportSha1 or SHA256 == ReportSha256
    | project Timestamp, DeviceName, ActionType, FileName, FolderPath,
        FileOriginUrl, InitiatingProcessFileName),
    (DeviceProcessEvents
    | where Timestamp > ago(30d)
    | where SHA1 == ReportSha1 or SHA256 == ReportSha256
    | project Timestamp, DeviceName, ActionType, FileName, FolderPath,
        ProcessCommandLine, InitiatingProcessFileName)
| order by Timestamp asc

• Hits in DeviceFileEvents only: the file landed (a download, a saved attachment, a copy) and nothing recorded it starting. FileOriginUrl shows where it came from.
• Hits in DeviceProcessEvents: it ran. The DeviceName values are your scope; follow each process tree from there.
• No hits: not proof of absence. A DLL never shows up as a process of its own, because rundll32.exe or another host process loads it. Look for its hash in DeviceImageLoadEvents too.

Then take the network section of the report:

// Domains and IPs from the report's network section
let ReportDomains = dynamic(["<domain-1>", "<domain-2>"]);
let ReportIPs = dynamic(["<ip-1>"]);
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where RemoteUrl has_any (ReportDomains) or RemoteIP in (ReportIPs)
| summarize FirstSeen = min(Timestamp), LastSeen = max(Timestamp), Connections = count()
    by DeviceName, InitiatingProcessFileName, RemoteUrl, RemoteIP
| order by FirstSeen asc

InitiatingProcessFileName is the column to read. A browser reaching the domain is a user who clicked a link. A binary from a Downloads or Temp folder reaching it is the sample, or its second stage, calling out. Both queries use documented columns of these tables; SOCSimulator has not run them against a live tenant.

Sandbox evasion: why a clean report is not a clean file

MITRE ATT&CK tracks this as T1497, Virtualization/Sandbox Evasion, with three sub-techniques:

On the sandbox side, ANY.RUN's plans page (checked October 2026) lists a 60-second VM timeout on its free Community plan, against 660 and 1,200 seconds on the paid tiers. A sample that sleeps for two minutes produces an empty 60-second report.

When the report is clean and the alert still looks wrong, re-run with a longer timeout and a guest OS that matches your fleet, use interactive mode to open the document and click through it yourself, and run the hunting queries above anyway.

Public sandboxes and what you upload

ANY.RUN's plans page also says public submissions and their reports are available to all users and may be used for research, asks users not to upload personal or confidential third-party data in public mode, and keeps private analyses to its paid plans. A phishing attachment can be a real invoice, a real contract or an employee's own file. Search the hash first: if the sample is already known, you get a report without uploading anything. If it isn't, and it may hold customer or employee data, use a private or internal sandbox.

Windows Sandbox is not an analysis sandbox

Windows Sandbox turns up in the same searches and does a different job. Microsoft describes it as a lightweight, isolated desktop that runs its own kernel on the Microsoft hypervisor and discards all software, files and state when it closes; it isn't available on Windows Home. It records nothing for you: no process tree, no PCAP, no report. Software installed on the host isn't available inside, so a monitoring tool has to be installed in every session. Microsoft also warns that networking is on by default and that enabling it can expose untrusted applications to the internal network, so turn it off in the .wsb configuration file before you open anything suspicious.