windows-driver-assessment

# Windows Driver Exposure Assessment ## Scope Use this lane only for an owner-authorized endpoint inventory or a disposable research VM. Preserve Windows security controls. Do not load vulnerable drivers, disable HVCI/VBS, bypass EDR, deploy a BYOVD chain, or use anti-cheat systems as test targets. ## Evidence-first workflow 1. **Pin the environment.** Record the Windows build, kernel build, VM snapshot ID, Secure Boot, HVCI, VBS, Microsoft vulnerable-driver blocklist state, and the exact driver file hash before analysis. 2. **Inventory exposure.** Collect driver path, service name, publisher, Authenticode chain, file version, loaded state, device interface, and vulnerability advisory or blocklist correlation. A name-only match is a lead, not a finding. 3. **Triage safely.** Perform static import/IOCTL/symbol review and ETW or debugger observation in the disposable VM. Capture a call stack or trace that ties the conclusion to the pinned binary. 4. **Verify a mitigation.** For a real exposure, capture the pre-remediation inventory; apply the documented vendor update, removal, or block policy; then repeat the same inventory and confirm the exposure no longer exists. 5. **Handle crashes as research artifacts.** Preserve the minimized input, minidump, symbols/build identity, stack trace, and a benign control execution. Do not convert a crash into persistence, privilege escalation, stealth, or production exploitation. ## Promotion rule A driver finding requires a stable binary hash, signer/version evidence, a reproducible observation in the isolated VM, and a negative control showing the mitigated configuration does not reproduce the condition. Otherwise record a triage lead only.