SOC Automation Project - Part 5

Building a SOC automation Home Lab: Part 5 - Sending Telemetry Containing Mimikatz and Triggering Custom Alert

A step-by-step guide for building your very own SOC Automation Home Lab using VMWare and DigitalOcean cloud provider

In this module we will generate telemetry between our Wazuh agent and server. Additionally, we will create a custom rule that will trigger an alert on Wazuh Manager every time mimikatz.exe is detected on our agent.

Generating Telemetry

What is Telemetry

Telemetry refers to the process of collecting, transmitting, and analyzing data regarding the performance and activity of the Wazuh infrastructure and the endpoints it monitors. This data includes security events, operational metrics, and other relevant information essential for maintaining and optimizing the system’s functionality.

Wazuh Agent Log Configuration

To ensure Wazuh can detect any activity related to mimikatz, we need to modify the ossec.conf file, which is the main configuration file for Wazuh.

To do this, navigate to C:\Program Files (x86)\ossec-agent and open ossec.conf.

Backup the ossec.conf file before making any changes. Administrator rights are required to edit this file.

The Log Analysis section specifies the logs that Wazuh will ingest. That said, we will need to add Sysmon logs in order to Wazuh detect mimikatz activity.

We will leave active response and remove everything else, because we won’t need them for this project.

To achive this, add the following lines to the Log Analysis section:

• location: Insert Sysmon’s service full name which can be obtained from Event Viewer.

Save the changes and restart the Wazuh service.

To verify that the Wazuh Manager is ingesting Sysmon logs, access the Wazuh Dashboard and navigate to Modules > Security Events. Searching for “sysmon” should yield some results.

Downloading Mimikatz

Mimikatz is a tool used to extract sensitive information, such as passwords and credentials, from a system’s memory. To download mimikatz to our agent, we must exclude the Downloads folder from Windows Defender scans.

Go to Windows Security > Virus & threat protection (you can Dismiss that message) > Manage Settings > Add or remove exclusions > Add an exclusion and select the Downloads folder.

Now we can download mimikatz without it being blocked by Windows Defender. Download it here.

If you are using Firefox and it blocks the download, just select allow download. If you’re using Chrome, go to Settings > Privacy and security > Security and select No security under Safe Browing.

Extract the zip file.

With mimikatz on our host, execute it on a powershell terminal with administrator rights.

# Starting Mimikatz
.\mimikatz.exe

Next, to check if Wazuh logged our mimikatz use from our Agent, we can see that it dind’t recorded any event.

This occurs because Wazuh, by default, logs events only when a rule or alert is triggered.

Changing Wazuh to Log Everything

To ensure that Wazuh logs everything, including our mimikatz activity, we need to modify Filebeat’s config file and the ossec.conf file on the Wazuh server.

Log into the Wazuh server via SSH and make the following changes to ossec.conf:

Backup the ossec.conf file before making any changes.

• logall: Change it to yes.
• logall_json: Change it to yes.

With this modifications, Wazuh will archive all logs in the “/var/ossec/logs/archives” folder.

Save the changes with Ctrl+X and restart the Wazuh Manager service.

Configuring Filebeat

Filebeat is used to collect, ship, and centralize logs from various sources. It reads log files, forwards them to a specified output (Logstash or Elasticsearch), and ensures that all log data is available for further analysis and processing.

To make sure Wazuh ingests these archives logs, we’ll need to enable them on Filebeat’s config file:

# Configuring Filebeat
nano /etc/filebeat/filebeat.yml

Again, after saving the changes made, restart the service.

# Restarting Filebeat Service
systemctl restart filebeat

Creating a New Index on Wazuh Manager

To search all logs, we need to create an index for archives, regardless if Wazuh triggers an alert or not.

To do this, go to Wazuh Manager Dashboard, select the hamburguer button and navigate to Stack Management > Index Patterns > Create index pattern.

Name the index, choose timestamp as the time field, and create the Archives Index.

Head back to Discover and select the new index to check if we’re getting all logs.

To make sure it is working, rerun mimikatz on our Agent.

From Event Viewer, we can see mimikatz activity on sysmon events (Event ID 1=proccess create, we’ll use this for our custom rule later)

After a few seconds, if we search for mimikatz on our new index, we should get some hits.

Creating an Alert (Custom Rule)

Our next step is to create a custom rule that triggers an alert when mimikatz is detected. For this, we will use the data.win.eventdata.originalFileName parameter (we can see its value on our previous mimikatz event in Wazuh).

This field contains the original name of a file involved in an event. This way, if an attacker renames mimikatz, the rule will still be triggered and an alert will be created.

To create a custom rule, head back to the Wazuh Manager dashboard and go to Management > Rules > Manage rules files.

Here we are presented with the Wazuh ruleset. However, our focus is on Sysmon rules, specifically those targeting Event ID 1.

These built-in Sysmon rules in Wazuh target Event ID 1, and we’ll use them as a reference to create our custom rule.

Next, select Custom rules and edit the local_rules.xml file.

Below the default rule, insert our custom rule:

Make sure the indentation is correct!

  <rule id="100002" level="15">
    <if_group>sysmon_event1</if_group>
    <field name="win.eventdata.originalFileName" type="pcre2">(?i)mimikatz\.exe</field>
    <description>Mimikatz Usage Detected</description>
    <mitre>
      <id>T1003</id>
    </mitre>
  </rule>

• Custom rule IDs start at 100000, in this case, ours will be 100002.
• The level ranges up to 15, with higher numbers indicating greater severity.
• For the field name, we specify win.eventdata.originalFileName (which is case sensitive) and use mimikatz.exe as the value.
• Additionally, we include the MITRE ATT&CK ID T1003, which refers to Credential Dumping.

Save the changes and when prompted to restart Wazuh, press Confirm.

Testing

To check if our custom rule is working as intended, we will rename mimikatz.exe to something else, in this case we changed it to notepad.exe.

After starting “notepad.exe”, head back to the Security Events on Wazuh Manager to see if it gets triggered.

As we can see, our renamed mimikatz was sucessfully detected by our custom rule.

Next Steps

In the next and final module, we will automate some steps with Shuffle SOAR features.