{ "id": "a29d290e-37e0-4332-b656-2d9494fcac5d", "created_at": "2026-04-06T00:16:03.234751Z", "updated_at": "2026-04-10T03:33:01.142087Z", "deleted_at": null, "sha1_hash": "3ded51d407728e8625ea2c574c86ec3c10ba8d6f", "title": "Improve kernel security with the new Microsoft Vulnerable and Malicious Driver Reporting Center", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 254059, "plain_text": "Improve kernel security with the new Microsoft Vulnerable and\r\nMalicious Driver Reporting Center\r\nBy Microsoft Offensive Research \u0026 Security Engineering (MORSE), Microsoft Threat Intelligence\r\nPublished: 2021-12-08 · Archived: 2026-04-06 00:05:21 UTC\r\nWindows 10 and Windows 11 have continued to raise the security bar for drivers running in the kernel. Kernel-mode driver\r\npublishers must pass the Hardware Lab Kit (HLK) compatibility tests, malware scanning, and prove their identity through\r\nextended validation (EV) certificates. This has significantly reduced the ability for malicious actors to run nefarious kernel\r\ncode on Windows 10 and Windows 11 devices.\r\nVulnerable driver attacks\r\nIncreasingly, adversaries are leveraging legitimate drivers in the ecosystem and their security vulnerabilities to run malware.\r\nMultiple malware attacks, including RobinHood, Uroburos, Derusbi, GrayFish, and Sauron, have leveraged driver\r\nvulnerabilities (for example CVE-2008-3431,1 CVE-2013-3956,2 CVE-2009-0824,3 and CVE-2010-1592).4\r\nVulnerable driver attack campaigns target security vulnerabilities in well-intentioned drivers from trusted original equipment\r\nmanufacturers (OEMs) and hardware vendors to gain kernel privileges, modify kernel signing policies, and load their\r\nmalicious unsigned driver into the kernel. In some cases, these unsigned drivers will disable antivirus products to avoid\r\ndetection. From there, ransomware, spyware, and other types of malware can be executed.\r\nMicrosoft Defender for Endpoint and Windows Security teams work diligently with driver publishers to detect security\r\nvulnerabilities before they can be exploited by malicious software. We also build automated mechanisms to help block\r\nvulnerable versions of drivers and help protect customers against vulnerability exploits based on the ecosystem and partner\r\nengagement.\r\nReporting vulnerabilities: Vulnerable and Malicious Driver Reporting Center\r\nTo help protect users against these types of attacks, Microsoft has created the new Vulnerable and Malicious Driver\r\nReporting Center. The Reporting Center is designed to be easy-to-use and requires only the driver file and a few details to\r\nopen a driver analysis case. Simply provide the driver binary for our analysis, details about the vulnerability or malicious\r\nbehavior of the driver, and an email address for follow-up.\r\nhttps://www.microsoft.com/security/blog/2021/12/08/improve-kernel-security-with-the-new-microsoft-vulnerable-and-malicious-driver-reporting-center/\r\nPage 1 of 6\n\nhttps://www.microsoft.com/security/blog/2021/12/08/improve-kernel-security-with-the-new-microsoft-vulnerable-and-malicious-driver-reporting-center/\r\nPage 2 of 6\n\nFigure 1: The Vulnerable and Malicious Driver Reporting Center.\r\nThe Reporting Center backend automatically analyzes the potentially vulnerable or malicious driver binary and identifies\r\ndangerous behaviors and security vulnerabilities including:\r\nDrivers with the ability to map arbitrary kernel, physical, or device memory to user mode.\r\nDrivers with the ability to read or write arbitrary kernel, physical, or device memory, including Port I/O and central\r\nprocessing unit (CPU) registers from user mode.\r\nDrivers that provide access to storage that bypass Windows access control.\r\nThe Reporting Center can scan and analyze Windows drivers built for x86 and x64 architectures. Vulnerable and malicious\r\nscanned drivers are flagged for analysis and investigation by Microsoft’s Vulnerable Driver team. This program is currently\r\nnot eligible for the Microsoft Security Response Center’s Bug Bounty program.\r\nhttps://www.microsoft.com/security/blog/2021/12/08/improve-kernel-security-with-the-new-microsoft-vulnerable-and-malicious-driver-reporting-center/\r\nPage 3 of 6\n\nReport a driver for analysis now.\r\nFeedback loop: Vulnerable drivers are automatically blocked in the ecosystem\r\nOur security teams work closely with the driver publisher to help analyze and patch the vulnerability and update in-market\r\naffected devices. Once the driver publisher patches the vulnerability, updates to all affected drivers are distributed by the\r\ndriver publisher, typically through Windows Update (WU). Once affected devices receive the latest security patches, drivers\r\nwith confirmed security vulnerabilities will be blocked on Windows 10 devices in the ecosystem using Microsoft Defender\r\nfor Endpoint attack surface reduction (ASR) and Microsoft Windows Defender Application Control (WDAC) technologies\r\nto protect devices against exploits involving vulnerable drivers to gain access to the kernel.\r\nMicrosoft Defender for Endpoint attack surface reduction rules\r\nVulnerable drivers ASR rule\r\nE3 and E5 enterprise customers will gain the benefit of using Microsoft Defender for Endpoint’s ASR rules to block\r\nmalicious and vulnerable drivers. ASR rules target and block entry points and code behavior used by malware and abused by\r\nattackers, preventing attacks from beginning in the first place. The vulnerable signed driver ASR rule prevents an application\r\nfrom writing a signed vulnerable driver to the system.\r\nVulnerable and malicious drivers are added to the vulnerable driver ASR rule to protect Microsoft Defender for\r\nEndpoint users against driver malware campaigns without any user intervention. ASR rules are supported in the following\r\nversions:\r\nWindows 10 Pro or Enterprise, version 1709 or later.\r\nWindows Server 1803 or later.\r\nWindows Server 2019.\r\nConfiguring the vulnerable driver ASR rule\r\nThe vulnerable driver ASR rule can be enabled and configured using Intune, mobile device management (MDM), Microsoft\r\nEndpoint Configuration Manager, Group Policy, and PowerShell. To enable the vulnerable driver ASR rule by each method,\r\nplease refer to the Microsoft documentation Use attack surface reduction to prevent malware infection.\r\nASR rules offer the following four settings:\r\n1. Not configured: Disable the ASR rule.\r\n2. Block: Enable the ASR rule.\r\n3. Audit: Evaluate how the ASR rule would impact your organization if enabled.\r\n4. Warn: Enable the ASR rule but allow the user to bypass the block.\r\nThe vulnerable driver ASR GUID is 56a863a9-875e-4185-98a7-b882c64b5ce5. The Intune name is Block abuse of\r\nexploited vulnerable signed drivers.\r\nFor the full list of ASR rule’s feature differences between E3 and E5 licenses, please refer to the Microsoft\r\ndocumentation Attack surface reduction features across Windows versions.\r\nWindows Defender Application Control\r\nMicrosoft driver blocklist\r\nhttps://www.microsoft.com/security/blog/2021/12/08/improve-kernel-security-with-the-new-microsoft-vulnerable-and-malicious-driver-reporting-center/\r\nPage 4 of 6\n\nDriver vulnerabilities confirmed by Microsoft Defender for Endpoint and Windows Security teams, including those reported\r\nby our security community through the Vulnerable Driver Reporting Center, are blocked by the Microsoft-supplied policy.\r\nThis policy is automatically updated and pushed down through WU to Secured-core devices, Hypervisor-Protected Code\r\nIntegrity (HVCI) enabled, and Windows in 10 S mode devices, by default. These classes of devices use WDAC and HVCI\r\ntechnology to block vulnerable and malicious drivers from running on devices before they are loaded into the kernel. The\r\nvulnerable driver blocklist policy is regularly updated and pushed out through WU to help protect against the latest kernel\r\nexploits.\r\nTo learn how to turn on HVCI in Windows 10 to opt into the automated Microsoft driver blocklist, or to verify if HVCI is\r\nenabled, visit Enable virtualization-based protection of code integrity.\r\nDefending your devices against vulnerable and malicious drivers\r\nCreating custom WDAC block policies\r\nWindows users can create and apply custom driver block policies to gain security parity with the Microsoft-supplied driver\r\nblock policy. Microsoft publishes the block policy and recommends all customers apply kernel block rules to help prevent\r\ndrivers with vulnerabilities from running on your devices or being exploited. By default, the policy is in audit mode. In this\r\nmode, drivers are not blocked from executing but will provide audit logging events. We recommend placing new policies in\r\naudit mode before enforcing them to determine the impact and scope of the blocked binaries using the audit logging events.\r\nFor more information about interpreting log events, please refer to the Microsoft documentation Use audit events to create\r\nWDAC policy rules.\r\nWDAC driver block policies are easy to create and deploy. Microsoft supplies both built-in PowerShell Cmdlets and\r\nthe WDAC Wizard desktop application to create, edit, and merge WDAC policies. Below is an example of the steps to\r\ndeploy the driver block policy in enforcement mode.\r\nStep 1. Initialize the variables to be used in the script.\r\n1 $PolicyXML = \"$env:windir\\schemas\\CodeIntegrity\\ExamplePolicies\\RecommendedDriverBlock_Enforced.xml\"\r\n1 \"$DestinationBinary=$env:windir+\\System32\\CodeIntegrity\\SiPolicy.p7b\"\r\nStep 2. Run the following to convert the XML file to binary in an elevated PowerShell host.\r\n1 ConvertFrom-CIPolicy $PolicyXML $DestinationBinary\r\nStep 3. Deploy and activate the driver control policy using Windows Management Instrumentation (WMI).\r\n1\r\nInvoke-CimMethod -Namespace root\\Microsoft\\Windows\\CI -\r\nClassName PS_UpdateAndCompareCIPolicy -MethodName Update -Arguments @{FilePath =\r\n$DestinationBinary }\r\nLearn more\r\nFor more information about deploying WDAC policies, see the Microsoft documentation Deploy WDAC policies using\r\nscript.\r\nhttps://www.microsoft.com/security/blog/2021/12/08/improve-kernel-security-with-the-new-microsoft-vulnerable-and-malicious-driver-reporting-center/\r\nPage 5 of 6\n\nIn addition to kernel-mode block and allow rules, rules can also be created for user-mode software. See our Microsoft\r\nrecommended block rules for more information. For general information about WDAC technology and policies, please see\r\nthe Windows Defender Application Control official documentation.\r\nIf you are a driver developer, follow the driver security checklist and the development best practices to reduce the risk of\r\nsecurity vulnerabilities. You can also open a driver analysis case through the new Vulnerable and Malicious Driver\r\nReporting Center.\r\nIf you have questions about the program or suspect a driver is vulnerable or malicious, please\r\ncontact vulnerabledrivers@microsoft.com.\r\nTo learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert\r\ncoverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.\r\n1CVE-2008-3431, CVE Details. 11 October 2018.\r\n2CVE-2013-3956, CVE Details. 22 August 2013.\r\n3CVE-2009-0824, CVE Details. 10 October 2018.\r\n4CVE-2010-1592, CVE Details. 29 April 2010.\r\nSource: https://www.microsoft.com/security/blog/2021/12/08/improve-kernel-security-with-the-new-microsoft-vulnerable-and-malicious-driver-reporting-c\r\nenter/\r\nhttps://www.microsoft.com/security/blog/2021/12/08/improve-kernel-security-with-the-new-microsoft-vulnerable-and-malicious-driver-reporting-center/\r\nPage 6 of 6", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://www.microsoft.com/security/blog/2021/12/08/improve-kernel-security-with-the-new-microsoft-vulnerable-and-malicious-driver-reporting-center/" ], "report_names": [ "improve-kernel-security-with-the-new-microsoft-vulnerable-and-malicious-driver-reporting-center" ], "threat_actors": [ { "id": "c1ac2a5e-0225-47a4-8ac5-5fa898c96bde", "created_at": "2023-01-06T13:46:38.472883Z", "updated_at": "2026-04-10T02:00:02.989134Z", "deleted_at": null, "main_name": "ProjectSauron", "aliases": [ "Sauron", "Project Sauron", "G0041" ], "source_name": "MISPGALAXY:ProjectSauron", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "a97fee0d-af4b-4661-ae17-858925438fc4", "created_at": "2023-01-06T13:46:38.396415Z", "updated_at": "2026-04-10T02:00:02.957137Z", "deleted_at": null, "main_name": "Turla", "aliases": [ "TAG_0530", "Pacifier APT", "Blue Python", "UNC4210", "UAC-0003", "VENOMOUS Bear", "Waterbug", "Pfinet", "KRYPTON", "Popeye", "SIG23", "ATK13", "ITG12", "Group 88", "Uroburos", "Hippo Team", "IRON HUNTER", "MAKERSMARK", "Secret Blizzard", "UAC-0144", "UAC-0024", "G0010" ], "source_name": "MISPGALAXY:Turla", "tools": [], "source_id": "MISPGALAXY", "reports": null } ], "ts_created_at": 1775434563, "ts_updated_at": 1775791981, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/3ded51d407728e8625ea2c574c86ec3c10ba8d6f.pdf", "text": "https://archive.orkl.eu/3ded51d407728e8625ea2c574c86ec3c10ba8d6f.txt", "img": "https://archive.orkl.eu/3ded51d407728e8625ea2c574c86ec3c10ba8d6f.jpg" } }