Containing The Fallout… Testing The Endpoint With Chain Reactions
29 March 2019
Intrusion detection is a topic that very much interests me, particularly on the network side. While looking at Wireshark and other monitoring tools is great fun, many intrusions start on the endpoint. The purpose of this post will be to test out different adversary TTP’s attacking the endpoint and see how to go about detecting each one.
These tests will allow myself as the analyst to develop a stronger system (in my lab) and identify what attacks can be detected, and what we need to fine tune for the next time.
Our Simulated Attackers
Utilizing Red Canary’s Atomic Red Team chain reactions (https://github.com/redcanaryco/atomic-red-team) , our test environment can be quickly put to the test with up to date attack scripts.
The Windows 10 VM, our host to be compromised in this situation, will be fully updated (Defender, Attack Surface Rules, etc.) as well as utilizing Sysmon (https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon). Our Windows 10 host is also logging PowerShell, in accordance with: https://www.fireeye.com/blog/threat-research/2016/02/greater_visibilityt.html .
For this project, our host will be compromised by a malicious document that makes heavy use of Windows PowerShell. I don’t need to go into why PowerShell is such a popular choice among bad guys looking to breach a network.
Utilizing MITRE ATT&CK (https://attack.mitre.org/), and reading over numerous vendor blog posts, I attempted to replicate the tactics seen once a malicious document is executed.
The first three attacks will use PowerShell for discovery and the following techniques: System Information, Network Connections, & Security Software Discovery.
netsh will be used for another discovery tactic to discover the firewall on the compromised host. Finally, PowerShell will execute a script to download Mimikatz and dump credentials. Along with the kitchen sink, automated collection and exfiltration will also be tested.
I created the below chain reaction pieced together from other reactions and with some commands I thought would be interesting to see how the EDR solution reacted.
Visibility & Detection
Fortunately cWatch EDR was able to alert on and identify each of the malicious PowerShell commands from the bat script I created.
The above alerts are received as “Suspicious PowerShell Execution”. A few of the commands have legitimate uses, so the analyst would need to start correlating the alerts and look deeper into the commands executed.
So the EDR was able to identify the discovery commands. But what about the Mimikatz script? Continuing on in the software we find:
There is obviously much more to look into based off of our alerts we received from cWatch. Mimikatz is a great tool for offensive research/testing, so there are many great articles on detecting its execution.
There are many ways to detect Mimikatz, thanks to Sysmon and a few Event Codes this is made simple. Let’s look at detecting Mimikatz in our Splunk instance where our Sysmon data is being forwarded.
EventCode 10: Process Access is a well known starting point when dealing with Mimikatz. Getting insight into EventCode 10 will allow the analyst to view any queries or read/write operations to the targeted processes address space.
From the Sysmon data we have captured, we can see svchost.exe as the SourceImage and lsass.exe as the TargetImage. Taking this information, we will move to Splunk and see what we can find.
That many events is time consuming. Let’s filter down some and dig into why svchost is accessing lsass.
Down the hole we keep going:
At last, we have the script that downloads the Mimikatz module:
I found this exercise extremely challenging and fun. There are a plethora of ways Mimikatz could have been detected. Furthermore, the EDR solution we used kept us busy enough that analyzing the traffic and alerts would have brought us the same information we found in Splunk.
With this project complete, it is now time to throw in an IDS/IPS into the mix and create some scripts that are a little quieter and leave less tracks. In addition, I will have to read over the Splunk documentation to power up my search syntax.
Hopefully this was helpful to someone, I hope to try out other EDR solutions and identify more weak points in my lab.