Your sample does nothing in the sandbox, but the SOC observed it active on a real host. What's the likely reason and your response?
Short answer
Malware commonly checks for VM/sandbox artifacts, short run times, or user interaction and stays dormant when it sees them. Disguise and harden the analysis VM, lengthen execution, or move to bare metal, and pull behavior from a memory image of the live host. Assuming it's broken or that the host was wrong ignores a sample proven malicious in the wild. A reboot changes nothing because the evasion logic still fires every run.
When a sample is inert in your sandbox yet demonstrably active on a production host, the interviewer is checking whether you trust your tools over the evidence — or the other way around. The host telemetry is ground truth; the sandbox is the thing that failed.
Why anti-analysis is the likely answer
Modern malware routinely fingerprints its environment before doing anything. It looks for VM and sandbox artifacts (specific drivers, MAC ranges, registry keys, low core/RAM counts), checks for analyst presence (recent files, mouse movement, uptime), and uses timing tricks (long sleeps that outlast a sandbox's short capture window). If it smells analysis, it simply does nothing — which is exactly what you observed. The response is to defeat those checks: harden and disguise the VM to look like a real workstation, extend the run time past the sleeps, simulate user interaction, and where needed analyze on bare metal. Critically, because the SOC already has a live infection, you can pull a memory image from the real host and recover the malware's behavior directly — often the fastest route of all.
Why the other options are wrong
- The sample is simply broken. It ran on a real host; "broken" code doesn't selectively work in production. This explanation ignores the one piece of hard evidence you have.
- The host's report was mistaken. Dismissing SOC telemetry to protect your sandbox result is backwards. The detection on a real machine is more authoritative than your lab's silence.
- Reboot the sandbox and hope. The evasion logic runs identically on every boot. Rebooting changes nothing and wastes time while the live host stays compromised.
What interviewers look for
A senior answer names specific evasion checks, explains concrete countermeasures (VM hardening, extended runtime, bare metal), and — the standout move — pivots to memory forensics on the already-infected host instead of fighting the sandbox. The judgment being probed is humility about tooling: when your environment and the real world disagree, the real world wins, and you adapt the analysis to it.
Likely follow-ups
- Name three concrete artifacts malware checks to fingerprint a sandbox, and how you'd hide each.
- Why is memory forensics of the already-infected host often the fastest path when the sample won't detonate?
- How would you trigger user-interaction-gated behavior (sleeps, mouse movement, specific domains) in your lab?