Using One Defense to Mitigate Bypass of Another

I am a big fan of using several layers of defense, but it is even better if you can use one defense to mitigate the bypass of another. I have written about this a little before. I ran into one of those scenarios recently and wanted to share it because it ties in nicely with my previous entries for both Windows Firewall with Advanced Security (WFwAS) and AppLocker.

In my internet ramblings I happened across the following blog post by David Fletcher of Black Hills Information Security.

https://www.blackhillsinfosec.com/bypassing-cylance-part-4-metasploit-meterpreter-powershell-empire-agent/

The primary purpose of that post was on how they were able to get around a particular security tool. The approach was fascinating and surprisingly simple - rename or move powershell.exe and all of the protections that were intended for that executable will no longer work. This had me thinking - what would this do to WFwAS rules that limit powershell from downloading content from the internet? I immediately knew the answer. Windows firewall rules limiting powershell connections to the internet were limited to the path and executable name. This would go right around it and let the attacker do their business, even as a standard user!

In the words of US Brigadier General Anthony McAuliffe, "NUTS!"

I started thinking about how I would address this, and after a little while an idea came to me. What if I used an AppLocker deny rule to deny powershell.exe from every location except where it is expected to run (and where my firewall rules apply)? Let's get to work!

First I created an AppLocker executable rule set to deny to prevent PowerShell from running. It could be based off of a digital signature (preferred) or hash, but the hash would require maintenance for each version and each time the file was updated.

For the Publisher rule it is important that the File name is specified.

Next, I added an exception based off of the approved path location.

In this case, the exception location is %SYSTEM32%\WindowsPowerShell\v1.0\powershell.exe

That's it! Now to test.

Look at that beautiful red text! 

We can see here that the two technologies working together are effective at stopping this. Windows firewall stops the first attempt to use PowerShell to download external content, and AppLocker stops the workaround!

If possible, rules like this should be configured to ensure (by Publisher or Hash) that all executables with outbound WFwAS rules can only be run from their expected location to ensure that these are not trivially bypassed by moving or renaming the executables.

If a good list of allowed applications was in place this type of activity would be stopped in most cases. This rule could be added to an existing policy for extra assurance or to cover any loopholes in the existing policy. If AppLocker isn't configured in an environment, it would also be possible to configure a new AppLocker policy that did nothing else but block this particular workaround for any executables defined in WFwAS policies. It would just need a deny rule similar to what is shown above, as well as an Allow rule to allow everything else. (I wouldn't recommend this policy by the way, but it would be better than nothing if you were trying to protect WFwAS rules.)

Unfortunately this will only work on Windows Enterprise Edition, I was not able to find a way to do this with Software Restriction Policies. :-(

I think that this is a great illustration of the benefits of defense in depth, even at the endpoint level. If there are ways around a mitigation or a technology it doesn't necessarily mean that technology is no longer useful. It may just mean that we need to get creative and find ways to protect it with the tools available to us.

I have several exciting posts lined up, hopefully I will be able to get them published over the next few weeks.

Until then, work hard and spend time with your family.
Branden
@limpidweb