Thursday, October 13, 2016

Using Application Compatibility Shims

There have been number of blog posts and presentations on Application Compatibility Shims in the past [See References at End].  Application Compatibility is a framework to resolve issues with older applications; however, it has additional use cases that are interesting. For example, EMET is implemented using shims[1,2]. Please see the Reference section below for additional reading and resources.  In short, this document will focus on the following tactics: injecting shellcode via In-Memory patches and injecting a DLL into a 32bit process, and lastly, detection and shim artifacts will be discussed.  An In-Memory patch has this advantage over backdooring an executable: it this preserves the signature and integrity checks.  This technique can also bypass some Application Whitelisting deployments.  AppLocker, for example, would allow the startup of a trusted application, and then an In-Memory patch could be applied to alter the application.

Shim Installation:
The shim infrastructure is built into Windows PE loader. Shims can be applied to a process during startup. There is a two-step process that I will refer to as “Match and Patch”.  The Match process checks the registry on process create and looks for a relevant entry. If an entry is found, the Match process further checks the associated .sdb file for additional attributes, version number for example.  Based on my understanding, the sdb does need to be present on disk. I have not encountered any tactics to load an sdb file from memory or remotely. When the Shim Databases are installed they are registered in the registry at the following two locations:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Custom
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\InstalledSDB

These entries can be created manually, using sdb-explorer.exe, or using the built-in tool sdbinst.exe. If you use sdbinst.exe there will also be an entry created in the Add/Remove Programs section. In order to install a shim, you need local administrator privileges.

An example of a shim entry would look like this:

Once the shim has been installed, it will be triggered upon each execution of that application. Remember, there is further validation of the executable inside of the sdb file. For example, matching a specific version or binary pattern. I have not found a way to apply a shim when a DLL is loaded, or apply a shim to an already running process.  These registry keys plus the actual sdb file are the indicators for the Blue Team that a shim is present.  

Shim Creation and Detonation:
There are two tools we can use to create shims. First, the Microsoft provided Application Compatibility Toolkit (ACT).  Second, the tool created by Jon Erickson, sdb-explorer.exe.  ACT will allow us to inject a DLL into a 32-bit process, while sdb-explorer allows us to create an In-Memory binary patch to inject shellcode. The ACT has no ability to parse or create an In-Memory patch. This can only be done via sdb-explorer.

There is an excellent walk-through here on creating an InjectDLL Demo.

For the remainder of this document, we will focus on using sdb-explorer to create and install an In-Memory patch.

My testing seems to indicate this will not work on Windows 10.  This tactic will only work on Windows versions <= 8.1.  I could be wrong about this, so please share any insight if you have it.

There are two approaches you can take with sdb-explorer.  First, you can simply Replace or write arbitrary bytes to a region in memory. Second, you can match a block of bytes and overwrite. There are advantages and disadvantages to both approaches. It is worth noting that this method of persistence will be highly specialized to the environment you are operating in. For example, you will need to know specific offsets in the binary   

For this to work, we need an offset to write out shellcode to. I like to use CFF Explorer.

Here we are going to target the AddressOfEntryPoint. There are other approaches as well.  The drawback to this approach is the application doesn’t actually execute. In order to do that you would need to execute your patch and then return control to the application.  I leave that as an exercise for the reader.

Once we have the offset, we can use the syntax provided by sdb-explorer to write our shellcode into the process at load time.

If we break down the syntax, it is pretty easy to understand.

Line 7. 0x39741 matches the PE Checksum. This is in the PE Header.

Line 8. 0x3689 is the offset of our AddressOfEntryPoint.  What follows is just stock shellcode to execute calc.

Once our configuration file is created, we “compile” or create the sdb.
sdb-explorer.exe –C notepad.conf –o notepad.sdb.

Then install it:

sdb-explorer.exe –r notepad.sdb –a notepad.exe

You can also use:

sdbinst –p notepad.sdb.

In either case it requires local administrative rights to install a shim.

Notepad.exe is nice. But more likely shim targets would be explorer.exe, lsass.exe, dllhost.exe, svchost.exe. Things that give you long term persistence. Of course your shellcode would need to return control to the application, instead of just hijacking AddressOfEntryPoint.

Shim Detection:
There are two primary indicators that a shim is being used. First, the registry keys mentioned above.  Second, the presence of the .sdb file. The presence of the .sdb file is not necessarily bad, it would be wise to build a baseline to understand which shims your organization uses and which would be an indicator. There was a good example of detecting shim databases given here:  Hunting Memory, on slide 27.  Also, some shim registration activity can be recorded in the Microsoft-Windows-Application-Experience-Program-Telemetry.evtx.




Wednesday, September 28, 2016

Application Whitelisting Bypass - CSI.EXE C# Scripting

We’ve seen it before, where attackers can bring signed trusted tools to your system to expand functionality.  Attackers can bring tools signed by any vendor you may have approved in your whitelist.  Administrators often approve files at the publisher level to ease deployment.

Below is an example of bringing a signed, vulnerable driver to bypass kernel mode protections.

Recently, Matt Graeber (@mattifestation) demonstrated the ability to bypass Device Guard by bringing a signed debugger (windbg, cdb) to the system.

C# Scripting - hosted inside of csi.exe is another example of a signed tool that can be repurposed to bypass user-mode code integrity.  

“Before delving into the details of the new C# scripting, it’s important to understand the target scenarios. C# scripting is a tool for testing out your C# and .NET snippets without the effort of creating multiple unit testing or console projects. It provides a lightweight option for quickly coding up a LINQ aggregate method call on the command line, checking the .NET API for unzipping files, or invoking a REST API to figure out what it returns or how it works. It provides an easy means to explore and understand an API without the overhead...”

Basically, you can have C# code interpreted interactively, this is actually a great way to learn the language.  

In the example below I demonstrate the ability to load an arbitrary exe into csi.exe. This can be loaded from a basic text file. This is done on a PC running Windows Device Guard.

Screen Shot 2016-09-26 at 9.17.09 AM.png

using System;
using System.Reflection;

string s = System.IO.File.ReadAllText(@"katz.txt");
byte[] b = System.Convert.FromBase64String(s);
Assembly a = Assembly.Load(b);
MethodInfo method = a.EntryPoint;
object o = a.CreateInstance(method.Name);
method.Invoke(o, null);

Where katz.txt is the base64 encoded image file / assembly you wish to execute.

Again, this is misplaced trust, we need to trust many of the binaries signed by Microsoft. But not all of them...

An adversary would need to bring csi.exe + some dependencies, all said about 6MB, uncompressed.  I leave it to the reader to discover what those might be.

There is a great mitigation example for Device Guard to block “untrustable” sponsoring executables like this here:

Please refer to this list here:

For continued updates of bypasses that are discovered.

Screen Shot 2016-09-26 at 9.29.54 AM.png

That’s all I have for today,



Tuesday, September 13, 2016

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 AppLocker bypasses 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 - 
1.)   Hello World!
2.)   Remove Constrained Language Mode in PowerShell
3.)   Mimikatz Execute -
b.)   Note: This simply executes Mimikatz, it does NOT bypass Credential Guard.

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."

If you find these types of files, help us catalog how they work and we can deploy proper mitigations. I will be posting these only when I have the vetted mitigation details ready for defenders.

Proof of Concept Video:  With Music ;-)

That’s all I have for today.