Driver Load is the loading of a kernel-mode driver into the operating system. Attackers may load malicious or vulnerable drivers to gain privileged access, disable protections, or hide activity, so defenders should control driver signing, monitor unusual loads, and investigate unsigned or untrusted drivers.
What Driver Load Means in Practice
Driver load is the moment a kernel-mode driver enters the operating system and gains privileged execution. Because it runs at the kernel layer, the event is security significant even when the driver is legitimate, since mistakes or abuse can affect core system integrity.
For defenders, the key question is not just whether a driver was loaded, but whether the load was expected, signed, and traceable to an approved software or hardware dependency. Unusual kernel driver activity often deserves the same scrutiny as high-risk privilege use elsewhere in the stack.
Why Driver Load Is Security Sensitive
A loaded driver can observe, modify, or interfere with low-level operating system behaviour. That makes driver load a high-value boundary for both attackers and defenders, because kernel access can be used to disable security tools, hide processes, tamper with memory, or weaken enforcement mechanisms that user-mode software relies on.
Security teams usually treat driver trust as a control problem, not a one-time approval problem. A driver that is safe in one context may still be risky if it is old, vulnerable, unsigned, improperly sourced, or loaded from an unexpected path.
What Organisations Should Check
Exposure analysis starts with asset inventory and driver visibility. Teams need to know which endpoints, servers, and special-purpose systems can load kernel drivers, what drivers are normally present, and which installation paths are sanctioned by policy.
It is also important to check whether the system is already protected by signing enforcement, reputation checks, and allowlisting for approved vendors. If a driver appears in telemetry without a clear business reason, that event should be compared against vendor documentation and the environment’s approved software baseline.
Operationally, driver loading should be monitored alongside other low-level integrity signals. The most useful view is often the combination of provenance, signature status, install source, and timing, rather than any single attribute in isolation.
How Driver Load Becomes an Attack Path
Attackers value driver load because kernel code can bypass many user-mode controls. A malicious driver may be introduced directly, or a vulnerable but signed driver may be abused to gain privileged access and interfere with detection.
That is why driver load integrity checking is a meaningful defensive technique. MITRE D3FEND Guide includes driver load integrity checking as part of a broader set of techniques for validating operating-system and process trust. For attack-pattern context, MITRE ATT&CK Enterprise Matrix helps defenders map kernel-level abuse to privilege escalation, persistence, and defence evasion behaviours.
When driver abuse is suspected, the investigation often expands beyond the driver itself to the mechanisms that loaded it, the persistence it may have established, and any protections it may have disabled.
Risk and Threat Considerations
Driver load creates concentrated risk because a single kernel component can undermine endpoint integrity, visibility, and response. If an attacker succeeds in loading a hostile or vulnerable driver, they may gain a durable foothold that is harder to inspect or remove than ordinary user-mode malware.
Failure mechanism: The operating system trusts the loaded driver enough to execute it in kernel mode, which can allow protection bypass, stealth, tampering, or privileged control of the host.
Impact: The result can include hidden malicious activity, weakened endpoint protections, compromised system integrity, and a more difficult incident response because the attacker operates below normal user-mode visibility.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1547 — Boot or Logon Autostart Execution | Driver loading can support persistence and low-level execution on a host. |
| Recommendation — Hunt for kernel-level persistence and review boot and load-time execution paths. | ||
| NIST SP 800-53 Rev 5 | SI-3 — Malicious Code Protection | Driver load control directly supports blocking or detecting hostile code execution. |
| CM-5 — Access Restrictions for Change | Driver loading is a privileged change that should be tightly restricted and approved. | |
| SI-7 — Software, Firmware, and Information Integrity | Driver integrity and trust are core to preventing tampered or untrusted kernel code. | |
| Recommendation — Enforce malicious code protections that inspect, block, or quarantine untrusted drivers. Restrict who can introduce kernel drivers and require approval for driver changes. Validate driver integrity and investigate unexpected kernel-module changes. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Driver loading is governed by secure baseline configuration and trusted software control. |
| Recommendation — Lock down driver installation and maintain a trusted software baseline. | ||
Practitioner Guidance
Why practitioners should care: Driver load is one of the few ordinary administrative events that can immediately change the trust posture of an endpoint. Treat it as a control point for integrity, not just as a software installation detail.
What to watch for: Focus on unsigned drivers, unexpected vendor names, unusual install times, and drivers that appear on systems where they have no clear operational purpose. Correlate driver events with changes in security tooling or unexplained instability.
Practitioner takeaway: If you cannot explain why a driver loaded, you should assume it deserves review until its source, signature, and purpose are verified.