Introduction and history
In the ever-evolving landscape of technology, the history of vulnerable drivers in Windows operating systems stands as a testament to the constant battle between innovation and security. From its inception, Windows has been a prime target for malicious actors seeking to exploit vulnerabilities in its drivers. These vulnerabilities, often overlooked, have played a significant role in the history of Windows, shaping its security policies and prompting a continuous cycle of patches and updates. The technique known as Bring Your Own Vulnerable Driver (BYOVD) has become a favoured strategy among threat actors. This involves introducing a digitally signed and trusted vulnerable driver into the kernel and exploiting it to gain kernel-level access. With this access a threat actor can undermine security measures, extract sensitive credentials, or alter system behaviour to remain undetected.
The exploitation of vulnerable drivers, which may have originated within the gaming community as a way to circumvent the anti-cheat engines, has evolved into a sophisticated technique that even echoes the methodologies of the infamous Stuxnet. Historically, the BYOVD gained notoriety in 2012 when it was used by the Shamoon wiper attack against Saudi Aramco. Multiple advanced persistence threats (APT) and nation-state groups have since utilized vulnerable drivers in their attacks over the last decade, leading to the proliferation of a well-known technique accessible to threat actors across various domains and interests. This technique gained an uptick in popularity in 2020 when ransomware gangs began incorporating it into their operations. DART has engaged with customers around the world who were affected by ransomware attacks where vulnerable drivers were used to circumvent or actively disrupt security solutions.
Threat actors discover vulnerabilities in the drivers and exploit them to achieve privilege escalation, circumvent the Windows Driver Signature Enforcement (DSE) and install a self-developed driver as rootkit or unhook security and monitoring solutions. This presents a significant cybersecurity risk, as it can provide threat actors with complete control over a system, enabling them to hide processes, network communication, evade detection and so on.
Hunting for vulnerable drivers
From a threat hunting perspective, it is important to understand what data sources are available and what coverage they have. Baselining the driver activity in the environment can greatly reduce the number of false positives in the hunts. The challenges encountered when conducting threat hunting for vulnerable drivers include: their presence in various legitimate locations, their potential to possess file extensions other than .sys, and the fact that even vulnerable drivers can exhibit seemingly convincing metadata. The following questions can guide threat hunting in identifying the vulnerable drivers:
- Do old signed drivers correspond to any required business application
- When was the driver signed
- Where is the driver located
- What process installed the driver
- Is the driver metadata normal for the environment
#MDE Advanced Hunting query for discovering drivers in the environment
DeviceFileEvents
| where ActionType == "FileCreated"
| where FileName endswith ".sys"
| invoke FileProfile(SHA1,10000)
| where GlobalPrevalence <= 500
| join kind=leftouter
(
DeviceFileCertificateInfo ) on SHA1
| project FileName, FolderPath, GlobalPrevalence, GlobalFirstSeen, GlobalLastSeen,
Signer, Signer1, Issuer, Issuer1, CertificateCreationTime, CertificateExpirationTime, CertificateSerialNumber
Similarly to the above query, the native Windows tool driverquery.exe provides a thorough list and csv output of drivers installed. This output can be ingested into a SIEM solution, aggregated, normalized and used in threat hunting.
Typical investigations should take into account the following:
-
File write events for driver in the environment
-
The installation of a new service (type: kernel mode driver) on the endpoint
-
The execution of a loader on the endpoint (it can be in memory)
-
Changes to the certificate root store (self-signed certificate might have been installed before loading a custom driver)
# MDE Advanced Hunting query for known vulnerable drivers using the community and Microsoft lists
# creating a database of files from the OpenSource list
let LolDriverSHA1 = externaldata(SHA1: string)[@"https://raw.githubusercontent.com/magicsword-io/LOLDrivers/main/detections/hashes/samples.sha1"] with (format="txt", ignoreFirstRecord=False);
# creating a database of files from the Microsoft Vulnerable Driver List
let indicatorsFromMsft = materialize(
externaldata(data:string)["https://learn.microsoft.com/en-us/windows/security/application-security/application-control/windows-defender-application-control/design/microsoft-recommended-driver-block-rules#vulnerable-driver-blocklist-xml"] with(format="raw")
| extend tempExtractedData = extract('(?sU)<pre><code class="lang-xml">(.*)</code></pre>', 1 , tostring(data))
| extend fix_xml = replace_strings(tempExtractedData,
dynamic(['<','>', '"']),
dynamic(['<','>','"'])
)
| project-away data, tempExtractedData
| extend parsed_xml = parse_xml(fix_xml)
| project-away fix_xml
| mv-apply x=['parsed_xml']['SiPolicy']['FileRules']['Deny'] on
(
extend _FriendlyName = x.['@FriendlyName']
| extend _Hash = x.['@Hash']
| extend _FileName1 = x.['@FileName']
| summarize VulnDrivers_Sha1 = make_set_if(_Hash, _FriendlyName endswith 'Hash Sha1'),
VulnDrivers_Sha256 = make_set_if(_Hash, _FriendlyName endswith 'Hash Sha256'),
VulnDrivers_FileNames1 = make_set(_FileName1)
)
| mv-apply y=['parsed_xml']['SiPolicy']['FileRules']['FileAttrib'] on
(
extend _FileName2 = y.['@FileName']
| summarize VulnDrivers_FileNames2 = make_set(_FileName2)
)
| extend VulnDrivers_FileNames = array_sort_asc(array_concat(VulnDrivers_FileNames1, VulnDrivers_FileNames2))
| project-away VulnDrivers_FileNames1, VulnDrivers_FileNames2, parsed_xml
);
//let VulnDrivers_FileNames = toscalar(indicatorsFromMsft | project VulnDrivers_FileNames);
let VulnDrivers_Sha1 = toscalar(indicatorsFromMsft | project VulnDrivers_Sha1);
//let VulnDrivers_Sha256 = toscalar(indicatorsFromMsft | project VulnDrivers_Sha256);
DeviceFileEvents | where SHA1 in~ (VulnDrivers_Sha1) or SHA1 in~ (LolDriverSHA1)From a hunting and investigation perspective, vulnerable driver lists from Microsoft and the community list from MagicSword in the above query, are simple external data sources. They can be incorporated into any SIEM solution, as well as integrated into periodic checks for detecting this attack behaviour.
- Microsoft Defender for Endpoint Advanced Hunting query
# MDE Advanced Hunting - Kernel services registered on device
DeviceEvents
| where ActionType contains "ServiceInstalled"
| extend ParsedFields=parse_json(AdditionalFields)
| extend AttributeList = ParsedFields.ServiceType
| where AttributeList == 1- System Event Log Event ID 7045
Figure 1: System Event Log, Event ID 7045 - New kernel service creation
- Sysmon Event ID 11
Figure 2: Sysmon Event Log, Event ID 11 - New file creation
- Sysmon Event ID 13
Figure 3: Sysmon Event Log, Event ID 13 - Service registry value set
- Sysmon Event ID 6
Figure 4: Sysmon Event Log, Event ID 6 - Driver loaded event
In the event the threat actor has full control of the system, a self-signed certificate can be introduced and installed in the environment. This will give the threat actor the possibility of installing a custom malicious driver(signed with the self-signed certificate) and gain persistent access to the system. A recommended hunting strategy would be to investigate the trusted certificates installed on a system during the incident timeframe.
# MDE Advanced Hunting for new certificates added to Root store
DeviceRegistryEvents
| where ActionType contains "RegistryKeyCreated"
| where RegistryKey contains "HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\SystemCertificates\\ROOT\\Certificates\\"
Strategies for monitoring and preventing vulnerable driver attacks
Microsoft recommends a defense in depth strategy with multiple layers to prevent vulnerable driver attacks. Detecting the unauthorized access as close as possible to the initial access point is critical when dealing with determined threat actors. To abuse a vulnerable driver, a threat actor would need to perform multiple operations until gaining full access to the system. These steps would give the defenders a wealth of opportunities to detect and mitigate the intrusion early on.
The Windows platform empowers organizations to realize their full potential in the manner they envision, but when it comes to securing the platform, a one-size-fits-all approach doesn't work. Each enterprise has its own set of vulnerabilities, risk acceptance, and security requirements. A well-rounded strategy for monitoring and preventing vulnerable driver attacks should be flexible, adaptable and tailored to the unique needs of each organization. It should strike the right balance between trust and operation, ensuring robust security without hindering the organization's activities. Microsoft continues to work closely with our independent hardware vendors (IHVs) and the security community to ensure the highest level of driver security for our customers. When driver vulnerabilities are found, we work with our driver partners to ensure they're quickly patched and rolled out to the ecosystem.
The technologies listed below can help organizations secure their environments from the risk of vulnerable drivers attacks.
Memory integrity or hypervisor-protected code integrity (HVCI)
Memory integrity and virtualization-based security (VBS) improve the threat model of Windows and provide stronger protections against malware trying to exploit the Windows kernel. VBS uses the Windows hypervisor to create an isolated virtual environment that becomes the root of trust of the OS that assumes the kernel can be compromised. Memory integrity is a critical component that protects and hardens Windows by running kernel mode code integrity within the isolated virtual environment of VBS.
Memory integrity can be configured using Windows security settings, Microsoft Intune or other MDM, Group Policy, Microsoft configuration manager or modifying the Windows registry settings. This is one of the most effective and recommended means to prevent vulnerable driver attacks on platforms that do not have any legacy dependencies such as old software in production environments.
Supported platforms:
Windows 10 Windows 11 Windows Server 2016 Windows Server 2019 Windows Server 2022
Smart App Control
Smart App Control provides robust protection against current and emerging threats by blocking malicious or untrusted apps on Windows platform, effectively mitigating risks from novel and evolving threats. Smart App Control is only available on a clean installation of Windows 11 version 22H2 and can be enforced or in evaluation mode. Smart App Control blocks the vulnerable drivers defined in the Microsoft vulnerable driver list.
Supported platforms:
Microsoft Defender for Endpoint attack surface reduction rules (ASR)
The block abuse of exploited vulnerable signed drivers ASR rule monitors and prevents an application from writing a signed vulnerable driver to the system. Vulnerable and exploited drivers are routinely identified and automatically added to the vulnerable driver ASR rule to protect Microsoft Defender for Endpoint users against driver malware campaigns. ASR rules are supported on most Windows versions beginning with Windows 2012 R2. Dependencies for planning and deploying the ASR rules are an important step in implementing this security strategy.
ASR rules offer the following four settings:
-
Not configured: disable the ASR rule.
-
Block: enable the ASR rule.
-
Audit: evaluate how the ASR rule would impact your organization if enabled.
-
Warn: enable the ASR rule but allow the user to bypass the block.
The vulnerable driver ASR rule GUID is 56a863a9-875e-4185-98a7-b882c64b5ce5. The Intune name is block abuse of exploited vulnerable signed drivers.
In addition to the ASR reports in the Defender portal, the ASR logs can be queried using Microsoft Defender for Endpoint advanced hunting events, action type:
- AsrVulnerableSignedDriverAudited
- AsrVulnerableSignedDriverBlocked
Alternatively, the Windows Event Logs Microsoft-Windows-Windows Defender Operational, can be ingested into your Sentinel SIEM or queried using built in Windows Event Viewer by navigating to Applications and Services Logs -> Microsoft -> Windows > Windows Defender -> Operational -> Event ID 1121 and Event ID 1122
Figure 5: Microsoft-Windows-Windows Defender Operational Event Log, Event ID 1121 - ASR Event Blocked
The vulnerable driver ASR rule can be configured using Intune, mobile device management (MDM), Microsoft Endpoint Configuration Manager, Group Policy, and PowerShell. To enable the vulnerable driver ASR rule by each method, please refer to the Microsoft documentation.
Windows Defender Application Control (WDAC)
Compared to HVCI, Smart App Control and ASR rules, Windows Defender Application Control (WDAC) can be tailored for your own security strategy. WDAC operates alongside EDR products, however, its trust model differs from traditional antivirus solutions. Instead of assuming applications are trustworthy by default, WDAC requires applications to earn trust before they are allowed to run. Microsoft recommends using this list of drivers within your existing Windows Defender Application Control policy. The Vulnerable Driver Block List is a curated list of drivers that have vulnerabilities and have been used in the threat landscape. New drivers can be submitted for analysis to Vulnerable and malicous driver reporting.
Blocking kernel drivers without sufficient testing can cause devices or software to malfunction, and in rare cases, cause the Operating System to stop responding. It's recommended to first validate this policy in audit mode and review the audit block events.
For critical environments that are unable to utilize HVCI or Smart App Control, but still require a tailored security strategy, Microsoft recommends configuring the vulnerable driver list WDAC policy or a custom version of the list and turning on additional protection features using the Windows Defender App Control Policy Wizard based on the environment requirements.
Supported platforms:
Windows 10 Windows 11 Windows Server 2016 Windows Server 2019 Windows Server 2022
Conclusion
In our exploration of inspecting vulnerable driver attacks, we have delved into their history, explored effective hunting methodologies, and dissected strategies for prevention and monitoring. We at Microsoft will continue to collaborate with the security community to defend against vulnerable drivers, and strive to fortify the security posture for all our valued customers. We strongly recommend all organizations actively leverage the technologies outlined in this blog to enhance their security and mitigate such attacks.
Microsoft
