Threat Hunting with ETW events and HELK — Part 2: Shipping ETW events to HELK ⚒
In the previous post, I went over the basics of the Event Tracing for Windows (ETW) model and also how to install SilkETW as a service to consume events in real-time via the event log. At this point, we are ready to start shipping the ETW events to an analytic platform such as the HELK project 😉.
In this post, I will show you how to send ETW events from a Windows endpoint to HELK with the help of a log shipper named Winlogbeat . In addition, I will show you how you can extend this setup and ship ETW events via Windows Event Forwarding (WEF) to a Windows Event Collector (WEC) server, and then send them to HELK via the same Winlogbeat log shipper.
This post is part of a four-part series. The other three parts can be found in the following links:
- Threat Hunting with ETW events and HELK — Part 1: Installing SilkETW 🏄♀🏄
- Threat Hunting with ETW events and HELK — Part 3: Hunt use cases ⚔️
- Threat Hunting with ETW events and HELK — Part 4: ETW events and Jupyter Notebooks 🚀
- This post assumes that you read the previous one, understand the basics of the ETW model, and already have SilkETW running as a service on a Windows endpoint.
SilkETW as a Service in a Nutshell
If you have SilkETW as a service running, but would like to refresh your memory on how it works, I put together the image below to show you how it leverages the ETW model to enable ETW events for collection, filtering and ingestion via the event log.
- It reads the contents of the provided SilkServiceConfig.xml config to identify the ETW providers it needs to enable and with what filters.
- It enables the ETW providers defined in the config file.
- It creates event trace sessions and subscribes them to the ETW providers
- It consumes events from the event trace sessions in real-time
- It writes consumed events to the SilkService-Log event log in real-time
SilkETW -> HELK Mode
If SilkETW is running as a service and it is populating the SilkService-Log event log, you are ready to install Winlogbeat and ship events to HELK.
git clone https://github.com/Cyb3rWard0g/HELK /opt/HELKcd /opt/HELK/dockersudo ./helk_install.sh -p "hunting" -i "<ip-address>" -b "helk-kibana-notebook-analysis" -l "basic"
The installation of Winlogbeat is pretty straightforward. You can follow the basic instructions from the official Winlogbeat Reference and get it up and running in less than two minutes or you could also follow the basic steps (simplified version) that I take to deploy it in my own environment:
- Download Winlogbeat installer zip package and decompress its contents to
C:\Program Files\on a a new folder named
- Backup the
winlogbeat.ymlconfig inside of
- Download new winlogbeat config from here. The reason why I only set the output.kafka option in my config is because I use the HELK project, and it uses Kafka as the first component in the data pipeline. Make sure you update the hosts IP address and Topic values to match your environment.
- Install Winlogbeat service. You can use the Winlogbeat PowerShell script:
& "C:\Program Files\Winlogbeat\install-service-winlogbeat.ps1"
- Start Winlogbeat service via PowerShell:
Explore Initial Data Shipped
Next, data will start flowing to the Kafka component of your HELK server. If for some reason, you didn’t want to use the HELK, and are doing this for the first time, you will have to create a Logstash config to filter the data and push it to a specific Elasticsearch index.
The following is an event sample that I captured while publishing raw data to the Kafka broker. Remember that the overall event schema has additional fields created by the Winlogbeat shipper. The actual ETW event is inside of a nested field as shown in the image below:
winlog > event_data > param1
Create Logstash Filter Config
Fortunately, the extraction of the ETW event from the nested field can be done via the Logstash Ruby Filter Plugin as shown below (inspired on Nate “neu5ron” Guagenti work). HELK already takes care of it for you!
Create Logstash Output Config
Once you extract the ETW event from the nested field, you need to set up an output config to send the events to a specific index in Elasticsearch. HELK already takes care of it for you!
Create Kibana Index Pattern
If you are familiar with the Kibana interfaces, you know that you have to create an index pattern to be able to visualize and interact with the data available in an Elasticsearch index. You can create it automatically with the following commands using the api saved_objects/index-pattern :
until curl -X POST "http://helk-kibana:5601/api/saved_objects/index-pattern/logs-endpoint-winevent-etw-*" \
-H "Content-Type: application/json" -H "kbn-xsrf: true" \
You will see the new index pattern in your Kibana index patterns view. Remember, HELK already takes care of it for you! 😱 🍻
Discover ETW Events
You can now query all the events shipped from the Microsoft-Windows-DotNETRuntime ETW Provider (GUID: e13c0d23-ccbc-4e12–931b-d9cc2eee27e4) assuming you used the SilkService config from the first post..
Discover > Index Pattern drop-down list > logs-endpoint-winevent-etw-*
Thats it! 🔥 🚒
Now, with a flat schema, you can easily filter original field names available from the Microsoft-Windows-DotNETRuntime ETW Provider events.
Can I Consume SilkService-Log via WEF?
Yes, you can set up Windows Event Forwarding (WEF) in your environment and send ETW events from the SilkService-Log to a Windows Event Collector (WEC). Then, you can install a log shipper on your WEC and ship them over to your HELK instance as shown before.
You would need to add at least the following components to the basic setup:
A Domain Controller
- A Domain to join Windows workstation and get policies applied to it
- A group policy object (GPO) to enable and set up WEF settings and Windows Remote Management (WinRM) services on all endpoints
A Windows Event Collector Server
- The wecsvc service running
- A SilkService-Log WEF Subscription
- A WEC Source Computer Initiated Subscription Setup
- A Winlogbeat config to consume ForwardedEvents (ETW events) and send them over to a HELK instance.
Windows Endpoints Setup
- Endpoints joined to the domain to apply the WEF and WinRM GPOs.
- A SilkService Config applied to endpoints. You can use the one from the first post, or another one with more ETW providers like the one below:
Is there a way to automate the deployment of all that? 😜
Yes! you could use vagrant and packer scripts to deploy all that at home. However, I would like to also be able to dynamically deploy and destroy the environment whenever I want even when I am not at home.
Enter the Blacksmith Project
The Blacksmith project is a project from the Hunters Forge community that focuses on providing dynamic easy-to-use templates for security researches to model and provision resources needed to automatically deploy applications in the cloud. It currently leverages “AWS CloudFormation” to model infrastructure in AWS and I use it to manage and store configurations and scripts to deploy the official small network environments to generate datasets for the Mordor project.
Currently the project has one environment named “The Shire”, and it leverages free telemetry from Sysmon and Windows event logs. However, with the development of SilkETW, I decided to create a second environment which Ruben Boonen (@FuzzySec) named Erebor (love it! 🙌) for researchers to use SilkETW as a service on more than one endpoint.
What is Erebor?
SilkETW + WEF + HELK = The Erebor Environment ⚔️
The Mordor environment Erebor is a small network similar to the shire , but with SilkETW running as a service for free telemetry, Windows Event Forwarding (WEF) set up to send events from the SilkService-Log event log to a Windows Event Collector (WEC), and Winlogbeat installed on the WEC to ship events from the ForwardedEvents event log over to a HELK instance.
How do I deploy the Erebor environment?
As I mentioned before, the Blacksmith project currently leverages “AWS CloudFormation” to model the needed infrastructure in AWS. Therefore you will have to first follow the steps available in the Blacksmith wiki to set up everything needed from an AWS perspective. Once you get all that set up, you can follow the instructions available here:
What If I just want to deploy the basic SilkETW to HELK Setup? 🌟
I also created a basic setup to only deploy a HELK instance and one Windows 10 workstation with SilkETW running as a service. All the configs and scripts are also available in the Blacksmith project. Same as the Erebor build, once you complete the AWS requirements, you can follow the instructions available in the wiki:
This is it for the second post of this series. I hope this was helpful to anyone that wanted to send SilkETW events in real-time to a HELK instance for additional analysis and research purposes. In the next post, I will show you how useful ETW events are to detect adversarial techniques by leveraging the Erebor environment setup 🏹.
If you had never heard of the Hunters Forge community, but like the projects, and would like to continue the conversation, feel free to join our slack channel by going to the following link:
Thank you for reading! and feedback is always welcome! 💜