Forum Discussion

Brass Contributor

Apr 03, 2019

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 writi...

eappelboom

Copper Contributor

Sep 15, 2021

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 allowed

simcpk
Brass Contributor
Sep 15, 2021
eappelboom 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:
https://github.com/mtth-bfft/win32k-mitigation
https://improsec.com/tech-blog/win32k-system-call-filtering-deep-dive