Skip to content

Hardware Fingerprint Sandbox Check

Malware queries CPU count, RAM size and disk capacity; the unrealistically small resources typical of automated sandboxes betray the analysis environment and suppress detonation.

Automated malware sandboxes are usually provisioned with minimal resources to maximise throughput: one or two CPU cores, a couple of gigabytes of RAM, and a small virtual disk. Malware fingerprints the machine by querying these values and compares them against thresholds a real user's workstation would easily exceed. If the box looks too small, the sample assumes it is in a sandbox and exits or stays dormant.

This is a beginner-level evasion that uses only documented APIs and no privileged operations, which makes it cheap to bolt onto any sample.

How it works

The malware reads processor count, physical memory and disk size, then rejects anything below realistic minimums.

c
#include <windows.h>

BOOL LooksLikeSandbox(void)
{
    SYSTEM_INFO si;
    GetSystemInfo(&si);
    if (si.dwNumberOfProcessors <= 2)            // too few cores
        return TRUE;

    MEMORYSTATUSEX ms = { sizeof(ms) };
    GlobalMemoryStatusEx(&ms);
    if (ms.ullTotalPhys < (4ULL << 30))          // < 4 GB RAM
        return TRUE;

    ULARGE_INTEGER freeBytes, totalBytes, totalFree;
    GetDiskFreeSpaceExW(L"C:\\", &freeBytes, &totalBytes, &totalFree);
    if (totalBytes.QuadPart < (60ULL << 30))     // < 60 GB disk
        return TRUE;

    return FALSE;
}

Disk size is also frequently queried with DeviceIoControl(IOCTL_DISK_GET_LENGTH_INFO), and core count via GetNativeSystemInfo or the NumberOfProcessors field in the PEB.

Detection & bypass

  • Static — Grep in IDA/Ghidra for imports of GetSystemInfo/GetNativeSystemInfo, GlobalMemoryStatusEx, GetDiskFreeSpaceExW, and DeviceIoControl with the IOCTL_DISK_GET_LENGTH_INFO control code. Look for the returned fields compared against round thresholds (2, 0x100000000 for 4 GB, etc.).
  • Dynamic — In x64dbg, breakpoint on kernel32!GlobalMemoryStatusEx, kernel32!GetSystemInfo, and kernel32!GetDiskFreeSpaceExW; inspect the structures they fill on return and the comparisons that follow to learn the exact thresholds the sample uses.
  • Patch / bypass — Provision a realistic analysis VM (4+ cores, 8 GB+ RAM, 200 GB+ disk) so every check passes naturally. Otherwise hook the query APIs to return large values, or patch the threshold constants / invert the conditional jumps that branch to the exit path.
  • Tools — A well-resourced VM template; Frida/ScyllaHide-style API hooks to inflate the reported values; x64dbg conditional-jump patching; tools like Pafish to verify your environment no longer trips common resource checks.
Votes

Comments(0)