Blog

How to Get the Most Value from Breach Simulations

By Will Enochs on Jun 12, 2018 3:38:20 PM

In case you missed it, I recently wrote a blog detailing how to run your own breach simulations. But do you know why running them is important? Defining the outcome is the first step to determine the answer to this question. 

Typically, the goal of breach and adversary simulations is to predict the likelihood of a specific attack scenario being successful in your environment before it happens. 

Breach simulations should allow you to find the weak spots and reinforce the hull of the ship before it springs a leak. I think we can all agree that everyone’s day is better if we can avoid the “grab a bucket, keep the ship from sinking” fire drill routine. However, before we can reinforce the hull we need to build a seaworthy vessel that will float.

Look Before You Breach

There are three key areas that you should carefully analyze before performing breach simulations. Each of these areas carry their own set of challenges  that won’t be solved in this post, but I will provide a few resources to help if needed. And you can always contact me here.

1. Asset management: Simply put, you need to know what exactly you are trying to protect. If you don’t know what assets you have and which are most important, you will have a hard time protecting them. So, find your assets, patch them, scan them for vulnerabilities, and know when a new one comes online.

If you need help, contact me here.

2. Baseline System Hardening: There are a lot of ways to do configuration management in the DevOps age depending on what your assets are and where they are located. The key is to know that you are starting from a known secure baseline each time. Since we are talking mainly about endpoints in this post, I have included two resources below. Anyone on your IT team should spend a few hours on getting educated on adsecurity.org

Securing Windows Workstations: Developing a Secure Baseline

MacOS Operating System Hardening

3. Authentication and Privilege

Although this area requires ongoing management, there are some usual offenders that will heavily contribute to the spread of malware in your environment. In general, you should strive to utilize the principal of least privilege when it comes to permissions, choose a reasonable password policy and restrict privileged account usage as much as possible. That means no “Domain Users” group added to the local admins group on workstations. (Yes, I still see this on a regular basis.)

Securing Privileged Access

Easy Ways to Build a Better P@$5w0rd

Harkening back to our goal above, if you are not at least doing a reasonable job managing the areas above, we both know how things will likely turn out (hint: badly) if an endpoint is compromised or you come under a targeted attack without giving these three areas attention first.

Vagrant Up

Hopefully you have downloaded some of the tools mentioned in the last post and are up and running with some type of lab environment capable of running a simple breach simulation. One of the resources I mentioned in the last blog for quickly setting up a full featured lab environment was DetectionLab by Chris Long. Let’s run through a simulation so that you can see what it looks like as well as test some payloads that your antivirus might miss. I am not going to cover setup of this environment because Chris already has great documentation here.

blog1

Step 1: Bringing up Detection Lab

Below you will see the 4 VM detection lab running,  but let’s focus on running some payloads on the win10 VM and see if they are detected by Windows Defender and what artifacts they leave on disk and what we could do to detect them.

blog2

Step 2: Check to verify Windows 10 threat definitions and operating system are up to date. 

blog3

blog4

Step 3: Payload Creation 

For this example we are going to use NPS Payload to generate an XML file that we can then launch using the Microsoft signed binary “MSBuild.exe”. There is a long list of Microsoft signed binaries that can be used to execute code and they have recently been coined as LOLBINS which stands for Living Off the Land BINaries and Scripts. A long list of those can be found here.

blog5

Step 4: Payload creation on Kali host

Once the payload was created, I hosted it over the network for the purpose of our demonstration. There are more sophisticated ways to do this, but our narrow scope is just to see how the host-based AV responds and what artifacts are left over that tell the story. Back on the WIN10 host lets execute our payload.

blog6

Win10.windomain.local

When we switch back to our Kali Linux VM we can see that upon execution of the payload we received a callback and successfully launched a Meterpreter shell that we used to effectively take complete control over the host including the collection of NTLM hashes. Since it is a patched Windows 10 host, the plaintext passwords are not stored in memory, however the NTLM hashes can be directly used for authentication across the network.

blog7

If we go back to the Win10 host we can see that no malicious activity was flagged on Windows Defender, but you will see that the signs of compromise are there if we look a little closer.

blog8

Defender on win10

Step 5: Evidence Left Behind

We can see where a remote connection was created on process(PID) 5356. This was the original process our meterpreter shell was running on before we migrated to the x64 svhost.exe process with a PID of 624.

blog9

We can see the intra-network traffic happening from host to host as a result of the reverse https Meterpreter shell.

blog10

We can see MSBuild.exe being used to execute a file across the network via Powershell logs.

blog11

When we look at the PowerShell script block log we can see the actual code that was executed in its deobfuscated form. This was the command that was executed as a result of MSBuild.exe executing the xml file which includes a block of shellcode.

blog12

As this simulation shows, the combination of all of this data makes it pretty apparent that something  is going on here. Yet, in this case, our antivirus solution gave us the “all clear.” There are some good resources that have compiled lists of common attacks and their event ids and artifacts they leave behind. One of them I recommend you check out would be JPCERT.

Takeaways 

  • Ensure you have Windows Management Framework (WMF) 5.1 installed to take advantage of all of the logging
  • Create and deploy the necessary Group Policies to enable the kind of logging you deem appropriate (Module Logging, Script Block Logging, Transcription Logging, etc …)
  • Forward your logs somewhere so that you have the ability to query them and also protect them from being deleted from the host. Any attacker that can own a single workstation can delete the logs from that workstation
  • Don’t rely solely on antivirus to secure your workstations. Antivirus mitigates a lot of low hanging fruit vulnerabilities and is always getting better but there remains many attack vectors that it doesn’t detect.
  • Register for Teklinks' webinar on June 26 to learn more about this topic:

Webinar on June 26

Register now for our webinar “The Breach Your Antivirus Missed” on June 26. In this webinar, TekLinks Cybersecurity Consulting Group will execute attacks against live systems to demonstrate artifacts that are left on the endpoint from many contemporary attack methods. We will also highlight certain variables that make a huge difference in your ability to detect these attacks. Register here.

TekLinks' Senior Cybersecurity Consultant Will Enochs may be reached at info@teklinks.com

Topics: cybersecurity


WHO IS TEKLINKS? A national leader in cloud computing, managed services, engineering services, and value-added resale. We’re a team of expert techies and business professionals who are passionate about building valuable relationships and getting things done right. Simply put: We make IT work for business.

New call-to-action
New call-to-action
New call-to-action

Sign Up for Blog Updates

Popular Posts: