The Challenge: ASR Rule Blocking a Legitimate UEFI Firmware Update

Recently, I encountered an issue where a legitimate UEFI firmware update was blocked by an Attack Surface Reduction (ASR) rule on a notebook. The ASR rule, designed to block vulnerable signed drivers, flagged the firmware update as a potential threat. However, the incident was not visible in the Microsoft Defender console, making it difficult to identify and respond to the issue promptly. This lack of visibility posed a significant challenge, as it delayed troubleshooting and resolution.

The Solution: Custom KQL Query and Notification Rule

To address this issue and ensure that similar incidents would be visible in the future, I created a custom KQL query to monitor ASR rule events related to vulnerable signed drivers. I also enabled a custom detection rule to trigger notifications whenever such events occur. Here’s the KQL query I used:

DeviceEvents
| where ActionType in ("AsrVulnerableSignedDriverAudited", "AsrVulnerableSignedDriverBlocked")
| project
    DeviceId,
    Timestamp,
    ReportId,
    DeviceName,
    ActionType,
    FileName,
    InitiatingProcessAccountName
| order by Timestamp desc

Breaking Down the Query

• DeviceEvents: This table contains all device-related events in Microsoft Defender.
• ActionType filter: The query filters for ASR rule events specifically related to vulnerable signed drivers, including:
  • "AsrVulnerableSignedDriverAudited": Events where the ASR rule audited the action but did not block it.
  • "AsrVulnerableSignedDriverBlocked": Events where the ASR rule actively blocked the action.
• project: This step selects only the relevant fields for analysis, such as DeviceId, Timestamp, DeviceName, ActionType, and FileName.
• order by Timestamp desc: Ensures the most recent events appear at the top for easier monitoring.

Implementing the Notification Rule

https://learn.microsoft.com/en-us/defender-xdr/custom-detection-rules
After creating the query, I set up a custom detection rule in the Microsoft Defender portal to ensure timely notifications for similar incidents in the future. Here’s how I did it:

1. Navigate to Advanced Hunting: In the Microsoft Defender portal, go to the “Advanced Hunting” section.
2. Run the Query: Test the KQL query to ensure it retrieves the desired results.
3. Create a Custom Detection Rule:
   • Click “Create detection rule.”
   • Paste the KQL query into the rule configuration.
   • Set the rule to run at Continuous (NRT) – Runs continuously, checking data from events as they’re collected and processed in near real-time (NRT)
   • Configure the severity level (e.g., Medium or High for blocked events).
4. Enable Notifications: Configure the rule to send notifications

The Outcome

Once the custom detection rule was enabled, I started receiving notifications for ASR rule events related to vulnerable signed drivers. This allowed me to quickly identify the blocked UEFI firmware update and take appropriate action.

Lessons Learned

1. Visibility is Critical: Even when ASR rules are functioning as intended, the lack of visibility into blocked events can hinder troubleshooting and response. Custom KQL queries and notification rules are essential for bridging this gap.
2. Understand ASR Rules: ASR rules are highly effective at blocking malicious activity, but they can occasionally block legitimate actions, such as firmware updates. It’s important to understand the rules in place and their potential impact on your environment.

Conclusion

By leveraging custom KQL queries and detection rules, you can enhance your organization’s visibility into ASR rule events and ensure timely responses to legitimate actions that may be blocked. If you’re managing ASR rules in Microsoft Defender, consider implementing a similar approach to improve your incident detection and response capabilities. This proactive step will help you maintain a balance between security and operational efficiency.