Using Defender Vulnerability Management to patch vulnerabilities

4 min readDec 21, 2023

I’ve spoken about MDVM before. This is a more specific discussion about it’s use to find vulnerabilities.

The alerts

Defender Vulnerability Management allows us to have a general view of the vulnerabilities in our environment or even a device-specific view.

These com in play and add up to what’s called “Exposure Level”. A metric that can be utilized to drive your Infosec program, for example.

If you’re looking at someone’s specific machine, you can find the machine under Devices → (Hostname) → Software Inventory. Check out the example below:

You can also see the threat context, which includes information about the existence of public exploits for each given vulnerable software from the inventory list.

If you can on any entry you can learn about the file path of the software and more details about the measured “Impact” of the software vulnerability. This can be seen below:

The User update conumdrum (if not Enterprise managed)

Solution is naturally to update or remove the software.

Updating software should be trivial for enterprise and centrally managed devices. However, for personal devices, it might not be that simple, here are a couple examples.

Having to Check “Windows’ Optional Updates”

If you’re managing your fleet manually, for small lab or VMs, for example. You’ll have to trigger updates yourself or let windows do that for you.

Some software though, have to be checked manually for “Optional Updates” under Windows Update → Advanced Options.

This creates a challenges for manually updating multiple devices as you’ll have to check each for these.

Another challenge this might cause, is that sometimes, reported out of date packages by MDVM might not be listed under “Windows’ Optional Updates”. As seen below.

Luckily, information online from Microsoft can help us find how to solve this. Check out the next section.

Software not “installed”

One of the beauties of MDVM is that not only does it look for Applications in your “installed” repo, it actually scans your entire device for executeables and apps available to the user/system. One such example is this report from MDVM in my lab, which found a libwebp under a razer installer folder, something that was not installed in the device, but that still presented a vulnerability — the only mitigation possible here is to delete the file outright and ensure this is unavailable in the system.

This Vulnerability could lead to a breach, since there are public exploits available for variations of it, as hackernews reported.

Of course, defender in depth controls would help us block this file in other layers/means — such as add it to an application blocklist if so we desired.

The solution

Understanding the relevance and usage of this software in the device can be a first step.

Of course, MDE is an EDR, so we can poll devices for software usage events.

Here’s the query I used for this (and it’s available in my github):

DeviceFileEvents
| where Timestamp > ago(30d)
| where InitiatingProcessFolderPath contains "C:\\Program Files"
| summarize arg_max(Timestamp, *) by DeviceId

This spits out Details on file creation / update from that initiating Process folder Path:

So we can determine if the desired software is performing activities, and which they are. If none are found in a large time span, we can safely assume the impact of removing it manually won’t be massive.

After a few minutes/hours (depending on the size of the disk of the machine and communications with the Defender XDR cloud) you’ll have the vulnerability removed from MDVM’s list and the device exposure level downgraded.