Windows Defender – Enumeration via Pervasive Mechanisms

Microsoft recently released Windows Defender signatures that blocks ALL files that can open or execute (such as .lnk or .pdf or .txt) with the word “Invoke-Mimikatz”. If you tried to open a blank text file called “Invoke-Mimikatz.txt”, it would be flagged as a Trojan!

You might ask “What is Mimikatz”?

Mimikatz is just a Visual C program designed to dump Windows credentials from memory, perform pass-the-hash or construct Golden tickets. It is open source and you can find it on Github.

So from the perspective of Windows, Mimikatz is bad news and blocking it with Windows Defender would be a good idea. However the way to go about this has been all wrong. 

The problem with blocking just a word is that it now creates a plethora of false-positives and wreaks havoc with the SIEM and SOC team (SORRY BLUE TEAM!!)

For instance, we can even target this pervasive mechanism through a wireless SSID name, causing a Trojan detection in a trusted windows process “netsh.exe”.

 

 

However the main topic of this post is Enumeration, not just annoyance factors such as that above.

Say a file called “test.pdf” was uploaded to a portal designed to accept information and that portal was running the latest Defender rules.

Once the upload was successful the file can be renamed to “Invoke-Mimikatz.pdf” and re-uploaded.

Was an error raised? Congratulations you’ve just enumerated the fact that the portal is running latest Windows Defender rules and opens or scans uploaded files!

 

This problem isn’t just isolated to Windows Defender, there will always be other systems at play that employ pervasive mechanisms to user inputs.

In the long run, this can more detrimental than helpful.

So the takeaway is this: Be specific with your rule-sets, not pervasive!

Leave a Reply

Your email address will not be published.