Getting Value from Breach Simulations and bypassing Windows Defender
Since the last post titled Getting Started with Breach Simulations I realized that I may have unintentionally put the cart before the horse with my ask of everyone to start performing breach/adversary simulations in their environment. So lets back up a step and put breach simulation in its proper place, then jump forward to a demonstration of an attack that can be executed on the most recent version of Windows 10 without being detected. It is always good to start out by defining the outcome we are after right?
The goal of breach and adversary simulations is to predict the likelihood of a specific attack scenario being successful in YOUR environment before it actually happens.
To use an analogy, breach simulations should allow you to find the week 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 or at least one that will float. So without rehashing what so many good frameworks have covered before(here, here, and here)or digressing into more boat-speak I will just mention three key areas that I think you should have a handle on before performing breach simulations will be the best use of your time. Each of these topics have their own hard problems to solve and represent deep rabbit holes that won’t be dealt with in this post but I will try to provide a few resources off the top of my head.
1. Asset management:
Simply put, you need to know what exactly you are trying to protect and if you don’t know what you have you will have a hard time protecting it. So find your assets, patch them, scan them for vulnerabilities, and know when a new one comes online.
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 but the takeaway is that you need 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 the blue team should spend a few hours on adsecurity.org.
3. Authentication and Privilege
This is not something you solve once because it requires ongoing management but there are some usual offenders here that will heavily contribute to the spread of malware in your environment. In a general sense 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.
harkening back to our goal above, if you are not at least doing a reasonable job with the above list then by all means feel free run some breach/adversary simulations because, well, it is fun to hack all the things and it might provide some motivation but 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 crack 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. Once of the resources I mentioned in the last blog for quickly setting up a full featured lab environment was DetectionLab by Chris Long. Lets give it a spin 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 on his Github repo linked above.
So here is our 4 VM lab up and going but lets 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.
On our Windows 10 computer you can see that our Threat definitions and operating system is up to date.
Payload Creation
For this example we are going to use NPS Payload to generate and 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.
Once we have a payload I just hosted it out 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.
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 dump the NTLM hashes of logged in users
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 are there if we look a little closer.
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 de-obfuscated 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 you can see, the combination of all of this data makes it pretty apparent that something other than normal computer stuff is going on here, yet our antivirus solutions gave us the “all clear” in this case. For an idea of some other attack vectors and what to look for I would recommend checking out what JPCERT has put together as well as all of the data around the Mitre ATT&CK framework.
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. Palantir has written a great article you can find here.
- 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.
