Friday, September 22, 2017

dbghost.exe - Ghost And The Darkness

I found another Device Guard bypass recently.  It was great to get to work with MSRC to get confirmation of the bypass, and to have them update the Device Guard configurations here:

Device Guard Configuration

This is another example of a misplaced trust bypass.  A trusted signed binary that can allow unapproved execution.

I'll keep this post short and sweet.

This tool is well documented on MSDN:

How to Use the Debug Diagnostic Tool v1.1 (DebugDiag) to Debug User Mode Processes

Read that carefully ;-)

So... dbghost will execute vbs scripts.  The next question is, what form? Anything special to do?

This is what caught my eye:

'Load the .NET debugger extension sos.dll (2.0 version)
CmdOutput = g_Debugger.Execute("!load C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\SOS.dll")
'Get the size of the GC
CmdOutput = g_Debugger.Execute("!eeheap -gc")

Couple of things there. If you are familiar with windbg, you will recognize that this allows you to not only execute .vbs... But you can execute windbg commands too.

Check out Matt Graeber's  example of some things you could do with windbg scripts:

Bypassing Application Whitelisting by using WinDbg/CDB as a Shellcode Runner

Thats it, I'll leave it for you to explore your own implementation here.

Special thanks to Matt Graeber  and Matt Nelson for the ideas, inspiration, and confirmation of the bypass.

This tool is not default, but it may be in your fleet.

Thats all for now. Reading MSDN pays off again ;-)



Sunday, September 17, 2017

Demogorgon - A Stranger Things Inspired Tool, Coming Soon.

This tool is inspired by the show "Stranger Things".
There are spoilers, so, if you want to watch the show, read no further.
You were warned.  :-)

First some background.  If you haven't seen the show.

In the show, an alternate reality, called the Upside Down is introduced.  Think of this as an overlay to the real world, same infrastructure and objects, but unseen, and inhabited with monsters.

"The Upside Down is an alternate reality or dimension existing in parallel to the human world. It contains the same locations and infrastructure as the human world, but it is much darker, colder, foggier..."

In one of the scenes, they discuss the Vale of Shadows from a D&D book...

"The Vale of Shadows is a dimension that is a dark reflection, or echo, of our world. It is a place of decay and death, a plane out of phase, a [place] with monsters. It is right next to you and you don’t even see it..."

Over the summer, I took some time off to reflect and think about things... While binge watching the show, I was inspired to think about Apex actors.  :-).  The result was a show inspired tool I wrote.

By Apex actors, I mean those actors that are untouchable so to speak.  Think of apex predators in the natural world.  These are the animals at the top of the food-chain...

Ok.  So the question becomes, if we are really into "Adversarial Emulation", how can we mimic the actions of these actors.  What exactly are Apex actors capable of?

Here would be a short list of what I would consider examples of Apex actor capabilities:

So, while we may think our Red Team operates like an Apex actor, we probably do not. 

So, what is the point of this post?

Over my time off this summer, I spent a fair amount of time exploring the idea of releasing a set of tools/capabilities to be able to emulate an Apex actor.

I wanted to build something that would give teams the ability to step up their game.  I want limited distribution to keep the "mystique" and to not to be a commodity tool.  

I wanted to something to allow Red Teams to operate from the "Upside Down" ;-).

The Upside Down being a Stranger Things reference to being able to operate from an "undetectable dimension", and interact with the actual infrastructure of an organization.  

Geeky? Yes. Possible? Absolutely.

I developed a tool, I'm calling Demogorgon:

"What’s a Demogorgon? Why were they so afraid to face it in battle? Demogorgon is none other than the Prince of Demons, and has been an iconic D&D creature since 1975, along with Orcus, his chief rival and enemy. You can find a short description of Demogorgon in the 5th edition Monster Manual under the Demon Lords section (pgs. 51-52), and a brief mention in the 5th edition Dungeon Master’s Guide in The Abyss section (pg. 62)." [1]

I will first share some of my architectural decisions and capabilities that I built into the tool.  The idea was to be a "rootkit-like thing".  Rootkits are interesting, in that they want to run, they want to hide. Some traditional rootkit capabilities just aren't always necessary, and will likely get you caught by modern Operating System defenses. 

Some things I've added include:
  • Novel execution, migration and repair capabilities. (The Flea)
  • Detailed logging and reporting from Red Team use.  
  • Modules delivered as keyed byte arrays.  Minimize PE structures, RWX regions etc... (Inspired by Ebowla )
Do we really need a new tool?  Maybe, if you don't think so, don't use it... Its not going to be for everyone anyway.  I wanted to learn some advanced tactics.  I wanted to push past modern detections and advance defender detection capabilities. 

I intend limited distribution to friends and family.  Once I've got the bugs worked out, I'll distribute to a wider audience, maybe.  I intend to limit distribution.  Maybe it will only be available west of the Mississippi :-) .

This tool is not meant to compete with tools like Empire, Cobalt Strike, or Metasploit.  From host based to network based, many organizations are prepared for and have strong detection capabilities for these tools.

These are all still highly effective tools, but they often have strong signatures and detections built around them.

If all goes well, the final development will be ready for October 31st release.  

Thats it, just a sneak peak of stranger things to come.

The idea behind Demogorgon, is to give Blue Teams a chance to face their nightmare, something they have never seen before, and something that they can't see.

Feel free to DM if you want to be added to the list of technical reviewers.



Saturday, September 2, 2017

Banned File Execution via InstallUtil.exe Nov 11, 2014 12:58 AM

I was going through some of my old research today, and thought I might share the genesis of one of my older findings.  I thought maybe it would be helpful to share my thinking and motivation for some of the research I have done in the past.

It was October 31, 2014.  We were running a Red Team exercise against our environment, it was the first engagement we had conducted since deploying our then Bit9 App whitelisting software.  Which was kicking our asses.  We had to learn to completely retool.  Dropping arbitrary unsigned, unapproved binaries was NOT going to work..

So, in an effort to try to circumvent the whitelisting we started enumerating all default .NET binaries on the system we were on.  We had proved earlier that year, this might actually be a useful angle for attack.  Details here: Application Whitelist Bypass Using IEExec .

For each binary, we asked the question.... How could I get this binary to execute my code... We were looking in:


The default path on Window 7.

After a couple hours trolling MSDN we worked our way alphabetically through the list of Assemblies.  We landed on InstallUtil.exe

InstallUtil.exe on MSDN

Now we needed to find a sample or understand HOW InstallUtil triggers execution... No real luck so we decided to Reverse the Assembly.

We used a .NET tool called ILSpy, you can also use dnSPy.

The first path from the args input passed to a Method call occurs on line 18.

This is important, cause we want to know what we can control or influence to get our assembly to execute.  We needed to know what InstallUtil.exe is looking for.  We can trace the arguments as they pass through ManagedInstallerClass.InstallHelper().

For sake of brevity...  We learned that we can influence InstallUtil.exe by crafting an Assembly that gets ingested by InstallUtil.exe and executed. If you continue to read/work through the Assembly. You will find that you need to decorate a class with the attribute

This lead to some really interesting behavior.  We discovered, we could execute this file in our environment,  EVEN if we explicitly banned that file.  This can be execute by any normal user and does not require any additional privileges to execute.

This was a real gem for sure.  We used the utility InstallUtil.exe to complete our mission and about a week and a half later, I finally had some time to report to the vendor. I posted a question to Bit9 in their User Exchange.

I won't share all the details of my original post, but the Carbon Black [CB] User Exchange is a fantastic way to share configuration data, Threat Intel and its a huge asset for CB customers and still is.

CB engineering immediately reached out to me and began digging into the internals of what caused this behavior, and it was subsequently fixed in later releases of their product.

Carbon Black (Bit9 when I was growing up ;-) . Has formal disclosure mechanism in place and they are really great to work with.  Reporting Security Vulnerabilities

So here we are almost 3 years since the original discovery of the use cases for InstallUtil.exe to bypass whitelisting deployments. At least original for me.  Others may have found but weren't blogging / talking about if they did....

If you want to test this against your environment, here is the original gist:

Shellcode via InstallUtil

Later we would write a full blown PE Loader for Mimikatz in InstallUtil

Mimikatz Inside InstallUtil

Here are some screen shots of my original dialogue / disclosure:

What does this all mean, and why am I posting this?

1. You should be aware of InstallUtil.exe as a mechanism to launch unapproved binaries.
2. When you find something, working with the vendor directly helps everyone be prepared.
3. Never stop being curious and investigating ways to adapt on an engagement.
4. InstallUtil has been seen in the wild example: Operation Cloud Hopper
5. This bypass, affects AppLocker as well as other Whitelisting tools.  Not Device Guard though.
6. .NET visibility is weak for a defender perspective, and its easy for an attacker to hide here.
7. App Whitelisting, even in audit mode allows you to track unsigned binaries as they move around your fleet.  For example, once we knew the hash, we could hunt where else it had landed.

I hope this was some helpful context on InstallUtil.exe and its history.

Feedback Welcome.