Getting Started with Breach Simulation

It is all too often that I am enlisted to perform a penetration test for a client, gain access to the internal network, and compromise the entire environment without them even knowing. This level of compromise would typically include gaining control of both their Active Directory domain as well as gaining access to other businesses critical systems and data. It is in this process that I am able to have very valuable conversations about their current technical and non-technical security controls, the risk current configurations pose to the business and hopefully provide valuable recommendations on a better way forward. Everyone wins in this situation however, it brings me to a few problems I aim to help organizations in addressing with blog posts such as this ones.

  1. Some companies can’t afford or choose not to perform penetration testing
  2. Performing the occasional penetration test is not enough for companies to truly keep up with the current threat landscape

The Tools

Luckily it has never been easier for the Blue Team (internal IT) to perform their own breach simulations to identify common security holes and ensure their organization has at least an acceptable level of visibility into their IT assets to detect an attack or compromised host. Below are a few useful tools for performing your own breach simulations without too much fuss but I must caution you: PLEASE DO NOT INSTALL, DEPLOY, OR EXECUTE THESE TOOLS ON YOUR PRODUCTION ASSETS. All of them execute code on the machines you point them at and many of them download files from the internet and leave artifacts on disk. I am not responsible for anything your might break as a result of not following my recommendation. Anyways, here are some of the tools:

  1. Mitre Caldera
  2. Uber Metta
  3. Endgame Red Team Automation
  4. Invoke-Adversary Powershell Scripts
  5. Red Canary Atomic Red Team

Now you might be asking, “if I can’t install these tools on production machines and I don’t have a lab environment what am I supposed to do”? Don’t worry my good friend — you can get up and going with an eval copy of your Windows operating system of choice at the Microsoft Eval center here or download a developer image tailored to you hypervisor of choice here. If you are limited on hardware resources and just want to dabble, a single virtual machine will be fine but I would highly recommend creating a full lab environment with a Windows domain so that you can see the full effects of certain attacks against “real” environments. For that task I would recommend spinning up a copy of DetectionLab by Chris Long, which in his words “is a collection of Packer and Vagrant scripts that allow you to quickly bring a Windows Active Directory online, complete with a collection of endpoint security tooling and logging best practices.” You can download everything you need here. My recommendation with detection lab would be to use a version of Vagrant and Packer that he has already tested unless you have just as much fun troubleshooting as you do simulating breaches. I was able to get it working on the the current version of MacOS, VMware Fusion, Vagrant, and Packer but not without some pain. I then uploaded all of the VMs to my ESXi lab environment for the real fun.

A Simulation To Get You Started

Just to highlight the types of things you can learn from simulating a breach on a lab machine I will show some examples of the aforementioned Invoke-Adversary tool on a patched Windows 7 Enterprise machine with the following configuration.

  • Operating System: Windows 7 Enterprise SP1 Build 7601
  • Microsoft Security Essentials
  • Powershell version 3 (note: Windows 7 ships with Powershell version 2 which gives even less logging ability but I needed to upgrade to version 3 in order to run the Invoke-Adversary scripts.)

I chose Windows 7 for this example on purpose because it still represents the largest install base in corporate America and around 39% of the overall Windows install base and as you will soon see does a somewhat poor job at detecting common attacks with an out-of-the-box configuration. Thankfully Windows 10 is a much more secure operating system out-of-the-box but lets not get ahead of ourselves. From an administrator command prompt type the following:

powershell -exec bypass
./Invoke-Adversary.ps1

Invoke-Adversary Credential Access

Since credential compromise is one of the most common attack vectors and can be linked back to more breaches than any other cause, lets start with Credential access and some good ole fashioned Mimikatz. Option [001] downloads the mimikatz.exe binary to disk and attempts to execute it locally, which is almost always detected and not really used in real attacks any longer because of the almost universal detection rate. For that reason we will skip it and quickly run through [002]-[007] to see if anything is detected and what activity is logged.

Credential Access Tactics [002]

For the sake of brevity and because I want you to go and run these tests your self I won’t show the output of all simulations but there was no Anti-virus alerts during any of the “Credential Access” activities except [001] which is downloading the aforementioned mimikatz binary to disk.

PowerShell Logging — What Your Endpoints Aren’t Telling You

When we go back and look at the Windows Event Log to see if there are any clues there we are disappointed once again. The only thing we see is that a PowerShell console was opened but have no visibility into what if any code was executed.

If we look at the Local Group Policy Editor (gpedit.msc) we can see a few options are available to us in PowerShell version 3 but they are not turned on by default. These settings are located under Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell

As you can see, none of these settings are configured by default which puts us at a severe disadvantage when it comes to detecting PowerShell attacks. Lets change Turn on Module Logging to Enabled, log out/in, and try our Invoke-Adversary commands again.

As you can see, it is now apparent that we are running the Invoke-Adversary.ps1 script and we have more detail about what is actually going on. This is where having PowerShell version 5.1 really shines because it gives us verbose script block logging among other things which can show us the exact code block that was executed on the system.

In Closing

Well friends, this is just the tip of the iceberg but my hope in this post was to

  1. Convince you of the need and value of breach simulation
  2. Provide you with lots of resources and a little bit of instruction to get you started. No excuses!
  3. Show you how little visibility and security you have with out-of-the-box versions of Windows 7
  4. Plead with you to up your endpoint security game
  5. Get you excited for the next blog post

In the next blog post we will take a look at additional endpoint attack vectors and more robust logging, detection and alerting mechanisms you will need to detect them. While many enterprise solutions exist I will be focusing on free or open source solutions such as Sysmon, osquery, SIEMs, and more.

Red Team @ Regions by day | Hobby and Learning Addict by night