Chapter 4

WOW64

How 32-bit applications run on 64-bit Windows: the WOW64 emulation layer, Heaven's Gate, filesystem and registry redirection, and why these redirections are a persistent source of detection blind spots

Scenario

A 32-bit malware sample drops a payload to C:\Windows\System32\malware.dll — except it doesn't. Because the sample is 32-bit and running under WOW64, "System32" is silently redirected to SysWOW64. Your detection rule looking for drops to System32 misses it. To close this blind spot, you need to understand WOW64 redirection and how to account for it in detection logic.

What WOW64 Is

WOW64 (Windows on Windows 64) is the compatibility subsystem that allows 32-bit applications to run on 64-bit Windows. The 64-bit OS runs 32-bit code in a constrained compatibility mode, with WOW64 acting as a translation layer between the 32-bit application and the 64-bit kernel.

WOW64 is implemented as a set of DLLs that are injected into every 32-bit process:

wow64.dll — Core WOW64 layer; handles system call thunking
wow64win.dll — WOW64 user interface extensions (GUI 32-to-64 translation)
wow64cpu.dll — CPU emulation for 32-bit x86 execution on 64-bit processor


  32-bit Process Running Under WOW64
  ─────────────────────────────────────────────────────────────────
  ┌────────────────────────────────────────────────────────────┐
  │  32-bit Application Code (x86)                            │
  │  32-bit stack, 32-bit registers (EAX, ESP, etc.)          │
  └──────────────────────────┬─────────────────────────────── ┘
                             │ calls
  ┌──────────────────────────▼─────────────────────────────── ┐
  │  32-bit ntdll.dll (SysWOW64\ntdll.dll)                    │
  │  Provides Win32 API stubs in 32-bit form                  │
  └──────────────────────────┬─────────────────────────────── ┘
                             │ 32-bit syscall attempt
  ┌──────────────────────────▼─────────────────────────────── ┐
  │  wow64.dll / wow64cpu.dll                                 │
  │  Intercepts 32-bit syscall                                │
  │  Thunks 32-bit arguments → 64-bit equivalents            │
  │  Executes Heaven's Gate (far JMP to 64-bit mode)          │
  └──────────────────────────┬─────────────────────────────── ┘
                             │ 64-bit syscall
  ══════════════════════ USER/KERNEL BOUNDARY ═════════════════
  ┌──────────────────────────▼─────────────────────────────── ┐
  │  64-bit Windows Kernel                                    │
  │  Always 64-bit; no 32-bit kernel on 64-bit Windows        │
  └─────────────────────────────────────────────────────────── ┘

32-bit Process Memory Layout Under WOW64

A 32-bit process under WOW64 has a 4GB virtual address space — the same as on native 32-bit Windows. However, the actual usable address space is limited to 2GB (or 3GB with the /LARGEADDRESSAWARE flag) because the upper 2GB are reserved for kernel-mode mappings in 32-bit mode. The WOW64 translation code itself lives in the upper portion of this 4GB space.

Simultaneously, the 64-bit OS has its full 128TB virtual address space. The WOW64 process exists as a 64-bit process that hosts the 32-bit code — it has both a 32-bit stack and execution mode, and the 64-bit stack used by the WOW64 thunking layer.

The SysWOW64 vs System32 Split

The directory names in Windows are confusing by historical accident:

Directory	Contains	Accessible to
`C:\Windows\System32\`	64-bit system DLLs and executables	64-bit processes (and 32-bit processes that disable redirection)
`C:\Windows\SysWOW64\`	32-bit system DLLs and executables	32-bit processes (via automatic redirection)
`C:\Windows\Sysnative\`	Virtual path — alias for real System32	32-bit processes wanting to bypass redirection (not real filesystem path)

The naming seems backwards ("SysWOW64 has 32-bit DLLs?") because it was named from the perspective of the 64-bit OS: "SysWOW64 is the System directory for WOW64 (32-bit) programs." System32 kept the name for compatibility even though it now holds 64-bit binaries.

Filesystem Redirection

When a 32-bit process accesses C:\Windows\System32\, WOW64 transparently redirects the path to C:\Windows\SysWOW64\. This happens in the kernel — the process doesn't need to do anything. The redirection is seamless from the application's perspective: it thinks it's accessing System32, but the kernel maps the path to SysWOW64.


  WOW64 Filesystem Redirection
  ─────────────────────────────────────────────────────────────────
  32-bit process writes to:           Actual write goes to:
  C:\Windows\System32\       ──────►  C:\Windows\SysWOW64\
  C:\Windows\System32\cmd.exe ──────►  C:\Windows\SysWOW64\cmd.exe (32-bit cmd)

  These paths are NOT redirected:
  C:\Windows\Sysnative\      ──────►  C:\Windows\System32\ (bypass redirection)
  C:\Windows\SysWOW64\       ──────►  C:\Windows\SysWOW64\ (already there, no redirect)
  C:\Program Files\          ──────►  C:\Program Files (x86)\ (separate program files redirect)

  Additional redirects:
  C:\Program Files\          ──────►  C:\Program Files (x86)\
  C:\Windows\lastgood\       ──────►  C:\Windows\lastgood\  (no redirect)

Disabling Redirection Programmatically

// 32-bit process can temporarily disable WOW64 filesystem redirection
// to access the real System32 directory

PVOID oldValue;
BOOL disabled = Wow64DisableWow64FsRedirection(&oldValue);
if (disabled) {
    // Now accessing C:\Windows\System32\ reaches the REAL System32 (64-bit)
    CopyFile("C:\\Windows\\System32\\payload.dll", ...);

    // Restore redirection when done
    Wow64RevertWow64FsRedirection(oldValue);
}

// Alternatively, use Sysnative virtual path (no API call needed):
// CreateFile("C:\\Windows\\Sysnative\\notepad.exe", ...)
// This bypasses WOW64 redirection even from a 32-bit process

Malware uses Wow64DisableWow64FsRedirection() to drop payloads into the real System32 directory from a 32-bit dropper. This is a reliable detection signal: a 32-bit process calling Wow64DisableWow64FsRedirection before writing to System32 is almost always malicious or suspicious.

Registry Redirection

The registry has a similar redirection mechanism for 32-bit processes. When a 32-bit process accesses HKEY_LOCAL_MACHINE\SOFTWARE\, WOW64 redirects it to HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\.

32-bit Process Reads/Writes	Actual Registry Path
`HKLM\SOFTWARE\`	`HKLM\SOFTWARE\WOW6432Node\`
`HKCU\SOFTWARE\`	`HKCU\SOFTWARE\` (NOT redirected — same path)
`HKLM\SOFTWARE\Classes\`	`HKLM\SOFTWARE\WOW6432Node\Classes\`

A 32-bit process setting a Run key at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run actually writes to HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run. Windows processes both Run key locations at startup — so the persistence works, but your detection rule monitoring only HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run may miss it.

// A 32-bit process can explicitly access the 64-bit registry view using
// KEY_WOW64_64KEY flag to bypass redirection:
HKEY hKey;
RegOpenKeyExA(
    HKEY_LOCAL_MACHINE,
    "SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion",
    0,
    KEY_READ | KEY_WOW64_64KEY,   // bypass WOW64 registry redirection
    &hKey
);
// This reads the REAL 64-bit HKLM\SOFTWARE\..., not WOW6432Node

Heaven's Gate

Heaven's Gate is the mechanism by which a 32-bit process transitions to 64-bit mode to execute 64-bit code. It exploits the fact that the x86-64 CPU can run both 32-bit (compatibility mode) and 64-bit (long mode) code in the same process — distinguished by the code segment selector in the CS register.


  Heaven's Gate — Far Jump from 32-bit to 64-bit Code
  ─────────────────────────────────────────────────────────────────
  32-bit code running in WOW64 process:
  CS = 0x23  (32-bit code segment — compatibility mode)

  To switch to 64-bit mode:
      jmp far 0x33:64bit_address   ; far JMP to 64-bit code segment
  or
      call far [mem] where [mem] = {0x33, 64bit_address}

  CS = 0x33  (64-bit code segment — long mode)

  Now executing 64-bit instructions:
      mov rax, 0x1234567890ABCDEF  ; 64-bit register access
      syscall                       ; 64-bit system call

  To return to 32-bit:
      retf                          ; far return back to CS=0x23

WOW64's wow64cpu.dll uses this exact mechanism to execute 64-bit syscalls from a 32-bit process. Malware exploits Heaven's Gate to break out of WOW64's constraints and directly execute 64-bit code — including 64-bit shellcode injected into 64-bit processes — from a 32-bit dropper.

; Heaven's Gate implementation (32-bit x86 assembly)
; Used by malware to execute 64-bit shellcode from a 32-bit process

bits 32

HeavensGate:
    jmp  far [jump_target]  ; far JMP: switches CS to 0x33 (64-bit)
    ; execution continues in 64-bit mode after this

jump_target:
    dd  payload_64bit        ; 32-bit address of 64-bit code
    dw  0x33                 ; new CS selector (64-bit long mode)

bits 64
payload_64bit:
    ; now in 64-bit mode — all 64-bit instructions available
    mov  rax, 0x00007FFXXXXXXXXX  ; can address full 64-bit space now
    syscall
    retf                         ; return to 32-bit mode

Malware Abuse of WOW64

Technique	What It Does	Detection
Heaven's Gate shellcode	32-bit dropper injects 64-bit shellcode into 64-bit process	32-bit process creating remote thread in 64-bit process; unusual CS transitions in ETW
WOW64 redirection bypass	Drop payload to real System32 from 32-bit process	Wow64DisableWow64FsRedirection API call; unexpected files in real System32
Registry redirection bypass	Write to 64-bit Run key from 32-bit process using KEY_WOW64_64KEY	Registry modification with KEY_WOW64_64KEY flag in process monitor
Spawning 64-bit child	32-bit process spawns 64-bit process using Sysnative path	Parent/child architecture mismatch; Sysnative in command line
WOW64 EDR hook bypass	EDR hooks 32-bit ntdll; malware uses Heaven's Gate to call 64-bit ntdll directly	Kernel-mode telemetry; syscall return address outside ntdll range

Detection Engineering Note

Detection rules targeting file system paths must account for WOW64 redirection. A Sigma rule for "DLL dropped to System32" needs to check both C:\Windows\System32\ AND C:\Windows\SysWOW64\. Similarly, registry persistence rules need to check both SOFTWARE\Microsoft\... and SOFTWARE\WOW6432Node\Microsoft\... Run key variants. Sysmon normalizes some of this — its image path events show the post-redirection path — but not all SIEM data sources do.

Q & A

Why would modern malware still ship as 32-bit when 64-bit is available?

Several reasons: (1) Maximum compatibility: A 32-bit executable runs on both 32-bit and 64-bit Windows. A 64-bit executable only runs on 64-bit Windows. Malware designed for mass deployment targets the broadest possible victim base, and some older systems and embedded devices still run 32-bit Windows. (2) Shellcode portability: 32-bit shellcode for exploits (buffer overflows, use-after-free) is often simpler to write and more broadly applicable. (3) Heaven's Gate evasion: A 32-bit dropper using Heaven's Gate can execute 64-bit code while the process itself appears as a 32-bit process. Some EDR products and security tools had blind spots for this cross-mode execution. (4) WOW64 blind spots in EDR: Historically, some EDR products hooked only the 64-bit ntdll, missing calls made through the 32-bit WOW64 path. The intersection of 32-bit and 64-bit code execution creates more complexity for defenders to cover. The trend is toward 64-bit malware for sophisticated targets, but 32-bit malware remains common for commodity campaigns targeting mixed environments.

If I see "Sysnative" in a process command line, is that always suspicious?

Not always, but it's a high-signal indicator worth investigating. The Sysnative virtual path is needed when a 32-bit process (specifically, a WOW64 process) needs to run a 64-bit executable from System32 without filesystem redirection silently substituting the SysWOW64 version. Legitimate uses: (1) 32-bit installer frameworks that need to call 64-bit tools. (2) 32-bit management scripts that invoke 64-bit executables. (3) SCCM/Intune management agents that are 32-bit but need to run 64-bit tools. Suspicious uses: a 32-bit malware dropper using C:\Windows\Sysnative\cmd.exe to execute a 64-bit command interpreter, which then has no WOW64 constraints and can access the full 64-bit filesystem and registry without redirection. The key contextual questions: What is the 32-bit parent process? Is it a known installer/management tool, or something unexpected like an Office document macro? What command follows the Sysnative path? Benign Sysnative invocations typically call specific known tools; malicious ones often call cmd.exe, powershell.exe, or drop a specific payload.

How does Heaven's Gate affect EDR telemetry?

Heaven's Gate creates a blind spot for user-mode EDR hooks because the mode switch bypasses the normal syscall path. When a 32-bit process uses Heaven's Gate to execute a 64-bit syscall: (1) The 32-bit ntdll stub is never called — so hooks on the 32-bit ntdll don't fire. (2) The 64-bit ntdll stub may also be bypassed if the malware executes its own inline syscall instructions — so hooks on 64-bit ntdll don't fire either. Modern EDRs defend against this through kernel-mode monitoring: the kernel doesn't care what mode the user-mode code was in before the SYSCALL instruction executed — it still handles the system call the same way and still fires kernel callbacks. So process creation, thread creation, image load, and network connection events generated through kernel callbacks are unaffected by Heaven's Gate. The telemetry gap is in user-mode event monitoring that relies on API hooks. If your EDR relies on a kernel driver with proper callback registrations, Heaven's Gate provides no evasion advantage against that monitoring.