Module 2 — User Mode and Syscalls

Path: Module 1 · Next: Module 3

0. Purpose

Connect API names in logs to kernel actions. When you see VirtualAlloc, NtOpenProcess, or syscall, you should know they are different layers of the same story.

1. ELI5

You want a glass of water (allocate memory, open a file):

1. You ask the hotel front desk (kernel32.dll) in plain language
2. The desk calls internal operations (ntdll.dll) with the building's formal procedure names (Nt*)
3. Operations rings the basement intercom (syscall) — only then does the manager act

EDR is like security cameras at the desk and the intercom.

2. Deep breakdown

sequenceDiagram
  participant App as Application
  participant K32 as kernel32.dll
  participant NTD as ntdll.dll
  participant Kern as ntoskrnl.exe

  App->>K32: VirtualAlloc(...)
  K32->>NTD: NtAllocateVirtualMemory(...)
  NTD->>Kern: syscall (SSN)
  Kern-->>NTD: NTSTATUS
  NTD-->>K32: NTSTATUS
  K32-->>App: LPVOID

Critical fact: the syscall executes in the kernel; ntdll holds the user-mode stub. See Syscalls Flow.

WOW64 note: 32-bit processes on 64-bit Windows use SysWOW64\ntdll.dll — separate syscall path. Always note process bitness in investigations.

System Service Numbers (SSN)

Each Nt* function maps to a syscall number that can change between Windows builds. Attackers may invoke syscalls directly (bypassing hooked ntdll stubs); defenders still see kernel-side effects via callbacks, ETW, and minifilters.

Lab .114 gateway DLL versions (from baseline):

Where telemetry attaches

flowchart LR
  APP[App] --> K32[kernel32]
  K32 --> NTD[ntdll]
  NTD -->|hooked stub| EDR[User-mode EDR hook]
  NTD -->|syscall| KERN[kernel callbacks]
  KERN --> FLT[minifilter / WFP]

Security engineer lens

Investigation habit: when a tool claims to "bypass API monitoring," ask: did it bypass user-mode hooks only, or kernel telemetry too?

Lab checkpoint — 192.168.50.114

# Confirm gateway DLLs exist and versions
'ntdll.dll','kernel32.dll','kernelbase.dll' | ForEach-Object {
  $p = Join-Path $env:windir "System32\$_"
  Get-Item $p | Select-Object @{N='DLL';E={$_}}, @{N='KB';E={[math]::Round($_.Length/1KB,1)}},
    @{N='Ver';E={$_.VersionInfo.FileVersion}}
}

# See which DLLs PowerShell loaded (runtime — not file edit)
powershell -NoProfile -Command "'ping'" | Out-Null
Get-Process -Id $PID -Module |
  Where-Object ModuleName -match 'ntdll|kernel32|amsi' |
  Select-Object ModuleName, FileName

Optional (admin): Sysinternals Process Explorer → lower pane → DLLs for powershell.exe — find ntdll.dll path and version.

Record in notebook

• Three-layer story in your own words (app → Win32 → NT → kernel)
• ntdll.dll and kernel32.dll versions on .114
• One example pair: Win32 function ↔ Nt* name

Navigation

← Module 1 · Module 3 →