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
- 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.
- 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.
- 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.
- 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.
- 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.
1---2name: windows-driver-assessment3description: Defensive Windows internals and driver exposure assessment for owner-authorized systems and disposable research VMs.4---56# Windows Driver Exposure Assessment78## Scope910Use this lane only for an owner-authorized endpoint inventory or a disposable11research VM. Preserve Windows security controls. Do not load vulnerable drivers,12disable HVCI/VBS, bypass EDR, deploy a BYOVD chain, or use anti-cheat systems as13test targets.1415## Evidence-first workflow16171. **Pin the environment.** Record the Windows build, kernel build, VM snapshot18 ID, Secure Boot, HVCI, VBS, Microsoft vulnerable-driver blocklist state, and19 the exact driver file hash before analysis.202. **Inventory exposure.** Collect driver path, service name, publisher,21 Authenticode chain, file version, loaded state, device interface, and22 vulnerability advisory or blocklist correlation. A name-only match is a lead,23 not a finding.243. **Triage safely.** Perform static import/IOCTL/symbol review and ETW or25 debugger observation in the disposable VM. Capture a call stack or trace that26 ties the conclusion to the pinned binary.274. **Verify a mitigation.** For a real exposure, capture the pre-remediation28 inventory; apply the documented vendor update, removal, or block policy; then29 repeat the same inventory and confirm the exposure no longer exists.305. **Handle crashes as research artifacts.** Preserve the minimized input,31 minidump, symbols/build identity, stack trace, and a benign control execution.32 Do not convert a crash into persistence, privilege escalation, stealth, or33 production exploitation.3435## Promotion rule3637A driver finding requires a stable binary hash, signer/version evidence, a38reproducible observation in the isolated VM, and a negative control showing the39mitigated configuration does not reproduce the condition. Otherwise record a40triage lead only.
purpleailab