SIEM Home Lab Series (Part 4)
Thumbnail image "System Code" by Yu. Samoilov is licensed under CC BY 2.0
This is the fourth part of a multi-part series on building a SIEM lab and training with ‘Purple Team’ skills. I say ‘Purple’ because while the emphasis will be on ‘Blue Team’ activities we will also need to use ‘Red Team’ techniques to populate our SIEM with relevant data. The series is broken out into the following parts:
Investigating with Winlogbeat
In part one we set up the SIEM using the Elastic Stack and if you are not familiar with Elastic or you want to follow along exactly as I do then feel free to check that out first.
In part two our primary focus was on understanding and setting up the correct type of event logging in our lab as well as installing and configuring the Elastic agents that will collect these events and ship them to our SIEM.
In part three we generated “malicious activities” via the Atomic Red Team framework and analyzed them in the SIEM.
In this last part we will analyze Active Directory attacks and also review some additional resources if you want to go further beyond the topics of this series.
Active Directory
Active Directory is used in some kind of meaningful way by just about every major company in the world so being familiar with it is definitely a useful skillset.
If you are brand new to the concepts of Active Directory you may want to stop here and review some of the fundamentals first:
You can also review this guide - Active Directory Fundamentals.
Making An Interesting AD Lab
An out-of-the-box deployment of Active Directory is sparsely populated and about as interesting as a math test. It contains almost nothing that is engaging from a learner’s prospective and so in order for us to more effectively practice with our tools we need to populate our directory with objects that closely mimic an enterprise environment.
Enter BadBlood.
BadBlood by Secframe fills a Microsoft Active Directory Domain with a structure and thousands of objects. The output of the tool is a domain similar to a domain in the real world. After BadBlood is ran on a domain, security analysts and engineers can practice using tools to gain an understanding and prescribe to securing Active Directory. Each time this tool runs, it produces different results. The domain, users, groups, computers and permissions are different. Every. Single. Time.
The documentation for this tool is actually pretty good so feel free to use that in order to get set up in your own lab.
Don’t forget to take a snapshot of your domain controller VM before you run the tool!
Powershell Logging
In part three of this series I made a point to enable Powershell transcription using Group Policy and while that was correct it technically isn’t enough for what we are trying to do. Following this guide you also want to enable Module Logging and Script Block Logging (you’ll see why in a bit).
Basic Recon
Here’s a hypothetical but totally realistic scenario:
Donna from HR gets an email with a PDF attachment that, unbeknownst to her, is a trojan that will install a remote access tool on her PC. Part of Donna’s job is to open attachments that come with emails so she does and then the malware gets installed on her machine.
Thanks a lot, Donna.
(I’m kidding of course - if it was easy to spot every malicious email then automated filters would have already stopped it long before it got to an end user)
So now the attacker has a foothold on a machine within the internal company network. It’s not that hard for them to escalate their privilege to SYSTEM, install the AD Powershell module…
…and start doing some recon for things such as admin accounts.
get-aduser -filter {AdminCount -eq 1} -Properties Name,AdminCount,ServicePrincipalName,PasswordLastSet,LastLogonDate,MemberOfIt’s trivial for the attacker to filter that output to just the SamAccountName and build themselves a target list. From this point there are any number of ways they could go including:
etc…
By the way, remember earlier that we enabled more verbose Powershell logging via Group Policy, right? Because we are smart AND proactive we also installed Winlogbeat on Donna’s computer before this incident happened and all we have to do now is filter for Event ID 4104 and the powershell.file.script_block_text field in our Elastic stack to easily see the exact Powershell commands being executed on that device.
Exploitation
A common and unfortunately still very successful exploit tactic used by attackers and pentesters alike is password spraying (see link above for details) so we are going to test that in our environment.
There are any number of ways to do this but we are going to use a tool called Kerbrute:
A tool to quickly bruteforce and enumerate valid Active Directory accounts through Kerberos Pre-Authentication
From a Kali Linux VM that we’ve connected to the environment I’ve prepared a list of admins gathered from Donna’s computer.
And then we launch the attack.
With
passwordspray, Kerbrute will perform a horizontal brute force attack against a list of domain users. This is useful for testing one or two common passwords when you have a large list of users. WARNING: this will increment the failed login count and lock out accounts. This will generate both event IDs 4768 - A Kerberos authentication ticket (TGT) was requested and 4771 - Kerberos pre-authentication failed
If we then go back to Elastic and adjust our filters we can clearly see the attack from the Domain Controller’s perspective.
Compare the screenshots from both Kali and Elastic - notice how Kerbrute only found one valid password and then look at the difference in the StatusDescription field (KDC_ERR_PRE_AUTH_FAILED versus KDC_ERR_NONE).
The next logical step is to build a detection alert so that if this ever happens again in our internal network we can hopefully catch it and stop the attacker in their tracks.
If we browse to the Kibana Security Detections page we can see that no detections triggered on the traffic from the password spraying so we will need to either find and enable a pre-built one or configure our own.
A quick search shows that as of this writing there are only two pre-built detections for password spraying and they are both meant for SaaS services, not an on-prem directory.
Fortunately Elastic has made it super easy to configure our own custom detection rule(s).
We start by choosing a rule type. In this case I am choosing ‘Threshold’ because we are looking for a large number of events in a short period of time. This is a basic detection and a smart attacker could easily get around it by spacing out their queries and adding some jitter to obfuscate what they are doing. While this is a legitimate concern there are two things to consider:
We aren’t trying to boil the ocean here. Focus on one thing at a time and then gradually iterate and improve it.
There are still lots of dumb attackers in the world who will get caught by this
Next, because the source of the particular logs we are watching is a Winlogbeat agent on our Domain Controller, we want to remove all the default index patterns except Winlogbeat. This is for performance reasons as it is not necessary for Elastic to search though all of those other indexes to trigger on logs that are not there.
Next we add a custom query; I’ve chosen to filter on the winlog.eventid of the login attempts that are generated by failed login attempts. We are grouping our results by the winlog.eventdata.StatusDescription, which in this case is the value ‘KDC_ERR_PRE_AUTH_FAILED’ and setting the threshold to 15.
When you are done click ‘Continue’.
It’s important to keep in mind that this is fine for a lab but in production you will need to tailor this specifically to your environment. Before implementing an alert like this you should first establish a baseline of what a “normal” login patterns look like for your workplace and then configure the detection to trigger on something that is “abnormal” from that.
Next we can configure additional information about the rule itself including a helpful description, severity score, tags for searching, MITRE tactic numbers, etc…
For my lab I am going to skip most of this but at work I make a point to fill in all of these fields. Some of these can be tremendously helpful and contribute to the overall usefulness and maturity of your SIEM.
Next we configure the schedule which I am leaving set with the default values.
Click ‘Continue’
Finally we get to the last section where we configure the actions to take when a rule is triggered. Because I am using the free license for my stack I do not have access to any option other than ‘Perform no actions’, which is fine. If you have a paid license then you can set up actions such as sending out an automated email or even integrate directly with some third-party apps such as Slack, PagerDuty or ServiceNow.
You can choose to save the rule and activate it or just save it and activate it later.
After we create our rule we are automatically taken back to the Detection Rules page and we can see our new rule in place.
Recall that the detection is set to run every 5 minutes so that gives us enough time to re-run our password spray attack again, check back with the dashboard and then…there’s our detection alert!
From here you would do whatever investigation needed to track down the source of the traffic and hopefully work your way back to the initial compromise.
Technically I cheated a bit by bringing in Kali to do the actual password attack directly in the network. In real life an attacker would most likely operate remotely using a compromised device either directly via a reverse shell or corporately as part of a botnet/C2 setup.
Despite using a shortcut the attack and the subsequent detection are both valid and hopefully seeing them together gave you some inspiration on how to implement a similar setup in your own environment.
Resources
Despite this being a multi-part series there is so much that got left out due to space and time constraints. If you are interested in Elastic or Active Directory security then please see below for links to a bunch of free resources that you can use to dive deeper than I could ever take you.
Good luck and happy learning!