Sandbox DLL Detection

Many sandboxes and isolation products inject a helper DLL into every monitored process to intercept API calls. Malware checks whether such a module is loaded — sbiedll.dll for Sandboxie, cuckoomon.dll / cmonitor.dll for Cuckoo, dbghelp.dll and api_log.dll for other instrumentation — and refuses to run when it finds one.

A second, stealthier variant inspects the prologues of common APIs for the trampolines those DLLs install, detecting the hooks rather than the module.

How it works

The simplest form calls GetModuleHandle on each suspicious DLL name; a non-NULL handle means the module is mapped into the process.

#include <windows.h>

const wchar_t *mods[] = {
    L"sbiedll.dll",    // Sandboxie
    L"cuckoomon.dll",  // Cuckoo Sandbox
    L"api_log.dll",    // generic API monitor
    L"dir_watch.dll",
    L"cmonitor.dll"
};

for (int i = 0; i < 5; i++)
    if (GetModuleHandleW(mods[i]) != NULL)
        ExitProcess(0);  // Sandbox monitoring DLL present.

The hook-detection variant reads the first bytes of an export such as NtWriteVirtualMemory and tests for a patched prologue (E9 jmp, FF 25 jmp indirect, or an int 3) instead of the genuine mov eax, <syscall> stub.

Detection & analysis

• Static analysis: look for GetModuleHandle / LoadLibrary calls referencing monitoring DLL names, or code that reads the first few bytes of an ntdll export and compares them against expected syscall-stub opcodes.
• Dynamic analysis: when analyzing under Sandboxie or Cuckoo, rename or unload the injected module, or hook GetModuleHandle to return NULL for the blocklisted names. Prefer hardware-assisted tracing that needs no in-process DLL.
• Detection rule hint: YARA-match the DLL-name strings (sbiedll.dll, cuckoomon.dll) alongside GetModuleHandle; in telemetry, flag reads of API prologue bytes immediately followed by a comparison and early exit.