feat(windows-etw): classify kernel image loads as driver_load

[Karib0u]

Summary

Follow-up to #485.

Classify Windows kernel image-load records as Sigma driver_load events and reuse the existing artifact resolver to populate hashes.

Source and measured cost

• Source: Microsoft-Windows-Kernel-Process, image-load event 5.
• A controlled signed driver load reported the full NT .sys path with System/kernel identity.
• The provider and image-load stream are already enabled, so this adds no provider traffic.
• Zero driver loads occurred in the measured 60-second idle window.
• The controlled 73,728-byte driver took 5.174 ms median and 7.408 ms mean to compute MD5, SHA1, and SHA256 in the lab PowerShell proxy. Native implementation cost is expected to be lower, but artifact I/O must remain bounded.

Scope

• Classify Kernel-Process event 5 kernel images before generic image loads.
• Normalize to Sigma driver_load with ImageLoaded.
• Reuse the loaded-image artifact resolver for Hashes and import hash.
• Add field-availability entries and pinned-corpus coverage assertions.
• Preserve observable artifact timeout, read, and hash failures.

Example Sigma coverage

The ten pinned rules use only ImageLoaded and/or Hashes. Examples include:

• Vulnerable WinRing0 Driver Load.
• WinDivert Driver Load.
• Malicious Driver Load by known hash.
• Process Hacker and System Informer driver loads.
• Drivers loaded from suspicious temporary paths.

Acceptance criteria

• A controlled signed driver load produces one driver_load event with a DOS path and hashes.
• User-mode DLL loads remain image_load.
• PID 0/4 semantics and unload behavior are fixture tested.
• Artifact work uses the existing bounded queue and deadline.
• All ten pinned rules are reported satisfiable, subject to observable artifact-resolution outcomes.
• Incremental event rate, processing latency, queue pressure, and dropped work are measurable.