SIEM Home Lab Series (Part 2)
Thumbnail image "Blurred Computer Code" by qubodup is licensed under CC BY 2.0
This is the second 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 will be broken out into the following parts:
Logging activity and ingesting data
Previously, 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 this post our primary focus will be 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.
Lab Overview
Let’s take a quick minute to review our lab setup and explain it’s various components.
This lab is intended to mimic a traditional on-prem enterprise network that uses Active Directory Domain Services to manage user accounts, passwords, and network authentication. The vast majority of organizations use Active Directory in some capacity so it is worth the time to practice with it and learn it’s ins and outs. At a minimum we are going to use one domain-joined Windows 10 workstation for the majority of our activity and later we may bring in a second workstation and an attacker computer to demonstrate additional attack vectors.
Active Directory Domain Controller
Windows Server 2019
Domain Services
DHCP
DNS
Elastic SIEM
Ubuntu Server 20.04 LTS
Elasticsearch
Kibana
Windows PC01
Windows 10 Enterprise
End User Workstation
Windows PC02
OPTIONAL
Windows 10 Enterprise
End User Workstation
Kali Linux
OPTIONAL
Attacker Workstation
Windows Event Logging
When activity happens on a Windows computer such as launching an application, opening a file, or logging into a remote computer, the local computer creates logs of those events.
Windows event logs are the bread and butter of Sysadmins and SOC analysts alike and if you are new to SIEMs and log analysis I would recommend starting with a quick synopsis of the basics of Windows Event Logging before continuing.
Microsoft has this to say regarding the auditing of Windows logs,
Security auditing is a methodical examination and review of activities that may affect the security of a system. In the Windows operating systems, security auditing is more narrowly defined as the features and services that enable an administrator to log and review events for specified security-related activities.
Hundreds of events occur as the Windows operating system and the applications that run on it perform their tasks. Monitoring these events can provide valuable information to help administrators troubleshoot and investigate security-related activities.
An absolutely essential resource for learning about and referencing Windows event logs is the Security Log Encyclopedia. Not only does it let you easily search for every log type by Event ID but also gives detailed breakdowns of the various log fields, examples of what normal logs look like, and supplemental information including resources and discussions. We will do a deep dive into using the Encyclopedia in part 3 of this series but if there is one thing you take from this blog post it should be to bookmark that link!
Audit Policy
Unfortunately the default settings for Windows logging are not very robust and we need to step in and adjust some things. To that end we will use a feature known as ‘audit policy’ to tell our Windows systems what to log.
Basic vs Advanced
Audit policy is broken down into two types - basic and advanced.
Basic audit policy was introduced with Windows 2000 and is comprised of 9 distinct categories.
Advanced audit policy came later with Windows 7/2008 and is comprised of 10 distinct categories with 50 subcategories. This is useful because it gives admins a great deal of flexibility when it comes to enabling just the event logs that they need for their own particular environment.
There are some interactions between the two that you want to be aware of but honestly you should just use advanced policies whenever possible.
Local vs GPO
Another aspect to consider is whether to configure audit policy locally on each individual machine or corporately via Group Policy Objects. Naturally, there are some considerations to take into account but for our lab we are going to do everything with GPOs.
Logging Recommendations
To help us determine what policies to enable in our lab we are going to reference Microsoft’s Audit Policy Recommendations for both our server and our workstation.
From our Domain Controller we launch the Group Policy Editor by going to Start -> Windows Administrative Tools -> Group Policy Management
In the editor go to Domains -> (your domain) -> Domain Controllers -> Default Domain Controllers Policy, right click to view the menu and select Edit.
From there you are going to go to Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> Audit Policies
If you click on the first category, Account Logon, you will be shown all of the subcategories underneath it and their current status (in this case ‘Not Configured’). It is easy to compare the current settings to Microsoft’s recommendations for those subcategories and make any needed changes.
We are going to use the ‘Stronger Recommendation’ for all of our audit policies in our home lab.
One other thing to check before you leave this policy is to make sure that it is being enforced.
You can verify the current Audit Policy settings on a Windows machine by launching a terminal as Admin and running auditpol.
auditpol /get /category:*Before going any further lets establish that enabling audit policies (especially via GPO) in a production environment should be done with great care and only with the consultation of your Sysadmins as well as your manager. It is very easy to cause servers to become unstable or even crash if they get overloaded with too much logging on top of whatever normal processing load they are handling.
DO NOT EVER CHANGE AUDIT POLICIES IN A PRODUCTION NETWORK WITHOUT FIRST CHECKING WITH YOUR SYSADMIN(S)!
For our workstation we are going to follow the exact same procedure but this time editing the Default Domain Policy (once again, making sure it is being enforced) using Microsoft’s stronger recommendations for Windows 10.
Sysmon
Gathering Windows Event Logs is the right place to start but they only document a fraction of what is actually going on with a system. To get richer details and to catch everything else that WEL misses you need Sysmon.
According to Microsoft’s documentation,
System Monitor (Sysmon) is a Windows system service and device driver that, once installed on a system, remains resident across system reboots to monitor and log system activity to the Windows event log. It provides detailed information about process creations, network connections, and changes to file creation time. By collecting the events it generates using Windows Event Collection or SIEM agents and subsequently analyzing them, you can identify malicious or anomalous activity and understand how intruders and malware operate on your network.
To this day I don’t understand why Sysmon does not come preinstalled on all Windows machines out of the box but at least Microsoft makes it easy to get and install.
If you would like to see a little bit of a deeper dive into Sysmon and what it can do for you I would highly recommend watching the video below where John Strand and his team walk you through it.
(Just as a side note: everyone over at Black Hills Information Security is great, they do really amazing things for the community, and you should definitely keep and eye on everything they do)
One thing to keep in mind, and was referenced in the video, is that we want to use a custom version of the Sysmon config file instead of the defaults that come with the app. Most people would be comfortable recommending you start with the version provided by Swift On Security and adjust it to meet your needs.
On the Active Directory server I rename the file to ‘config.xml’ and move it into C:\Windows.
Next, I move into the Sysmon folder and install the app.
.\sysmon64.exe -accepteula -i c:\windows\config.xmlRepeat the same process for the Windows workstation and any other Windows computers in your lab.
Ingesting Data
Now that we have our systems properly set up to log everything that we care about (at least as much as a Windows system can be) we can now focus on pushing all that data into our SIEM.
There are two types of agents that we are going to use in the lab - Beats and the new Elastic Agent via Fleet.
Elastic Beats
Beats are open source data shippers that you install as agents on your servers to send operational data to Elasticsearch.
These are the traditional agents used by Elastic over the years (though Elastic is capable of ingesting a variety of data sources) and there are several different kinds of Beats but the one we are going to use for this lab is Winlogbeat.
Winlogbeat’s primary function is to gather Windows Event Logs and ship them to Elastic. We are only going to install it on the Active Directory server as we are going to save the Elastic Agent for our workstation.
From within the Domain Controller go to the download page for Winlogbeat and grab the 64-bit zip file.
https://www.elastic.co/downloads/beats/winlogbeatFrom the Downloads folder extract the zip file into the C:\Program Files folder.
Rename the new Winlogbeat-<version> folder to just Winlogbeat.
Open a command prompt as Administrator and launch Powershell with the execution policy bypassed.
Move into the Winlogbeat folder and run the install script.
.\install-service-winlogbeat.ps1Winlogbeat is now installed but we need to configure it to point to our Elastic server.
Launch Wordpad (or download and use Notepad++) and open the winlogbeat.yml file in the Winlogbeat folder (if using Wordpad make sure to change the file t ype to ‘All Documents’ in order to see the YAML file).
Why not just use Notepad.exe? Unfortunately notepad does not respect the formatting of a YAML file and we need to maintain that in order for everything to work properly.
Once you have the file open you can optionally change the view to ‘No wrap’ to make it a little easier to work with.
Scroll down to the section called Elasticsearch Output.
Change the output.elasticsearch host to your Elastic server IP address (but keep the port as 9200).
Uncomment the line for protocol and change it to ‘http’.
Uncomment the lines for username and password, leave the username as ‘elastic’ and change the password value to whatever you set it to before.
You will also want to find the section called ‘Kibana’, uncomment the line for the host, and change the value to the IP address of your Elastic server.
Save your changes and move back to the command line to run the agent setup. This loads assets such as the recommended index template as well as some prebuilt Kibana dashboards.
.\winlogbeat.exe setup -eStart Winlogbeat.
Start-Service winlogbeatOn your Elastic server, go to the ‘Discover’ page in the Kibana admin dashboard.
Change your index pattern to ‘winlogbeat-*’ and voila!
Elastic Agent
The final bit of installation for our lab is to set up the new Elastic Agent on our Windows 10 workstation. The idea behind the Elastic Agent is to merge all of the different Beats agents into one unified client that also includes security features such as anti-malware protection.
As of this writing the new agent is still in beta so definitely do not deploy this in your production environment; you should absolutely go wild in your home lab though and have some fun with it.
To start we need to go to the ‘Fleet’ page in the Kibana dashboard.
You will notice at the bottom of the page that Fleet is also in beta and should not be used in production.
Next we are going to go all the way to the right of the page and click on ‘Settings’.
Make sure that the URLs for Kibana and Elasticsearch both point to the IP address of your Elastic server (leave their respective ports alone). Save any changes that you make.
Next, go to Integrations -> Installed Integrations -> Endpoint Security.
Click the button to ‘Add Endpoint Security’.
Leave the agent policy set to ‘Default policy’, put in whatever name you like for the integration setting, and click ‘Save Integration’.
You should be automatically taken to the Policies tab where you can view all the integrations currently configured for the default policy.
Next, go back to Integrations -> All Integrations, search for ‘Windows’, and click on it.
Click on the button to ‘Add Windows’.
Follow the same procedure you did before to add the Endpoint Security integration and save your changes. You should now have the Windows integration installed alongside the others.
Next, go to the ‘Agents’ tab and click the button to ‘Create user and enable central management’.
Click the button to ‘Add Agent’.
You should now see instructions to install the Elastic Agent - first by downloading the 64-bit zip file on our Windows 10 workstation.
Similarly to how we set up Winlogbeat on the Active Directory server we need to do the same for the Elastic Agent by extracting the zip file to C:\Program Files.
Rename the folder to ‘Elastic-Agent’.
Open Powershell as administrator and move into the new folder.
Back in the Kibana Fleet dashboard copy the install command that has been auto-created for you.
Back on your workstation, paste the command into the Powershell terminal, add in the flag ‘—insecure’, and hit ENTER.
Back in Kibana you should now see your workstation in the Agents tab.
If you made it this far snap yourself a beer and pat yourself on the back!
It was a lot of work to get this far but it will be worth it once you see the capabilities of Elastic and how it can help you as a security professional. At this point you are now fully set up with your new Elastic Stack and I would encourage you to play around with it and see all the things it can do. In the next and last part of this series I will be demonstrating some of the cool features and use cases as well as point you towards some resources that you can use on your own.