Let's Create Your First Ever Rootkit (Absolute Beginners)

Main technological concepts covered

• Kernel-mode (ring 0) drivers and privilege levels

  • Explains Windows protection rings: user mode (ring 3) vs kernel mode (ring 0).
  • Warns that mistakes in kernel mode typically lead to BSODs (no “runtime error” safety net like in user-space languages).

• Why rootkits exist (vs user-mode malware)

  • Rootkits are described as malware that gains kernel-mode privileges.
  • They require deep OS internals knowledge, so they are less common than user-mode malware.

• Classic rootkit mechanisms (theoretical background)

  • Process hiding via kernel doubly linked lists
    • Windows Task Manager uses an ActiveProcessLinks linked list in kernel space.
    • A rootkit can unlink a process entry so it disappears from Task Manager.
    • Unloading can restore visibility.
  • PatchGuard impact
    • PatchGuard / kernel patch protection monitors critical kernel structures.
    • Tampering with protected lists/tables can trigger a bug check → BSOD.
  • Hooking SSDT
    • Mentions SSDT (System Service Descriptor Table) hooking used historically (often for AV/EDR).
    • Notes PatchGuard integrity checks break this approach, but suggests documented kernel callbacks as an alternative direction.

Product/engineering “guide” content (building the demo rootkit)

The video outlines a proof-of-concept that implements a malicious kernel driver + user-mode client.

1) Driver communication design: IOCTL + IRP

• IOCTL codes
  • 32-bit identifiers encoding device type, function code, transfer method, and required access.
• IRPs (IO request packets)
  • Kernel mechanism that carries the IOCTL code plus data from user mode to kernel mode.

Analogy: IOCTL = what to do, IRP = how it’s sent.

2) Kernel driver interface: device object + symbolic link

• The driver creates a kernel device using IoCreateDevice.
• It creates a symbolic link with IoCreateSymbolicLink so user mode can open it with CreateFileW.
• The driver unload routine deletes the symbolic link/device.

3) IRP handlers used in the driver

The driver handles only three IRP types:

• Create IRP (on CreateFileW)
• Close IRP (on handle close)
• Device Control IRP (on DeviceIoControlW)

Behavior:

• For create/close: returns success without doing much.
• For device control:
  • Reads the IOCTL from the IRP stack.
  • If it matches the custom IOCTL, performs the token theft logic.

The rootkit’s actual payload (token stealing + “invincibility”)

A) Steal/copy the SYSTEM process access token

• Uses kernel EPROCESS structures:
  • Each process has an EPROCESS.
  • The token is stored at a member offset within EPROCESS (token pointer).
• Steps described:
  1. Get EPROCESS for the SYSTEM process (PID 4).
  2. Get EPROCESS for the calling user-mode process (PID from IRP request).
  3. Hardcode the token member offset (Windows changes offsets per build).
  4. Overwrite the user process token pointer so it behaves like SYSTEM:
     • “Make it invincible” (high-level goal).

Kernel debugging requirement

• Uses WinDbg to find EPROCESS and determine member offsets (example: token at offset 0x248).
• Requires enabling:
  • kernel debugging
  • driver test signing
• Uses PsLookupProcessByProcessId to obtain EPROCESS pointers.
• Uses reference counting and later ObDereferenceObject to avoid structure lifetime issues.

B) Make the process immune to termination (modify protection level)

• Explains Windows process protection levels:
  • Non-protected
  • Light protected
  • Fully protected
• Uses the EPROCESS protection byte (example offset 0x5FA).
• The protection byte is broken into bitfields:
  • Type bits (3 bits)
  • Audit bit (1 bit)
  • Signer bits (4 bits)
• Uses bit manipulation / union bitfield understanding to set the process to:
  • Fully protected with Win system signature (example bit pattern: level value 0x72 in the demo).

Result (in the concept demo):

• After setting protection correctly, Task Manager termination fails with “access denied.”

C) Memory access (LSASS read as proof)

• The user-mode tool attempts to read memory of LSASS after token/protection changes.
• Why it may have failed initially:
  • Modern Windows checks not only token privileges (e.g., SE debug) but also:
    • protection level compatibility
    • signer signature compatibility
• Example rule stated:
  • If LSASS is light protected with ELSA signature, the caller must match protection type/signing constraints (not just rely on a stolen token).

Build/run steps included (tutorial-like instructions)

• Build environment

  • Uses Visual Studio 2026
  • Install latest SDK and Windows Driver Kit
  • Create an “empty kernel-mode driver” project

• Debugging/tooling

  • Use WinDbg with kernel attach
  • Enable test signing + kernel debugging; restart VM

• Load the driver

  • Use sc to create/start a kernel service pointing to the .sys path

• Run

  • Start the user-mode program and demonstrate:
    • token changes
    • attempted LSASS memory access
  • Demonstrate termination protection failure/success depending on whether the protection byte is updated

Key speakers / sources (as stated by the subtitles)

• Primary speaker: the video narrator/instructor (no name provided in the subtitles)
• Referenced authority/source: Microsoft (PatchGuard, EPROCESS behavior, driver signing rules, Windows kernel symbols)
• Tooling referenced: WinDbg (debugger maintained by Microsoft)
• Framework/library referenced: Windows kernel APIs, including:
  • IoCreateDevice
  • CreateFileW
  • DeviceIoControlW
  • PsLookupProcessByProcessId
  • ObDereferenceObject