Skip to content

TheMalwareGuardian/Awesome-Bootkits-Rootkits-Development

BranchesTags

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

20 Commits
Bookmarks
Bookmarks
 
 
Environment
Environment
 
 
Images
Images
 
 
.gitignore
.gitignore
 
 
LICENSE
LICENSE
 
 
README.md
README.md
 
 

Repository files navigation

🏴‍☠️ Awesome Bootkits & Rootkits Development

DEF CON 33 Main Stage Talk

A curated compilation of extensive resources dedicated to bootkit and rootkit development.

Table of Contents

TheMalwareGuardian

Whoami

BIOS UEFI

Deep dive into BIOS UEFI.

Specifications

Return here once you have developed a better grasp of the subject.

Basics

This should be your starting point.

  • Web Wikipedia: Booting -> In computing, booting is the process of starting a computer as initiated via hardware such as a button on the computer or by a software command
  • Web OsDev: UEFI -> UEFI is a specification for x86, x86-64, ARM, and Itanium platforms that defines a software interface between the operating system and the platform firmware/BIOS.
  • Blog: Programming for EFI -> Tech-savvy individuals know the Extensible Firmware Interface (EFI) and its newer variant, the Unified EFI (UEFI) as a replacement for the older Basic Input/Output System (BIOS) on PCs and other computers. What you may not be aware of is that EFI is a complex software environment, comparable in size and features to a simple OS such as DOS. As such, EFI can host a variety of programs—but those programs can't spring into existence fully-formed, like Athena from Zeus' head. Rather, they must be written by individuals.

Videos

Familiarize yourself with UEFI watching these videos.

Windows Boot

Gain an understanding of the Windows boot process and the existing protection mechanisms at startup.

Vulnerabilities

Explore BIOS vulnerabilities, it's fine if it appears challenging at this moment.

Tools

Analyze, test, and modify UEFI firmware.

  • Github: UEFITool - UEFI firmware image viewer and editor -> UEFITool is a cross-platform open source application written in C++/Qt, that parses UEFI-compatible firmware image into a tree structure, verifies image's integrity and provides a GUI to manipulate image's elements. Project development started in the middle of 2013 because of the lack of cross-platform open source utilities for tinkering with UEFI images.
  • Github: CHIPSEC - Platform Security Assessment Framework -> CHIPSEC is a framework for analyzing the security of PC platforms including hardware, system firmware (BIOS/UEFI), and platform components. It includes a security test suite, tools for accessing various low level interfaces, and forensic capabilities. It can be run on Windows, Linux, Mac OS X and UEFI shell. Instructions for installing and using CHIPSEC can be found in the manual.
  • Github: CHIPSEC - Training, Writing Modules & Tools
  • Presentation: CHIPSEC - BlackHat USA 2014
  • Github: UEFI Firmware Parser -> The UEFI firmware parser is a simple module and set of scripts for parsing, extracting, and recreating UEFI firmware volumes. This includes parsing modules for BIOS, OptionROM, Intel ME and other formats too.
  • Github: FwHunt Community Scanner -> Tools for analyzing UEFI firmware and checking UEFI modules with FwHunt rules.
  • Github: FwHunt Rules -> The Binarly Firmware Hunt (FwHunt) rule format was designed to scan for known vulnerabilities in UEFI firmware.
  • Github: Kraft Dinner -> Tool to dump UEFI runtime drivers implementing runtime services for Windows.
  • Github: Flashrom -> It is a utility for detecting, reading, writing, verifying and erasing flash chips. It is often used to flash BIOS/EFI/coreboot/firmware images in-system using a supported mainboard, but it also supports flashing of network cards (NICs), SATA controller cards, and other external devices which can program flash chips.
  • Web Hex Rays: IDA Free -> This (completely!) free version of IDA offers a privilege opportunity to see IDA in action. This light but powerful tool can quickly analyze the binary code samples and users can save and look closer at the analysis results.
  • Web Ghidra SRE: Software Reverse Engineering framework -> A software reverse engineering (SRE) suite of tools developed by NSA's Research Directorate in support of the Cybersecurity mission

EDK2

Study the development of applications and drivers (bootkit components) in the UEFI environment.

Basics

Configure the required development environment.

Videos

Check out these videos to learn advanced development techniques.

  • Youtube Video: UEFIForum - Driver Development with EDKII -> The world of UEFI is unlike OS-based software ecosystems in several aspects and the difference can be daunting to a developer who is starting to write UEFI device drivers.
  • Youtube Video: Queso Fuego - UEFI Programming in C -> Intro, setup, and hello world program to start programming for x86_64 EFI applications. We'll be writing a program to make GPT disk images with an EFI system partition and basic data partition, and an OS loader EFI application for an operating system bootloader. Everything will follow official specifications and documentation for UEFI, ACPI, FAT32, etc. as much as possible.

PoCs

UEFI applications and drivers.

  • Github: EDK2 - MdeModulePkg Applications -> Sample applications of MdeModulePkg package.
  • Github: Shim - A first-stage UEFI bootloader -> Shim is a trivial EFI application that, when run, attempts to open and execute another application. It will initially attempt to do this via the standard EFI LoadImage() and StartImage() calls. If these fail (because Secure Boot is enabled and the binary is not signed with an appropriate key, for instance) it will then validate the binary against a built-in certificate. If this succeeds and if the binary or signing key are not forbidden then shim will relocate and execute the binary.
  • Github: Super UEFIinSecureBoot Disk -> Super UEFIinSecureBoot Disk is a proof-of-concept (not actively maintained or enhanced) bootable image with GRUB2 bootloader designed to be used as a base for recovery USB flash drives. Key feature: disk is fully functional with UEFI Secure Boot mode activated. It can launch any operating system or .efi file, even with untrusted, invalid or missing signature.
  • Github: TcpTransport -> A UEFI application to receive TCP network packets.
  • Github: UefiVarMonitor -> The runtime DXE driver monitoring access to the UEFI variables by hooking the runtime service table.
  • Github: FakeSecureBoot -> UEFI DXE driver to fake Secure Boot. Hooks the gRT->GetVariable function to always return enabled if Secure Boot state is queried.

Bootkits

The most advanced malware that infects the boot process, which remains undetectable.

Basics

What is a bootkit exactly? Are they the elements you can develop with EDK2?

  • Web Kaspersky: Bootkit -> A bootkit is a malicious program designed to load as early as possible in the boot process, in order to control all stages of the operating system start up, modifying system code and drivers before anti-virus and other security components are loaded. The malicious program is loaded from the Master Boot Record (MBR) or boot sector. In effect, a bootkit is a rootkit that loads before the operating system.
  • Web CrowdStrike: Bootkit - Definition, Prevention, and Removal -> A strong cybersecurity strategy should not only include reactive approaches to cyberattacks, but should also include proactive prevention methods for infections such as bootkit. Mitigating the consequences of a bootkit infection and removing the infection are valuable tools for your cybersecurity team. Bootkits are stealthy, and understanding how they work and how to combat them can help keep your business safe from threat actors.
  • Web Positive Technologies: Bootkits: evolution and detection methods -> Bootkits were previously thought to exist mainly in proof-of-concept form, and not used in real attacks. However, only two years separated the appearance of the first PoC and the first bootkit attack.

Videos

Watch these videos to learn what a bootkit is and the techniques used in its development.

Analysis

Gain a true understanding of this malware by reading its analyses.

  • Web WeLiveSecurity: BlackLotus UEFI bootkit - Myth confirmed -> The first in-the-wild UEFI bootkit bypassing UEFI Secure Boot on fully updated UEFI systems is now a reality.
  • Web Binarly: The Untold Story of the BlackLotus UEFI Bootkit -> My experience with the analysis and detection of rootkits and bootkits goes back more than 20 years. In the early 2000s, the main challenge was dealing with infected machines when rootkits and bootkits modified the operating system kernel to conceal malicious components. It was such a fun time reverse engineering advanced threats in the good old days that I co-wrote "Rootkits and Bootkits: Reversing Modern Malware and Next Generation Threats", a book full of the most interesting stories of our time going down the rabbit hole of advanced malware.
  • Web WeLiveSecurity: UEFI threats moving to the ESP - Introducing ESPecter bootkit -> ESET research discovers a previously undocumented UEFI bootkit with roots going back all the way to at least 2012.
  • Web Palo Alto: Diving Into Glupteba's UEFI Bootkit -> Glupteba is advanced, modular and multipurpose malware that, for over a decade, has mostly been seen in financially driven cybercrime operations. This article describes the infection chain of a new campaign that took place around November 2023. We will focus on one intriguing and previously undocumented feature: a Unified Extensible Firmware Interface (UEFI) bootkit.
  • Web SecureList: FinSpy - Unseen findings -> FinSpy, also known as FinFisher or Wingbird, is an infamous surveillance toolset. Kaspersky has been tracking deployments of this spyware since 2011.
  • Web SecureList: CosmicStrand - The discovery of a sophisticated UEFI firmware rootkit -> FinSpy, also known as FinFisher or Wingbird, is an infamous surveillance toolset. Kaspersky has been tracking deployments of this spyware since 2011.
  • Web SecureList: MosaicRegressor - Lurking in the Shadows of UEFI -> UEFI has become a prominent technology that is embedded within designated chips on modern day computer systems. Replacing the legacy BIOS, it is typically used to facilitate the machine's boot sequence and load the operating system, while using a feature-rich environment to do so. At the same time, it has become the target of threat actors to carry out exceptionally persistent attacks.
  • Web WeLiveSecurity: LoJax - First UEFI rootkit found in the wild, courtesy of the Sednit group -> ESET researchers have shown that the Sednit operators used different components of the LoJax malware to target a few government organizations in the Balkans as well as in Central and Eastern Europe.
  • Web Twitter X: ESETresearch - Malicious EFI samples -> ESETresearch identified multiple malicious EFI bootloader samples. The malware displays a ransom message and prevents the computer from booting. It can compromise computers with disabled UEFI Secure Boot feature.
  • Web VMWare: Detecting UEFI Bootkits in the Wild -> Threat actors are continually looking for ways to improve the persistence of their malware and implants. Bootkits, meaning rootkits running at the firmware level, have been utilized for this purpose. Once bootkits are installed, it can be extremely difficult to detect or remove versus OS-level rootkits as they are executed prior to the actual OS boot process.
  • Web Binarly: UEFI Bootkit Hunting: In-Depth Search for Unique Code Behavior -> Firmware threats such as bootkits and implants have become increasingly prevalent due to their persistence and ability to evade detection compared to traditional OS-level malware. Attackers favor these threats because they can remain undetected even when conventional security measures are in place, especially if UEFI Secure Boot is disabled. Detecting unknown bootkits under these circumstances is a critical challenge in cybersecurity. Mostly, the publicly known UEFI implants and bootkits have been detected after successful deployment, which points to the limitations of the existing security solutions.

Source Code

Observe that the components shown in the source code are the applications and drivers you can develop with EDK2.

  • Github: Abyss -> Abyss is a comprehensive project thoroughly designed with the explicit goal of establishing a robust foundation for the development of bootkits. By offering a centralized repository of knowledge, Abyss stands as a valuable initiative for anyone looking to contribute to and benefit from the collective understanding of this field.
  • Github: RedLotus -> Windows UEFI Bootkit in Rust designed to facilitate the manual mapping of a driver manual mapper before the kernel (ntoskrnl.exe) is loaded, effectively bypassing Driver Signature Enforcement (DSE).
  • Github: EfiGuard -> Portable x64 UEFI bootkit that patches the Windows boot manager, boot loader and kernel at boot time in order to disable PatchGuard and Driver Signature Enforcement (DSE).
  • Github: BlackLotus -> An innovative UEFI Bootkit designed specifically for Windows. It incorporates a built-in Secure Boot bypass and Ring0/Kernel protection to safeguard against any attempts at removal. This software serves the purpose of functioning as an HTTP Loader.
  • Github: DmaBackdoorBoot -> UEFI DXE driver intended for executing of kernel mode and user mode payloads under the Windows operating system by having an arbitrary code execution at early boot stage during DXE phase of the platform initialization.
  • Github: Bootlicker -> A generic UEFI bootkit used to achieve initial usermode execution.
  • Github: Bootkit Showcase -> Real-World Examples of Infrastructure Security Threats.
  • Github: SandboxBootkit -> Bootkit tested on Windows Sandbox to patch ntoskrnl.exe and disable DSE/PatchGuard.
  • Github: Umap -> Windows UEFI bootkit that loads a generic driver manual mapper without using a UEFI runtime driver.
  • Github: UEFI-Bootkit -> A small bootkit designed to use zero assembly.
  • Github: PeiBackdoor -> This project implements early stage firmware backdoor for UEFI based firmware. It allows to execute arbitrary code written in C during Pre EFI Init (PEI) phase of Platform Initialization (PI).
  • Github: Rovnix -> Volume Boot Record Bootkit.
  • Github: Vector EDK -> EFI Development Kit.
  • Github: Dreamboot -> UEFI bootkit.
  • Github: UEFIBootkit -> Simple PoC for a bootkit written as a UEFI Option ROM Driver.
  • Web Back Engineering: Voyager - A Hyper-V Hacking Framework For Windows 10 x64 (AMD & Intel) -> Voyager is a project designed to offer module injection and vmexit hooking for both AMD & Intel versions of Hyper-V. This project works on all versions of Windows 10-x64 (2004-1507).
  • Github: Efi-Memory - PoC EFI runtime driver for memory r/w & kdmapper fork -> Efi-memory is a proof-of-concept EFI runtime driver for reading and writing to virtual memory. It uses EfiGuards method of hooking SetVariable to communicate with the user-mode process.
  • Github: EFI Driver Access -> Efi Driver Access is a simply project to load a driver during system boot with the idea to give the user kernel access for read/write memory without restrictions.

Windows Kernel

Explore the heart of Windows.

Basics

The essentials for learning how Windows operates beneath the surface.

Videos

Watch these videos to gain a deeper understanding of Windows' core components.

  • Youtube Video: Pavel Yosifovich - Native Applications What, Why, and How? -> Normally, native applications are built by Microsoft only. Examples include Smss.exe (the session manager), CSrss.exe (the Windows subsystem process), and UserInit.exe (normally executed by WinLogon.exe on a successful login).
  • Youtube Video: ACCU 2019 - Windows Native API -> Many programmers are familiar with the Windows "Win32" API that provides access to a large variety of services, from user interface to memory management; but far fewer have much idea about the Windows "Native" API which is the mechanism used to access the operating system services located in the kernel.
  • Youtube Video: BlackhHat 2015 - Battle Of The SKM And IUM, How Windows 10 Rewrites OS Architecture -> In Windows 10, Microsoft is introducing a radical new concept to the underlying OS architecture, and likely the biggest change to the NT design since the decision to move the GUI in kernel-mode. In this new model, the Viridian Hypervisor Kernel now becomes a core part of the operating system and implements Virtual Secure Machines (VSMs) by loading a true microkernel - a compact (200kb) NT look-alike with its own drivers called the Secure Kernel Mode (SKM) environment, which then uses the Hypervisor to hook and intercept execution of the true NT kernel. This creates a new paradigm where the NT Kernel, executing in Ring 0, now runs below the Secure Kernel, at Ring ~0 (called Virtual Trust Level 1).
  • Youtube Video: Windows IT Pro - Sysinternals Overview (Microsoft, tools, utilities, demos) -> Learn about the tools that security, developer, and IT professionals rely on to analyze, diagnose, troubleshoot, and optimize Windows from creator Mark Russinovich. Find out which utilities will help you optimize any Windows system's reliability, efficiency, performance, and security.
  • Youtube Video: DotNext - Pavel Yosifovich, Windows 10 internals for .NET developers -> The .NET Framework provides some level of abstraction over the Windows OS, but understanding the way Windows works can make you a better .NET developer. Windows 10 is progressing at a faster cadence than in the past. Some of its features are not exposed to .NET developers directly.
  • Youtube Video: REcon 2019 - The Last Generic Win32K KASLR Defeat in Windows -> This talk will describe the final mistake that Microsoft made when 'fixing' the shared heap (desktop heap and session heap) structures that are shared by User and GDI objects in Win32k.sys, which have leaked kernel pointers for over 2 decades to user-mode. I will cover how existing techniques were broken in Fall Creator's Update (RS4), and how this build, and the subsequent (RS5 and 19H1) had a critical implementation flaw which still made KASLR bypasses possible.
  • Youtube Video: TryHackMe - Windows Internals -> In this video, we begin working through the "Host Evasion" module on TryHackMe which is part of the Red Team path.

Structures

Learn about the opaque structures of Windows, the core code of the kernel.

  • Web CodeMachine: Windows kernel data structures -> Catalog of key Windows kernel data structures.
  • Web Vergilius Project: Windows kernel -> Take a look into the depths of Windows kernels and reveal more than 60000 undocumented structures.
  • Web Geoff Chappell: Windows kernel -> Because kernel-mode programming, e.g., of device drivers and file system filter drivers, is the commercial specialty that funded this website's early development as a free public resource, it could not easily itself be a subject for the free public resource. Not until 2016 did it start getting serious attention at this website, not even to publish old notes whose commercial value had long passed. Now, however, the Kernel study is well on its way to becoming a resource to reckon with for the functions and structures exposed by the kernel and the HAL.
  • Web ReactOS -> Imagine running your favorite Windows applications and drivers in an open-source environment you can trust. That's the mission of ReactOS!

Debugging

Analyze and debug critical structures along with the entire kernel.

Basics

Debug the Windows OS.

  • Web Microsoft: WinDbg -> WinDbg is a debugger that can be used to analyze crash dumps, debug live user-mode and kernel-mode code, and examine CPU registers and memory.
  • Web WinDbg Org -> WinDbg Quick Links, Extensions, Scripts.
  • Web Microsoft: Setting Up Kernel-Mode Debugging -> How to start debugging Windows kernel.
  • Web Microsoft: Local Kernel-Mode Debugging -> Debugging Tools for Windows supports local kernel debugging. This is kernel-mode debugging on a single computer. In other words, the debugger runs on the same computer that is being debugged.
  • Web Microsoft: Remote Debugging Using WinDbg -> Remote debugging involves two debuggers running at two different locations. The debugger that performs the debugging is called the debugging server. The second debugger, called the debugging client, controls the debugging session from a remote location. To establish a remote session, you must set up the debugging server first and then activate the debugging client.
  • Github: Modern Debugging with WinDbg Preview DEFCON 27 workshop -> It's 2019 and yet too many Windows developers and hackers alike rely on (useful but rather) old school tools for debugging Windows binaries (OllyDbg, Immunity Debugger). What they don't realize is that they are missing out on invaluable tools and functionalities that come with Microsoft newest WinDbg Preview edition. This hands-on workshop will attempt to level the field, by practically showing how WinDbg has changed to a point where it should be the first tool to be installed on any Windows (10) for binary analysis machine: after a brief intro to the most basic (legacy) commands, this workshop will focus around debugging modern software (vulnerability exploitation, malware reversing, DKOM-based rootkit, JS engine) using modern techniques provided by WinDbg Preview (spoiler alert to name a few, JavaScript, LINQ, TTD).
  • Web Microsoft: Reading and Filtering Debugging Messages -> The DbgPrintEx, vDbgPrintEx, vDbgPrintExWithPrefix, and KdPrintEx routines send a message to the kernel debugger under conditions that you specify. This procedure enables you to filter out low-priority messages.
  • Web CodeMachine: WinDBG quick start tutorial -> This post goes over the important commands in WinDBG through a step-by-step follow-along style walkthrough to help you get a jump start into using WinDBG and getting familiar with the commonly used commands.
  • Web WinDbg Info: Common WinDbg Commands -> Common WinDbg Commands thematically grouped by Robert Kuster

Commands

Key commands to use in the official Microsoft debugger, WinDbg.

Scripting

Create a script to automate the debugging process.

Classic
JavaScript
Python
  • Web PyPI: PYKD -> Python Extension for WinDbg.
  • Blog: PYKD Tutorial Part 1 -> Using windbg script syntax is such annoying thing that almost all reverse engineers have problems dealing with it but automating debugging gives such a power that can't be easily ignored. A good solution to solve this problem is using the power and simplicity of Python and Windbg together.
  • Blog: PYKD Tutorial Part 2 -> Using windbg script syntax is such annoying thing that almost all reverse engineers have problems dealing with it but automating debugging gives such a power that can't be easily ignored. A good solution to solve this problem is using the power and simplicity of Python and Windbg together.
PowerShell
  • Web PowerShell Gallery: WinDbg -> Module for automation of Windows Debugging.
  • Blog: Scripting WinDbg with PowerShell -> A while back, Roberto Farah published a script library to help control WinDbg through PowerShell. I've been using WinDbg for more debugging lately, and decided (after following one to many object references by hand) that I needed to script my investigations.
Extensions

Protection Mechanisms

How the core of Windows is secured.

Driver Signature Enforcement (DSE)

Prevent the use of unsigned drivers.

Basics
  • Web Microsoft: Signing a Driver -> All drivers running on 64-bit versions of Windows must be signed before Windows will load them. However, driver signing is not required on 32-bit versions of Windows. In order to sign a driver, a certificate is required. You can create your own certificate to sign your driver with during development and testing. However, for a public release you must sign your driver with a certificate issued by a trusted root authority.
  • Web Microsoft: Introduction to Test-Signing -> Drivers should be test-signed with a digital signature during development and test for the following reasons: To facilitate and automate installation, To be able to load kernel-mode drivers on 64-bit versions of Windows Vista and later versions of Windows, To play back certain types of next-generation premium content, all kernel-mode components in Windows Vista and later versions of Windows must be signed.
  • Web Driver Easy: Disable Driver Signature Enforcement on Windows 10 Easily! -> On Windows 8 and Windows 10 (64-bit), Microsoft has included a feature, driver signature enforcement. It is a feature that is designed to ensure that users of Microsoft can only load drivers that have been signed by Microsoft.
  • Web Make Use Of: How to Disable Driver Signature Enforcement and Install Unsigned Drivers on Windows -> Sometimes, Windows will block you from installing an unsigned driver, which is a driver you've downloaded elsewhere other than through a Windows Update or the device manufacturer's website. But if you need the driver, and you know it is perfectly safe, you can turn off driver signature enforcement and let it through.
  • Web How To Geek: How to Disable Driver Signature Verification on 64-Bit Windows 8 or 10 -> 64-bit versions of Windows 10 and 8 include a "driver signature enforcement" feature. They'll only load drivers that have been signed by Microsoft. To install less-than-official drivers, old unsigned drivers, or drivers you're developing yourself, you'll need to disable driver signature enforcement.
Bypasses
  • Web Code Project: Disable Driver Signature Enforcement with DSE-Patcher -> Driver Signature Enforcement (DSE) was introduced by Microsoft starting with Windows Vista x64. DSE is a security feature of the operating system, which ensures that only valid signed drivers are loaded. To install unsigned drivers, the DSE security feature has to be disabled. DSE-Patcher can be used to disable DSE on all 64-bit operating systems starting with Windows Vista and later. We developed DSE-Patcher to show the interested coder how easy it is to use known vulnerabilities and change memory in kernel address space.
  • Web Fortinet: The Swan Song for Driver Signature Enforcement Tampering -> Code Integrity is a threat protection feature first introduced by Microsoft over 15 years ago. On x64-based versions of Windows, kernel-mode drivers must be digitally signed and checked each time they are loaded into memory. This is also referred to as Driver Signature Enforcement (DSE).
  • Blog: The dusk of g_CiOptions: circumventing DSE with VBS enabled -> In this article, we will explore the concept of bypassing Driver Signature Enforcement (DSE) in the Virtualization Based Security (VBS) era with only a write-what-where exploit primitive.
  • Blog: Offset-free DSE bypass across Windows 11 & 10: utilising ntkrnlmp.pdb -> Parsing ntkrnlmp.pdb on the target to eliminate the need for static offsetting and thus safely and dynamically bypassing driver signature enforcement across multiple Windows 10 & 11 versions.
  • Blog: g_CiOptions in a Virtualized World -> In this post we will look at a common technique used to disable driver signing enforcement, how VBS has attempted to stop attackers from exploiting this, and how when not partnered with HVCI, just how easy it is to bypass this security control.
  • Github: DisableDSE -> A method to Disable DSE using .data ptr hooks.
  • Github: DSE Hook -> Load unsigned kernel-driver by patching dse in 248 lines. This project abuses a vulnerable driver called "winio64.sys".
  • Github: DSE & PG bypass via BYOVD attack
  • Github: PastDSE -> It is a Driver Sign Enforcement "bypass" using a leaked EV code signing certificate. It is actually not a real bypass since it does only change the date to 01-01-2014 before signing the driver and restores it afterwards. The Kernel driver loader will accept all driver images as long as the code was signed by a extended validation code signing certificate which was not revoked.
  • Github: Gigabyte Disable DSE -> Code to disable DSE (Driver Signature Enforcement) using vulnerable gigabyte driver.

Virtualization Based Security (VBS)

Assume the kernel can be compromised and create an isolated virtual environment.

Basics
  • Web Microsoft: Virtualization-based Security (VBS) -> Virtualization-based security, or VBS, uses hardware virtualization and the Windows hypervisor to create an isolated virtual environment that becomes the root of trust of the OS that assumes the kernel can be compromised. Windows uses this isolated environment to host a number of security solutions, providing them with greatly increased protection from vulnerabilities in the operating system, and preventing the use of malicious exploits which attempt to defeat protections. VBS enforces restrictions to protect vital system and operating system resources, or to protect security assets such as authenticated user credentials.
Videos
  • Presentation: BlackHat USA 2016: Analysis of the Attack Surface of Windows 10 Virtualization-Based Security
  • Youtube Video: BlackHat USA 2016: Analysis of the Attack Surface of Windows 10 Virtualization-Based Security -> In Windows 10, Microsoft introduced virtualization-based security (VBS), the set of security solutions based on a hypervisor. In this presentation, we will talk about details of VBS implementation and assess the attack surface - it is very different from other virtualization solutions. We will focus on the potential issues resulting from the underlying platform complexity (UEFI firmware being a primary example).
  • Youtube Video: BSidesKC 2022 - No Code Execution? No Problem! - Living The Age of Virtualization-Based Security -> Windows 11 saw the default enablement of some of the most powerful exploit mitigations on the market - many of them falling under the purview of Virtualization-Based Security, or VBS. These exploit mitigations are instrumented through Microsoft's hypervisor, Hyper-V, which provides a "higher root of trust" than the Windows kernel itself. With the advent of the default enablement of these mitigations - simply put - the "old" way of doing things won't suffice when it comes to kernel exploitation. Hypervisor-Protected Code Integrity (HVCI), one of these hypervisor-based mitigations, works by outright preventing any malicious, unsigned shellcode from running within the Windows kernel. Does this now mean "game over" for attackers? This talk investigates how these new, modern mitigations work and how today's attackers must and can adapt to the new bar set by these exploit mitigations.

Kernel Patch Protection (KPP) / PatchGuard

Prevent alterations to critical components and structures.

Basics
Videos
  • Youtube Video: RSA Conference - Windows Kernel Patch Protection -> This session will look at a critical flaw in the design of Windows Kernel Patch Protection (PatchGuard), a system used to prevent modification to kernel code and other critical structure. The design of PatchGuard will be discussed, along with the design of an attack which uses the flaw in PatchGuard to disable the PatchGuard response entirely.
Bypasses
  • Web Uninformed: Bypassing Patchguard on Windows -> In the caste system of operating systems, the kernel is king. And like most kings, the kernel is capable of defending itself from the lesser citizens, such as user-mode processes, through the castle walls of privilege separation. However, unlike most kings, the kernel is typically unable to defend itself from the same privilege level at which it operates. Without the kernel being able to protect its vital organs at its own privilege level, the entire operating system is left open to modification and subversion if any code is able to run with the same privileges as the kernel itself.
  • GitHub: PatchGuardBypass -> Bypassing PatchGuard on modern x64 systems.
  • Web CyberArk: GhostHook -> Bypassing PatchGuard with Processor Trace Based Hooking.
  • GitHub: InfinityHook -> Kernel driver that will hook system calls.
  • Blog: New bypass disclosed in Microsoft PatchGuard (KPP) -> After GhostHook and InfinityHook, we now have ByePg.
  • Blog: ByePg -> Defeating Patchguard Using Exception - Hooking.
  • Github: Shark -> Turn off PatchGuard in real time for win7 (7600) ~ later.
  • Github: UPGDSED -> Universal PatchGuard and Driver Signature Enforcement Disable.
  • Github: PgResarch -> PatchGuard Research.

Drivers

Components linked to malware that targets the core of Windows.

Basics

Learn the basics of creating kernel mode drivers.

Windows Driver Kit (WDK)

Configure the workspace to develop those unique drivers.

Videos

Learn with visual examples how to develop those drivers.

Source Code

Samples of kernel mode drivers.

  • Github: Windows driver samples -> This repo contains driver samples prepared for use with Microsoft Visual Studio and the Windows Driver Kit (WDK). It contains both Universal Windows Driver and desktop-only driver samples.
  • Github: Windows Kernel Programming second edition book samples
  • Github: VectorKernel -> PoCs for Kernelmode rootkit techniques research or education. Currently focusing on Windows OS. All modules support 64bit OS only.
  • Github: Hidden -> 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.
  • Web Back Engineering: Physmeme - Windows Unsigned Kernel Driver Mapper -> Physmeme is a driver mapper that works with any form of read and write to physical memory. It is highly modular code that allows a reverse engineer to easily integrate their own vulnerable driver. If you are able to read and write to physical memory you can now map an unsigned driver into your kernel just by coding four functions.
  • Github: Anti-Delete -> Protects deletion of files with a specified extension using a kernel-mode driver.
  • Github: DisplayMiniportHooking -> Port and miniport drivers are a concept that Microsoft uses to simplify the development of kernel code by different vendors. The port driver (Supplied by Microsoft) is responsible of performing common tasks and by that it helps vendors to avoid writing a lot of boilerplate code. Miniport drivers, supplied by third party vendors, are responsible for the execution tasks for a specific device. The miniport registers its callback functions with the port driver, which triggers them when needed.
  • Github: KernelProcessList -> Example Windows Kernel-mode Driver which enumerates running processes.
  • Github: Blackout -> Kill anti-malware protected processes (BYOVD) (Microsoft Won).
  • Github: Kernel Callbacks Removal (Bypassing EDR Detections)
  • Github: RealBlindingEDR -> Remove AV/EDR Kernel ObRegisterCallbacks, CmRegisterCallback, MiniFilter Callback, PsSetCreateProcessNotifyRoutine Callback, PsSetCreateThreadNotifyRoutine Callback, PsSetLoadImageNotifyRoutine Callback...
  • Github: Offensive Windows Drivers Development -> Offensive-Windows-Drivers-Development is a research project designed to explore the development of Windows kernel-mode and user-mode drivers for offensive security purposes. The project focuses on techniques for low-level interaction with the Windows operating system, including file system interception, process manipulation, and advanced memory operations.

Reversing

Explore the functional behavior of official drivers.

Basics
  • Blog: Mimidrv In Depth: Exploring Mimikatz's Kernel Driver -> Mimikatz provides the opportunity to leverage kernel mode functions through the included driver, Mimidrv. Mimidrv is a signed Windows Driver Model (WDM) kernel mode software driver meant to be used with the standard Mimikatz executable by prefixing relevant commands with an exclamation point (!). Mimidrv is undocumented and relatively underutilized, but provides a very interesting look into what we can do while operating at ring 0.
  • Blog: Methodology for Static Reverse Engineering of Windows Kernel Drivers -> Attacks against Windows kernel mode software drivers, especially those published by third parties, have been popular with many threat groups for a number of years. Popular and well-documented examples of these vulnerabilities are the CAPCOM.sys arbitrary function execution, Win32k.sys local privilege escalation, and the EternalBlue pool corruption. Exploiting drivers offers interesting new perspectives not available to us in user mode, both through traditional exploit primitives and abusing legitimate driver functionalities.
  • Blog: Windows kernel driver static reverse using IDA and GHIDRA -> Here are some notes for Windows drivers reverse enginering noob. This topic is already covered and you can find many resources on Internet, here we will use IDA and GHIDRA and observe differences.
Videos
  • Youtube Video: Nir Lichtman - Reverse Engineering Simple Windows Driver -> In this video I will demonstrate how you can reverse engineer a simple "Hello, World" driver on Windows 10.
  • Presentation: REcon 2015 - Reverse Engineering Windows AFD.sys (Steven Vittitoe)
  • Youtube Video: REcon 2015 - Reverse Engineering Windows AFD.sys (Steven Vittitoe) -> What happens when you make a socket() call in Windows? This presentation will briefly walk through the rather well documented winsock user mode framework before diving into the turmoil of ring 0. There is no map to guide us here. Our adventure will begin where MSDN ends and our first stop along the way is with an IOCTL to AFD.sys, or the awkwardly named ancillary function driver. This driver is of particular interest because it is so widely used and yet most people that use it do not even know it exists. Nearly every Windows program managing sockets depends on this driver. Even more interesting is that the device created by AFD.sys is accessible from every sandbox Google Project Zero looked at. In fact, there isn't even support to restrict access to this device until Windows 8.1. Staying true to Windows style AFD.sys is a complex driver with over 70 reachable IOCTL's and support for everything from SAN to TCP. It is no wonder that this driver weighs in at 500KB. This complexity combined with accessibility breed a robust ring 0 attack surface. Current fuzzing efforts will also be shared in this presentation and the time we are done you should have a good idea of what happens when making a socket() call without having to spend hours in IDA to figure it out.

Fuzzing

Identify vulnerabilities in those drivers.

Basics
  • Web Check Point: Bugs on the Windshield - Fuzzing the Windows Kernel -> In our previous research, we used WinAFL to fuzz user-space applications running on Windows, and found over 50 vulnerabilities in Adobe Reader and Microsoft Edge. For our next challenge, we decided to go after something bigger: fuzzing the Windows kernel. As an added bonus, we can take our user-space bugs and use them together with any kernel bugs we find to create a full chain - because RCEs without a sandbox escape/privilege escalation are pretty much worthless nowadays.
  • Web CyberArk: Finding Bugs in Windows Drivers, Part 1 - WDM -> Finding vulnerabilities in Windows drivers was always a highly sought-after prize by sophisticated threat actors, game cheat writers and red teamers. As you probably know, every bug in a driver is, in essence, a bug in the Windows kernel, as every driver shares the memory space of the kernel. Don't get me started about user-mode drivers, as they are not interesting. Thus, having the capability to either run code in the kernel, read and write from the model registers, or duplicate privileged access tokens is really all you need to own the system. This two-part blog series will go through the methodology of finding vulnerabilities in WDM drivers, followed by utilizing kernel fuzzing via kAFL. We won't go through other frameworks and models since they are either too niche (looking at your WIA mini driver) or too complicated (looking at you, NDIS). Most bugs seem to be in WDM or in KMDF (might visit KMDF in a future blogpost). In the second blog, timed for RSA Conference in San Francisco, we will talk about kernel fuzzing via kAFL and Intel PT, combining the expertise of low-level reversing, manual vulnerability research with the strong engine of kAFL, alongside using grammar-based fuzzing, which results in finding multiple vulnerabilities.
Videos
  • Youtube Video: HackInTheBox 2019 - The Art Of The Windows Kernel Fuzzing -> Over the year, the Windows kernel has been enhanced through a variety of kernel security additions making it harder for security researchers to find kernel issues, bugs, and exploits. This talk will cover the art of the kernel fuzzing and a tool I developed to aid security researchers in kernel fuzzing. I will introduce a new method of fuzzing Windows kernels, demonstrate the fuzzing framework and how it works.
Tools

Exploitation

Take advantage of the vulnerabilities.

Basics
  • Web Living Off The Land Drivers -> Living Off The Land Drivers is a curated list of Windows drivers used by adversaries to bypass security controls and carry out attacks. The project helps security professionals stay informed and mitigate potential threats.
  • Web CrowdStrike: The Current State of Exploit Development, Part 1 -> In Part 1, we addressed binary exploitation on Windows systems, including some legacy and contemporary mitigations that exploit writers and adversaries must deal with in today's cyber landscape.
  • Web CrowdStrike: The Current State of Exploit Development, Part 2 -> In Part 2, we will walk through more of the many mitigations Microsoft has put in place.
  • Web VMWare: Hunting Vulnerable Kernel Drivers -> In information security, even seemingly insignificant issues could pose a significant threat. One notable vector of attack is through device drivers used by legitimate software developers. There are numerous available drivers to support legacy hardware in every industry, some of which are from businesses that have long stopped supporting the device. To continue operations, organizations rely upon these deprecated device drivers.
  • Web Connor McGarr: Exploit Development CVE-2021-21551 - Dell 'dbutil_2_3.sys' Kernel Exploit Writeup -> I stumbled across this SentinelOne blog post the other day, which outlined a few vulnerabilities in Dell's dbutil_2_3.sys driver, including a memory corruption vulnerability. Although this vulnerability was attributed to Kasif Dekel, it apparently was discovered earlier by Yarden Shafir and Staoshi Tanda, coworkers of mine at CrowdStrike.
  • Blog: Windows Kernel Exploitation HEVD on Windows 10 22H2 -> In this article, I'll share the insights I've gained from self-studying Windows kernel exploitation.
  • Web Fluid Attacks: HEVD - kASLR + SMEP Bypass -> During the last posts, we've been dealing with exploitation in Windows Kernel space. We are using HackSys Extremely Vulnerable Driver or HEVD as the target which is composed of several vulnerabilities to let practitioners sharpen the Windows Kernel exploitation skills.
  • Web Avast: Lazarus and the FudModule Rootkit: Beyond BYOVD with an Admin-to-Kernel Zero-Day -> When it comes to Windows security, there is a thin line between admin and kernel. Microsoft's security servicing criteria have long asserted that "[a]dministrator-to-kernel is not a security boundary", meaning that Microsoft reserves the right to patch admin-to-kernel vulnerabilities at its own discretion. As a result, the Windows security model does not guarantee that it will prevent an admin-level attacker from directly accessing the kernel. This isn't just a theoretical concern. In practice, attackers with admin privileges frequently achieve kernel-level access by exploiting known vulnerable drivers, in a technique called BYOVD (Bring Your Own Vulnerable Driver).
  • Web Microsoft Community: Strategies to monitor and prevent vulnerable driver attacks -> In the ever-evolving landscape of technology, the history of vulnerable drivers in Windows operating systems stands as a testament to the constant battle between innovation and security. From its inception, Windows has been a prime target for malicious actors seeking to exploit vulnerabilities in its drivers. These vulnerabilities, often overlooked, have played a significant role in the history of Windows, shaping its security policies and prompting a continuous cycle of patches and updates. The technique known as Bring Your Own Vulnerable Driver (BYOVD) has become a favoured strategy among threat actors. This involves introducing a digitally signed and trusted vulnerable driver into the kernel and exploiting it to gain kernel-level access. With this access a threat actor can undermine security measures, extract sensitive credentials, or alter system behaviour to remain undetected.
  • Web Microsoft: Microsoft recommended driver block rules -> Microsoft has strict requirements for code running in kernel. So, malicious actors are turning to exploit vulnerabilities in legitimate and signed kernel drivers to run malware in kernel. One of the many strengths of the Windows platform is our strong collaboration with independent hardware vendors (IHVs) and OEMs. Microsoft works closely with our IHVs and security community to ensure the highest level of driver security for our customers. When vulnerabilities in drivers are found, we work with our partners to ensure they're quickly patched and rolled out to the ecosystem.
  • Web Check Point: Breaking Boundaries: Investigating Vulnerable Drivers and Mitigating Risks -> Have you ever wondered why there are so many vulnerable drivers and what might be causing them to be vulnerable? Do you want to understand why some drivers are prone to crossing security boundaries and how we can stop that?
  • Blog: BYOVD A Kernel Attack: Stealthy Threat to Endpoint Security -> The cybersecurity landscape is continually evolving, with adversaries employing increasingly sophisticated tactics to evade detection and compromise systems. One such technique gaining prominence is Bring Your Own Vulnerable Driver (BYOVD). This method leverages legitimate signed but vulnerable drivers to bypass security controls, granting attackers unparalleled access and control over compromised systems on kernel level.
Videos
Lab
  • Github: HackSys Extreme Vulnerable Driver -> The HackSys Extreme Vulnerable Driver (HEVD) is a Windows Kernel driver that is intentionally vulnerable. It has been developed for security researchers and enthusiasts to improve their skills in kernel-level exploitation. HEVD offers a range of vulnerabilities, from simple stack buffer overflows to more complex issues such as use-after-free, pool buffer overflows, and race conditions. This allows researchers to explore exploitation techniques for each implemented vulnerability.
  • Github: Capcom Rootkit Proof-Of-Concept
PoCs
  • Github: KDMapper - Exploits iqvw64e.sys Intel driver -> KDMapper is a simple tool that exploits iqvw64e.sys Intel driver to manually map non-signed drivers in memory.
  • Github: KDMapper - Vulnerable Driver Manual Mapper -> This repository contains C++ code to load custom drivers by exploiting a vulnerable driver in Windows. This project demonstrates a technique to bypass DSE (Driver Signature Enforcement) and PatchGuard using a vulnerable driver, and to load a custom driver. It serves as a proof of concept for security research purposes.
  • Github: RTCore64 Vulnerability -> Use RTCore64 to map your driver on windows 11.
  • Github: CVE-2024-49138 POC -> Proof of Concept that exploits CVE-2024-49138 in CLFS.sys. CrowdStrike detected the vulnerability actively exploited by threat actors. Tested on Windows 11 23h2.

Tools

Study and examine kernel components.

  • Web Microsoft: WinDbg -> WinDbg is a debugger that can be used to analyze crash dumps, debug live user-mode and kernel-mode code, and examine CPU registers and memory.
  • Github: DumpScan -> Finding secrets in kernel and user memory.
  • Web Microsoft: Sysinternals Suite -> The Sysinternals Troubleshooting Utilities have been rolled up into a single Suite of tools. This file contains the individual troubleshooting tools and help files. It does not contain non-troubleshooting tools like the BSOD Screen Saver.
  • Web SourceForge: Process Hacker -> A free, powerful, multi-purpose tool that helps you monitor system resources, debug software and detect malware.
  • Github: Capa - The FLARE team's open-source tool to identify capabilities in executable files -> Capa detects capabilities in executable files. You run it against a PE, ELF, .NET module, shellcode file, or a sandbox report and it tells you what it thinks the program can do. For example, it might suggest that the file is a backdoor, is capable of installing services, or relies on HTTP to communicate.

Rootkits

The most advanced malware that infects the operating system kernel, which remains undetectable.

Basics

What is a rootkit exactly? Are they Kernel Mode Drivers?

Videos

Watch these videos to understand how to develop this malware with advanced features.

Analysis

Source Code

Complex examples of this malware.

  • Github: Benthic -> Benthic is a comprehensive project thoroughly designed with the explicit goal of establishing a robust foundation for the development of rootkits. By offering a centralized repository of knowledge, Benthic stands as a valuable initiative for anyone looking to contribute to and benefit from the collective understanding of this field.
  • Github: Nidhogg -> Nidhogg is a multi-functional rootkit to showcase the variety of operations that can be done from kernel space. The goal of Nidhogg is to provide an all-in-one and easy-to-use rootkit with multiple helpful functionalities for operations. Besides that, it can also easily be integrated with your C2 framework.
  • Github: Black Angel -> lack Angel is a Windows 11/10 x64 kernel mode rootkit. Rootkit can be loaded with enabled DSE while maintaining its full functionality.
  • Github: Cronos -> Cronos is Windows 10/11 x64 ring 0 rootkit. Cronos is able to hide processes, protect and elevate them with token manipulation.
  • Github: Spectre -> Windows kernel-mode rootkit that abuses legitimate communication channels to control a machine. Hiding Processes, token manipulation , hiding tcp network connections by port...
  • Github: Sunder -> Windows rootkit modeled after Lazarus Group's FudModule rootkit. Reference this version of Sunder for an example of the appid.sys driver exploit, which was utilized by Lazarus Group FudModule rootkit. Sunder's vulnerable driver in this GitHub repository is Dell's dbutil_2_3.sys driver, since it is a simple vulnerability and therefore makes the rootkit-specific code easier to read. This driver is blocked by Microsoft.
  • Blog: Eagle -> This post will go through some of the basic rootkit techniques, using one of the first publicly available rootkits made in Rust as a proof of concept. Many anti-cheats and EDRs are utilizing Windows kernel drivers using rootkit-like techniques to detect game hackers or adversaries. However, this is a cat and mouse game, and the game hackers and malware authors have been years ahead of the industry. Why was this made? For fun, learning, to demonstrate the power of Rust and because Rust is awesome. This post assumes that the reader understands the basics of how Windows Kernel programming and how device drivers work.
  • Github: Eagle -> Windows Kernel Rookit in Rust (Rusty Rootkit).
  • Github: ZwHawk -> A kernel rootkit with remote command and control interface for windows.
  • Github: www.rootkit.com mirror -> www.rootkit.com users section mirror, sql database dump, and a few other files/rootkits.
  • Github: TDL (Turla Driver Loader) -> Driver loader for bypassing Windows x64 Driver Signature Enforcement.
  • Github: Autochk Rootkit -> Reverse engineered source code of the autochk rootkit.
  • Github: Reptile -> LKM Linux rootkit.

Techniques

Installation, bfuscation and persistence techniques applied by this malware.

I/O control codes (IOCTLs) / I/O request packets (IRPs)

Basics
  • Web Microsoft: Introduction to I/O control codes -> I/O control codes (IOCTLs) are used for communication between user-mode applications and drivers, or for communication internally among drivers in a stack. I/O control codes are sent using IRPs. User-mode applications send IOCTLs to drivers by calling DeviceIoControl, which is described in Microsoft Windows SDK documentation. Calls to DeviceIoControl cause the I/O manager to create an IRP_MJ_DEVICE_CONTROL request and send it to the topmost driver.
  • Web Microsoft: I/O request packets -> Most of the requests that are sent to device drivers are packaged in I/O request packets (IRPs). An operating system component or a driver sends an IRP to a driver by calling IoCallDriver, which has two parameters: a pointer to a DEVICE_OBJECT and a pointer to an IRP. The DEVICE_OBJECT has a pointer to an associated DRIVER_OBJECT. When a component calls IoCallDriver, we say the component sends the IRP to the device object or sends the IRP to the driver associated with the device object. Sometimes we use the phrase passes the IRP or forwards the IRP instead of sends the IRP.
  • Web RedTeamNotes: Sending Commands From Your Userland Program to Your Kernel Driver using IOCTL -> This is a quick exercise that demonstrates how to: Create a simple WDM kernel mode driver, that can receive and respond to a custom defined input/output control code (IOCTL) sent in from a userland program. Create a simple userland program that can sent a custom defined IOCTL to the kernel driver. Pass some data from the userland program to the kernel driver via DeviceIoConctrol. Pass some data back from the kernel to the userland program.
  • Web Windows IOCTL Reference
  • Blog: Understanding IOCTLs for Windows Vulnerability Research & Exploit Development -> Input/Output Control (IOCTL) is a control code that allows user-mode applications to send specific commands to device drivers. These commands can trigger various operations, such as reading data, writing data, or performing hardware-specific tasks.

Direct Kernel Object Modification (DKOM)

Basics
PoCs
  • Github: DKOM -> Windows 10 Direct Kernel Object Manipulation.
  • Github: Win_Rootkit -> A kernel-mode rootkit with remote control that utilizes C++ Runtime in it's driver. Uses DKOM and IRP Hooks.
  • Github: HideProcess -> A basic Direct Kernel Object Manipulation rootkit that removes a process from the EPROCESS list, hiding it from the Task Manager.
  • Github: HideDriver -> Using DKOM to hide kernel mode drivers.
  • Github: Rootkit DKOM -> Direct Kernel Object Manipulationon _EPROCESS internal structure.

Keyboard Filter (Keylogger)

Basics
  • Web Apriorit: Keystroke Monitoring -> In this article we will consider the methods of hooking keyboard data in the kernel mode. The described approaches can be used for solving the tasks of keystroke analysis, blocking and also redefining some combinations.

Windows Filtering Platform (WFP)

Basics
  • Web Microsoft: Windows Filtering Platform -> Windows Filtering Platform (WFP) is a set of API and system services that provide a platform for creating network filtering applications. The WFP API allows developers to write code that interacts with the packet processing that takes place at several layers in the networking stack of the operating system. Network data can be filtered and also modified before it reaches its destination.
  • Web Scorpio Software: Introduction to the Windows Filtering Platform -> As part of the second edition of Windows Kernel Programming, I’m working on chapter 13 to describe the basics of the Windows Filtering Platform (WFP). The chapter will focus mostly on kernel-mode WFP Callout drivers (it is a kernel programming book after all), but I am also providing a brief introduction to WFP and its user-mode API.
  • Github: WFP Explorer -> GUI tool to view Windows Filtering Platform objects (WIP).
PoCs
  • Github: ProxyIntercept -> The sample driver consists of a kernel-mode Windows Filtering Platform (WFP) callout driver (Proxy-Intercept.sys) that intercepts all transport layer traffic (for example, Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and nonerror Internet Control Message Protocol (ICMP)) sent to or received from a configurable remote peer and queues then to a worker thread for out-of-band processing.
  • Github: WFP Traffic Redirection Driver -> WFP Traffic Redirection Driver is used to redirect NIC traffic on network layer and framing layer, based on Windows Filtering Platform (WFP).
  • Github: WFP-Example -> WFP is Windows Filtering Platform. This repository has wfp sample codes.
  • Github: TransportAnalyzer -> Simple Windows Filtering Platform kernel-mode driver designed to analyze incoming and outgoing TCP packets.
  • Github: NetFilterDriver -> It is a sample of Windows kernel driver that based WFP (Windows Filtering Platform) for filtering/interacting with packet processing
  • Github: WFPCalloutExplorer -> It is a specialized tool meticulously designed to identify currently loaded Windows Filtering Platform (WFP) callout filter drivers. It achieves this objective by scrutinizing whether these drivers import the vital FWPKCLNT!FwpsCalloutRegister function.

WinSock Kernel (WSK)

Basics
  • Web Microsoft: Introduction to Winsock Kernel -> Winsock Kernel (WSK) is a kernel-mode Network Programming Interface (NPI). With WSK, kernel-mode software modules can perform network I/O operations using the same socket programming concepts that are supported by user-mode Winsock2. The WSK NPI supports familiar socket operations such as socket creation, binding, connection establishment, and data transfers (send and receive). However, while WSK NPI supports most of the same socket programming concepts as user-mode Winsock2, WSK NPI is a completely new and different interface with unique characteristics such as asynchronous I/O that uses IRPs and event callbacks to enhance performance.
PoCs
  • Github: libwsk -> It is a wrapper for the WSK (Winsock-Kernel) interface. With libwsk, kernel-mode software modules can perform network I/O operations using the same socket programming concepts and interface that are supported by user-mode Winsock2.
  • Github: KSOCKET -> It provides a very basic example on how to make a network connections in the Windows Driver by using WSK.

Minifilter

Basics
  • Web Microsoft: Filter Manager Concepts -> The Filter Manager (FltMgr.sys) is a system-supplied kernel-mode driver that implements and exposes functionality commonly required in file system filter drivers. File system filter developers can use FltMgr's functionality to write minifilter drivers that are simpler to develop than legacy file system filter drivers. The end result is a shortened development process and higher-quality, more robust drivers.
  • Web Apriorit: How to Develop a Windows File System Minifilter Driver, Complete Tutorial -> Minifilter drivers are must-have components of Windows development projects that are necessary to control or change system behavior. Compared to legacy file system filter drivers, minifilters require less code, improve communication within the system, and lower security and misconfiguration risks.
  • Blog: Understanding Mini-Filter Drivers for Windows Vulnerability Research & Exploit Development -> Basically, Mini-Filter Drivers are one of the components of modern Windows file system architecture. They provide a way for developers to monitor and modify file system operations without needing to interact directly with lower-level file system drivers. Mini-filters operate within the file system filter driver framework, allowing them to intercept and process I/O operations in a structured manner.
PoCs
  • Github: MCP-PoC -> Minifilter Callback Patching Proof-of-Concept.
  • Github: IRPLogger -> IRPLogger (IRP stands for I/O Request Packet) is a tool to monitor and log any I/O activity that occurs in the system. IRPLogger is implemented as a File System Minifilter Drivers. IRPLogger is based on the MiniSpy minifilter sample.
  • Github: Minivers File System Minifilter Driver -> Windows file system minifilter driver which generates backup copies of certain files before they change.

Forge Signature Timestamps

Basics

Interrupt Descriptor Table (IDT) Hooking

Basics
  • Web RedTeamNotes: Interrupt Descriptor Table (IDT) -> Interrupts could be thought of as notifications to the CPU that tells it that some event happened on the system. Classic examples of interrupts are hardware interrupts such as mouse button or keyboard key presses, network packet activity and hardware generated exceptions such as a division by zero or a breakpoint - interrupts 0x00 and 0x03 respectively.
  • Web MIT: Interrupt Descriptor Table -> The interrupt descriptor table (IDT) associates each interrupt or exception identifier with a descriptor for the instructions that service the associated event. Like the GDT and LDTs, the IDT is an array of 8-byte descriptors. Unlike the GDT and LDTs, the first entry of the IDT may contain a descriptor.
  • Youtube Video OpenSecurityTraining: Interrupt Descriptor Table
PoCs

System Service Descriptor Table (SSDT) Hooking

Basics
  • Web RedTeamNotes: System Service Descriptor Table (SSDT) -> System Service Dispatch Table or SSDT, simply is an array of addresses to kernel routines for 32 bit operating systems or an array of relative offsets to the same routines for 64 bit operating systems. SSDT is the first member of the Service Descriptor Table kernel memory structure.
  • Web Infosec: Hooking the System Service Dispatch Table (SSDT) -> In this article we'll present how we can hook the System Service Dispatch Table, but first we have to establish what the SSDT actually is and how it is used by the operating system.
  • Web AppsVoid: SSDT View -> SSDT View is a Windows OS utility designed to list the most significant aspects of the System Service Descriptor Table (SSDT) including system service indexes, system service addresses, system service names and the module name which corresponds to the system service address.
PoCs
  • Github: MasterHide -> A x64 Windows Driver created to monitor/hide or block access from processes, objects, files (whatever you want, your imagination is the limit here) using SSDT/Shadow SSDT hooks.
  • Github: TitanHide -> A driver intended to hide debuggers from certain processes. The driver hooks various Nt* kernel functions (using SSDT table hooks) and modifies the return values of the original functions.
  • Github: STrace -> A DTrace on windows syscall hook reimplementation. Think of this like a patchguard compatible SSDT hook, but without hacks.

Tools

Rootkit scanners.

  • Web Gmer: Rootkit Detector and Remover -> It is an application that detects and removes rootkits.
  • Web Microsoft: RootkitRevealer v1.71 -> RootkitRevealer is an advanced rootkit detection utility. It runs on Windows XP (32-bit) and Windows Server 2003 (32-bit), and its output lists Registry and file system API discrepancies that may indicate the presence of a user-mode or kernel-mode rootkit. RootkitRevealer successfully detects many persistent rootkits including AFX, Vanquish and HackerDefender (note: RootkitRevealer is not intended to detect rootkits like Fu that don't attempt to hide their files or registry keys). If you use it to identify the presence of a rootkit please let us know!

Environment

Build a testing environment.

Bootkits (Development)

Build an environment to develop Bootkits (UEFI/DXE Applications and Drivers).

Windows Kernel (Debugging)

Build an environment to debug the Windows kernel.

  • Web Microsoft: Install the Windows debugger -> WinDbg is a debugger that can be used to analyze crash dumps, debug live user-mode and kernel-mode code, and examine CPU registers and memory.
  • Web Microsoft: BCDEdit /debug -> The /debug boot option enables or disables kernel debugging of the Windows operating system associated with the specified boot entry or the current boot entry.

Rootkits (Development)

Build an environment to develop Rootkits (Kernel Mode Drivers).

  • Web Microsoft: Visual Studio 2022 Community -> Free, fully-featured IDE for students, open-source and individual developers.
  • Web Microsoft: Windows SDK -> The Windows SDK (10.0.26100) for Windows 11 provides the latest headers, libraries, metadata, and tools for building Windows applications. Use this SDK to build Universal Windows Platform (UWP) and Win32 applications for Windows 11, version 24H2 preview and previous Windows releases.
  • Web Microsoft: Download the Windows Driver Kit (WDK) -> The WDK is used to develop, test, and deploy drivers for Windows.
  • Web Microsoft: Other WDK downloads -> The Windows Driver Kit (WDK) is used to develop, test, and deploy Windows Drivers. This topic contains information about versions of the Windows Driver Kit (WDK), Enterprise WDK (EWDK), and additional downloads for support purposes. To develop drivers, use the latest public versions of the Windows Driver Kit (WDK) and tools, available for download on Download the Windows Driver Kit (WDK).

Cybersecurity Resources

Additional cybersecurity resources that will assist you in developing bootkits/rootkits.

Books

Key readings to excel in this field.

Courses

Courses related to this subject.

  • Course Zero2Auto: Malware Analysis (≈$150) -> Developed for those looking to further enhance their skills in the Malware Analysis/Reverse Engineering field.
  • Web Zero Day Engineering: Zero Day Vulnerability Research Training (≈$1600) -> This 4-day intensive training will expose you to full stack essentials of vulnerability research and exploit development, starting from (almost) zero pre-requisites. The training system consolidates all the foundational knowledge and basic skills that you will need to build upon later as you advance and specialize in the field. Created and taught live by a top vulnerability researcher and binary hacker.
  • Web TrainSec: Windows Internals and Programming (≈$50-$900)
  • Course ZeroPointSecurity: Offensive Driver Development (≈$55) -> Learn how to set up a development testing environment for writing Windows kernel-mode drivers using Hyper-V, WinDbg, and Visual Studio. Cover the basic anatomy of a driver from loading and unloading, I/O control codes, interaction from userland, and kernel debugging.
  • Web Maldev Academy (≈$500) -> Maldev Academy is a comprehensive malware development course that focuses on x64 malware development, providing knowledge from basic to advanced level. The course is primarily designed for individuals in offensive security, but it also caters to beginners who have no prior experience in malware development.

Master's Degree

If you wish to acquire this knowledge, along with other topics related to malware analysis, reversing, and bug hunting, under the guidance of top-notch professionals, do not hesitate to get in touch with the institution where I am an instructor, offering a Master's degree (Máster en Reversing, Análisis de Malware y Bug Hunting) in this field.

Contact

This project represents a dedicated exploration into the intricate realm of bootkits and rootkits, with a specific focus on providing a comprehensive resource for both my students and individuals embarking on their journey in this complex field.

This work is designed to offer valuable insights and resources to support your educational and developmental goals, making it suitable for anyone seeking to delve into bootkit/rootkit development. If you have specific inquiries, require additional clarification, or wish to engage in collaborative efforts, feel free to connect with me on LinkedIn – Alejandro Vazquez Vazquez.

About

A curated compilation of extensive resources dedicated to bootkit and rootkit development.

Topics

kernel rootkit reverse-engineering uefi kernel-driver malware-research uefi-bootkit bootkit malware-development low-level-programming dxe-driver uefi-application kernel-programming kernel-rootkit

Resources

Readme

License

GPL-3.0 license
Activity

Stars

156 stars

Watchers

5 watching

Forks

17 forks
Report repository

Languages