Module 5: Sandbox Detection & Process Protection

The Sandbox Problem

Sandboxes are purpose-built analysis VMs. They share common characteristics that distinguish them from real workstations: low resource allocation (RAM, CPU, disk), generic hostnames and usernames, specific virtualization drivers, and the presence of analysis tools. Hooka exploits these artifacts through eight distinct detection functions, each targeting a different sandbox fingerprint. Individually, each check has false-positive potential — but combined, they provide high-confidence detection.

RAM Size Detection

Sandboxes typically allocate minimal RAM to their analysis VMs — often 2–4 GB. Real workstations in 2024 almost always have 8 GB or more. CheckMemory() queries the total physical memory via GlobalMemoryStatusEx and flags environments with less than 4 GB of RAM as probable sandboxes.

Gofunc CheckMemory() (bool, error) {
    // Uses GlobalMemoryStatusEx to get total physical RAM
    // Returns true if RAM < 4GB (sandbox indicator)
}

Disk Size Detection

Analysis VMs use thin-provisioned disks that are often 40–80 GB. Production machines almost always have 100 GB+. CheckDisk() calls GetDiskFreeSpaceExW on the system drive and flags disks smaller than 100 GB total capacity.

Network Connectivity Check

Many sandboxes run in isolated network environments without internet access to prevent malware from reaching C2 infrastructure. CheckInternet() attempts an HTTP connection to a known-good external endpoint. Failure to connect suggests an isolated sandbox environment.

Hostname Pattern Matching

Sandbox VMs frequently use default or generic hostnames. CheckHostname() retrieves the machine hostname via os.Hostname() and compares it against a list of known sandbox hostname patterns:

• WIN-* and DESKTOP-* with random suffixes
• SANDBOX, MALWARE, VIRUS
• JOHN-PC, TEQUILABOOMBOOM
• Other common sandbox default names

Username Pattern Matching

Similar to hostname checks, sandboxes often run under predictable usernames. CheckUsername() retrieves the current user via os.Getenv("USERNAME") and checks against known sandbox defaults:

• admin, administrator, user
• malware, sandbox, virus
• test, sample, analyst

CPU Core Count

Sandboxes allocate minimal CPU resources — often a single core or two. CheckCpu() queries the processor count via runtime.NumCPU() and flags systems with fewer than 2 cores as likely VMs. Most physical workstations have 4+ cores.

Virtualization Driver Detection

Hypervisors install specific drivers that are visible from within the guest. CheckDrivers() enumerates loaded drivers and checks for signatures from common virtualization platforms:

Analysis Tool Detection

If analysis tools are running, the environment is almost certainly being monitored. CheckProcess() enumerates running processes via CreateToolhelp32Snapshot and looks for known analysis and debugging tools:

• Network analysis: wireshark.exe, tcpdump.exe, fiddler.exe
• Process monitoring: procmon.exe, procexp.exe, processhacker.exe
• Debuggers: x64dbg.exe, x32dbg.exe, ollydbg.exe, windbg.exe, ida.exe, ida64.exe
• Sandbox agents: vmsrvc.exe, vboxservice.exe, vmtoolsd.exe

Target Restriction Flags

These flags are particularly useful in targeted operations where you know the exact username and hostname of the target machine. If the loader lands on the wrong system (analyst VM, wrong workstation), it exits without executing any payload.

BlockDLLs() — Self-Protection

BlockDLLs() applies the DLL blocking policy to the current process. It calls NtSetInformationProcess with ProcessMitigationPolicy to enable the PROCESS_CREATION_MITIGATION_POLICY_BLOCK_NON_MICROSOFT_BINARIES_ALWAYS_ON flag. After this call, any attempt to load a DLL that is not signed by Microsoft will fail.

CreateProcessBlockDLLs(cmd) — Spawn Protected Process

CreateProcessBlockDLLs(cmd) creates a new process with DLL blocking enabled from the start. It uses CreateProcessW with an extended startup info structure containing the mitigation policy attribute. This is particularly useful when spawning a sacrificial process for injection — the target process is protected from EDR DLL injection from the moment it starts.

Go// CreateProcessBlockDLLs spawns a new process with non-MS DLL blocking
func CreateProcessBlockDLLs(cmd string) (*windows.ProcessInformation, error) {
    // 1. Initialize STARTUPINFOEX with PROC_THREAD_ATTRIBUTE_LIST
    // 2. Set PROC_THREAD_ATTRIBUTE_MITIGATION_POLICY
    // 3. Enable BLOCK_NON_MICROSOFT_BINARIES_ALWAYS_ON
    // 4. CreateProcessW with EXTENDED_STARTUPINFO_PRESENT
}

Hooka's Sleep() Function

Hooka implements a custom sleep mechanism that delays execution without using the obvious kernel32.Sleep API. This serves two purposes:

• Time-based evasion: delays execution past the sandbox's analysis window
• API-level stealth: avoids hooking on the standard Sleep function

The --sleep CLI flag inserts a sleep call at the very beginning of the loader's execution, before any sandbox checks or injection occurs.