Skip to content
Reverse Engineering
Anti-Analysisbeginner

CPU Core & RAM Sandbox Check

Malware checks CPU core count, RAM and disk size and exits without running its payload if the host looks too small — a hallmark of automated sandboxes.

Automated malware sandboxes are usually provisioned with minimal resources to maximise the number of samples a host can analyse in parallel: one or two virtual CPUs, 1–2 GB of RAM, and a small disk. Real user machines, by contrast, ship with four or more cores, 8 GB or more of memory, and disks measured in hundreds of gigabytes.

Malware turns this asymmetry into a sandbox check. It queries the core count, physical memory and disk size, and if any value falls below a threshold it assumes it is being detonated in an analysis environment and refuses to run — exiting silently or branching to inert decoy code so the sandbox observes nothing malicious.

The checks are individually weak (an analyst can simply provision a beefier VM), but they are cheap, require no special privileges, and combine with MAC-OUI checks, timing checks and artefact scans into a layered fingerprint that defeats default sandbox configurations.

How it works

c
#include <windows.h>

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

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

    ULARGE_INTEGER freeC, totalC, freeAll;
    if (GetDiskFreeSpaceExW(L"C:\\", &freeC, &totalC, &freeAll))
        if (totalC.QuadPart < (60ULL << 30))    // < 60 GB system disk
            return TRUE;

    return FALSE;
}

On Linux the equivalent reads nproc/sysconf(_SC_NPROCESSORS_ONLN), parses MemTotal from /proc/meminfo, and calls statvfs("/") for disk size:

c
long cores = sysconf(_SC_NPROCESSORS_ONLN);
if (cores < 2) bail_out();
// parse /proc/meminfo -> MemTotal; statvfs("/") -> f_blocks * f_bsize

Detection & analysis

Static analysis:

  • Look for GetSystemInfo/dwNumberOfProcessors, GlobalMemoryStatusEx/ullTotalPhys, and GetDiskFreeSpaceExW (Windows) or sysconf(_SC_NPROCESSORS_ONLN), /proc/meminfo reads and statvfs (Linux), with the returned values compared against small constants (2, 2<<30, 60<<30).
  • A cluster of these three queries feeding an early ExitProcess/return is the recognisable shape of a resource-floor sandbox check.

Dynamic analysis:

  • Provision the analysis VM with realistic specs — 4+ cores, 8 GB+ RAM, a 100 GB+ disk — so every threshold passes and the payload detonates.
  • Alternatively, hook GetSystemInfo/GlobalMemoryStatusEx/GetDiskFreeSpaceExW (or patch the comparison branches) to return host-like values.

Detection rule hint:

Flag code that reads CPU core count, total physical RAM and disk size and compares each against a low threshold, then terminates or skips its main routine when the host is too small — this resource-floor pattern is characteristic of sandbox evasion rather than legitimate capability detection.

Votes

Comments(0)