🏴‍☠️ Abyss: Windows UEFI Bootkit

<p align="center"> <img src="Images/Logos/Abyss_Squid_DEF_CON.png"> </p> <p align="center"> <i> Built not in a corporate lab, but by a guy in his twenties hacking from his mom's couch in a town forgotten by God. If I can tamper with the boot process of modern operating systems and write one of the most technically demanding malwares out there - what's your excuse for not building one too? You're part of a red team? Offensive security engineer? Or maybe you're just a curious threat emulation nerd looking to prove yourself? Then you already know this field isn't about theory, it's about action. Your team needs access. They need stealth. They need persistence. Dive into the abyss and build your own bootkit. </i> </p>

---

---

---

📑 Table of Contents

<ul> <li><a href="#whatisabootkit">What is a Bootkit?</a></li> <li><a href="#buildyourfirstbootkit">Build Your First Bootkit</a></li> <li><a href="#abyssbootkit">Abyss Windows UEFI Bootkit</a></li> <details> <summary>📂</summary> <ul> <li><a href="#abyssbootkit-architecture">Architecture</a></li> </ul> </details> <li><a href="#cybersecurityconferences">Cybersecurity Conferences</a></li> <li><a href="#resources">Awesome Resources</a></li> <li><a href="#contact">Contact</a></li> </ul>

---

---

---

<div id='whatisabootkit'/>

🐙 What is a Bootkit?

When you're not sure how something works, you ask those who know. And when no one knows - you reverse it, debug it, break it down, and share what you've learned so the next person doesn't have to start from zero.

• CrowdStrike

  "Bootkits are a type of modern malware used by a threat actor to attach malicious software to a computer system. Bootkits can be a critical security threat to your business and often involve rootkit tools for evading detection. These attacks target the Unified Extensible Firmware Interface (UEFI), software that connects a PC's operating system with its device firmware".

• Mitre Att&ck

  "Adversaries may use bootkits to persist on systems. A bootkit is a malware variant that modifies the boot sectors of a hard drive, allowing malicious code to execute before a computer's operating system has loaded. In UEFI (Unified Extensible Firmware Interface) systems, a bootkit may instead create or modify files in the EFI system partition (ESP). The ESP is a partition on data storage used by devices containing UEFI that allows the system to boot the OS and other utilities used by the system. An adversary can use the newly created or patched files in the ESP to run malicious kernel code."

• Demistification

  At its core, a bootkit is simply a rootkit that executes before the operating system loads. Instead of relying on post-boot vulnerabilities or privilege escalation, a bootkit operates at the firmware level, gaining control before the kernel initializes.

  What does that mean practically?

  • In Windows, a rootkit typically takes the form of a kernel-mode driver (KMDF), a .sys file injected or loaded into the OS kernel to gain stealthy control over system behavior.
  • In Linux, rootkit functionality is commonly implemented via a Loadable Kernel Module (LKM), a .ko file injected into the kernel.

  A bootkit, in contrast, is usually a UEFI application, UEFI driver or DXE Runtime driver that loads before the operating system. Its purpose is to establish persistence, bypass early protections, and prepare or inject the platform-specific rootkit into the kernel before it has even initialized.

  So, if you're researching how to build a rootkit (a malware that hides processes, files, network connections, prevents analysis, manipulates hardware, and more), you're already halfway to building a bootkit. A bootkit is just a rootkit with pre-OS delivery mechanics, exploiting UEFI as a launchpad.

---

---

---

<div id='buildyourfirstbootkit'/>

🧪 Build Your First Bootkit

Before diving into the core internals of Abyss, you may want to get your hands dirty building your first proof-of-concept bootkit. This project includes several minimal working examples inside the "Bootkits/" directory, each tailored to help you understand how UEFI Applications and DXE Runtime Drivers interact with system firmware during the early boot process. These samples serve as a practical foundation for writing, compiling, and testing your own malicious (or research) UEFI payloads.

If this is your first time working with UEFI, it's strongly recommended to begin by following the manual setup instructions provided in "Bootkits/". This will help you understand how the environment is built, how EDK2 works, and how UEFI binaries are compiled and tested from scratch. You'll also get to run hands-on proof-of-concepts that demonstrate the mechanics of early-boot persistence and memory tampering.

Once you're comfortable building and testing these samples, and you've gained confidence booting your own unsigned UEFI code, you can leverage the automation scripts in the "Development Environment/" folder to streamline your workflow across multiple systems or quickly rebuild your dev setup.

And once you've reached that point, when booting unsigned code feels like second nature, come back here. That was just the warm-up. The real challenge begins with the full-featured bootkit included in this project: Abyss. Dive deeper, trace the hooks, map the memory patches, and see how far down the firmware rabbit hole goes.

---

---

---

<div id='abyssbootkit'/>

🧭 Abyss Windows UEFI Bootkit

<p align="center"> <img src="Images/Logos/Abyss_Bootkit.png"> </p>

Abyss (Abismo) is not just a bootkit - and it's definitely not just a repository for proof-of-concepts. It is a comprehensive offensive research project developed to centralize the study, development, and simulation of advanced bootkit techniques across both Windows and Linux platforms, with a strong emphasis on UEFI specification exploration, low-level OS tampering, and firmware-to-kernel attack chains.

This project is designed to support offensive security teams, threat researchers, and adversary simulation professionals, enabling realistic emulation of APT-grade bootkits and rootkits within controlled environments. Abyss reimplements and extends concepts inspired by real-world and academic malware such as BlackLotus, ESPecter, and Bootkitty, serving as a robust foundation for further analysis and experimentation.

Rather than focusing on one platform or single technique, Abyss is built to be a modular, extensible base for:

• Studying UEFI internals and boot service abuse.
• Developing bootkits with modular payloads and persistence strategies.
• Investigating practical firmware-to-OS attacks involving runtime drivers and functions hooks/patches.
• Experimenting with pre-boot network communication, in-memory and disk-based injection, and dynamic payload loading.

All components have been thoroughly tested on virtualized environments (VMware, QEMU) as well as on dedicated physical hardware prepared for UEFI experimentation. That said, Abyss is not a plug-and-play bootkit - it assumes you have (or want to build) the skills to adapt and extend it. Function hooking and patching mechanisms are tightly coupled to firmware/OS versions and must often be tuned manually. This may involve reverse engineering, disassembly, firmware debugging, and deep reading of the UEFI specification - thousands of pages of it.

If you're here expecting a one-click bootkit, you're in the wrong place. But if you're here to build, break, and learn, Abyss will take you far.

Abyss exists to equip red teams and security researchers with the tools and knowledge to understand how modern APTs can deploy malicious UEFI firmware implants. It is for those actively working in low-level offensive research, malware design, and boot/firmware threat emulation.

---

---

---

<div id='abyssbootkit-architecture'/>

🧩 Architecture

Abyss follows a modular architecture designed to enable complex firmware-to-kernel attack chains, built on top of UEFI Boot Services and Runtime Services abuse through advanced hooking techniques and in-memory patching.

To better understand the functionalities that Abyss implements, it's useful to first look at the internal structure that orchestrates its execution.

The codebase is organized into modules that follow the actual execution order of the boot process, from the very first initialization steps in UEFI firmware to runtime interaction with the operating system. While these modules don't correspond one-to-one with the conceptual phases described below, they're laid out in execution order, so by following them sequentially, you'll naturally uncover the internal phases that Abyss transitions through.

The following list outlines those underlying execution phases, not as strict folder names, but as the logical flow that Abyss follows under the hood:

• 🔧 Initialization Phase
  Parses the bootkit configuration, allocates required memory regions, initializes internal flags, and loads auxiliary drivers. This phase lays the foundation for all subsequent behavior.

• 📡 Pre-Boot Operations Phase
  Uses UEFI Boot Services to perform privileged actions before the OS is loaded, including UEFI and DXE driver injection, network communication, staging of payloads either in memory or to disk, and direct reading or modification of files within accessible partitions.

• 🪝 Boot Transition Interception Phase
  Hooks UEFI services to hijack execution flow just before the original Windows Boot Manager takes control.

• 🧬 Windows Boot Manager Hooking Phase
  Gains control over the transition from firmware to the OS loader by hooking i