Kernel Drivers (.sys, Driver Services, BYOVD)

What it is

Kernel drivers are the Windows counterpart of Linux kernel modules: .sys PE files loaded into ring 0 by the Service Control Manager, the Plug and Play manager or a direct NtLoadDriver call. Legitimate hardware and security products need them; attackers use them for rootkits and, far more often today, for Bring Your Own Vulnerable Driver (BYOVD): they drop a signed but exploitable driver (for example RTCore64.sys, gdrv.sys, dbutil_2_3.sys, procexp152.sys) and use it to kill EDR processes or tamper with kernel memory. Every driver needs a service entry, a file on disk and a successful signature check, and each of those steps leaves traces.

Location

What it proves

• Registration: a Services key with Type 1 or 2 shows a driver was configured to load, with its ImagePath and Start mode (0 boot, 1 system, 2 automatic, 3 demand, 4 disabled).
• Install time and account: event 7045 gives the service name, file path, "kernel mode driver" type and start type; 4697 adds the subject account.
• File identity: Amcache InventoryDriverBinary records the driver's SHA-1, signing status, company and version, even after the file is deleted.
• Blocked loads: CodeIntegrity events show Windows refused a driver because of signing level or policy.

It does not prove the driver was actually loaded or exploited. A service created with sc create and started once may leave no load record in default logging. Confirm with memory (loaded modules), Sysmon event 6 (driver loaded) if Sysmon was deployed, or follow-on effects such as EDR services stopping.

Key fields

Timestamps

• Services key LastWrite (FILETIME, UTC): creation or last change of the service. Changing Start or ImagePath updates it.
• 7045 / 4697: UTC event times, the most reliable install anchor.
• setupapi.dev.log: section start and end times are written in local time; convert before timelining.
• .sys file $SI and $FN times in the $MFT: $FN is harder to timestomp and often exposes a dropped driver dated to look like an OS file.
• Amcache: key LastWrite reflects when the inventory ran, not necessarily when the driver arrived.

Retention and clearing

The registry key and file remain until removed. Attackers often delete the service and .sys after use: look for the deletion in the USN journal, for the orphaned Amcache entry and for the 7045 event, which survives service deletion until the System log rolls over (20 MB default). The CodeIntegrity Operational log is small (commonly about 1 MB), so blocked-load events can be overwritten quickly. Log clearing raises event 104 (System) or 1102 (Security).

Collection

KAPE RegistryHivesSystem, EventLogs, Amcache and USBDevicesLogs (which includes the setupapi logs), plus the driver files themselves:

driverquery /v /fo csv > E:\case\driverquery.csv
driverquery /si /fo csv > E:\case\driver_signing.csv
sc query type= driver state= all > E:\case\sc_drivers.txt
robocopy C:\Windows\System32\drivers E:\case\drivers *.sys /COPY:DAT

Get-WinEvent -FilterHashtable @{LogName='System'; Id=7045} |
  Where-Object Message -match 'kernel mode driver|file system driver' |
  Select-Object TimeCreated, Message | Export-Csv E:\case\7045_drivers.csv -NoTypeInformation
Get-WinEvent -LogName 'Microsoft-Windows-CodeIntegrity/Operational' |
  Select-Object TimeCreated, Id, Message | Export-Csv E:\case\codeintegrity.csv -NoTypeInformation

Parsing tools

• Autoruns (Sysinternals): the Drivers tab with "Verify code signatures" and VirusTotal checks; autorunsc -a d -h -s -c for CSV.
• sigcheck (sigcheck -e -h -c C:\Windows\System32\drivers) for signer and hashes of every .sys.
• Registry Explorer / RegRipper for offline SYSTEM hives (remember to pick the active control set).
• AmcacheParser for InventoryDriverBinary.
• EvtxECmd for 7045, 4697 and CodeIntegrity events.
• Volatility 3: windows.modules, windows.modscan and windows.driverscan to compare listed and carved modules and spot unlinked drivers; see the memory forensics guide.

Investigation tips

• Hash every non-Microsoft driver and match against the LOLDrivers project (loldrivers.io) and Microsoft's vulnerable driver blocklist. A signed driver from a gaming, overclocking or hardware vendor on a server is a classic BYOVD sign.
• ImagePath in \Users\, \ProgramData\, \Windows\Temp\ or a random short service name paired with Type 1 and Start 3 is typical of tool-dropped drivers.
• In CodeIntegrity/Operational, events such as 3033 (image did not meet signing level), 3077 (blocked by an enforced application control policy) and 3076 (audit mode) are the usual starting points; exact IDs and wording vary by build and policy, so read the message.
• The vulnerable driver blocklist is on by default on recent Windows 11 builds and with HVCI or Smart App Control, but coverage lags new drivers; check VulnerableDriverBlocklistEnable and the policy version before concluding a driver could not load.
• Correlate the driver install minute with the installed programs timeline, Windows Defender service stops and tamper protection events.
• Remember that PnP driver installs (USB devices, printers) also land in setupapi.dev.log and DriverStore: separate benign hardware noise from manual pnputil /add-driver installs.