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.

Cheers,

Casey
@subTee


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.

Cheers,

Casey 
@subTee