A suspicious file is detonated in a sandbox and does almost nothing. Traditionally, that lack of activity might suggest the file poses little risk.
But the more important question is why it stayed quiet. Did the file fail to execute, or did it recognize the sandbox and decide not to reveal what it could do?
Modern malware is increasingly selective about when it executes. It can look for virtualization artifacts, measure system timing, detect user activity, and check whether the host resembles a real endpoint.
Some strains even use trigonometry to determine whether mouse movements appear human or automated. If something looks artificial, the malware may remain dormant, delay execution, or conceal its primary function.
Virtualization and sandbox avoidance, mapped to ATT&CK technique T1497, now rank among the more prevalent evasion techniques observed in current threat activity. A sample that stays quiet during analysis may behave very differently once it reaches a real endpoint.
Why silent malware is still dangerous
Observable behavior has long been considered a source of truth by security teams. Any detonation that produces network traffic, credential access, changes to persistence, or memory injection gives analysts something to investigate.
However, if there is little or no visible activity, the instinct is to treat the sample as lower risk or of diminished value. That instinct is now dangerous. In many cases, inactivity is part of the tradecraft.
User-activity checks are one way malware verifies whether an environment is real. However, in automated settings, it can be difficult to mimic the small inconsistencies in human behavior.
Real endpoints can show browsing history, recent files, inconsistent mouse movement, pauses of varying lengths, and they can be filled with noise from typical work.
Sandboxes generally lack these things. Malware authors understand this, and many strains will wait for evidence of direct human interaction before proceeding, which makes the absence of behavior a possible indicator of evasion, rather than safety.
Take LummaC2 malware as an example. Instead of just checking if the mouse moves, it looks at how it moves. It samples cursor positions, measures the Euclidean distances and angles between them, and distinguishes real human movement from the smooth, straight lines generated by the scripts. Real mouse movement has micro curves, hesitations, and small changes in direction that scripts don’t have. If the math says the movement is fake, the malware stays inactive.
How malware evades sandbox detection
Malware also uses timing checks to avoid sandboxes.
Some types do more than just wait. For example, Blitz runs two threads in parallel and compares their performances. One thread runs CPUID instructions, while the other does floating-point math. On physical hardware, the result is usually above a certain value, showing that the system is real. In a virtual machine, extra overhead can lower the result, revealing the sandbox.
User-activity checks work differently. Some strains use them to decide whether a human is present, which can include waiting for realistic interaction, or, in LummaC2’s case, using trigonometry to determine whether mouse movement looks human or synthetic. When a suspicious file stays quiet after those checks, that may be deliberate evasion, rather than a lack of capability.
Attackers are now putting more effort into hiding, lasting longer, and avoiding detection.
Because of this, defenders need to reconsider what it means when a file seems quiet. A file that runs smoothly might still leave important clues. Did it check its surroundings before stopping? Did it look for signs that it was being analyzed? Did it wait for real mouse movement? Did it track how long it had been running, or try to outlast the test? These actions can tell you more than a clear attack can.
What defenders need to do differently
Security teams should stop assuming that a quiet result means that everything is safe. If a suspicious file runs, checks for how long it has been running or for user activity, and then does nothing, it needs a closer look.
Teams should test their defenses against malware that tries to avoid detection, instead of thinking all is well just because the sandbox found nothing. They should also watch for silent problems, like devices that stop sending logs or systems where security tools have been turned off or changed.
Analysis environments also need to be harder to fool. Hardware-assisted or bare-metal detonation environments are more difficult for malware to fingerprint. Time-based countermeasures can help by speeding time forward in a believable way, forcing malware that tries to wait out observation windows to reveal itself sooner.
When a file stays quiet, defenders should go beyond just looking at the file itself. They should use breach and attack simulations to see if their systems can still spot and respond to malware that delays its actions, checks its environment, or waits to act until things seem real.
Sandboxes used to make it easy to tell if a file was dangerous. Now, this is less reliable because some malware will stay quiet if it thinks it’s being watched. What seems inactive during testing might actually be checking its surroundings and waiting for a real system.
Teams need to reconsider what silence means. A file that does nothing isn’t always safe — it might just mean the malware knew it was being tested.