In my post about how insecure AppLocker really are we concluded that the only valid bypass technique (from the 7 I tested) was actually msbuild.exe. The next question is, how can we mitigate this to harden the default setup?

In this post I will cover how to go beyond the default rules in AppLocker and harden it to prevent msbuild.exe from working. I will explain different methods of mitigating using AppLocker. But before we dive into rule making, let me first explain the default rules in detail.

If you are wondering how to create the Default AppLocker rules you can read the first part of this blogpost:
AppLocker – Case study – How insecure is it really? – Part 1

or watch this GIF.
(Note that the gif assumes that you are in a domain environment. It is no problem doing this on a single host without a domain)

 

 

AppLocker Default Executable rules

These section is used to defined the rules around binary files (.exe and .com files) that are allowed to run.

The default executable rules looks like this:

The first rule named “(Default Rule) All files located in the Program Files folder” makes sure that everyone can execute any binary file located within “Program files” and “Program files(x86)”.
Let me show you the details behind the first rule just to give you the basics. I will not go over every rule in such detail, just this first rule.

If we open the rule you can see that it is defined like this:

The important part to notice from this screenshot is that the everyone group is used.

 

Notice the %PROGRAMFILES% variable. This is a special AppLocker variable. As you probably understand from the %PROGRAMFILES%\* path, it means that everything under programfiles can be executed.  %PROGRAMFILES% actually refers to both “Program files” and “Program files(x86)”

The complete AppLocker variable list can be found here:

https://technet.microsoft.com/en-us/library/ee460944(v=ws.11).aspx

Here is a screenshot of the important part:

This is pretty straightforward to understand.

The second rule named “(Default Rule) All files located in the Windows folder”, I will not cover in detail with screenshots. But the rule means that everything under C:\windows is allowed to execute.

The third rule named “(Default Rule) All files” is actually a rule created only for the users that are local administrator on the system. This means that if you are a local administrator you are allowed to execute everything on that system. This could be seen as a weakness, but if you are a local administrator on a Windows box, AppLocker is pretty easy to stop just by halting a service. The reasoning for this rule I think is to prevent lockout for admins.

 

 

AppLocker Default Windows installer rules

These section is used to defined the rules around windows installer files (.msi, .mst and .msp files).
The default Windows installer rules looks like this:

In this section we encounter our first Publisher rule. The rule named “(Default Rule) All digitally signed Windows Installer files” will allow every digitally signed Windows installer file to execute.

The publisher part looks like this inside the rule.

In theory this could be a valid bypass if you create a signed msi file that the client trusts. More on that in upcoming blogposts.

The rule named “(Default Rule) All Windows Installer files in %systemdrive%\Windows\Installer” will allow all installer files located within that folder to execute.

The rule named “(Default Rule) All Windows Installer files is created for administrator to allow them to install everything on the system.

 

 

AppLocker Default Script rules

These section is used to defined the rules around script files (.ps1, .bat, .cmd, .vbs and .js).

These rules are pretty basic I got a feeling if you read everything above about executable and windows installer rules you will get this one.

 

AppLocker DLL rules

These section is used to defined the rules around DLL files (.dll and .ocx).
The default DLL rules looks like this:

 

 

AppLocker Packaged app Rules

These section is used to defined the rules around packaged apps from the Microsoft Store (.appx).

The Package app Rules only allow Publisher rules to be defined. The one default rule allows every signed package app to run. This rule is very important on Windows 10, since the start menu is now a Package App you can actually prevent the start-menu from working if you do not have this rule in place.

 

Hardening

Okay, we have now covered the default rules pretty good. Now is the time where we define a rule prevent msbuild.exe from running. How do we do that? Well, the easiest way I have found is to create a deny rule based on its signature. To do this you first go into the executable section of your AppLocker policy and create a new rule with a right click like this:

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

Also notice that this is targeted to Everyone. If you want to create rules that only should target some parts of the organization you would configure it here using groups.

Now click next until you come to the Publisher part. Here you will need to browse to the msbuild.exe file located under C:\Windows\Microsoft.NET\Framework\V4.0.30319\ :

 

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

Hit next until you are finished.

You should now have a deny rule like this:

 

Thats it. Now to test it 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.

I thought I should also mention that you can create rules using PowerShell, I just choose not to cover that in this blogpost.

 

Testing the deny rule

If I now try to run the msbuild bypass again it will look like this:

I know what you are thinking… What if I rename that to something else? Just to show you that it does not matter what the file is named I created a copy of msbuild within the same folder and changed the name to MySecretCopyOfMSBuild.exe.

The results of execution looks like this:

And this is because it is looking on the digital signature of the file and not the actual file name.
The event log looks like this:

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