Definition
Ensuring the integrity of drivers loaded during initialization of the operating system.
How it works
This technique can be accomplished in a number of ways:
- A kernel level security agent installed on a host machine ensures that the driver associated with the agent is first in the initialization order. A dependent DLL associated with the driver is configured to be processed before other dependent DLLs and executes a number of operations to ensure the driver associated with the security agent is initialized first.
- Kernel components can be signed by a certificate obtained by a third party to verify the source of the component and whether it has been modified. When signed, the component will include a signature block implemented as a hash value of the component header and can also include a certificate chain. The signature and certificate data are typically added before the kernel component is distributed to the public.
Considerations
- The private keys to sign certificates as reputable companies have been stolen in the past -- in cases such as where certificates from Adobe, Realtek, and JMicron have been used to sign malicious executables. (Source: https://resources.infosecinstitute.com/cybercrime-exploits-digital-certificates/#gref)
- Trusted Root Certificate Authorities have been compromised, yielding the ability to use the compromised keys to generate certificates with an arbitrary company name.
- It may not be difficult for an attacker to start an organization which can obtain a signed certificate.
- A root certificate authority (CA) whose certificate is trusted in the verification logic could generate incorrect certificates, if they are lax or have ulterior motives.
Implementation perspective
Driver Load Integrity Checking should be treated as a technical defensive capability rather than a product checkbox. In practice, teams should define the protected scope, the conditions under which the technique acts, and the observable evidence that demonstrates the intended behavior. For this technique, likely engineering context includes the relevant system, activity, and evidence sources.
Use the technique to increase the effort, prerequisites, or constraints an adversary must overcome before exploitation or misuse succeeds.
Questions to ask
- Which component, configuration, credential, interface, or behavior is being hardened?
- What secure baseline or policy defines the intended state?
- How are exceptions approved, time-limited, and reviewed?
- How is the hardened state verified after deployment and significant change?
Evidence and validation
- Approved hardening standards and configuration baselines
- Automated configuration or integrity assessment results
- Exception records with owners, rationale, and expiration dates
- Test results demonstrating that the intended restriction is enforced
Common failure patterns
- A secure setting is documented but not enforced consistently across the environment.
- Hardening breaks required functions and is permanently weakened through undocumented exceptions.
- Teams measure deployment of a product rather than verification of the hardened condition.
This implementation perspective is original Bare Metal Cyber educational content. It does not replace the official D3FEND definition or establish that a specific product implements the technique.
Technique hierarchy
Top-level family
Parent techniques
Direct child techniques
None listed at this level.
Artifacts and ontology entities
These relationships describe how D3FEND connects a defensive technique to artifacts or other ontology entities. They describe graph semantics, not a product certification.
Explicit technique relationships
NIST SP 800-53 relationships
The relation label is preserved from the D3FEND ontology. It is not converted into a claim that the control automatically implements or validates this technique.
ATT&CK Enterprise mitigation relationships
These links come from the D3FEND ontology’s ATT&CK mitigation mapping. They help users navigate between the knowledge bases and do not guarantee mitigation effectiveness.
Authoritative sources
- Open this technique on the official D3FEND website ↗
- Open the official ontology resources ↗
- Integrity assurance through early loading in the boot phase ↗Crowdstrike Inc · Ion-Alexandru Ionescu · PatentReference
- Protected computing environment ↗Microsoft Technology Licensing LLC · Sumedh Barde, Jonathan Schwartz, Reid Kuhn, Alexandre Grigorovitch, Kirt Debique, Chadd Knowlton, James Alkove, Geoffrey Dunbar, Michael Grier, Ming Ma, Chaitanya Upadhyay, Adil Sherwani, Arun Kishan · PatentReference
Bare Metal Cyber is an independent educational publisher and is not affiliated with or endorsed by The MITRE Corporation. MITRE D3FEND™ and the D3FEND logo are trademarks of The MITRE Corporation. MITRE ATT&CK® and ATT&CK® are registered trademarks of The MITRE Corporation. Use of D3FEND source material is subject to the official Terms of Use.