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 🚀

Requirements

• 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.

Deploy HELK

First, make sure you read the requirements to install HELK doc. Then, all you have to do is clone the repo and run the helk_install.sh script as shown below:

git clone https://github.com/Cyb3rWard0g/HELK /opt/HELK
cd /opt/HELK/docker
sudo ./helk_install.sh -p "hunting" -i "<ip-address>" -b "helk-kibana-notebook-analysis" -l "basic"

Install Winlogbeat

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 Winlogbeat
• Backup the winlogbeat.yml config inside of C:\Program Files\Winlogbeat
• 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: Start-Service winlogbeat .

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" \
      -d"{\"attributes\":{\"title\":\"logs-endpoint-winevent-etw-*\",\"timeFieldName\":\"@timestamp\"}}"
      do
          sleep 1
      done

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:

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 🏹.

Thank you for reading! and feedback is always welcome! 💜

References

https://docs.microsoft.com/en-us/windows/win32/api/evntprov/ns-evntprov-event_filter_descriptor

https://github.com/OTRF