Wednesday, September 27, 2017

CLRGuard - Let's Kick the Door Down. Part One

I really like this tool!  Let me start with that. ;-)

I really appreciate Joe Desimone ( @dez_ ) and EndGame making this available open source.

First, check this DerbyCon 2017 Talk out, it will help you have the necessary background.

The code can be found here:

I've had some time to experiment with this code the last few days.

Lets look at the tool.  Its pretty straight forward to deploy for your testing. 

I wanted to show you how this tool can disrupt the MSBuild attacks I have been working on. 

The feature that I have abused in the past execute .NET assemblies in memory, is called Inline Tasks

Lets see what happens when we try to run Mimikatz Inside MSBuild:


I will do another post in the future to go over the internals and some bypasses (I may have found a one or two  :-)  ).

This is a great training tool.  When you find bypasses to this type of defense, it will lead you to better capabilities as an attacker.  I encourage you to dig in and learn from this prototype.  Really good stuff.

This is one of the first tools, I've seen to directly challenge the tactics I am using in .NET to block the capability.

Here is an analogy.

This tool, is NOT an Over-The-Horizon Tool.

Sometimes, we choose to engage attackers Off-Horizon with data collection and analytics.

Sometimes, you have to get in their face a bit, kick in some doors. Write mitigations that directly disrupt the attacks.  Kick in some doors, if you will.

Both tactics have their place.

This tool is designed for the tactical hunt. To get inline with attackers.

Thats all for today.  Great Work Joe, keep it up.



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.    Unknown release date.  Stay tuned.

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.



***UPDATE-  9/27/2017 ***
Thanks all or the interest.  I have enough interest and technical reviewers.  I'll be keeping posted as the release gets closer.
*** ***

***UPDATE 9/28/2017 ***
This is going to be significantly delayed. As I am distracted on another project ;-).
*** ***

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.



Friday, August 25, 2017

msxsl.exe Working As Designed.

So, I recently was exploring XSL, and injection and came across several interesting references.

<msxsl:script> Element

XSLT Script Block Sample

The basic gist, and what I think is interesting is that you can host/execute scripts inside trusted signed binaries that ingest XML.

So, here is an example, a tool called msxsl.exe.

You can download it here:

1. start /b msxsl.exe customers.xml report.xsl
2. start /b msxsl.exe report.xsl
3. start /b msxsl.exe customers.xml

The sample code above just show a very basic example.   If you look at the parameters accepted, either the xml or xsl file can be a url.

So, msxsl.exe while not default, may exist in your fleet, and it packs a powerful punch. It is a trusted binary that can be used to bypass some script controls.

Here again, you have a tool, that is working as designed, yet gives has functionality that can easily circumvent many controls.

By that I mean, execution events are likely not being noticed.... And it allows you to load and execute vbs/js and more...

I recently updated a sample you can use for testing.  So, I using the amazing DotNetToJscript, all you need is to update the base64 shell code here and you can execute in the context of msxsl.exe.  Keep in mind its a 32 bit application.

MSXSL Test Cases

You could easily base64 encode and deliver this script host runner too.  Its small but packs a big punch ;-)


Thats all.  Short and simple.


Casey Smith

Saturday, July 22, 2017

DEFCON 30 CFP: New Directions in Cryptanalysis, an Exploration of Disruptive Disclosure

I had some free time today, and started thinking about what would it be like to disclose a globally disruptive vulnerability. Where and how would you do that? I started thinking about what might this actually look like. So I chose the theme as a rogue cipher punk team that solves some critical equations. How would they get the word out. Safely? While I'm working out the details, this is my fictional write up of what that CFP looks like in 2022. I know its a bit different than my other blog posts. But hopefully highlights the dependency and brittleness we have if this were to ever occur. I don't think we can really imagine the scale of disruption.

So, here it is my 2022 DEFCON 30 CFP, a work of fiction. The setting is 5 years after a globally disruptive disclosure affecting cryptographic algorithms. This is the CFP submitted to DEFCON 30, in 2022 to outline the events that took place. The idea is less focused on the how it the equations were solved, and more on the "now what"... that they have been...How would you distill down what you needed to say in 90 minutes. What does the audience know, what have they lived through...

Here you go:

Title of Presentation: New Directions in Cryptanalysis, an Exploration of Disruptive Disclosure
Presentation Length: 80 minutes 10 Minutes Q&A
Presenters:  Mallory

Abstract:  Cryptography in the modern era was based on the assumption that certain mathematical problems are difficult to solve. These algorithms were said to be intractable. This talk explores how our team found a solution in polynomial-time to the Discrete Log Problem (DLP) and the Integer Factorization Problem (IFP). These two problems are closely related as you are now aware. What did we do when we found solutions to these problems? This talk will discuss the challenges our team faced in communicating our research. We will explore the mathematical primitives and assumptions that led to our solution. This talk will focus on the implications these solutions had on the global infrastructure.  We will also explain the background behind the Cipher Suite Resilience (CSR) standard, and how organizations can be better prepared for rapid cipher suite shifts. From signed Kernel Drivers to secure Authentication and Communication. The impact of this disclosure was far reaching. Hardly an area of modern technology was not affected by this disclosure. This talk will be a behind the scenes look at the events of 2017.  Including detailed information on how we disclosed the solution and remained anonymous. We think this talk will help organizations be better prepared for the next globally disruptive disclosure.

Bio: Mallory is a member of the Kult of Pythagoras (KoP), an international organization founded in 2005 with the idea that mathematical knowledge and solutions should no longer be held exclusively by any organization. These solutions and knowledge should be freely available for the benefit of humanity. The founding members are known only as Alice, Bob and Mallory.  In late 2017, Mallory revealed a solution to the Discrete Log Problem(DLP) and Integer Factorization Problem (IFP). Originally focused on internet security, their research has since had a direct impact on many fields including Genetics, Astronomy and many other Data-driven sciences. To this day the members of KoP remain anonymous.


1. Who is the Kult of Pythagoras? What do we believe, and what is our mission? (3-5 minutes)

A brief introduction about each of the founding members.  Our objectives and philosophy.

2. Talk Introduction.  Outline of what we will cover.  (10 minutes)

Modern mathematical research is shrouded in a language and mystique of its own. We will discuss the challenges we faced bringing forwarded a solution to the DLP & IFP. What are the realities faced by researchers wanting to disclose a globally disruptive solution?  Who did we tell first? How did we maintain equality for global disclosure? What means were used to alert authorities and organizations that a solution had been found.  What was adequate lead time to allow organizations to prepare for the disclosure?

3. Vintage Cipher Suite Background and primitives. (5 minutes)
It has now been proven these are solvable and cryptographic systems that use these should be decommissioned. This will lay the foundation for how these problems are related.

Discrete Log Problem (DLP)
Integer Factorization Problem (IFP)
Root Finding Problem (RFP)

4.  Roots of Unity - The Square Root of One. ( 15 minutes )
The solution to DLP and IFP resides in an elegant number, the square root of 1.  It was known that the square root with a prime modulus can be found efficiently using the Tonelli-Shanks Algorithm. By applying this to a composite modulus we were able to efficiently find factors of a modulus of any size. This also led to an alternative way to compute the multiplicative inverse of an exponent, the basis for many cryptographic schemes.
5.  The Disclosure - How we did it. Safely. (20 Minutes )
Solving these problems was only the beginning. Disclosing the solution to these problems is not often considered when working on a solution. The impact of solving these equations is of immense interest to certain individuals and organizations. In order to ensure that these solutions were not suppressed, we devised a scheme to announce to the world that we indeed had access to such solutions and were prepared to disclose them, for free. In order to better prepare the global community for our disclosure, Mallory devised a scheme for both proving to the world that we had a solution, and at the same time, protecting that solution until organizations were prepared. This is now known anecdotally as the "Your Crypto Has No Clothes" memo of December 2017. This led to a global effort to remove vulnerable cipher suites. While many organizations were caught unprepared, we feel that the gap between the memo and disclosure, allowed competent organizations to be understand what was on the horizon and to prepare.

6.  The Chase - How we were hunted. How we stayed safe. (10 Minutes )
Once we announced our intent to disclose, an organized effort took place to suppress the disclosure. By taking the proper countermeasures we were able to watch this unfold, and were alerted to encroachments on our privacy perimeter. Needless to say, there are people who did not want this solution to be disclosed. We quickly learned who was interested in suppressing this disclosure, and took steps to ensure the world got the solutions to these equations. We seek to inform future researchers of our lessons learned, and provide tips for future disruptive disclosure.

7. Cipher Suite Resilience (CSR) - Be ready for the next one. ( 10 Minutes )
In 2017 we learned how dependent our systems and protocols were in antiquated algorithms quickly. The disclosure revealed how critical, brittle and fragile our systems are and incapable of change. From this emerged the CSR, a suite of standards to prepare organizations, systems, and protocols for disruptive disclosures. We hope organizations are now adopting and implementing the recommendations in this standard.

8.  The Conclusion.  (5 Minutes )
We will close with our thoughts on the current events we see unfolding today.  The consequences of the lack of cipher resiliency, and ideas on how to move forward.

List of Conferences:  We have not presented this material to any other conferences.

Why is this a good fit for DEFCON:

We have been in attendance and participated in DEFCON for several years. We feel that our conversations and philosophies were heavily influenced by this community. We feel this is the best venue to bring forward the behind the scenes look at what happened in 2017. The responsible disclosure of these disruptive solutions proved to be much more difficult than we imagined. We hope to share our lessons learned so that other researchers can benefit.  We hope to inspire others to bring forward solutions that have been locked away.

Previous experience:
We have presented under different names at DEFCON, BlackHat, DerbyCon, multiple BSides events. We will present our original document of solutions for archive in the DEFCON proceedings.  

List of facilities requested: Mallory will provided a link to the video file securely to the organizers of DEFCON. This talk has been pre-recorded. In an effort to maintain our privacy, we hope you will accept this unusual talk delivery.

Monday, June 12, 2017

Attacking the CLR - AppDomainManager Injection

I have been interested in attacking CLR to be able to manipulate .NET apps, like PowerShell.
For example using .NET profilers here:

Recently I was reading this article about the CLR and execution events:

One of the interesting things I stumbled on was this reference to CLR tuning:

Of particular interest I saw these environment variables that can be set. You can also set these in an app.config file.

AppDomain Managers are interesting in that they setup the environment, before your .NET app runs.

I'll keep this short.  You can manipulate the runtime, by getting your code to execute prior to the application.

Here's some code.

This also can work against PowerShell.exe too.  ;-)

I leave it to you to explore whats possible here.

Have fun, keep asking questions!



Thursday, May 18, 2017

Subvert CLR Process Listing With .NET Profilers

I recently stumbled onto an interesting capability of the CLR.

"A profiler is a tool that monitors the execution of another application. A common language runtime (CLR) profiler is a dynamic link library (DLL) that consists of functions that receive messages from, and send messages to, the CLR by using the profiling API. The profiler DLL is loaded by the CLR at run time."

So. whats the big deal, really?

Turns out in .NET 4 allows for Registry-Free Profiler Startup and Attach.  This can lead to some unintended consequences.

In order for this work, you need to set 3 environment variables.

Again from MSDN:

Startup-Load Profilers

A startup-load profiler is loaded when the application to be profiled starts. The profiler is registered through the value of the following environment variable:
Starting with the .NET Framework 4, you use either the COR_PROFILER or the COR_PROFILER_PATH environment variable to specify the location of the profiler. (Only COR_PROFILER is available in earlier versions of the .NET Framework.)
  • COR_PROFILER={CLSID of profiler}
  • COR_PROFILER_PATH=full path of the profiler DLL
If COR_PROFILER_PATH is not present, the common language runtime (CLR) uses the CLSID from COR_PROFILER to locate the profiler in the HKEY_CLASSES_ROOT of the registry. If COR_PROFILER_PATH is present, the CLR uses its value to locate the profiler and skips registry lookup. (However, you still have to set COR_PROFILER, as discussed in the following list of rules.)
So, if our objective is to hijack a .NET process, like say PowerShell, we don't really want a Profiler to load, we just want to be able to manipulate the process.  It turns out you can get a dll to load into the .NET process that is not even a Profiler.  This was interesting to me.  The CLSID is just random for this purpose.

So, I had this idea, I could write quick POC DLL that hides a process from PowerShell.  Well, short story is this.  If you load a Profiler, and don't properly setup the Profiler structures, then the .NET CLR will promptly eject your dll.

For details of how we hook and hide see this article.

Thats ok.  ;-)  So what I did was create a DLL that loads another DLL from memory, and then when my profiler gets evicted, my hooking dll will stay resident.  So the Profiler just becomes a bootstrap.

The result seen in this clip below.  We enumerate processes with Get-Process in a "non-profiled" PowerShell process.  We get the details just fine.  Then we set our environment variables, load our PowerShell process, and now, the processes are not seen.


Why does this matter.  As PowerShell become the window through which many sysadmins poll and interrogate the operating system.  By using attaching a malicious profiler, we can mold the output so to speak to be what we want.

This was just a very basic example.  I leave it up to you to explore further capabilities of tampering with the CLR/.NET applications through profilers.

Hope that was helpful.

Thats all for today.


Wednesday, May 3, 2017

Using Application Compatibility Shims


There have been number of blog posts and presentations on Application Compatibility Shims in the past [See References at End].  Application Compatibility is a framework to resolve issues with older applications; however, it has additional use cases that are interesting. For example, EMET is implemented using shims[1,2]. Please see the Reference section below for additional reading and resources.  In short, this document will focus on the following tactics: injecting shellcode via In-Memory patches and injecting a DLL into a 32bit process, and lastly, detection and shim artifacts will be discussed.  An In-Memory patch has this advantage over backdooring an executable: it this preserves the signature and integrity checks.  This technique can also bypass some Application Whitelisting deployments.  AppLocker, for example, would allow the startup of a trusted application, and then an In-Memory patch could be applied to alter the application.

Shim Installation:
The shim infrastructure is built into Windows PE loader. Shims can be applied to a process during startup. There is a two-step process that I will refer to as “Match and Patch”.  The Match process checks the registry on process create and looks for a relevant entry. If an entry is found, the Match process further checks the associated .sdb file for additional attributes, version number for example.  Based on my understanding, the sdb does need to be present on disk. I have not encountered any tactics to load an sdb file from memory or remotely. When the Shim Databases are installed they are registered in the registry at the following two locations:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Custom
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\InstalledSDB

These entries can be created manually, using sdb-explorer.exe, or using the built-in tool sdbinst.exe. If you use sdbinst.exe there will also be an entry created in the Add/Remove Programs section. In order to install a shim, you need local administrator privileges.

An example of a shim entry would look like this:

Once the shim has been installed, it will be triggered upon each execution of that application. Remember, there is further validation of the executable inside of the sdb file. For example, matching a specific version or binary pattern. I have not found a way to apply a shim when a DLL is loaded, or apply a shim to an already running process.  These registry keys plus the actual sdb file are the indicators for the Blue Team that a shim is present.  

Shim Creation and Detonation:
There are two tools we can use to create shims. First, the Microsoft provided Application Compatibility Toolkit (ACT).  Second, the tool created by Jon Erickson, sdb-explorer.exe.  ACT will allow us to inject a DLL into a 32-bit process, while sdb-explorer allows us to create an In-Memory binary patch to inject shellcode. The ACT has no ability to parse or create an In-Memory patch. This can only be done via sdb-explorer.

There is an excellent walk-through here on creating an InjectDLL Demo.

For the remainder of this document, we will focus on using sdb-explorer to create and install an In-Memory patch.

My testing seems to indicate this will not work on Windows 10.  This tactic will only work on Windows versions <= 8.1.  I could be wrong about this, so please share any insight if you have it.

There are two approaches you can take with sdb-explorer.  First, you can simply Replace or write arbitrary bytes to a region in memory. Second, you can match a block of bytes and overwrite. There are advantages and disadvantages to both approaches. It is worth noting that this method of persistence will be highly specialized to the environment you are operating in. For example, you will need to know specific offsets in the binary   

For this to work, we need an offset to write out shellcode to. I like to use CFF Explorer.

Here we are going to target the AddressOfEntryPoint. There are other approaches as well.  The drawback to this approach is the application doesn’t actually execute. In order to do that you would need to execute your patch and then return control to the application.  I leave that as an exercise for the reader.

Once we have the offset, we can use the syntax provided by sdb-explorer to write our shellcode into the process at load time.

If we break down the syntax, it is pretty easy to understand.

Line 7. 0x39741 matches the PE Checksum. This is in the PE Header.

Line 8. 0x3689 is the offset of our AddressOfEntryPoint.  What follows is just stock shellcode to execute calc.

Once our configuration file is created, we “compile” or create the sdb.
sdb-explorer.exe –C notepad.conf –o notepad.sdb.

Then install it:

sdb-explorer.exe –r notepad.sdb –a notepad.exe

You can also use:

sdbinst –p notepad.sdb.

In either case it requires local administrative rights to install a shim.

Notepad.exe is nice. But more likely shim targets would be explorer.exe, lsass.exe, dllhost.exe, svchost.exe. Things that give you long term persistence. Of course your shellcode would need to return control to the application, instead of just hijacking AddressOfEntryPoint.

Shim Detection:
There are two primary indicators that a shim is being used. First, the registry keys mentioned above.  Second, the presence of the .sdb file. The presence of the .sdb file is not necessarily bad, it would be wise to build a baseline to understand which shims your organization uses and which would be an indicator. There was a good example of detecting shim databases given here:  Hunting Memory, on slide 27.  Also, some shim registration activity can be recorded in the Microsoft-Windows-Application-Experience-Program-Telemetry.evtx.




Wednesday, April 26, 2017

Consider Application Whitelisting with Device Guard

I realize that Twitter is a difficult medium to articulate full discussions, so I wanted to engage the topic with a blog post. Over the last couple years, I have focused a fair amount of time drawing attention to the use/misuse of trusted binaries to circumvent Application Whitelisting (AW) controls.  What I have not often discussed, is the actual effectiveness that I have seen of using AW. I would like to take the time to describe what I see are the strengths of AW, and encourage organizations to consider if it might work for their environments.
The genesis of this discussion came from my colleague, Matt Graeber (@mattifestation).  We’ve spent a fair amount of time looking at this technology as it applies to Microsoft’s Device Guard. And while we agree there are bypasses, we also believe that a tool like Device Guard can dramatically reduce the attack surface and tools available to an adversary.
One question you must ask yourself and your organization is this… How long will you allow the adversary to use EXE/DLL tradecraft to persist and operate in your environment? I have heard a great deal of discussion and resistance to deploying AW. However, I personally have not heard anyone who has deployed the technology say that they regret whitelisting.
When the organization I used to work for deployed AW in 2013, it freed up our team from several tasks.  It gave us time to hunt and prepare for the more sophisticated adversary.  There are many commodity attacks and targeted attacks that take various forms.  However, one commonality they all often share is to drop an EXE or DLL to disk and execute. It is this form of attack that you can mitigate with AW.  With whitelisting, you force the adversary to retool and find new tradecraft, because unapproved, unknown binaries will not execute…
How long will you continue to perform IR and hunt C2 that is emitted from an unapproved PE file?
Here are some of the common reasons I have heard for NOT implementing AW. There are probably others, but this summarizes many.

1.     Aren’t there trivial bypasses? It doesn’t stop all attacks.
2.     Too much effort.
3.     It doesn’t scale.
I’ll take each of these and express my opinion. I’m open to dialogue on this and if I’m wrong, I would like to hear it and correct course…
1.     Aren’t there trivial bypasses to AW?  It doesn’t stop all attacks.
There are indeed ways to bypass AW.  I have found a few.  However, most of the bypasses I have demonstrated require that you have already obtained access to, and have the ability to execute commands on the target system. How does the attacker gain that privilege in the first place if you deny them arbitrary PE’s?  Most likely it will be from a memory corruption exploit in the browser or other application.  How many exploit kits, macros, or tools lead to dropping a binary and executing it?  Many do…
Most of the bypasses I have used are rooted in misplaced trust.  Often administrators of AW follow a pattern of “Scan A Gold Image & Approve Everything There”.  As Matt Graeber has pointed out to me several times, this is not the best approach.  There are far too many binaries that are included by default that can be abused. A better approach here is to explicitly trust binaries or publishers of code.  I can’t think of a single bypass that I have discovered that can’t be mitigated by the whitelist itself.  For example, use the whitelist to block regsvr32.exe or InstallUtil.exe.
Don’t fall victim to the Perfect Solution Fallacy.  The fact that AW doesn’t stop all attacks, or the fact that there are bypasses, is no reason to dismiss this as a valid defense.

“Nobody made a greater mistake than he who did nothing because he could do only a little.” –Edmund Burke
AW, in my opinion, can help you get control of software executing in your environment. It actually gives teeth to those Software Installation Policies. For example, it only takes that one person trying to find the Putty ssh client, and downloading a version with a backdoor to cause problems in your network.  For an example of how to backdoor putty see this recent post. Or use The Backdoor Factory (BDF). The thing is, it doesn’t matter that putty has a backdoor.  The original file has been altered, and will not pass the approval process for the whitelist, and the file will be denied execution. Only the approved version of putty would be able to execute in your environment.
2.     Too much effort.
Well… I’ve heard this, or some variation of it.  I understand that deploying and maintaining AW takes tremendous effort if you want to be successful.  It actually will take training multiple people to know how to make approvals and help with new deployments.
You will actually have to work very closely with your client teams, those in IT that manage the endpoints.  These partnerships can only strengthen the security team’s ability to respond to incidents. You can leverage tools like SCCM to assist with AW approvals and deployments.
The level of effort decreases over time.  Yes, there will be long hours on the front end, deploying configurations, reviewing audit logs, updating configs, etc… Some admins are so worried they will block something inadvertently; they are paralyzed to even try.  I think you’ll find out, Yes, you will block something legitimate.  Accept that this will happen, it’s a learning process, take it in steps.  Use that as an opportunity to get better.
I’ll say it again; I haven’t met anyone who has made the effort to deploy AW say that they regret the decision…
If you think it’s too hard, why not try 10% of the organization and see what you learn?
Stop telling me you aren’t doing this because it’s too hard… Anything worth doing well is going to require some effort and determination.
3.     It doesn’t scale.
Nope, it may not in your environment.  I never said it would… You must decide how far to go.  You may not get AW everywhere, but you can still win with it deployed in critical locations.  The image below describes how I think about how AW applies to different parts of your organization.  It is not a one-size-fits-all solution.  There are approaches and patterns that affect how you will deploy and configure whitelists. I think you should start with the bottom, and work your way up the stack.
Start to think of your environment in terms of how dynamic the systems are.  At the low end of the are those fixed function systems.  Think about systems similar to Automated Teller Machines.  These often only need to be able to apply patches.  New software rarely ever lands here.  Next, you have various department templates, each department will be unique, but likely fits a pattern.  Then IT Admins, who often need to install software to test or have more dynamic requirements.  At the top of the environment, are Developer workstations.  These are systems that are emitting code and testing.  I’m not saying you can’t whitelist here.  You can, I’ve done it.  But it will require some changes to build processes, code signing etc…

Yes, this is an overly simplified analogy, but I hope it helps you see where you can begin to prioritize AW deployments.
So, begin to reorient how you think about your systems to how dynamic they are.  You will have your quickest wins and earliest wins by starting at the bottom and moving your way up the hierarchy.


I am curious for open debate here.  If AW sucks, then let me hear why.  Tell me what your experience has been.  What would have made it work?  I’m interested in solutions that make a long term actual difference in your environment.  It is my opinion that AW works, despite some flaws.  It can dramatically reduce the attack patterns used by an adversary and increase the noise they generate.  I also believe that by implementing AW, your security teams can gain efficiencies how they operate. I am open to learn here.
If you are tasked with defending your organization, I’m asking you, as you begin to roll out Windows 10, to consider using Device Guard.

Ok, that’s all I have today.  Sincere feedback welcome.  If you think I’m wrong, I’d like to hear why...