Monday, August 31, 2015

JScript .NET Who Cares & Its Not As Bad As You Think...

tl;dr This is not client side arbitrary shellcode execution.

Recently I released a Proof Of Concept Script to demonstrate executing shellcode via JScript .NET.

Why?

I just wanted to see if it could be done.

JScript .NET is a .NET programming language developed by Microsoft. It allows you to compile binaries using the jsc compiler provided with the .NET framework. The compiler is found in places like:

C:\Windows\Microsoft.NET\Framework\v2.0.50727\jsc.exe Shellcode.js
C:\Windows\Microsoft.NET\Framework\v4.0.30319\jsc.exe Shellcode.js

This produces a binary called Shellcode.exe, which is new and untrusted and will get blocked by any Application Whitelist.

Why bother doing this?

I wanted to learn.  To see what it would take to work, and see if there are any other applications.

Turns are a couple useful applications:

1. Embed the JScript into an ASPX application, to achieve server side execution/persistence
    Seen Here: JScript Aspx Integration
2. Use of the eval function for dynamic execution and obfuscation.
3. JS files can pass many filters and then be compiled locally.

So there you have it. I wanted to see if I could use reflection to access native api functions via JScript .NET.

It is possible.




So, its not as bad as you may be thinking.

Cheers!

Casey
@subTee


Thursday, August 27, 2015

Hiding In Plain Sight - COM Surrogate Application Whitelisting Bypass & Persistence

dllhost.exe


What exactly are all those Dllhost.exe processes and What are they doing?

Best description I have found to describe what is happening here:

"The dllhost.exe process goes by the name COM Surrogate ... What is this COM Surrogate...?
The COM Surrogate is a fancy name for Sacrificial process for a COM object that is run outside of the process that requested it. Explorer uses the COM Surrogate when extracting thumbnails, for example. If you go to a folder with thumbnails enabled, Explorer will fire off a COM Surrogate and use it to compute the thumbnails for the documents in the folder. It does this because Explorer has learned not to trust thumbnail extractors; they have a poor track record for stability. Explorer has decided to absorb the performance penalty in exchange for the improved reliability resulting in moving these dodgy bits of code out of the main Explorer process. When the thumbnail extractor crashes, the crash destroys the COM Surrogate process instead of Explorer.
In other words, the COM Surrogate is the I don't feel good about this code, so I'm going to ask COM to host it in another process. That way, if it crashes, it's the COM Surrogate sacrificial process that crashes instead of me process. And when it crashes, it just means that Explorer's worst fears were realized."

Again, Dllhost is a trusted signed binary that executes other binaries.  So, it is a candidate for Whitelisting bypass. With the added bonus of being a persistence mechanism.

I wrote a Proof Of Concept here: [Updated]

Basically, this is just going to execute some shell code once we register the COM+ Application.

1: [.NET SDK]     sn.exe key.snk 

2:  C:\Windows\Microsoft.NET\Framework\v4.0.30319\csc.exe /r:System.EnterpriseServices.dll /keyfile:key.snk /target:library /out:dllguest.dll dllguest.cs

3: [As Administrator]     C:\Windows\Microsoft.NET\Framework\v4.0.30319\regsvcs.exe dllguest.dll

4: [From PowerShell]     $b = New-Object -ComObject dllguest.bypass
         OR
    [From VBScript]         Dim obj
                                         Set obj = CreateObject("dllguest.Bypass")
5. [Jscript]
                                       var o = new ActiveXObject("dllguest.Bypass");

6. [Poweliks Like]
rundll32.exe javascript:"\..\mshtml,RunHTMLApplication ";o=new%20ActiveXObject("dllguest.Bypass");


Here is one place you can find the registered COM service:


It does require Admin rights to install the COM+ Application. And all this example does is execute shellcode. Feel free to explore other aspects of COM Surrogate persistence. There is quite a bit more here.

When was the last time you checked your workstation for a COM+ Application.  Further more, if the target system is running a tool like Sysmon

They will see TONS of entries for dllhost.exe.  They look like this:


So there you go.  Blend in with the noise, bypass all the things.  Camouflage is a way for hunters to blend in with the terrain.  Dllhost.exe certainly helps you blend in with the system noise.

This works brilliantly with a Meterpreter Reverse Shell.



So there you go.  Until next time






Cheers!

Casey 
@subTee






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:
https://github.com/subTee/ShmooCon-2015
Video #39 Whitelisting Evasion
https://archive.org/details/shmoocon-2015-videos-playlist#

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)

InstallUtil.exe

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:

[System.ComponentModel.RunInstaller(true)]

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.  

How? 

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.
https://gist.github.com/subTee/00cdac8990584bd2c2fe

2. This example just executes shellcode. Pretty straight forward stuff.
https://gist.github.com/subTee/a06d4ae23e2517566c52

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


Cheers!

Casey
@subTee