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.

Securing Windows Workstations: Developing a Secure Baseline

MacOS Operating System Hardening

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.

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.

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

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.

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.

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.

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.

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.

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

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

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.

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.