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

Understanding Kernel Mode and Anti-Cheat Software

Introduction to Protection Rings

• The commonality between anti-cheat software and antivirus programs is that they operate with drivers at ring zero or kernel mode.

• Ring three, known as user mode, has the least privileges, limiting what can be done by malicious entities.

• Modern operating systems rarely use rings one and two; their existence is mainly for backward compatibility.

Risks of Kernel Mode

• Operating in kernel mode can lead to critical errors like BSOD (Blue Screen of Death) if exceptions are not handled properly.

• A quote emphasizes the danger of overconfidence in creative endeavors: "the less you around, the less you'll find out."

Exploring Rootkits

User Mode vs. Kernel Mode Malware

• Rootkits are a type of malware that operates with kernel mode privileges, making them more complex than typical user-mode malware.

• Windows Task Manager queries the kernel for active processes using a doubly linked list called active process links.

Manipulating Process Lists

• By unlinking a process from this list, it can be hidden from the Task Manager—a technique used by rootkits.

• Demonstration shows how loading a driver can hide Notepad from running processes; unloading it makes Notepad reappear.

Kernel Patch Protection

Microsoft’s PatchGuard

• PatchGuard monitors critical components in the kernel to prevent tampering; failing its checks results in BSOD.

SSDT Hooking Mechanism

• Malware may hook into the System Service Descriptor Table (SSDT), which contains pointers to Windows API implementations.

Creating Kernel Drivers

Basics of Kernel Drivers

• Kernel drivers are portable executables similar to EXE files but managed differently by the OS compared to user-mode applications.

Address Space Management

• Unlike user-mode processes that have isolated virtual address spaces, all kernel drivers share a single address space.

Communication Between User Mode and Kernel Drivers

IOCTL Codes and IRPs

• IOCTL codes serve as unique identifiers for functionalities requested from kernel drivers by user-mode applications.

Functionality Implementation

• IRPs (IO Request Packets), package IOCTL codes along with additional data for communication between modes.

Access Tokens in Windows

Understanding Access Tokens

• Each process on Windows has an access token defining its permissions; there are 36 total token privileges available.

Privileges of System Process

• The system process holds significant privileges such as SE load driver privilege and SE debug privilege which allow extensive control over other processes.

Developing a Rootkit Driver

Setting Up Development Environment

• Visual Studio 2026 is recommended for writing kernel drivers; necessary components include SDK version and Windows Driver Kit installation.

Basic Structure of a Driver

• A basic driver includes entry and unload functions; these manage initialization and cleanup tasks when loaded or unloaded from memory.

Creating Device Interfaces

Device Creation Process

• A device acts as an intermediary between user-mode programs and kernel drivers, facilitating secure communication through symbolic links.

Symbolic Links Explained

• Symbolic links point back to devices created by drivers allowing safe access for user-mode applications via CreateFileW API calls.

Implementing IOCTL Handling

Defining IRP Handlers

• Different types of IRPs require specific handlers within the driver code to manage requests effectively.

Custom IOCTL Code Creation

• An IOCTL code combines parameters like device type, function code, transfer method, and required access into a single integer value.

Stealing Access Tokens

EPROCESS Structure Overview

• Each running process has an EPROCESS structure containing vital information including its access token location within memory.

Token Member Manipulation

• To steal an access token from another process involves locating both EPROCESS structures then modifying their token members directly.

Overview of Kernel Driver Development

Predefining APIs and Structures

• The two necessary APIs must be predefined as they are not exported by the Windows kernel, requiring the inclusion of the NTDDK header for driver definitions.

• The address of the token member within both EPROCESS structures is obtained by adding its offset from WinDbg to the EPROCESS structure's address, using pointer arithmetic.

Manipulating Access Tokens

• After obtaining pointers to both token members, they are dereferenced to overwrite the user mode process access token with that of the system process.

• A reference count mechanism ensures stability while accessing EPROCESS structures; if any issues arise during reading, it could lead to a BSOD (Blue Screen of Death).

• Using PSLookupProcessByProcessId API increments reference counts for both EPROCESS structures, ensuring their presence in kernel memory until references drop to zero.

User Mode Program Setup

IOCTL Code Definition

• In the user mode program, defining an IOCTL code matching that in the kernel driver is essential for communication.

• The CreateFileW API opens a handle to the kernel driver and sends a create IRP which triggers its handler.

Sending Device Control Commands

• Once a handle is established, DeviceIoControlW API sends an invincible process IOCTL code to trigger device control IRP handling in the rootkit.

• The handler checks if the received IOCTL matches expected codes and extracts process ID for further actions like stealing tokens.

Additional Functions in User Mode

Token Information and Memory Reading

• Two additional functions include printing token information (security ID, privileges status), and reading LSASS memory as proof of concept.

• LSASS stores sensitive credentials; thus tools like Mimikatz target it for credential dumping.

Kernel Driver Execution

Loading Kernel Driver

• To load the kernel driver into memory, an administrator command prompt is used with SC utility commands specifying service details.

• After creating and starting this service successfully, it becomes ready to receive IOCTL codes from user mode programs.

Observing Process Privileges

• Upon running the user mode program post-token theft, significant changes in SID and privileges are observed compared to before stealing access tokens.

Achieving Process Protection Levels

Understanding Process Protection Types

• Windows has three protection levels: non-protected processes can be terminated easily; light protected processes have limited immunity; fully protected processes cannot be terminated from user space.

Modifying Protection Byte

• To achieve invincibility against termination attempts from user space applications requires modifying protection bytes found at specific offsets within EPROCESS structures.

Detailed Examination of Protection Bytes

Structure Analysis

• The protection byte consists of bits indicating type (non-protected/light/fully), audit status, and signer information. Each bit serves distinct purposes regarding process security measures.

Setting Protection Levels

• By manipulating these bits—setting them appropriately—user-mode processes can gain full protection against termination attempts by other applications or users.

Finalizing Driver Functionality

Testing Protected Status

• After recompiling and running again with modified protections, attempts to terminate result in "access denied," confirming successful implementation of full protection mechanisms.

Conclusion on Memory Access Checks

• Despite having system-level access tokens initially failing memory read checks on LSASS due to lacking required protections highlights evolving security measures within Windows architecture.