Anti-Analysis

Malware probes real outbound connectivity and bails when it hits the fake or filtered internet that analysis sandboxes commonly simulate.

Using GetTickCount uptime and the scarcity of recently-used files to detect freshly-booted automated analysis sandboxes.

The INT 2D kernel-debugging interrupt skews the instruction pointer under a debugger, so a debugger that mishandles it is revealed.

Detecting the Wine compatibility layer by probing for Wine-specific exports such as wine_get_unix_file_name in ntdll.

Malware raises an exception routed through its own SEH handler; if a debugger swallows it first the handler never runs, revealing the analysis.

Querying the display size lets malware spot the small or unusual resolutions typical of headless automated sandboxes and refuse to run.

Malware scans its own executable code pages for stray 0xCC (INT3) bytes that a debugger writes when planting a software breakpoint, then bails out or corrupts itself if any are found.

Detecting analysis sandboxes by checking for injected monitoring DLLs such as sbiedll.dll and cuckoomon.dll, or for API hooks they install.

Arming memory with PAGE_GUARD turns the first access into a one-shot STATUS_GUARD_PAGE_VIOLATION, exposing single-steppers and memory-scanning tools.

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.

Enumerating running processes and window titles to spot reverse-engineering tools such as x64dbg, Process Monitor, Wireshark, and OllyDbg.

A process debugs itself or a forked child so the single debug port is occupied, blocking any external debugger from attaching.

Reading the 12-byte vendor signature returned by CPUID leaf 0x40000000 to identify the specific hypervisor a sample is running under.

Malware monitors mouse movements, click counts, or browser history to determine whether it is running in a real user environment rather than an automated sandbox.

Malware measures elapsed wall-clock time with GetTickCount to detect the artificial slowdown caused by single-stepping or software breakpoints in a debugger.

Malware enumerates running processes to verify its parent is explorer.exe; an unexpected parent (e.g., a sandbox or analysis tool) triggers evasive behaviour.

Malware calls CheckRemoteDebuggerPresent (or NtQueryInformationProcess with ProcessDebugPort) to detect a user-mode debugger attached to the process.

Malware reads the CPU debug registers DR0–DR3 via GetThreadContext to detect hardware breakpoints set by a debugger.

Querying ProcessDebugPort, ProcessDebugFlags, and ProcessDebugObjectHandle through NtQueryInformationProcess to detect an attached debugger.

Malware inspects the Flags and ForceFlags fields of the process heap header (via PEB.ProcessHeap) to detect debugger-modified heap metadata.

Malware reads the NtGlobalFlag field of the PEB (offset 0x68/0xBC) to detect if the process was launched under a debugger via the 0x70 heap flag combination.

Malware compares each NIC's MAC OUI prefix against known VMware, VirtualBox, Hyper-V and QEMU ranges to decide if it is running inside a VM.

Sandboxes often patch Sleep() to fast-forward time so samples detonate quickly; malware detects the skipped delay by comparing wall-clock timestamps before and after sleeping.

On Linux, a process calls ptrace(PTRACE_TRACEME) on itself so that any debugger trying to attach later fails — a single process can only be traced once.

Calling NtSetInformationThread with ThreadHideFromDebugger detaches a thread from the debugger so its exceptions stop reaching the analyst.

A timing-based anti-analysis check that uses the high-resolution performance counter to detect single-stepping or breakpoint-induced execution delays.

Reading registry keys and service entries left by VirtualBox and VMware Guest Additions reveals a virtual machine to evasive malware.

Detecting a virtualized environment by checking bit 31 of ECX returned by CPUID leaf 1, and reading the hypervisor vendor string from leaf 0x40000000.

A legacy Windows trick that calls OutputDebugStringA after clearing the last-error code, then checks GetLastError: on old systems the call left the error untouched only when a debugger was attached.

Using the RDTSC instruction to measure execution time and detect the slowdown caused by single-stepping or breakpoints in a debugger.

A Windows API call that reads the BeingDebugged flag in the PEB to detect a user-mode debugger attached to the current process.