For details on how the default rules works and how to implement them please see part 1 of the hardening posts here:

https://oddvar.moe/2017/12/13/harden-windows-with-applocker-based-on-case-study-part-1/

 

Hardening

In “AppLocker – Case study – How insecure is it really? – Part 2” we concluded that there is 1 definitive bypass technique that works and 2 possible ones. If you are concerned on blocking these executable’s I suggest that you implement the rule in Audit mode to uncover legitimate usage of the files.

 

MSHTA.exe

The definitive one was mshta.exe.
This is pretty easy to block and there are different approaches to this one.
The most common I see is that people change the association of .HTA files to notepad. Doing this is really simple using Group Policy Preferences. A guide on this can be found here: http://www.grouppolicy.biz/2011/09/how-to-use-group-policy-to-change-open-with-file-associations/

This means that .HTA files will be opened in Notepad instead. However this is not bullet-proof since you can serve .HTA files from a webserver and define MIME type and still get it executed.
Source: https://twitter.com/subtee/status/852687635172786176

The other way is to block mshta.exe in Windows. This can be done with a deny rule in AppLocker.

First you navigate to the Executable rules in your AppLocker policy and start a new rule:

 

Now click next until you see the permissions page. Here you need to set it to Deny like this:

Now click next until you come to the Publisher part. Here you will need to browse to the mshta.exe file located under C:\Windows\system32 :

Next you need to make sure that you target every version of mshta.exe by dragging the arrow up to “File name” like this:

Now just click next next until you are finished.

A deny rule should be in place and it should look something like this:

Now that the rule is in place you will need to make sure that the client receives his Group Policy first(run gpupdate).
If you are running this on a single machine using local policy you will need to restart the Application identity service.

 

Testing the deny rule

If I now try the mshta bypass that launched the empire stager it will look like this:

 

And the event log looks like this:

 

 

MSDT.exe and PresentationHost.exe

Since we are not 100% sure about these bypass I choose to create a block rule for these as well. The method is exactly the same as above, just change the binary with the correct one.

MSDT.exe is located in c:\windows\system32.
PresentationHost.exe is located in c:\windows\system32.