Mastering Windows Kernel Warfare: Build Your Own EDR & Rootkits from Scratch + Video

By /

Listen to this Post

Featured Image

Introduction:

The Windows kernel is the ultimate battleground for modern cybersecurity—where attackers deploy invisible rootkits and defenders build endpoint detection and response (EDR) systems to stop them. A new advanced training course by Ido V., hosted by XINTRA, promises to arm security professionals with hands-on skills in offensive kernel exploitation, defensive EDR engineering, and reverse engineering of Windows drivers and internals.

Learning Objectives:

  • Build a functional EDR from scratch, implementing both detection and prevention mechanisms at the kernel level.
  • Develop and analyze rootkits using offensive tradecraft techniques, including stealth, persistence, and evasion.
  • Reverse-engineer Windows kernel components, drivers, and callback mechanisms like ETW, mini-filters, and process monitors.

You Should Know:

  1. Kernel-Mode vs. User-Mode: The Foundation of EDR and Rootkits

The post highlights building EDRs and rootkits “from scratch while mastering the Windows kernel.” Understanding the divide between user mode (Ring 3) and kernel mode (Ring 0) is critical. EDR sensors and rootkits both operate in kernel mode to gain unrestricted system visibility or stealth.

Step‑by‑step guide: Setting up a kernel debugging environment

To follow along with kernel development, you need a dual-machine setup (host + virtual machine).

  1. On Windows host (debugger): Install WinDbg from the Windows SDK.
  2. On VM (target): Enable kernel debugging via bcdedit: 
    bcdedit /debug on
bcdedit /dbgsettings serial debugport:1 baudrate:115200
  3. Connect WinDbg using serial pipe or network (KDNET). For serial:

– VM: Add a named pipe, e.g., `\\.\pipe\kd_pipe`
– WinDbg: File → Kernel Debug → COM → Port = \\.\pipe\kd_pipe, Baud = 115200
4. Break into kernel (Ctrl+Break) and verify with !process 0 0.

Linux alternative (if analyzing Windows kernel remotely): Use `virt-viewer` or `libvirt` to attach debug stubs, but native Windows tools are mandatory for driver development.

  1. Building Your Own EDR: Kernel Callbacks & Mini‑Filters

The course teaches “Kernel callbacks, ETW, mini filters and more.” These are the building blocks of any EDR’s detection engine. A mini‑filter driver intercepts file I/O, registry, and process creation before the OS completes the operation.

Step‑by‑step guide: Registering a process creation callback

Create a kernel driver (using Visual Studio + WDK) that logs every new process.

1. DriverEntry function – set up callback:

NTSTATUS DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath) {
PsSetCreateProcessNotifyRoutineEx(ProcessNotifyCallback, FALSE);
return STATUS_SUCCESS;
}

2. Callback implementation – log process name and PID:

void ProcessNotifyCallback(PEPROCESS Process, HANDLE ProcessId, PPS_CREATE_NOTIFY_INFO CreateInfo) {
if (CreateInfo) {
DbgPrint("[bash] New process: %wZ (PID: %d)\n", CreateInfo->ImageFileName, ProcessId);
}
}

3. Build and deploy – sign the driver (test signing allowed with bcdedit /set testsigning on) and load using sc.exe:

sc create MyEdr type= kernel binPath=C:\drivers\MyEdr.sys
sc start MyEdr

4. Verify – use `fltmc` to list filters or check DbgView for process creation logs.

To block malicious processes (prevention): Set `CreateInfo->CreationStatus = STATUS_ACCESS_DENIED;` inside the callback.

3. Rootkit Tradecraft: Hiding Processes & Files

The offensive side of the course covers “rootkits & offensive tradecraft.” A classic rootkit technique is DKOM (Direct Kernel Object Manipulation) – unlinking a process from the `EPROCESS` active process list.

Step‑by‑step guide: Hide a process by unlinking EPROCESS

Warning: Use only in controlled labs.

  1. Locate target EPROCESS – use `PsLookupProcessByProcessId` to get the `PEPROCESS` address.
  2. Navigate the doubly linked list – `EPROCESS.ActiveProcessLinks` (a `LIST_ENTRY` structure). Flink points to next, Blink to previous.

3. Remove the entry:

PLIST_ENTRY current = &eprocess->ActiveProcessLinks;
current->Blink->Flink = current->Flink;
current->Flink->Blink = current->Blink;
// Restore original pointers when unhiding

4. Test – after modification, `!process 0 0` in WinDbg no longer shows the hidden PID, but Task Manager may still list it due to other APIs; advanced rootkits also hook NtQuerySystemInformation.

Detection mitigation for defenders: EDRs should not rely solely on the active process list. Use ETW for process creation events (which are harder to suppress) and scan kernel memory for inconsistencies.

4. Reversing Windows Kernel Drivers: Tools & Techniques

Reverse engineering is a core pillar of the course. Many malware families load malicious drivers after exploiting a vulnerable legitimate driver (BYOVD – Bring Your Own Vulnerable Driver).

Step‑by‑step guide: Static and dynamic analysis of a driver

  1. Extract driver – locate `.sys` files in C:\Windows\System32\drivers\. Use `driverquery /v` to list loaded drivers.

2. Static analysis with IDA Pro or Ghidra:

  • Load the driver image (Ghidra’s x86/64 loader supports PE).
  • Locate `DriverEntry` (usually export ordinal 1). Identify `MajorFunction` table entries (e.g., IRP_MJ_DEVICE_CONTROL).
  • Look for IoCreateDevice, IoCreateSymbolicLink, and `DeviceIoControl` dispatch routines.

3. Dynamic analysis in a VM with WinDbg:

  • Set breakpoint on DriverEntry: `bp MyDriver!DriverEntry`
    – After loading the driver, use `lm m MyDriver` to verify base address.
  • Trace IOCTL handlers: send test requests from user mode using `DeviceIoControl` and capture kernel responses.

4. Scripted analysis (PowerShell to query driver metadata):

Get-WmiObject Win32_SystemDriver | Select-Object Name, State, PathName
Get-AuthenticodeSignature -FilePath C:\path\driver.sys

5. ETW for EDR: Building Telemetry Without Hooks

Event Tracing for Windows (ETW) provides high‑performance, low‑overhead system telemetry. Unlike kernel callbacks, ETW is less likely to be tampered with by rootkits. The course includes “ETW” as a key detection component.

Step‑by‑step guide: Consuming ETW process events from a kernel driver

  1. Enable ETW provider – Microsoft-Windows-Kernel-Process provider (GUID: {22fb2cd6-0e7b-422b-a0c7-2fad1fd0e716}).
  2. Register a callback using `EtwRegister` and `EtwSetInformation` (requires Windows 10+). Simplified approach: use user‑mode `EventTrace` with a kernel‑mode helper.

3. Alternate user‑mode EDR sensor (easier for prototyping):

using System.Diagnostics.Tracing;
var listener = new ETWTraceListener();
listener.EnableProvider("Microsoft-Windows-Kernel-Process");

4. Correlate kernel callbacks with ETW – cross‑validate process creation events. If a process appears in one but not the other, a rootkit is likely interfering.

6. Kernel Vulnerability Research & Exploit Mitigation

The instructor specializes in vulnerability research and exploit development. One common kernel bug is improper validation of user‑mode pointers passed to IoDeviceControl. An attacker can supply a crafted buffer leading to arbitrary kernel memory write.

Step‑by‑step guide: Exploiting a vulnerable IOCTL (for educational defense)

  1. Identify vulnerable driver – look for IOCTL codes that use `METHOD_NEITHER` without ProbeForRead/Write.
  2. Write user‑mode exploit that passes a kernel address (e.g., 0xFFFFF80001234567) and a write payload.
  3. Defense: Validate user addresses – always wrap `__try/__except` around ProbeForWrite: 
    __try {
ProbeForWrite(UserBuffer, BufferLength, sizeof(UCHAR));
RtlCopyMemory(KernelBuffer, UserBuffer, BufferLength);
} __except(EXCEPTION_EXECUTE_HANDLER) {
return STATUS_ACCESS_VIOLATION;
}
  4. Test mitigation – run the exploit against the patched driver; it should crash safely or return an error.

Windows command to check for vulnerable drivers: Use `Sysinternals Sigcheck` to verify driver signing and known CVEs:

sigcheck -e -n C:\Windows\System32\drivers.sys

7. Cloud & API Security Relevance (Extended Context)

Although the course focuses on the Windows kernel, modern EDRs often forward telemetry to cloud SIEM/SOAR platforms. Securing that API channel is critical. Apply API security hardening:

Linux/Cloud command example – verifying API endpoint TLS using OpenSSL:

openssl s_client -connect api.xintra.org:443 -servername api.xintra.org -tls1_2

Windows PowerShell – enforce HTTPS for telemetry upload:

Invoke-WebRequest -Uri "https://edr.telemetry/events" -Method Post -Body $json

What Undercode Say:

  • Mastery of kernel callbacks and ETW is non‑negotiable for building production‑grade EDRs that resist rootkit evasion.
  • Offensive knowledge (rootkits, DKOM, IOCTL exploitation) directly informs defensive hardening – you cannot defend what you do not understand.
  • The course’s emphasis on reverse engineering and vulnerability research addresses the current gap between signature‑based AV and modern, behavior‑based endpoint security.

Prediction:

As Microsoft locks down user-mode hooks with PatchGuard and HVCI, EDRs will fully migrate to kernel-native telemetry and event-driven callbacks, while attackers will shift to firmware and hypervisor rootkits. Courses like this will become essential for professionals aiming to defend the Windows kernel in the post-2025 threat landscape—expect demand for kernel-level EDR engineers to triple within two years.

▶️ Related Video (84% Match):

🎯Let’s Practice For Free:

IT/Security Reporter URL:

Reported By: Lina L – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky

Related Posts: