How to Use Microsoft 365 Defender and Sentinel to Defend Against Zero Day Threats: Part I

Quash New Threats Fast

Not a week goes by without the announcement of a new zero-day exploit that’s active in the wild. Every organization needs to be prepared for the next zero-day threat and have a process in place for how these vulnerabilities are investigated and mitigated.

In my job, I am responsible for our SOC (Security Operations Center) which delivers security services to customers, including vulnerability management. Recently, we encountered many zero-day threats that required mitigation (Log4J, HAFNIUM, ProxyShell…). This is the first installment of a two-part series that walks through a process to respond to zero-day threats, including the Microsoft capabilities you can use.

Four main steps mitigate a zero-day threat:

• Identify the impact of the zero-day on the environment.
• Detect abuse of the vulnerability.
• Implement Antivirus updates for additional detections (and possible protection).
• Mitigate vulnerability through product updates or configuration changes.

While I have put the steps in a specific order, this does not mean every vulnerability happens in that order. Sometimes, a vulnerability will have mitigation (fix) before Microsoft creates a detection capability.

Identifying the Impact

Identifying the impact of a vulnerability is often the most crucial step of the entire list. It will determine if the vulnerability impacts the organization, and what kind of impact to expect (there is a big difference between having one vulnerable machine and twenty).

To identify vulnerabilities, I pivot to Microsoft Defender Vulnerability Management (MDVM). This product is included in the Microsoft Defender for Endpoint license but can also be purchased separately. MDVM is supported on all operating systems (Windows, Linux, macOS, Android, and iOS), so it can identify vulnerabilities on all platforms.

The type of vulnerability controls how fast it appears in MDVM. Vulnerabilities in well-known applications such as Chrome, Windows, and Exchange are identified immediately. Looking back at Log4J, it took a day or two before proper identification happened. This was mainly because the vulnerability was not for a specific application but for a module in thousands of applications that Defender was not built for. I imagine Microsoft has updated its algorithms and can now identify all kinds of vulnerabilities quickly.

When Defender identifies a vulnerability, Microsoft gives an overview of every device impacted in the environment. After retrieving the list, it is up to you to check the actual impact on the environment. It is your job to augment the insights provided by MDVM and enrich them with business-specific information that can change the impact and the severity. A vulnerability on a server hosting the central ERP system is more critical than one affecting an end user’s device. The same goes for an internet-facing device, as these devices are more easily accessible compared to a device in an internal network.

Detecting Abuse of The Vulnerability

When a zero-day threat first appears, a patch is often unavailable. This is why it is essential to have detections in place that can identify active exploitation of the vulnerability. Creating detections is done through your XDR system (Extended Detection and Response, such as Microsoft 365 Defender and custom detections) or your SIEM (like Microsoft Sentinel). The choice of where to create detections (XDR or SIEM) depends on what product the vulnerability applies to and where the product logs are stored. For example, the latest Exchange vulnerability (named ProxyNotShell) can be monitored by checking the HTTP logs on Exchange servers. As product logs are not included in Microsoft 365 Defender, the detections must be created in a SIEM holding the HTTP data.

Creating detection rules based on vulnerabilities is not for everyone. Most of the time, it requires a test environment where you can simulate the attack and verify how the attack surfaces in logs. This requires both skill and adequate resources, which are not available to every organization. If you are such an organization, I recommend that you lean on the community and the official Microsoft blogs.

The Microsoft Security community is very active on both Twitter and LinkedIn. Detections are online for most vulnerabilities that can be used within detection systems (Microsoft 365 Defender or Microsoft Sentinel). The following sources are some I follow personally to stay up to date on new vulnerabilities:

• Kevin Beaumont – @GossiTheDog
• Alex Verboon – @alexverboon
• SwiftonSecurity – @SwiftOnSecurity

Detections don’t provide any guarantees and should be adequately tested before being put into production. To find official sources, check the official MRSC blogs published after the announcement of a new vulnerability. These blog posts are delayed compared to the detections created by the community but provide a more ‘official’ way of finding detection methods.

You might ask why should I bother creating detections. Are these not things that Microsoft Defender for Endpoint will monitor and detect (avoiding the need to make custom detections)? While the question is valid, it is difficult to answer as Microsoft Defender for Endpoint is a black box when discussing detections. Microsoft does not provide a list of all detections included in the product. They do this to avoid the chance that attackers might reverse engineer detections to identify gaps. This means there is no 100% sure way to know when and if Microsoft adds detections.

Implementing AV/EDR Updates

A few days after a vulnerability is announced, Microsoft will release new signature updates, providing detection and prevention capabilities for this new vulnerability (Figure 1). This applies to both the Antivirus (Microsoft Defender Antivirus) and EDR (Endpoint Detection and Response – Microsoft Defender for Endpoint). Often, these updates are shared on the same MRSC blogs as the detections. When such an update is released, it is essential to update all endpoints across your environment as soon as possible.

The size of signature updates for Microsoft Defender Antivirus is minimal, and they are released at least every four hours. These updates should be treated independently of the regular Windows Update cadence as they must be rolled out much faster across the environment. I recommend having your endpoints and servers check Windows Update (on the internet) for signature updates rather than using an internal update server such as MEMCM or WSUS. The cadence of these signature updates is too rapid to allow an internal system to download the update and distribute it to all systems. Such an update strategy will only hinder you when dealing with an update to protect against a zero-day exploit.

If you have created an adequate update roll-out window, the only thing left to do is monitor the roll-out of a critical signature update. This can be achieved using the Microsoft Defender Antivirus report within Microsoft Endpoint Manager.

Looking Ahead to Part 2

While the first part of the blog focuses on detection, the second part will investigate mitigation and what processes need to be in place. Besides that, I will cover some helpful reporting capabilities to report the status of zero days to your higher-level management and discuss what products outside of the Microsoft stack, are useful.