Bypassing Application Whitelisting using MSBuild.exe - Device Guard Example and Mitigations

I’ve said it before, but when you start down the road of Application Whitelisting, you need to take the extra steps to look at the functionality of the applications you are trusting, and see if they come with “extra features”.

By using signed Microsoft binaries, and injecting code into them, we effectively cloak our binaries so that they can execute, even under the watchful eye of Device Guard.

It is important to realize; this is a misplaced trust bypass.  The product works fine, in fact, you can even use Device Guard to mitigate against this bypass. See details below.

Device Guard is a new addition and is very effective at mitigating untrusted code. Please don’t mistake this bypass as a reason to dismiss this defense.  I highly recommend Device Guard to organizations.  For additional information, you can watch this talk:

In May of this year, I started looking into a way to bypass Device Guard. I like to start with default utilities that may be able to execute code as they are often implicitly trusted.  None of my previous AppLockerbypasses would work against Device Guard, so it was time to try something new.

I built up a base Windows 10 Enterprise Workstation.  An example Device Guard configuration can be found here by Matt Graeber (@mattifestation):

I found a Microsoft signed tool called MSBuild.exe. This is a default .NET utility that ships with Windows. I usually start with the question; ‘HOW could I get MSbuild to execute code for me?’.

Turns out, MSBuild.exe has a built in capability called “Inline Tasks”.  These are snippets of C# code that can be used to enrich the C# build process.  Essentially, what this does, is take an XML file, compile and execute in memory on the target, so it is not a traditional image/module execution event.

If you trust MSbuild on your system, or if it gets picked up in a “Gold” Image for Device Guard, it can be used to execute arbitrary binaries. 

Inline Task Reference:

So, I wrote a quick POC to make sure I could get my code to execute on the system, before going too far down the road.

Once I knew the code would execute via MSbuild.exe, I set out to wrap Mimikatz into a file to allow it to execute inside of MSBuild.exe. This wasn’t too hard, since I had done something like this for InstallUtil.exe last year.  I also wrote a utility to remove PowerShell Constrained Language mode, if needed.

Examples:  Tested on Windows 10 x64 Only - 

You will need to monitor execution of this tool in your environment. It is my belief, that you will likely not need this tool on devices that run Device Guard, but it will be up to you to monitor execution events to determine that.  Tools like Sysmon or even Device Guard in Audit Mode.

Also monitoring 4688 events

One documented mitigation solution using Device Guard is to follow the guidance in Matt’s blog reference below to be certain that untrustworthy binaries don’t execute.

Matt has also created a sample configuration to block these types of binaries.  This can be found here:

Here is what I have been trying to say for some time…"If you authorize things to run that that can then be used to run arbitrary code, then it can bypass many whitelisting applications. This means for a real lockdown administrators need to block these types of binaries.  MsBuild.exe being the latest in a growing list of default tools that behave this way."

That’s all I have for today.

Cheers,

Casey

@subTee