Malware
Sandbox
Sandbox is a controlled environment where you run a file or load a page to watch what it does, with limits so it cannot hurt anything real. It answers 'what does this do?' without trusting it.
How it is measured
A sandbox run produces a behavior report: files created or changed, processes started, cron or registry changes, DNS lookups, and outbound connections with their contents. For web content, a headless browser with network capture records scripts loaded, redirects followed, and requests made.
Quality depends on isolation and realism. Block access to your real network, use throwaway credentials, and give the sample believable input and time. Some malware waits minutes or checks for a virtual machine before acting, so a quiet report may only mean it noticed.
Worked example
A shop owner receives a zip with 'shipping_label.js'. In a disposable Linux VM with no shared folders, running it under Node with network logging shows one DNS lookup for 'cdn-files-view.example' and a POST containing the machine's hostname and username, then a download of a 200 KB file.
The same file run on the owner's laptop would have fetched that second file and installed it. The sandbox gave the domain and the exfiltrated fields at no cost. The domain goes into the blocklist and the file hash into the ticket.
How it differs
Quarantine holds a suspect file still. A sandbox lets it run, in a cage, so you can learn its behavior. Quarantine is for containing and sandbox is for studying.
Common errors
Running a sample in a VM with a shared clipboard or folders. Leaving access to the internal LAN. Concluding 'harmless' from a quiet 30-second run. Using a sandbox the malware recognizes. Putting real credentials in the test.
In practice
Keep a throwaway VM, snapshotted clean, with no shared folders and networking restricted to a logging proxy. Run suspect files and pages there, record the domains and files they touch, and revert the snapshot after each run. Feed what you learn into your blocklist.