This blog will be about why sometimes the Windows Microsoft Defender event log, does not show you everything you want! For example notifications about ASR rules!

I will divide this blog into Multiple parts

1. The Issue
2. Troubleshooting the Issue
3. Microsoft Defender Logs
4. Solving the Issue
5. ASR rules Active on Windows 1607

1. The Issue

Today I was called in to take a look at a weird excel addin error. Suddenly on all Windows 2016 Remote desktop servers from a specific customer, they got the following error when opening excel:

“Access Denied to folder”

The first thing that will come to mind, is looking at the latest Windows and Office patches that have been installed. And so I did, after removing all the latest patches within a test environment the problem remains. So, I excluded patching problems.

2. Troubleshooting the Issue

What’s next? AppLocker logs also didn’t show any blockades, so my second thought was the antivirus. I opened the Windows Defender / operational log to check if Windows Defender ASR could be blocking something

but I didn’t encounter anything that pointed me in the right direction. Looking at Microsoft-Windows-Windows Defender/Operational I was expecting these events: 1121, 1122 or 5007. As shown below….. nothing!

But I was pretty sure Defender was blocking these actions, why do you think? Because when you don’t know exactly what is happening with a process, you need to run Procmon, so I did. Running Procmon showed me the Defender MsMpEng.exe process each time when turned on this addon.

3. Microsoft Defender Logs

It’s a good thing Microsoft Defender also logs his actions somewhere else, it also uses a plain text file called MPLog which you can find in the C:\ProgramData\Microsoft\Windows Defender\Support folder.

Opening this text file showed me some more information.

Block on rule 0x3b576869-…, State=1, Inheritance=0x0, Parent=”C:\Program Files (x86)\Microsoft Office\Office16\EXCEL.EXE”, ParentCmdline=””, Target=”C:\Users\superuser\AppData\Local\Temp\34\Deployment\VH0GGBT9.QR1\EE2X5TET.NY5.application”, TargetCmdline=””, InvolvedFile=””

So, a “rule” is blocking this process suddenly? Without proper event logs? Searching for 0x3b576869 resulted in zero results but searching for 3b576869, showed me some more results.

So the asr rules starting with 3b576869 is just the “block Office applications from creating executable content”

4. Solving the Issue

So let’s exclude Microsoft Excel for now from the ASR rules to be for sure if this one is causing all of the issues!

Add-MpPreference –AttackSurfaceReductionOnlyExclusions "C:\Program Files (x86)\Microsoft Office\Office16\excel.exe"

After adding this exclusion, the AFAS Excel plugin was working again. That’s the first and most important result but… I really wanted to know why there weren’t any logs in the Defender operational log.

The first place to look when you suspect Defender is not logging anymore would be:

HKLM\System\CurrentControlSet\Control\WMI\Autologger\DefenderAuditLogger

“Start” has to be configured to 1.

As shown above, “start” has the correct value so what else is happening? But then I realized something…

UPDATE. Of course, at this moment Windows 2016 is supported!

https://docs.microsoft.com/en-us/microsoft-365/security/defender-endpoint/enable-attack-surface-reduction?view=o365-worldwide?id=5004252

And it is logging events!!!! (as it should)

5. ASR Active on Windows Server 1607?

So, you will need at least Windows Server 1803. But our servers were the 1607 version.

After some digging, I found out the ASR rules were automatically configured when the server was deployed even when ASR should not be available in this Windows version. To be 100% sure I installed the same software on a 2019 terminal server. Take a look at the Defender operational log below! Just as you expected, a nice warning.

But why out of the blue was it blocking this software with ASR? I still don’t know, the only thing I can guess is it looks like a combination of things.

The first one will be the antivirus engine upgrade some weeks ago in combination with the 2020-10 KB4580346 update last weekend.

Conclusion:

Only using the Windows event log for troubleshooting is not enough, use Procmon and look for other log files. It’s good to know Windows defender also has a nice plain text file to search in. Last but not least, it’s very nice to see ASR rules are working on Windows 2016 version 1607 even when event logging is not working as you’d expect.