91 lines
2.9 KiB
Markdown
91 lines
2.9 KiB
Markdown
---
|
|
name: analyzing-windows-driver-malware
|
|
description: 'Analyzes malicious and vulnerable Windows kernel drivers (.sys) by parsing the PE for
|
|
the native subsystem, identifying DriverEntry/IRP dispatch and IOCTL handlers, and flagging BYOVD
|
|
and kernel-callback abuse. Activates for requests to analyze a Windows driver, examine a .sys
|
|
sample, or assess a BYOVD/kernel driver threat.'
|
|
domain: cybersecurity
|
|
subdomain: reverse-engineering
|
|
tags:
|
|
- reverse-engineering
|
|
- windows-driver
|
|
- kernel
|
|
- byovd
|
|
- ioctl
|
|
version: 1.0.0
|
|
author: analyst-ai-pack
|
|
license: Apache-2.0
|
|
mitre_attack:
|
|
- T1068
|
|
- T1014
|
|
- T1547.006
|
|
d3fend:
|
|
- D3-SDA
|
|
- D3-FA
|
|
references:
|
|
- 'Windows Driver Kit (WDM/IRP) — https://learn.microsoft.com/windows-hardware/drivers/'
|
|
- 'MITRE ATT&CK T1068 Exploitation for Privilege Escalation — https://attack.mitre.org/techniques/T1068/'
|
|
---
|
|
|
|
# Analyzing Windows Driver Malware
|
|
|
|
## When to Use
|
|
|
|
- You have a `.sys` kernel driver (malicious rootkit driver or a vulnerable driver used for BYOVD)
|
|
and need to identify its entry, IRP/IOCTL handlers, and dangerous kernel operations.
|
|
- You are assessing privilege-escalation or kernel-stealth risk.
|
|
|
|
**Do not use** this by loading the driver — analyze it statically. Loading kernel code is
|
|
dangerous and is the threat itself.
|
|
|
|
## Prerequisites
|
|
|
|
- The driver `.sys` (read inertly).
|
|
|
|
## Safety & Handling
|
|
|
|
- Read bytes statically; never install/load the driver. Note its signing status for BYOVD context.
|
|
|
|
## Workflow
|
|
|
|
### Step 1: Confirm it is a kernel driver
|
|
|
|
```bash
|
|
python scripts/analyst.py inspect driver.sys
|
|
```
|
|
|
|
Verifies the PE native subsystem (1), kernel imports (`ntoskrnl.exe`, `hal.dll`), and reports
|
|
imported kernel APIs.
|
|
|
|
### Step 2: Identify dispatch and dangerous primitives
|
|
|
|
Flag IRP/IOCTL handling (`IoCreateDevice`, `IoCreateSymbolicLink`, `IRP_MJ_DEVICE_CONTROL`),
|
|
arbitrary read/write primitives (`MmMapIoSpace`, `ZwMapViewOfSection`, `MmCopyMemory`), and
|
|
callback registration (`PsSetCreateProcessNotifyRoutine`, `ObRegisterCallbacks`).
|
|
|
|
### Step 3: Assess BYOVD/stealth potential
|
|
|
|
Map exposed IOCTLs to capabilities (physical memory access, process kill, token theft) that BYOVD
|
|
abuse relies on.
|
|
|
|
### Step 4: Document
|
|
|
|
Record the driver's handlers, dangerous primitives, signing status, and risk.
|
|
|
|
## Validation
|
|
|
|
- Native subsystem and kernel imports confirm a driver.
|
|
- Dispatch/IOCTL and dangerous-primitive imports are reported with evidence.
|
|
- Capabilities are tied to concrete imported APIs.
|
|
|
|
## Pitfalls
|
|
|
|
- Legitimate vendor drivers that are nonetheless exploitable (BYOVD) — context matters.
|
|
- Drivers resolving APIs dynamically, hiding imports.
|
|
- Confusing user-mode helper components with the kernel driver itself.
|
|
|
|
## References
|
|
|
|
- See [`references/api-reference.md`](references/api-reference.md) for the inspector.
|
|
- WDK and ATT&CK T1068 references (linked in frontmatter).
|