Forum Discussion
Custom Exploit Guard Rules Occasionally Ignored
We're having a lot of issues with deadlocks that I'm convinced are somehow related to mitigations that Windows Defender ATP Exploit Guard is taking. In an effort to rule this out, I've started writing some custom rules to bypass app-specific mitigations for certain processes. For no reason at all that I can discern, the rules are sometimes ignored. For example, I want to audit only any Win32k system calls for the AcroCEF.exe process so my rule is as follows --
After a reboot, to make sure that the settings have been applied before any AcroCEF.exe process instances are started, I see the 7 entries in the Microsoft-Windows-Security-Mitigations/Kernel Mode log in a span of 2 seconds --
Process '\Device\HarddiskVolume2\Program Files (x86)\Adobe\Acrobat DC\Acrobat\AcroCEF\AcroCEF.exe' (PID 7388) would have been blocked from making system calls to Win32k.sys.
Process '\Device\HarddiskVolume2\Program Files (x86)\Adobe\Acrobat DC\Acrobat\AcroCEF\AcroCEF.exe' (PID 6476) would have been blocked from making system calls to Win32k.sys.
Process '\Device\HarddiskVolume2\Program Files (x86)\Adobe\Acrobat DC\Acrobat\AcroCEF\AcroCEF.exe' (PID 4728) was blocked from making system calls to Win32k.sys.
Process '\Device\HarddiskVolume2\Program Files (x86)\Adobe\Acrobat DC\Acrobat\AcroCEF\AcroCEF.exe' (PID 11168) would have been blocked from making system calls to Win32k.sys.
Process '\Device\HarddiskVolume2\Program Files (x86)\Adobe\Acrobat DC\Acrobat\AcroCEF\AcroCEF.exe' (PID 12092) was blocked from making system calls to Win32k.sys.
Process '\Device\HarddiskVolume2\Program Files (x86)\Adobe\Acrobat DC\Acrobat\AcroCEF\AcroCEF.exe' (PID 10404) would have been blocked from making system calls to Win32k.sys.
Process '\Device\HarddiskVolume2\Program Files (x86)\Adobe\Acrobat DC\Acrobat\AcroCEF\AcroCEF.exe' (PID 7496) would have been blocked from making system calls to Win32k.sys.
Sorry for the formatting -- this forum doesn't seem to give a good code option.
As you can see, 5 of the the AcroCEF.exe instances were audited and not blocked, as expected, but 2 were blocked. What would explain that behavior?
simcpk Did you ever figure this out? We noted the ProcessCommandline is different.
C:\Program Files (x86)\Adobe\Acrobat DC\Acrobat\AcroCEF\AcroCEF.exe" --type=renderer is blocked
"C:\Program Files (x86)\Adobe\Acrobat DC\Acrobat\AcroCEF\AcroCEF.exe" --type=utility is allowedeappelboom I never got any further with this. Fortunately for us, our deadlocks disappeared just as mysteriously as they started so I was able to move on. I am still curious as to why that behavior existed and my only guess is that they may have been filtering the calls to win32k.sys based on the actual functions they were using and knew some to be "safe". As you mentioned, it was when passing the --type=renderer parameter that it was getting blocked which would align with what I think I understand about the filtering mechanism, since it's the GUI threads that are blocked. When passing (what sounds like) a non-GUI thread, the call was allowed.
More reading:
mtth-bfft/win32k-mitigation: A test project to try the new win32k.sys system call filtering mitigation in Windows 10 (github.com)
Win32k System Call Filtering Deep Dive — Improsec | improving security
