Monday, August 24, 2015

Application Whitelisting Evasion 101 - Trusted Things That Execute Things "InstallUtil.exe"

I'm not much of a blogger/writer. But I think this topic warrants open discussion. So here goes my first attempt to articulate what I have been talking about.

I have given a couple talks on this topic:
Video #39 Whitelisting Evasion

Despite my bypass "gimics", is Whitelisting an effective Defense?

I still think it works well against opportunistic attacks.  However, the modern adversary has many techniques at their disposal to circumvent these types of controls. Even if they running as Kernel Mode Drivers.

Those of you who have have heard my talk, will recognize these tactics, but I wanted to put them down in a blog for wider discussion.

There are a number of "Trusted Things That Execute Things".  This, based on my research is one of the big gaps in Whitelisting.  If you are a defender, you need to be aware of them.

My favorite bypass techniques (so far)  are, in no particular order:
1. InstallUtil.exe
2. PowerShell (Future Blog)
3. Exploit/Migrate (Future Blog)
4. WMI Providers  (Future Blog)
5. COM Surrogates  (Future Blog)


This file is one of my favorites of late. It is found in the .NET directory. It takes a .NET assembly as a parameter and locates the class that is properly decorated with the attribute:


Once executed, InstallUtil locates the Install or Uninstall function in the provided assembly.  You can specify this in the call.  Install is default. Uninstall can be called with the "/U" parameter. 

There is something a bit magical about this utility.  It circumvents nearly all Whitelisting applications.  


Because it loads the assembly in a manner that allows us to bypass the prescribed manner that vendors use to block execution events.

What the hell does that mean?  

The point at which execute operations are detected only read-only access to the section is requested. Later, execute access is requested which results in the image being mapped as EXECUTE_WRITECOPY and subsequently allows unchecked execute.

Microsoft has stated here:

Based on my limited understanding here. What we found is a tool that loads Assemblies with Read Permission, and LATER changes the permissions to Execute.  This is contrary to the guidance provided for how to block executable code.

So, in order to demonstrate the full capabilities of this tool I began to explore its functionality.

Here are a couple examples:
1. This example will load Mimikatz inside of the process space of InstallUtil.exe
 This is incredibly shitty code that I wrote one afternoon to see if I could get it to work. It is heavily customized to load the Mimikatz executable, it does not run arbitrary binaries like Invoke-ReflectivePEInjection, but it does work.

2. This example just executes shellcode. Pretty straight forward stuff.

There are several other techniques and fun things you can do with InstallUtil.

- It accepts Parameters for example /DecryptionKey="pass"
- It can be used to create Janus/Two-Face binaries.  Binaries that have 2 distinct behaviors.  One that is exhibited when called by Main(), and another when you Invoke the same binary with InstallUtil.exe

Something like this:

You would then first, compile the binary.
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe /out:PELoader.exe PELoader.cs

This can get caught by systems if you try to outright execute the new file.  Notice the 'Access Denied'.  However, if I invoke the same file like this:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtil.exe /logfile= /LogToConsole=false /U PELoader.exe
I get the file to execute just fine.

Ok, Got it?

.NET reflection mastery is a powerful way to circumvent Application Whitelising.

Like this guy:

So, there it is my first blog.  Some of you have heard this before, for others, especially defenders, I hope you will carefully watch out for InstallUtil.exe



No comments:

Post a Comment