In my internet ramblings I happened across the following blog post by David Fletcher of Black Hills Information Security.
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!"|
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.|
|In this case, the exception location is %SYSTEM32%\WindowsPowerShell\v1.0\powershell.exe|
|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 whitelisting policy 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.