DC0079: Driver Load
The process of attaching a driver, which is a software component that allows the operating system and applications to interact with hardware devices, to either user-mode or kernel-mode of a system. This can include benign actions (e.g., hardware drivers) or malicious behavior (e.g., rootkits or unsigned drivers). Examples:
- Legitimate Driver Loading: A new graphics driver from a vendor like NVIDIA or AMD is loaded into the system. - Unsigned Driver Loading: A driver without a valid digital signature is loaded into the kernel. - Rootkit Installation: A malicious rootkit driver is loaded to manipulate kernel-mode processes. - Anti-Virus or EDR Driver Loading: An Endpoint Detection and Response (EDR) solution loads its driver to monitor system activities. - Driver Misuse: A legitimate driver is loaded and exploited to execute malicious actions, such as using vulnerable drivers for bypassing defenses (e.g., Bring Your Own Vulnerable Driver (BYOVD) attacks).
Analyst context for executives and security teams
Driver Load matters because drivers can operate at privileged levels of a system and are used for both normal operations and security tooling. The same event class can also represent higher-risk activity such as unsigned driver loading, rootkit installation, or misuse of legitimate vulnerable drivers. For leaders, this is a coverage question: can the organization distinguish expected hardware, EDR, and vendor driver activity from unusual or risky driver loading?
Executive priority
Treat driver-load visibility as a resilience and assurance control, not just a technical log source. If the organization cannot evidence which drivers are loading, whether they are signed, and whether loading patterns are expected, SOC and incident response teams may have limited ability to assess kernel-level tampering, rootkit-like behavior, or misuse of vulnerable drivers. This can affect incident confidence, compliance evidence, endpoint security assurance, and vulnerability prioritization around risky or obsolete drivers.
Technical view
ATT&CK defines Driver Load as the attachment of a driver to user-mode or kernel-mode, including legitimate vendor drivers, unsigned drivers, EDR/AV drivers, rootkit drivers, and misuse of legitimate drivers. No ATT&CK detection guidance, platforms, tactics, or related techniques were supplied for this object, so teams should validate locally which endpoint and operating system telemetry records driver load events, signature state, driver path, publisher, hash, load context, and the initiating process or service where available.
Likely telemetry
- Endpoint driver load events
- Kernel or system event logs that record driver attachment
- Driver file metadata including path, hash, publisher, and digital signature status
- Endpoint security or EDR telemetry for driver activity
- Service or process context associated with driver installation or loading
Detection direction
- Baseline known-good driver loads for hardware vendors, operating system components, and security tools to reduce noise from legitimate driver activity.
- Prioritize review of unsigned, unexpectedly signed, newly observed, unusual-path, or rare driver loads where telemetry supports those attributes.
- Correlate driver load events with recent software installation, driver update, endpoint security deployment, or administrative change activity before escalating.
- Validate whether telemetry can distinguish user-mode and kernel-mode driver loading, because kernel-mode visibility is often more important for tamper and rootkit investigations.
- Because ATT&CK provides no detection text for this data component, detection logic should be tested against local logging fidelity and expected administrative workflows rather than assumed coverage.
Mitigation priorities
- Maintain an approved-driver inventory for business-critical endpoints and security tools.
- Enforce driver signing and trusted publisher controls where supported by the environment and operational requirements.
- Include vulnerable or obsolete drivers in vulnerability management and exception review processes.
- Restrict administrative pathways used to install or load drivers and retain evidence of authorized changes.
- Ensure incident response playbooks include driver load review when investigating suspected endpoint tampering or stealthy persistence.
Analyst notes and limits
This object is a data component, not a technique. Its value is evidentiary: it helps determine whether defenders can observe driver loading that may be benign, security-tool related, or suspicious. The supplied ATT&CK record includes examples such as legitimate graphics drivers, unsigned drivers, rootkit installation, EDR driver loading, and vulnerable driver misuse, but provides no tactic mapping or relationship context.
The supplied ATT&CK fields do not specify platforms, tactics, detections, mitigations, relationships, or active threat use. Any prioritization, detection thresholds, or control recommendations must be validated against the organization’s endpoint platforms, logging configuration, approved driver inventory, and change-management records.
Driver Load
The process of attaching a driver, which is a software component that allows the operating system and applications to interact with hardware devices, to either user-mode or kernel-mode of a system. This can include benign actions (e.g., hardware drivers) or malicious behavior (e.g., rootkits or unsigned drivers). Examples:
- Legitimate Driver Loading: A new graphics driver from a vendor like NVIDIA or AMD is loaded into the system. - Unsigned Driver Loading: A driver without a valid digital signature is loaded into the kernel. - Rootkit Installation: A malicious rootkit driver is loaded to manipulate kernel-mode processes. - Anti-Virus or EDR Driver Loading: An Endpoint Detection and Response (EDR) solution loads its driver to monitor system activities. - Driver Misuse: A legitimate driver is loaded and exploited to execute malicious actions, such as using vulnerable drivers for bypassing defenses (e.g., Bring Your Own Vulnerable Driver (BYOVD) attacks).
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | a9de550218bb… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DC0079Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.