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.



Saturday, September 10, 2016

Now For Something A Bit Different...

I had the chance to attend a non-security conference this week.  It was the Rocky Mountain Fiction Writers Conference.  Thanks to my good friend Warren Hammond we presented on Hacking. 

“Advice? I don’t have advice. Stop aspiring and start writing. If you’re writing, you’re a writer. Write like you’re a goddamn death row inmate and the governor is out of the country and there’s no chance for a pardon. Write like you’re clinging to the edge of a cliff, white knuckles, on your last breath, and you’ve got just one last thing to say, like you’re a bird flying over us and you can see everything, and please, for God’s sake, tell us something that will save us from ourselves. Take a deep breath and tell us your deepest, darkest secret, so we can wipe our brow and know that we’re not alone. Write like you have a message from the king. Or don’t. Who knows, maybe you’re one of the lucky ones who doesn’t have to.” 

I love that quote and it makes me consider what I blog about some times, the tone and the content...

It was good for me to engage in conversations and dialogue COMPLETELY out of my normal infosec circles.  I had the chance to attend a session on "Weapon Systems Of The Future" For Science Fiction writers. 

I was struck by the conversation about how much imagination drives reality.

Here is a basic example:

I was struck with the idea, what are imagining for offense and defense.  What will our attacks and defense look like in 10-15-25 years.  

Its hard to know for sure. 

I just wonder what role does our ability to use our imagination and creativity to block/detect certain attacks.  It may not exist yet, but "What if IT DID."  And if so how could we build it...

So, I've created some space this weekend to do some imagining and brainstorming on attacks and defense.  

So far I've had 1 breakthrough on the Application Whitelisting front, I hope to be able to blog about soon.  I want to prove some ideas a bit first.  

Some classic reading for DFIR

Here are some things to consider...This article was written and published in 1988...

"The intruder conjured up no new methods for breaking operating systems; rather he repeatedly applied techniques documented elsewhere. Whenever possible, he used known security holes and subtle bugs in different operating systems..."

"By studying the printouts, we developed an understanding of what the intruder was looking for. We also compared activity on different dates in order to watch him learn a new system, and inferred sites he entered through pathways we could not monitor. We observed the intruder’s familiarity with various operating systems and became familiar with his programming style. Buried in this chatter were clues to the intruder’s location and persona, but we needed to temper inferences based on traffic analysis."

And Lastly...
"Perhaps no computer or network can be totally secure. This study suggests that any operating system will be insecure when obvious security rules are ignored. From the intruder’s widespread success, it appears that users, managers, and vendors routinely fail to use sound security practices. These problems are not limited to our site or the few dozen systems that we saw penetrated, but are networkwide. Lax system management makes patching utility software or tightening a few systems ineffective. 

We found this intruder to be a competent, patient programmer, experienced in several operating systems. Alas, some system managers violate their positions of trust and confidence. Our worldwide community of digital networks requires a sense of responsibility. Unfortunately, this is missing in some technically competent people."

So, this weekend I am reflecting back and forward a bit to see where it may lead ;-)

Anyway.  Hopefully this is interesting to you you.

Thats all I have for today.



Wednesday, September 7, 2016

Shellcode Via JScript / VBScript - Happening Now!

I recently came across a dll called DynamicWrapperX -

This is an interesting dll, in that it advertises that you can execute win32 calls inside of Jscript / VBScript.  I cannot vouch for the trustworthiness of this dll.  Meaning, only install this in a test environment.  However, I can vouch that this dll gives you extraordinary access to the win32 API, plus other dlls on the system.

The documentation is a bit esoteric, but once you work through the details you can work out how to call any function.

Here is an example on calling a function to pop a MessageBox.

DX = new ActiveXObject("DynamicWrapperX");                  // Create an object instance.
DX.Register("user32.dll", "MessageBoxW", "i=hwwu", "r=l");  // Register a dll function.
res = DX.MessageBoxW(0, "Hello, world!", "Test", 4);        // Call the function.

Let's break that down.

0. Install dynwrapx.dll either for all or just one user, admin not required.
1. Instantiate the DX object
2. Register the user32.dll
a. Parameter Breakdown
b. dll name
c. function name
d. input parameter types
e. return value type
3. Execute the script file, with either regsvr32.exe , or cscript.exe

So if you look at the function MessageBoxW on MSDN you see this:

int WINAPI MessageBox(
 _In_opt_ HWND    hWnd,
 _In_opt_ LPCTSTR lpText,
 _In_opt_ LPCTSTR lpCaption,
 _In_     UINT    uType

You see that the return value of the function is int => l
hWnd => h
lpText => w
lpCaption => w
uType => u

These mappings are in the documentation.  You chain all that together and get the "i=hwwu" and the "r=l" inputs to the Register Function

So. I decided to see if I could get this thing to execute shell code.  


Register 2 functions

VirtualAlloc, and CreateThread  Then leverage the built-in NumPut(Var, Address, [,offset], [,type] function to write your shellcode into memory.  High level steps are:

1. Allocate a Block of mem RWX via VirtualAlloc- The return of this is the base address of the allocation.
2. Loop through your shellcode and write each byte into the space allocated in step 1.
3. Call CreateThread

Sure enough it works perfectly.  The one caveat is that this will only execute x86 shellcode. So when you call regsvr32 or cscript against your script file, you need to call from syswow64 on an x64 system.  

Example SCT Here:
Example JS Here:
Example Dropper Fully Automated:  
^This last example downloads, registers dll, executes Shellcode.  Makes no effort to clean up.

Again, I did not write this dll, so I can only recommend you execute this in a test environment.

According to one researcher I spoke with, this is being used in the wild. So you may want to sweep your environment or logs for the hash. Unless, you have a need for your users to access win32 API this way, its probably not supposed to be there...

I also wanted to give a shout to b33f - @FuzzySec for the shellcode posts here:
This is a great blog all around.

Screen Shot 2016-08-31 at 1.57.05 PM.png

Thats all I have for today.