ModTracer - ModTracer Finds Hidden Linux Kernel Rootkits And Then Make Visible Again

ModTracer Finds Hidden Linux Kernel Rootkits and then make visible again.

Another way to make an LKM visible is using the imperius trick: https://github.com/MatheuZSecurity/Imperius

VectorKernel - PoCs For Kernelmode Rootkit Techniques Research

PoCs for Kernelmode rootkit techniques research or education. Currently focusing on Windows OS. All modules support 64bit OS only.

NOTE

Some modules use ExAllocatePool2 API to allocate kernel pool memory. ExAllocatePool2 API is not supported in OSes older than Windows 10 Version 2004. If you want to test the modules in old OSes, replace ExAllocatePool2 API with ExAllocatePoolWithTag API.

Environment

All modules are tested in Windows 11 x64. To test drivers, following options can be used for the testing machine:

1. Enable Loading of Test Signed Drivers

2. debugging-in-windbg--cdb--or-ntsd">Setting Up Kernel-Mode Debugging

Each options require to disable secure boot.

Modules

Detailed information is given in README.md in each project's directories. All modules are tested in Windows 11.

TODO

More PoCs especially about following things will be added later:

• Notify callback
• Filesystem mini-filter
• Network mini-filter

Recommended References

• Pavel Yosifovich, Windows Kernel Programming, 2nd Edition (Independently published, 2023)

• Reversing-<a href=" https:="" title="Obfuscation">Obfuscation/dp/1502489309">Bruce Dang, Alexandre Gazet, Elias Bachaalany, and Sébastien Josse, Practical Reverse Engineering: x86, x64, ARM, Windows Kernel, Reversing Tools, and Obfuscation (Wiley Publishing, 2014)

• Greg Hoglund, and Jamie Butler, Rootkits : Subverting the Windows Kernel (Addison-Wesley Professional, 2005)

• Evasion-Corners/dp/144962636X">Bill Blunden, The Rootkit Arsenal: Escape and Evasion in the Dark Corners of the System, 2nd Edition (Jones & Bartlett Learning, 2012)

• Pavel Yosifovich, Mark E. Russinovich, Alex Ionescu, and David A. Solomon, Windows Internals, Part 1: System architecture, processes, threads, memory management, and more, 7th Edition (Microsoft Press, 2017)

• Andrea Allievi, Mark E. Russinovich, Alex Ionescu, and David A. Solomon, Windows Internals, Part 2, 7th Edition (Microsoft Press, 2021)

• Matt Hand, Evading EDR - The Definitive Guide to Defeating Endpoint Detection Systems (No Starch Press, 2023)

Researchers Uncover First Native Spectre v2 Exploit Against Linux Kernel

New Glibc Flaw Grants Attackers Root Access on Major Linux Distros

Blackbone - Windows Memory Hacking Library

Windows memory hacking library

Features

• x86 and x64 support

Process interaction

• Manage PEB32/PEB64
• Manage process through WOW64 barrier

Process Memory

• Allocate and free virtual memory
• Change memory protection
• Read/Write virtual memory

Process modules

• Enumerate all (32/64 bit) modules loaded. Enumerate modules using Loader list/Section objects/PE headers methods.
• Get exported function address
• Get the main module
• Unlink module from loader lists
• Inject and eject modules (including pure IL images)
• Inject 64bit modules into WOW64 processes
• Manually map native PE images

Threads

• Enumerate threads
• Create and terminate threads. Support for cross-session thread creation.
• Get thread exit code
• Get main thread
• Manage TEB32/TEB64
• Join threads
• Suspend and resume threads
• Set/Remove hardware breakpoints

Pattern search

• Search for arbitrary pattern in local or remote process

Remote code execution

• Execute functions in remote process
• Assemble own code and execute it remotely
• Support for cdecl/stdcall/thiscall/fastcall conventions
• Support for arguments passed by value, pointer or reference, including structures
• FPU types are supported
• Execute code in new thread or any existing one

Remote hooking

• Hook functions in remote process using int3 or hardware breakpoints
• Hook functions upon return

Manual map features

• x86 and x64 image support
• Mapping into any arbitrary unprotected process
• Section mapping with proper memory protection flags
• Image relocations (only 2 types supported. I haven't seen a single PE image with some other relocation types)
• Imports and Delayed imports are resolved
• Bound import is resolved as a side effect, I think
• Module exports
• Loading of forwarded export images
• Api schema name redirection
• SxS redirection and isolation
• Activation context support
• Dll path resolving similar to native load order
• TLS callbacks. Only for one thread and only with PROCESS_ATTACH/PROCESS_DETACH reasons.
• Static TLS
• Exception handling support (SEH and C++)
• Adding module to some native loader structures(for basic module api support: GetModuleHandle, GetProcAdress, etc.)
• Security cookie initialization
• C++/CLI images are supported
• Image unloading
• Increase reference counter for import libraries in case of manual import mapping
• Cyclic dependencies are handled properly

Driver features

• Allocate/free/protect user memory
• Read/write user and kernel memory
• Disable permanent DEP for WOW64 processes
• Change process protection flag
• Change handle access rights
• Remap process memory
• Hiding allocated user-mode memory
• User-mode dll injection and manual mapping
• Manual mapping of drivers

Requirements

• Visual Studio 2017 15.7 or higher
• Windows SDK 10.0.17134 or higher
• WDK 10.0.17134 or higher (driver only)
• VC++ 2017 Libs for Spectre (x86 and x64)
• Visual C++ ATL (x86/x64) with Spectre Mitigations

PPLcontrol - Controlling Windows PP(L)s

This tool allows you to list protected processes, get the protection level of a specific process, or set an arbitrary protection level. For more information, you can read this blog post: Debugging Protected Processes.

Usage

1. Download the MSI driver

You can get a copy of the MSI driver RTCore64.sys here: PPLKiller/driver.

2. Install the MSI driver

Disclaimer: it goes without saying that you should never install this driver on your host machine. Use a VM!

sc.exe create RTCore64 type= kernel start= auto binPath= C:\PATH\TO\RTCore64.sys DisplayName= "Micro - Star MSI Afterburner"
net start RTCore64

3. Use PPLcontrol

List protected processes.

PPLcontrol.exe list

Get the protection level of a specific process.

PPLcontrol.exe get 1234

Set an arbitrary protection level.

PPLcontrol.exe set 1234 PPL WinTcb

Protect a non-protected process with an arbitrary protection level. This will also automatically adjust the signature levels accordingly.

PPLcontrol.exe protect 1234 PPL WinTcb

Unprotect a protected process. This will set the protection level to 0 (i.e. None) and the EXE/DLL signature levels to 0 (i.e. Unchecked).

PPLcontrol.exe unprotect 1234

4. Uninstall the driver

net stop RTCore64
sc.exe delete RTCore64

Use cases

Debugging a protected process with WinDbg

WinDbg just needs to open the target process, so you can use PPLcontrol to set an arbitrary protection level on your windbg.exe process.

1. Get the PID of the windbg.exe process.
2. Use PPLcontrol to set an arbitrary protection level.

C:\Temp>tasklist | findstr /i windbg
windbg.exe                    1232 Console                    1     24,840 K
C:\Temp>PPLcontrol.exe protect 1232 PPL WinTcb
[+] The Protection 'PPL-WinTcb' was set on the process with PID 1232, previous protection was: 'None-None'.
[+] The Signature level 'WindowsTcb' and the Section signature level 'Windows' were set on the process with PID 1232.

Inspecting a protected process with API Monitor

In addition to opening the target process, API monitor injects a DLL into it. Therefore, setting an arbitrary protection level on your apimonitor.exe process won't suffice. Since the injected DLL is not properly signed for this purpose, the Section signature flag of the target process will likely prevent it from being loaded. However, you can temporarily disable the protection on the target process, start monitoring it, and restore the protection right after.

Failed to load module in target process - Error: 577, Windows cannot verify the digital signature for this file. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source.

1. Get the PID of the target process.
2. Use PPLcontrol to get the protection level of the target process.
3. Unprotect the process.
4. Start monitoring the process with API Monitor.
5. Restore the protection of the target process.

C:\Temp>tasklist | findstr /i target
target.exe                    1337 Services                   1     14,160 K
C:\Temp>PPLcontrol.exe get 1337
[+] The process with PID 1337 is a PPL with the Signer type 'WinTcb' (6).
C:\Temp>PPLcontrol.exe unprotect 1337
[+] The process with PID 1337 is no longer a PP(L).

C:\Temp>PPLcontrol.exe protect 1337 PPL WinTcb
[+] The Protection 'PPL-WinTcb' was set on the process with PID 1337, previous protection was: 'None-None'.
[+] The Signature level 'WindowsTcb' and the Section signature level 'Windows' were set on the process with PID 1337.

Build

1. Open the solution in Visual Studio.
2. Select Release/x64 (x86 is not supported and will probably never be).
3. Build solution

Credit

• @aceb0nd for the tool PPLKiller
• @aionescu for the article Protected Processes Part 3: Windows PKI Internals (Signing Levels, Scenarios, Root Keys, EKUs & Runtime Signers)

Hidden - Windows Driver With Usermode Interface Which Can Hide Processes, File-System And Registry Objects, Protect Processes And Etc

Hidden has been developed like a solution for reverse engineering and researching tasks. This is a windows driver with a usermode interface which is used for hiding specific environment on your windows machine, like installed RCE programs (ex. procmon, wireshark), vm infrastructure (ex. vmware tools) and etc.

Features

• hide registry keys and values
• hide files and directories
• hide processes (experimental, might be not stable)
• protect specific processes
• exclude specific processes from hiding and protection features
• usermode interface (lib and cli) for working with a driver

and so on

System requirements

Windows Vista and above, x86 and x64

Recommended build environment

• Visual Studio 2019
• Windows Driver Kit 10

Building

Following guide explains how to make a release win32 build

1. Open Hidden.sln using Visual Studio
2. Build Hidden Package project with configurations Release, Win32
3. Open build results folder <ProjectDir>\Release

Installing

1. Disable a digital signature enforcement on a test machine (bcdedit /set TESTSIGNING ON) and reboot it
2. Copy files from <ProjectDir>\Release\Hidden Package to a test machine
3. Right mouse click on Hidden.inf and choose Install
4. Start a driver (sc start hidden)
5. Make sure service is running (sc query hidden)

Important: Keep in mind that the driver bitness have to be the same to an OS bitness

Hiding

A command line tool hiddencli is used for managing a driver. You are able to use it for hiding and unhiding objects, changing a driver state and so on.

To hide a file try the command

hiddencli /hide file c:\Windows\System32\calc.exe

Want to hide a directory? No problems

hiddencli /hide dir "c:\Program Files\VMWare"

Registry key?

hiddencli /hide regkey "HKCU\Software\VMware, Inc."

Maybe a process?

hiddencli /hide pid 2340

By a process image name?

hiddencli /hide image apply:forall c:\Windows\Explorer.EXE

To get a full help just type

hiddencli /help

Fake PoC for Linux Kernel Vulnerability on GitHub Exposes Researchers to Malware

Researchers Uncover New Linux Kernel 'StackRot' Privilege Escalation Vulnerability

BugChecker - SoftICE-like Kernel Debugger For Windows 11

Introduction

BugChecker is a SoftICE-like kernel and user debugger for Windows 11 (and Windows XP as well: it supports Windows versions from XP to 11, both x86 and x64). BugChecker doesn't require a second machine to be connected to the system being debugged, like in the case of WinDbg and KD. This version of BugChecker (unlike the original version developed 20 years ago) leverages the internal and undocumented KD API in NTOSKRNL. KD API allows WinDbg/KD to do calls like read/write virtual memory, read/write registers, place a breakpoint at an address etc.

By contrast, the original BugChecker, like SoftICE as well, used to "take over" the system, by hooking several kernel APIs (both exported and private), taking control of the APIC, sending IPIs etc. This approach increases complexity exponentially (and lowers system stability), since the implementation must be compatible with all the supported versions and sub-version of Windows (at the function signature level) as well as all the possible supported hardware configurations. Moreover, 20 years later, PatchGuard makes this solution impossible.

By contrast, this version of BugChecker, by intercepting calls to KdSendPacket and KdReceivePacket in the kernel, presents itself to the machine being debugged as a second system running an external kernel debugger, but, in reality, everything happens on the same machine. Typically this is achieved by replacing KDCOM.DLL (which is the module that implements serial cable communication for the KD API in Windows) and by starting the system in kernel debugging mode. This approach (inspired by VirtualKD) lowers complexity and increases stability and compatibility (and portability, for example, to ARM - and modularity, since the lower level debugger capabilities are implemented behind KdXxxPacket and could be replaced with a custom implementation). Moreover, the presence of a kernel debugger at boot time (although "fake") makes Windows disable PatchGuard.

At the moment, BugChecker requires a PS/2 keyboard for input and a linear framebuffer to write its output.

Features

• Support for Windows XP up to Windows 11, x86 and x64, and SMP kernels. Support for WOW64 processes on x64.
• Integration of QuickJSPP, which is a port of QuickJS to MSVC++. Before calling QuickJS, BugChecker saves the FPU state (on x86) and switches to an expanded stack of 128KB.
• Commands accept JS expressions. For example, "U rip+rax*4" and "U MyJsFn(rax+2)" are valid commands. Custom functions can be defined in the Script Window. CPU registers are declared as global scope variables automatically by BugChecker.
• Support for PDB symbol files. PDB files can be specified manually or Symbol Loader can download them from a symbol server.
• JavaScript code can call the following asynchronous functions: WriteReg, ReadMem, WriteMem.
• Breakpoints can have a JS condition: if condition evaluates to 0, no "breakin" happens. This allows to set "Logpoints" and breakpoints that can change the flow of execution.
• Log window shows the messages sent to the kernel debugger (for example DbgPrint messages).
• JavaScript window with syntax highlighting.
• The tab key allows, given few digits, to cycle through all the hex numbers on the screen or, given few characters, to cycle through all the symbols containing those characters.
• EASTL and C++20 coroutines make creating new commands a breeze. Feel free to send your pull requests!

Videos (Youtube)

Demonstration of BugChecker on Windows 11 22H2, inside VirtualBox 7.0.4. A JavaScript breakpoint condition is written that changes the flow of execution in an user mode thread.

BugChecker running in a very constrained environment: a Raspberry Pi 4 (4GB RAM), via QEMU on Windows XP (512MB RAM). A breakpoint is used to log all the SYSENTER calls from user mode to the kernel. The service index is stored in a JavaScript array.

Running BugChecker directly on bare metal, on an HP Pavilion Dv2000, which is an old PC with a PS/2 keyboard. The OS is Windows 7 Home 32bit.

Installation Instructions

Introduction

Make sure that Secure Boot is disabled when installing and using BugChecker. Typically you can re-enable it later. If you are using VMware or VirtualBox, Secure Boot can be disabled in the virtual machine settings.

Consider also enabling legacy boot menu, if using Windows 8, 10 or 11, by using the command: bcdedit /set "{current}" bootmenupolicy legacy. It allows a smoother experience during boot, by allowing to select the BugChecker boot option and then to disable Driver Signature Enforcement at the same time.

Instructions

The first step is to start Symbol Loader:

If necessary, disable the display drivers, by clicking on the "Disable Display Drvs" button. The same thing can be accomplished in Windows Device Manager. After the display drivers have been disabled, they remain disabled even after a system reboot. They can be re-enabled at any time later when not using BugChecker.

The point here is that BugChecker needs a linear framebuffer with a format of 32 bits-per-pixel, to draw its interface. When disabling the display drivers, Windows dismisses hardware acceleration for drawing its UI and falls back to VGA compatibility mode. If running on bare metal or VMware, you should disable display drivers. If running on VirtualBox, you should disable display drivers or set the vm_screen setting in BugChecker.dat, as described below. If running on QEMU, you don't need to disable display drivers but make sure to specify the "-vga std" display device.

Note that VGA compatibility mode could limit the maximum screen resolution. VMware is limited to a maximum resolution of 1152x864. QEMU with the "-vga std" display device doesn't suffer from this limitation.

Interestingly if BugChecker is installed on a system with more than one graphics card, it is possible to disable the display drivers of only one graphics card, which will be the card connected to the screen that will show the BugChecker UI. The second card (set as the main display) will retain all its 2D and 3D acceleration features, including OpenGL and DirectX support (NOTE: tested on VMware, with Windows 11 and a DisplayLink display).

Then click on "Start Driver", then on "Auto Detect" and finally on "Save". "Auto Detect" should be able to determine width, height, physical address and stride of the framebuffer automatically. However, you can specify these settings manually (don't forget to click on "Save" when finished). If "Stride" is 0, it is calculated as "Width" * 4 automatically when starting the driver. "Address" (i.e. physical address of the framebuffer) can be get obtained in Windows Device Manager, by clicking on "Properties" of the display device, under the "Resources" tab.

Then click on "Callback" in the "KDCOM Hook Method" section, then on "Copy/Replace Kdcom" and finally you can reboot the system.

This setup process has to be done only once and the display drivers can be re-enabled, if necessary. When using BugChecker however the display drivers must be disabled again, if required by your configuration.

vm_screen setting for VirtualBox (Experimental)

The vm_screen setting in BugChecker.dat allows to open the BugChecker debugger UI in VirtualBox without specifying in advance a screen resolution in Symbol Loader and without disabling display drivers.

The idea is to write directly to the I/O ports and to the Command Buffer of the virtual display device in order to obtain the current screen resolution and to notify the hypervisor of any update in the framebuffer.

This solution was inspired by the X.org xf86-video-vmware driver.

This solution works only for VirtualBox VMs and by editing manually the BugChecker.dat file:

• In Symbol Loader, manually set the width and height of the framebuffer to the maximum resolution possible (i.e. the dimensions of your computer screen). Set the stride to 0.
• The BugChecker.dat file is created by Symbol Loader in "C:\Windows\BugChecker".
• The vm_screen setting should be added under "settings->framebuffer".
• The hierarchy of the settings in this file is determined by the tabulation characters (not spaces).
• The format of the setting is Command_Buffer_Start_Address (comma) Command_Buffer_End_Address (comma) I/O_Port_Base
• IMPORTANT: In the VM setting, under Display, select "VBoxSVGA" as the Graphics Controller and uncheck "Enable 3D Acceleration".

This is an experimental feature. In the future, this setting will be automatically added by Symbol Loader.

Implemented Commands

The command name and syntax are chosen to be as close as possible to those of the original SoftICE for NT:

• ? javascript-expression: Evaluate a javascript expression.
• ADDR eprocess: Switch to process context (returns control to OS).
• BC list|*: Clear one or more breakpoints.
• BD list|*: Disable one or more breakpoints.
• BE list|*: Enable one or more breakpoints.
• BL (no parameters): List all breakpoints.
• BPX address [-t|-p|-kt thread|-kp process] [WHEN js-expression]: Set a breakpoint on execution.
• CLS (no parameters): Clear log window.
• COLOR [normal bold reverse help line]|[reset]: Display, set or reset the screen colors.
• DB/DW/DD/DQ [address] [-l len-in-bytes]: Display memory as 8/16/32/64-bit values.
• EB/EW/ED/EQ address -v space-separated-values: Edit memory as 8/16/32/64-bit values.
• KL EN|IT: Set keyboard layout.
• LINES [rows-num]: Display or set current display rows.
• MOD [-u|-s] [search-string]: Display module information.
• P [RET]: Execute one program step.
• PAGEIN address: Force a page of memory to be paged in (returns control to OS).
• PROC [search-string]: Display process information.
• R register-name -v value: Change a register value.
• STACK [stack-ptr]: Scan the stack searching for return addresses.
• T (no parameters): Trace one instruction.
• THREAD [-kt thread|-kp process]: Display thread information.
• U address|DEST: Unassemble instructions.
• VER (no parameters): Display version information.
• WD [window-size]: Toggle the Disassembler window or set its size.
• WIDTH [columns-num]: Display or set current display columns.
• WR (no parameters): Toggle the Registers window.
• WS [window-size]: Toggle the Script window or set its size.
• X (no parameters): Exit from the BugChecker screen.

Build Instructions

Prerequisites

• Visual Studio 2019
• Windows Driver Kit 7.1.0

Note: WDK should be installed in its default location, i.e. X:\WinDDK, where X is the drive where the BugChecker sources are saved.

Visual Studio Projects Description

• BugChecker: this is the BugChecker kernel driver, where the entirety of the debugger is implemented. The "Release|x86" and "Release|x64" output files are included in the final package. During initialization, the driver loads its config file at "\SystemRoot\BugChecker\BugChecker.dat" (all the symbol files are stored in this directory too) and then it tries to locate "KDCOM.dll" in kernel space. If found, it tries to call its "KdSetBugCheckerCallbacks" exported function, thus hooking KdSendPacket and KdReceivePacket.
• SymLoader: this is the Symbol Loader. Only the "Release|x86" output file is included in the final package. Symbol Loader is used to change the BugChecker configuration (configuration is written to "\SystemRoot\BugChecker\BugChecker.dat"), to download PDB files and to install the custom KDCOM.dll module.
• KDCOM: this is the custom KDCOM.dll module that NTOSKRNL loads on system startup. It exports the "KdSetBugCheckerCallbacks" function that the driver calls to hook KdSendPacket and KdReceivePacket.
• pdb: this is the Ghidra "pdb" project. The original version outputs the contents of a PDB file to the standard output in xml format. The code was modified in order to generate a BCS file instead.
• NativeUtil: since Symbol Loader is a WOW64 application in Windows x64, the calls to those APIs that must be made from architecture native images were moved here (for example the calls to the Device and Driver Installation API).
• HttpToHttpsProxy: this is an ASP.NET Core application whose function is to act as an internet proxy for Symbol Loader when run in Windows XP. Since XP has outdated TLS support, Symbol Loader cannot download files from an arbitrary symbol server. After deploying this application in an IIS on the same network, it is possible to download files from a symbol server in Windows XP prepending "http://<YOUR_IIS_SERVER_IP>/HttpToHttpsProxy/" to the server URL in Symbol Loader.

Credits

• VirtualKD: the first POC of BugChecker was built modifying VirtualKD.
• BazisLib: the code behind the "Copy/Replace Kdcom + Add Boot Entry" button in Symbol Loader is from VirtualKD and uses BazisLib.
• EASTL: No way to use MSVC++ STL here. EASTL is an excellent alternative.
• Ghidra: the "pdb" project in BugChecker is from Ghidra. It was modified to generate BCS files.
• Zydis: for the disassembler window in BugChecker.
• ReactOS: for the Windows KD internal type definitions.
• SerenityOS: for the low level bitmap manipulation functions used by the BugChecker memory allocator. Since I started BugChecker after I saw a video of Andreas (after 10 years of abstinence from C/C++ and any type of low level programming), I wanted to include a small piece of SerenityOS in BugChecker.

Platbox - UEFI And SMM Assessment Tool

UEFI and SMM Assessment Tool

Features

Platbox is a tool that helps assessing the security of the platform:

• Dumps the platform registers that are interesting security-wise
  • Flash Locks
  • MMIO and Remapping Locks
  • SMM Base and Locks
  • MSRs
• RW access to the PCI configuration space of devices.
• RW to physical memory and virtual memory.
• Allows allocating physical memory and map memory to usermode.
• Read and Write MSRs.
• Dump SPI Flash content (BIOS) into a file.
• Basic dumb SMI Fuzzer.
• Dump S3 Bootscript (from SMM-Lockbox) into a file.
• Dump EFI Memory Map (Linux only for now).
• List UEFI variables.
• Supports Linux and Windows.
• Supports Intel and AMD.

Example of 'chipset' command output for an AMD platform

Project Structure

The project is divided as follows:

• PlatboxDrv: kernel drivers used for Linux and Windows.
• PlatboxLib: the usermode component that loads the kernel driver and provides access to all the previously listed features.
• PlatboxCli: a console client that uses the library.
• Pocs: an example of a program using features from the libary.

Compilation Steps

Windows

cmake -G "Visual Studio 17 2022" -A x64 -S .. -B "build64" 
cmake --build build64/ --target platbox_cli --config Release

Apple zero-day spyware patches extended to cover older Macs, iPhones and iPads

“Dirty Pipe” Linux kernel bug lets anyone write to any file