April 23, 2026
AuthorAdrián DíazRead time14 minPublishedApr 23, 2026TopicsWindows InternalsEDR Evasion Table of Contents The previous post covered call stack spoofing: how an implant makes its call stack
Loading kernel drivers is a “Holy Grail” operation for attackers. It grants Ring 0 privileges, allowing for persistence, EDR blinding (“Killer Drivers”), or Bring Your Own Vulnerable Driver (BYOVD) attacks.
While the end result is the same (code running in the kernel), the forensic trails differ significantly depending on the tool used:
sc.exe: The direct, noisy approach via Service Control Manager.
devcon.exe: The stealthier approach leveraging the Windows Plug and Play (PnP) subsystem.The Service Control utility allows users to register a driver explicitly as a service. This is the “classic” method, often monitored by standard security baselines.
The attacker executes a command to register the driver. The key indicator is the type= kernel flag pointing to a user-writable location.
sc create DBUtilDrv2 binPath= C:\users\public\DBUtilDrv2.sys type= kernel
sc start DBUtilDrv2
Process Creation (Event ID 1): Look for sc.exe spawned by cmd.exe or powershell.exe containing binPath= (non-system directory) and type= kernel.
Registry (Event ID 12/13): sc.exe writes directly to the Services hive.
Key: HKLM\System\CurrentControlSet\Services\<DriverName>
Values: Type = 0x1 (Kernel Driver), ImagePath = Path to malicious driver.
Security Log: Event 4697 (A Service Was Installed) is the highest fidelity indicator here.
Red Team Note: This method is “loud.” Modifications to
HKLM\...\Servicesare heavily scrutinized. We use this only when we know logging is weak or we need speed over stealth.
devcon.exe (Device Console) is part of the Windows Driver Kit. Attackers use it to bypass standard service monitoring by abusing the SetupAPI and Plug and Play stacks. This leaves a much more complex, scattered footprint.
Instead of talking to the Service Controller directly, devcon requests the installation of an INF file for a “Root” (virtual) device.
devcon.exe install C:\Temp\DBUtilDrv2.inf Root\DBUtilDrv2
1. Process Anomalies The parent process is often powershell.exe triggering devcon.exe. However, the actual work is handed off to DrvInst.exe (Driver Install) and svchost.exe -k DcomLaunch (DeviceInstall service).
2. The Phantom Device (Registry) Unlike sc.exe, devcon does not initially write to the Services hive. It creates a “Phantom” device node.
Key: HKLM\System\CurrentControlSet\Enum\ROOT\<DeviceID>
Indicator: Look for new keys in Enum\ROOT that map to unknown hardware IDs.
3. Driver Staging (Registry) Before installation, the driver is staged in the Driver Store.
Key: HKLM\DRIVERS\DriverDatabase\DriverPackages
Value OemPath: This is a smoking gun. It reveals the original source of the INF file (e.g., C:\Users\Target\Documents\). Legitimate drivers usually originate from System paths.
4. File System & “Timestomping” devcon creates GUID-named folders in %TEMP% and %SystemRoot%\System32\DriverStore\Temp.
Anomaly: SetupAPI often preserves the vendor’s timestamp from the driver package. You might see a “new” temp file created with a timestamp from 2 years ago (setup behavior that mimics timestomping).
| Feature | sc.exe (Service Control) | devcon.exe (Plug & Play) |
| Mechanism | Direct Service Creation | SetupAPI / Driver Store Staging |
| Key Process | sc.exe |
devcon.exe -> DrvInst.exe |
| Primary Registry | HKLM\...\Services |
HKLM\...\Enum\ROOT & DriverDatabase |
| File Artifacts | Driver file stays in place | Staged to %SystemRoot%\DriverStore |
| Stealth Level | Low (Well known) | High (Complex artifact trail) |
Successfully loading a driver usually leads to one of two outcomes:
BYOVD (Bring Your Own Vulnerable Driver): The attacker loads a legitimate, signed driver (like DBUtilDrv2) that has known vulnerabilities. They then exploit this driver to elevate privileges. Signature verification is useless here because the driver is valid.
Killer Drivers: The attacker loads a custom malicious driver specifically designed to terminate EDR processes (e.g., killing MsMpEng.exe via kernel API ZwTerminateProcess).
Watching sc.exe or devcon.exe command lines is the weak way to catch this: the arguments can be obfuscated, and a driver can be registered straight through the registry or the native API with no command line at all. The reinforced rule ignores how the driver was registered and keys on the load itself (Sysmon Event ID 6), firing when a driver loads unsigned or from a user-writable path. That event is the invariant both routes in this post ultimately produce.
title: Suspicious Kernel Driver Load (Unsigned, Untrusted, or User-Profile Path)
id: 8c863b14-1284-400c-874a-8b66e664109b
status: experimental
description: Detects a kernel driver load that is unsigned, carries an untrusted signature status, or comes from a user-profile directory. This is the load itself (Sysmon Event ID 6), the invariant that fires no matter which method registered the driver, so it does not depend on watching sc.exe or devcon.exe command lines. Signature badness triggers on its own; the path branch is scoped to \Users\ and \AppData\ only, because legitimate signed drivers (Defender, anti-cheat, EDR, installer-staged drivers) do load from \ProgramData\ and C:\Windows\Temp and must not alert here.
references:
- https://valhguard.com/2025/10/20/detecting-driver-loading-sc-vs-devcon/
author: Adrian Diaz, Valhguard
date: 2025-10-20
tags:
- attack.privilege-escalation
- attack.t1543.003
- attack.t1068
logsource:
category: driver_load
product: windows
detection:
selection_unsigned:
Signed: 'false'
selection_untrusted:
SignatureStatus:
- 'Unavailable'
- 'Expired'
- 'Revoked'
selection_userprofile:
ImageLoaded|contains:
- '\Users\'
- '\AppData\'
condition: selection_unsigned or selection_untrusted or selection_userprofile
falsepositives:
- Portable or test-signed drivers deliberately loaded from a user profile directory in development environments
- A validly signed but genuinely vulnerable driver (classic BYOVD) loads as trusted and will not match here; cover that with a known-vulnerable-driver blocklist (for example loldrivers) rather than this rule
level: high
It validates clean and compiles to Splunk, Sentinel (KQL), Elastic and CrowdStrike. A signed but vulnerable driver (BYOVD) will pass the signature checks, so pair this with a vulnerable-driver blocklist (the Microsoft recommended block list or loldrivers.io) for that case.
// Step 1: Find sc/devcon
let DriverTools = DeviceProcessEvents
| where Timestamp > ago(1d)
| where (FileName =~ "sc.exe" and ProcessCommandLine has_any ("type=kernel", "type= kernel"))
or (FileName =~ "devcon.exe" and ProcessCommandLine has "install")
| project TimeProc=Timestamp, DeviceName, ToolName=FileName, CommandLine=ProcessCommandLine;
// Step 2: Find Kernel Driver Load
let DriverLoads = DeviceEvents
| where Timestamp > ago(1d)
| where ActionType == "DriverLoad"
| project TimeLoad=Timestamp, DeviceName, DriverName=FileName, DriverPath=FolderPath, DriverHash=SHA1;
DriverTools
| join kind=inner (DriverLoads) on DeviceName
// Alert if the driver loaded within 5 minutes of the tool running
| where (TimeLoad - TimeProc) between (0min .. 5min)
| project TimeProc, TimeLoad, DeviceName, ToolName, CommandLine, DriverName, DriverPath, DriverHash
AuthorAdrián DíazRead time14 minPublishedApr 23, 2026TopicsWindows InternalsEDR Evasion Table of Contents The previous post covered call stack spoofing: how an implant makes its call stack
How three generations of call stack spoofers defeat the x64 unwinder, and where the detection still holds.
Both techniques make a process lie about itself, and both are on nearly every engagement. But they fail differently under scrutiny: one leaves a clean mechanical tell the spoof cannot erase, the other leaves nothing to compare against. Where the truth actually lives.
Patch ETW and the CLR goes dark, load from a byte array and you dodge AMSI, Sysmon catches the DLL load anyway. Two of those are wrong on modern .NET and the third is structurally impossible. Where the telemetry for in-memory .NET really is, and which signals survive an operator inside the process.
ETW is the eyes of your EDR. What happens when an attacker covers them? We dissect the specific Red Team techniques used to blind Windows Event Tracing, including session hijacking and EtwEventWrite patching, and show Blue Teams how to spot the silence.
Virtualization is not just infrastructure; it is a weapon. Red Teams leverage portable QEMU instances to bypass host-based EDRs and evade behavioral analysis. We analyze how attackers deploy these “invisible machines” without administrative privileges and provide the KQL hunting queries defenders need to detect unauthorized virtualization on their networks.