Archive - Defender AV - Improving Windows Defender Update Efficacy

Today we're going to talk about the best (and worst) methods for Windows Defender definition/intelligence updates and how to configure them. This post from SwiftOnSecurity got me thinking about the way we handle our fallback for definition/intelligence updates, and while I was originally planning on a broader coverage of things like exclusions and other policy settings, this article alone started getting way too long :)

As the above tweet indicates, ConfigMgr is definitely not the best update tool for Windows Defender. We've traditionally used Windows Update as the primary update source and then relied on ConfigMgr/WSUS as fallback methods. While this works, it's pretty terrible because the following has to happen:

First, ConfigMgr tells WSUS to sync with Windows Updates, then it approves the definition update, then it downloads the definition update which means a new revision of the package which now needs to be replicated out to the distribution points. Once the agents on your clients check in and figures out there are updates available, they download the package to the client, kick off the install, and then the agent at some point will report back to ConfigMgr that updates have completed. To make this work effectively, Update Synchronization, Automatic Deployment Rule, and agent check-in must all be very frequent (plus dealing with timing windows), and then you end up looking like this:

Options for Update Sources

There are 5 updates sources available for Definition / Intelligence Updates: Microsoft Update, UNC file shares, WSUS, Configuration Manager, MS Malware Protection Center. That's actually the order of precedence that I use, and while everyone's situation may be different, I think it is helpful to define how each works, when and where we would rely on each, and why. For even more details on these, you can check the docs here: Sources for Defender AV

First up, we have Microsoft Update which has some common misconceptions around it. Many engineers do not choose this option because they are concerned about the network impact, but it's actually far more minimal than you would think. In addition to this, these updates are available outside of your network without having to expose systems to the Internet or tunnel clients back in. This is imperative in our modern "work from anywhere" architecture.

Since the agent knows the update version installed, it only pulls a small delta between the latest version and the version installed. The more frequently you update, the smaller these deltas are, and on average, my deltas have been around 250K per client. Scaled out to 10K machines, we're looking at 2.4GB of data per hour assuming all checked in and pulled down the content. I recommend setting clients to update definitions every 1 hour.

If bandwidth is truly a concern, we can look at UNC shares which not only reduces WAN bandwidth but can also reduce processing time on your endpoints. Essentially, we have a script running on a file server that downloads the latest definitions once, processes them, and the client can more easily consume these updates without having to do the processing or hitting the WAN. To scale, you can use DFS or simply add multiple UNC shares to the policy.

Microsoft has a great document on setting up UNC shares specifically geared toward VDI which I feel is a disservice to this method as it works extremely well for both virtual and non-virtual infrastructure (endpoints): Deployment Guide for Defender AV in VDI

I have loosely based the following content off this document with a few improvements. This method uses a scheduled task to download updates, and it's best practice to use a limited user account to run this. Here's how to set up a gMSA (requires RSAT AD PS modules on the file server), but you could alternatively use a limited service account.

#Powershell
New-ADServiceAccount -Name "gmsa-wdav" -RestrictToSingleComputer
Add-ADComputerServiceAccount -Identity "SERVER1" -ServiceAccount "gmsa-wdav"
Install-ADServiceAccount -Identity "gmsa-wdav"

Next, we need to create a share to host the files on and set permissions so that EVERYONE can read (share permission) and only the gMSA can modify (NTFS permissions). For the NTFS permissions, you will need to select Domain as the search location and enable Service Accounts under Object Types, search for the gMSA, and then give it Modify permissions:

Now, we need the following Powershell script (modified for your paths) saved to the file server:

#Paths
$vdmpath = 'C:\Shares\wdav-update\{00000000-0000-0000-0000-' + (Get-Date -format "yMMddHHmmss") + '}'
$vdmpackage = $vdmpath + '\mpam-fe.exe'

#Create content path
New-Item -ItemType Directory -Force -Path $vdmpath | Out-Null

#Download update
$ProgressPreference = 'SilentlyContinue'
Invoke-WebRequest -Uri 'https://go.microsoft.com/fwlink/?LinkID=121721&arch=x64' -OutFile $vdmpackage

#Extract update
Start-Process -FilePath $vdmpackage -WorkingDirectory $vdmpath -ArgumentList '/x'

#Cleanup previous update
$cleanup = (Get-ChildItem -Path C:\Shares\wdav-update -Directory).FullName
if ($cleanup.Count -gt 5) { Remove-Item -Path $cleanup[0] -Recurse -Force }

Next, we need to create the scheduled task (modify with the correct path to where you saved the script and service account name):

#Powershell
$action=New-ScheduledTaskAction -Execute 'powershell.exe' -Argument '-ExecutionPolicy Bypass -File "C:\Shares\wdav-update\wdav-download.ps1"'
$trigger=New-ScheduledTaskTrigger -Daily -At '00:15'
$principal = New-ScheduledTaskPrincipal -UserId "gmsa-wdav$" -LogonType Password
$settings=New-ScheduledTaskSettingsSet -ExecutionTimeLimit 0
$task = Register-ScheduledTask -TaskName "wdav-download" -Action $action -Principal $principal -Trigger $trigger -Settings $settings
$task.Triggers.Repetition.Duration = "P1D"
$task.Triggers.Repetition.Interval = "PT30M"
$task | Set-ScheduledTask

Running the scheduled task should download and extract content that will look like this:

Now we just have to set policy for the endpoints to use the UNC using your preferred method:
Group Policy
ConfigMgr
PowerShell
WMI...
MDM

The only downside here is that UNC's are usually not available externally, but who knows if this will end up changing things: SMB over QUIC

In any case, WSUS and Configuration Manager both have the same issue of availability, but they're worse in the syncing windows and having to maintain the WSUS database. For now, I'm leaving these as fallback options, but as we move more workloads into Intune, I think we'll be spinning these down over the summer.

The last option is to use the Malware Protection Center as a fallback, but by default, the agent only checks in after being out of date for more than 14 days 😱. While you can change this, I don't think it's worth it, and I'll rely on Microsoft Update and the new file share method.

If you work in K12 or higher ed, we'd love for you to join us on the OpsecEdu Slack. If you have any questions, please feel free to hit me up on Twitter or request an invite to the Slack channel by sending an email to [email protected] using your work email.