Kernel Signed Driver Validation Research
CLAUDE AI Assisted / Guided Research - Claude created this README for example.
The aim, take a problem, question for research, and use Claude to augment, enrich, enhance.
Research Aim - Understand and Extend and exploit custom signed kernel drivers.
Check claims for accuracy, test, validate, challenge, learn.
The driver signature validation is performed entirely in kernel mode through the CI.dll (Code Integrity) module. Here's the breakdown:
-
CI.dll - CI.dll is a kernel-mode library that allows drivers to validate Authenticode signatures in kernel mode. When the Windows kernel verifies drivers as they are loaded, this must be done in kernel mode.
-
CiValidateImageHeader() - This function is used by ntoskernel.exe when a driver is being loaded to verify its signature. It maps the file in kernel space and extracts its signature, and also calculates the file digest.
-
g_CiOptions - DSE (Driver Signature Enforcement) is implemented using the kernel mode library CI.dll. The CI.dll module defines the variable g_CiOptions, which controls whether Windows enforces driver signature verification.
When Hypervisor-protected Code Integrity is active, there's an additional layer:
Upon loading a new driver, the secure kernel is also triggered and uses its own instance of the code integrity library, SKCI.dll (Secure Kernel Code Integrity). The digital signature is validated and checked to be authorized within the current policy in the Secure World (VTL1). Only then are executable and non-writable permissions applied.
Custom Kernel Signers (CKS) allows users to decide what certificates are trusted or denied in kernel. It requires the CodeIntegrity-AllowConfigurablePolicy-CustomKernelSigners policy to be enabled.
The SIPolicy.bin file (which defines trusted signers) is loaded during the early boot process and enforced by CI.dll in kernel mode. The validation never touches user mode—CI.DLL is not callable outside the kernel, ensuring that signature checks cannot be bypassed from user-mode code.
Approach
I'll search for information about the kernel structures that handle driver signature verification and custom kernel signers.Based on the research, here's what I found about kernel structures that hold approved kernel driver signers:
The Code Integrity module (CI.dll) contains several critical global variables that control driver signature enforcement:
CI!g_CiOptions- A configuration variable with flags that control Driver Signature Enforcement (DSE), typically set to 0 to completely disable DSEnt!SeCiCallbacks(ornt!g_CiCallbacks) - A callback structure filled by CiInitialize() containing function pointers like CiValidateImageHeader() and CiValidateImageData()
During signature validation, CI.dll uses specific structures to hold certificate information:
PolicyInfo Structure:
typedef struct _PolicyInfo {
int structSize;
NTSTATUS verificationStatus;
int flags;
PVOID certChainInfo; // Pointer to certificate chain data
FILETIME revocationTime;
FILETIME notBeforeTime;
FILETIME notAfterTime;
} PolicyInfo;The certChainInfo buffer contains data about the entire certificate chain in both parsed format (organized sub-structures) and raw format (ASN.1 certificate blobs, keys, EKUs), making it easy to check the subject, issuer, certificate chain, and hash algorithms.
Yes, custom kernel signers are supported through Windows Defender Application Control (WDAC) policies:
WDAC policies containing custom signer information are stored at:
-
Single policy format:
C:\Windows\System32\CodeIntegrity\SiPolicy.p7b<EFI System Partition>\Microsoft\Boot\SiPolicy.p7b
-
Multiple policy format (Windows 10 1903+):
C:\Windows\System32\CodeIntegrity\CiPolicies\Active\{PolicyGUID}.cip<EFI System Partition>\Microsoft\Boot\CiPolicies\Active\{PolicyGUID}.cip
-
Microsoft recommended driver blocks:
driversipolicy.p7bin the%windir%\system32\CodeIntegritydirectory, which contains blocks enforced by HVCI, Smart App Control, or S mode
When the operating system boots, either WINLOAD or the kernel CI driver loads the policy from disk into memory and begins enforcement based on the configured rules. The policy files contain:
- Signer definitions with certificate TBS (To-Be-Signed) hashes
- Extended Key Usage (EKU) requirements
- Rule options (like requiring EV certificates for kernel drivers)
- UpdatePolicySigners - certificates authorized to update the policy
Functions like CiCheckSignedFile() and CiValidateFileObject() are exported by CI.dll to validate signatures, and the ntoskrnl.exe uses CiValidateImageHeader() when loading drivers. These functions:
- Extract certificates from the PE signature
- Validate against the loaded WDAC policy rules
- Check certificate chains and EKUs
- Return validation results in the PolicyInfo structure
The actual certificate data from loaded policies resides in CI.dll's memory space, managed by internal functions like MinCryptVerifyCertificateWithPolicy2().
Note: Custom kernel signers use a specific OID (1.3.6.1.4.1.311.79.1) when signing policy files to indicate the content is specifically a WDAC policy.
-
Code Integrity in the Kernel: A Look Into ci.dll (Cybereason)
-
CI.dll FIPS 140 Security Policy Documents (NIST/Microsoft)
-
Driver Signature Enforcement (BorderGate)
-
The Swan Song for Driver Signature Enforcement Tampering (Fortinet)
-
A Quick Insight into the Driver Signature Enforcement (j00ru)
-
Back Doors for Cross-Signed Drivers (Geoff Chappell)
-
Windows10-CustomKernelSigners (HyperSine)
-
SSDE - Secure Boot Self-Signed Driver Enrollment (valinet)
-
Kernel-Mode Code Signing Requirements
-
Windows Driver Signing Tutorial
-
WDAC Notes (SpyNetGirl)
-
Windows Device Guard Code Integrity Policy Reference
A kernel-mode driver for Windows that enumerates and displays information about currently active Windows Defender Application Control (WDAC) policies and their approved signers.
This driver helps security researchers and system administrators verify which kernel-mode code signing certificates are currently trusted on a Windows system. It's useful for:
- Auditing security configurations
- Verifying WDAC policy deployment
- Testing and debugging custom WDAC policies
- Ensuring no unexpected signers are trusted
The driver:
- Enumerates WDAC policy files from standard locations
- Reads policy files (SiPolicy.p7b, driversipolicy.p7b)
- Attempts to extract certificate information from policies
- Outputs findings to the kernel debugger (DebugView or WinDbg)
- Windows 10/11 SDK
- Windows Driver Kit (WDK) for Windows 10/11
- Visual Studio 2019 or later with C++ development tools
- Administrator privileges
- Windows 10 version 1607 or later / Windows 11
- Test Mode enabled OR properly signed driver
- Administrator privileges
- Open Visual Studio
- Create a new "Empty WDM Driver" project
- Add
PolicyEnumerator.cto the project - Build the solution (x64 Debug or Release)
REM Open "x64 Native Tools Command Prompt for VS"
cd /d <project_directory>
msbuild PolicyEnumerator.vcxproj /p:Configuration=Release /p:Platform=x64REM Open WDK Build Environment
cd /d <project_directory>
buildSince this driver is not Microsoft-signed, you must enable test mode:
REM Run as Administrator
bcdedit /set testsigning on
shutdown /r /t 0REM Create a self-signed certificate
makecert -r -pe -ss PrivateCertStore -n "CN=Test Driver Signing" TestDriverSign.cer
REM Sign the driver
signtool sign /s PrivateCertStore /n "Test Driver Signing" /t http://timestamp.digicert.com PolicyEnumerator.sysREM Install to Trusted Root
certmgr /add TestDriverSign.cer /s /r localMachine root
REM Install to Trusted Publishers
certmgr /add TestDriverSign.cer /s /r localMachine trustedpublisherREM Run as Administrator
REM Copy driver to system directory
copy PolicyEnumerator.sys C:\Windows\System32\drivers\
REM Create the service
sc create PolicyEnumerator type= kernel binPath= C:\Windows\System32\drivers\PolicyEnumerator.sys
REM Start the driver
sc start PolicyEnumerator
REM View output in DebugView or WinDbg
REM Stop the driver
sc stop PolicyEnumerator
REM Delete the service
sc delete PolicyEnumerator- Download OSR Driver Loader from https://www.osronline.com/article.cfm%5Earticle=157.htm
- Register the driver
- Start the driver
- View output in DebugView
devcon install PolicyEnumerator.inf Root\PolicyEnumerator
devcon enable Root\PolicyEnumeratorThe driver outputs information to the kernel debug log. To view:
- Download DebugView from https://learn.microsoft.com/sysinternals/downloads/debugview
- Run as Administrator
- Enable "Capture Kernel" (Ctrl+K)
- Enable "Enable Verbose Kernel Output"
- Start the driver
- View the output in DebugView
REM Attach kernel debugger
windbg -kl
REM View debug output
!dbgprintThe driver will output information similar to:
[PolicyEnum] ========================================
[PolicyEnum] Enumerating WDAC Policy Files
[PolicyEnum] ========================================
[PolicyEnum] Checking: \SystemRoot\System32\CodeIntegrity\SiPolicy.p7b
[PolicyEnum] SUCCESS - File size: 12345 bytes
[PolicyEnum] Parsing policy buffer (Size: 12345 bytes)
[PolicyEnum] Found potential certificate at offset 0x200 (Size: 1024 bytes)
[PolicyEnum] OID at +0x10: 55 04 03 ...
[PolicyEnum] Name at +0x50: Microsoft Windows Production CA
...
[PolicyEnum] Total potential certificates found: 3
[PolicyEnum] Checking: \SystemRoot\System32\CodeIntegrity\driversipolicy.p7b
...
For complete policy analysis, use PowerShell tools after identifying policy files:
# List all active policies (Windows 11 2022+)
CiTool.exe -lp
# Export policy to XML for analysis
# Note: Binary to XML conversion requires reverse engineering or tools-
Binary Format: WDAC policy files use an undocumented binary format. This driver provides basic parsing but may not extract all signer information.
-
Encrypted Policies: Some policies may be encrypted or signed, making direct parsing difficult.
-
Multiple Policies: Modern systems (Windows 10 1903+) support up to 32 active policies in
CiPolicies\Active\. This driver shows legacy locations only. -
Certificate Extraction: The parser looks for ASN.1 certificate patterns but full X.509 parsing is complex.
- Test Environment Only: This driver is for testing and research purposes.
- No Production Use: Do not deploy on production systems without thorough testing.
- Test Signing: Test-signed drivers reduce security; disable test mode after testing.
- Run this driver to identify policy files
- Copy policy files for offline analysis
- Use Microsoft's ConfigCI PowerShell module for full parsing:
# If you have XML source Get-CIPolicy -FilePath .\policy.xml
- Verify test mode is enabled:
bcdedit /enum - Check driver is signed:
signtool verify /pa PolicyEnumerator.sys - Review Event Viewer > Windows Logs > System for errors
- Ensure "Capture Kernel" is enabled
- Check driver is running:
sc query PolicyEnumerator - Verify DebugView is running as Administrator
- Ensure running as Administrator
- Check file permissions on policy files
- Some policies may be protected by HVCI/VBS
REM Stop and remove driver
sc stop PolicyEnumerator
sc delete PolicyEnumerator
REM Remove driver file
del C:\Windows\System32\drivers\PolicyEnumerator.sys
REM Disable test mode (optional)
bcdedit /set testsigning off
shutdown /r /t 0For production environments, consider these alternatives:
-
CiTool.exe (Windows 11 2022+)
CiTool.exe -lp
-
PowerShell ConfigCI Module
Get-Command -Module ConfigCI
-
WDAC Wizard
- GUI tool for policy management
- Available on GitHub
This code is provided for educational and testing purposes. Use at your own risk.
This driver directly interacts with security-critical system components. Improper use could affect system stability or security. Always test in isolated environments first.
Inpsired by - Learn to pick up and think like an adversary and use their tools.
