A file arrives that nobody asked for: an invoice you don't recognise, a ZIP from a supplier who never sends ZIPs, or a "shipping label" with an .exe inside. Double-clicking it on your work laptop is a bad idea. Opening it in a forensic lab isn't necessary either. A sandbox, meaning a throwaway virtual machine, sits comfortably in the middle. You give the sample a machine you don't care about and watch what it does, one behaviour at a time.

Why a Sandbox Is the Right First Move

Antivirus gives you a verdict: clean or malicious. A sandbox gives you a story. That difference matters, because a file can evade detection and still be obviously hostile once you watch it spawn a command shell, write to a startup folder, and try to reach a domain registered last week.

Two honest caveats. First, a sandbox is a controlled risk, not a guarantee. Malware does escape virtual machines, usually through the conveniences people leave switched on: shared folders, clipboard sharing, shared USB devices. Second, if the file arrived on a company device, tell your security team before you start. They may have legal obligations, an incident process, or a policy that overrides your curiosity.

Step 1: Build a Disposable Lab

What you need

• A hypervisor: VirtualBox, VMware Workstation Player, or Hyper-V.
• A Windows 10 or 11 guest with two cores, four gigabytes of RAM, and a 60 GB disk.
• A snapshot taken before anything else happens.
• A host-only or internal network adapter, never bridged.
• Optional but useful: a simulated internet service such as INetSim or FakeNet-NG.

Locking the guest down

Install the guest system, patch it, then immediately snapshot it and call that snapshot "clean base". From that point, every sample gets a fresh clone. Turn off shared folders, drag-and-drop, clipboard sharing, and USB passthrough. Don't sign into personal accounts inside the guest, and don't mount host drives. Set the network adapter to host-only so the machine can't reach your router, your NAS, or the printer.

Some samples refuse to run without internet access, since they check in with a server before doing damage. A simulated internet usually solves this. It answers DNS and HTTP locally, so you still see which domains and URLs the file wanted to contact, while nothing leaves your machine. If you truly need real connectivity, put the guest on a network you can tear down, and keep it away from anything you'd miss.

Step 2: Handle the Sample Without Touching It

Move the file inside a password-protected archive when you transfer it. That is standard practice in malware handling, and it also stops mail filters and endpoint protection from mangling the attachment before you get to it. Rename the extension as well, for instance from .exe to .exe_hold, so an accidental double-click does nothing.

Before you run anything, take a hash of the file. On Linux, sha256sum; in PowerShell, Get-FileHash; on a Windows command line, certutil -hashfile filename SHA256. The hash is a fingerprint you can search for later and compare against known samples. Keep it in your notes.

Be careful with public multi-engine scanning sites. They're excellent for a quick reputation check, but submitted files can be shared with partners and researchers. If the sample came from your employer, a client, or a customer, treat the content as confidential and stick to your own lab.

Step 3: Run It and Watch Three Channels

Behaviour falls into three buckets, and you want eyes on all of them at once.

Process behaviour

Process Explorer, SystemInformer, or Process Monitor will show you the process tree. The interesting pattern is a familiar program spawning something unexpected: Word launching cmd.exe, a PDF reader starting powershell.exe with a long encoded argument, or rundll32.exe loading a library from a temporary folder. Note the parent-child relationships and the command lines.

Network behaviour

Run Wireshark, or watch Process Monitor's network events. You're looking for the destination, not the payload: raw IP addresses with no domain, unusual ports, HTTP POST requests carrying data outward, DNS lookups for long random-looking names. With a simulated internet in place, you'll capture the domain names even when the connections fail.

File and registry behaviour

Take a system snapshot with Regshot before execution, run the sample, then compare. Cross-check with Process Monitor filters and Autoruns. Pay attention to new files in %AppData%, %Temp%, and the Startup folder, and to changes in Run keys, scheduled tasks, and services.

What the Signals Actually Mean

A few behaviours carry a lot of weight:

• Persistence. A Run key, scheduled task, or new service means the file wants to survive a reboot.
• Long sleeps. Waiting several minutes before acting is a common trick to outlast automated analysis.
• Anti-analysis checks. Strings such as "VBox", "VMware", or queries about disk size and mouse movement suggest the sample is deciding whether it's being watched.
• Self-deletion. A dropper that removes itself after running usually fetched something worse.
• Security tampering. Attempts to disable Defender, the firewall, or event logging.
• Rapid file changes and shadow copy deletion. Both point strongly toward ransomware.

Write down what you saw, in order, with timestamps. A timeline is worth more than a single indicator: "the document spawned PowerShell, which downloaded a second file, which registered a scheduled task two minutes later" tells a story nobody can argue with.

Mistakes That Break the Isolation

Most lab accidents come from a short list of habits. Skipping the snapshot, then realising halfway through that you'd like the machine back. Leaving the network adapter bridged "just for a moment". Copying a URL out through the clipboard and pasting it into a browser on the host. Running everything as administrator, which hides how the sample behaves under normal privileges. Keeping one long-lived VM stuffed with months of samples instead of cloning a clean base each time. Any one of these can undo an otherwise careful setup.

A Repeatable Routine

Build the clean base once and snapshot it. Clone it per sample. Hash the file, note where it came from, and disconnect sharing. Connect only to a simulated network, start your monitoring tools, then execute. Watch processes, connections, and file changes for ten to fifteen minutes, and again after a reboot. Capture screenshots, export the Process Monitor log, record the hash and the domains contacted. Then revert to the snapshot and, if the sample is a confirmed threat, share what you learned with the people who need it.

One more thing: if the file touched a real device before you got to it, or if the lab was compromised, stop and involve your security team or an incident response professional. Sandbox work is safe when it stays inside the box, and knowing when to hand it over is part of doing this well.

Photo: This_is_Engineering / Pixabay