Sysmon Detection Rules, Playbooks, and Alerts
In my previous post, I covered how to configure a Wazuh agent and Symon to ship Symon logs to a Security Onion. Now that we have the benefit of increased visibility into process creation provided by Sysmon, we can configure Wazuh rules and/or Playbooks to detect and alert on malicious activity that may be found in Sysmon Logs.
Automate Detection and Alerting
Ok, so its important to understand why we implement rules or playbooks to detect and alert. We are attempting to automate the process of detecting and alerting on malicious behavior. Sure, we could try to manually comb through millions of Sysmon logs ourselves looking for malicious behavior but that clearly wouldn’t be feasible. Rules and playbooks are criteria that we define that if met trigger certain actions. As the logs are ingested in the database they are parsed and searched. If they meet the criteria that we’ve defined, the system can either ignore it or Alert depending on how we’ve configured it.
What Behavior Do We Want To Detect?
Before we can effectively implement rules or playbooks we need to establish what we are trying to detect. To do this we need to emulate malicious behavior. For this, we can use the Invoke-AtomicTest Powershell module by Atomic Red Team. Installation and detailed instructions on the use of this tool is outside the scope of this write up but I have included a link to the official wiki for instructions.
For this demonstration I’ve utilized two Atomic Red team tests. Each test executes Mimikatz in a slightly different method and we will implement rules or Playbooks to detect both. After I run each test, I will show the corresponding Sysmon log to show the behavior captured in the log so that we might implement rules or playbooks to obtain detection coverage.
- T1003.001-6 Offline Credential Theft with Mimikatz
- T1003.001-10 Powershell Mimikatz.
T1003.001-10 Powershell Mimikatz
- Symon logs are found in Event viewer under Application and Services/Microsoft/Windows/Sysmon/Operational
- If we click “find” and search for “mimikatz,” we will find a process creation log (event 1) with Mimikatz mentioned.
- In the command line we see the command that is executed by the script. We only care about the MimiKatz purposes of this write up. The part underlined in red may be able to be detected via rule or Playbook and generate an alert.
T1003.001-6 Offline Credential Theft with Mimikatz
Choosing Our Playbook or Rule
For the first test, I will demonstrate picking and implementing a “play” from the Detection Playbook that comes pre-installed with Security Onion. Although Playbooks don’t alert as quickly to malicious behavior (they run every 3 minutes) they don’t require restarting Wazuh and go into effect immediately. For this reason I prefer utilizing playbook’s for complex detections or for experimental detections. For the second test, I will demonstrate a Wazuh rule.
Find , Pick and test Your Play
- Scroll down and click to expand “view sigma”
- Under “detection” there are 3 selections. These field represent the parameters the playbook is searching for
- The condition is the criteria that must be met to generate an alert.
- Even with a rudimentary level of knowledge about Sigma rules, we can see that our desired command line behavior is represented in Selection 1 and 2.
The Detection Playbooks contains a great many community created sigma rules. You can run different Atomic Red team tests and try to find pre-made rules to establish coverage so that you may detect potential malicious action. If a rule hasn’t been created, you can create your own. Refer to the Sigma documentation and Playbook documentation.
Wazuh rules are a bit trickier to implement compared to Detection Playbook plays in my opinion. There aren’t as many well crafted rules in the community so you will more then likely need to create your own if rules are your sole source of detection. They are beneficial in that they can result in much quicker alerts since playbook only runs every 3 minutes.
Anatomy Of A Rule
- This is a rule written by the Wazuh Community. I had to modify the rule_id to match the schema established in the Security Onion install version of Wazuh.
- The top line identifies the rule ID. For custom rules, the ID must be assigned a value between 100000-120000
- The Level is also assigned on the top line. It can be between 0-16. Think of it as a scale of “severity” Active responses are crafted based on levels. I.e only respond to level “4” or higher.
- The if_group essentially says that if a rule in “sysmon_event1” group has been met then proceed to look at the conditions of this rule. In this case “sysmon_event1” are precrafted rules by Wazuh that deal with process creation
- The “field name” section is the value that we are searching for to determine whether suspicious activity exists. In this case its searching for “mimikatz.exe” in the event data “image” field in the Sysmon logs.
- The “Description” field just gives a brief description of why the rule is triggered. Note – Do not be too catastrophic or alarmist. It should “alert” the viewer but it shouldn’t trigger a panic attack. Keep it factual.
- This rule is essentially the Wazuh rule version of the Sigma Play I showed earlier. Notice that it is searching the command line field in the event data portion of the sysmon log.
- the field with the :: is selection_3 from the sigma playbook .
- Having two fields forces an “AND” operation.
- This rule was posted originally by Fabricio from Wazuh in the Wazuh google forum.
- For the Wazuh Build shipped with Security Onion, custom rules go into /opt/so/rules/hids/local_rules.xml
- Remember, its important that rule ID’s do not duplicate. Every rule must have an unique ID.
- Rules can be placed in “groups” as shown in the picture with the tag </group> at the beginning and end of the set of rules. It must also have a group name as shown in the picture.
- After placing rule inside that file, run
- After the Wazuh agent has restarted, ensure there are no errors in compiling the rules by running `sudo cat /nsm/wazuh/logs/ossec.log`
Testing Our Rule
- After the Wazuh manager has restarted, run your invoke-AtomicTest commands again.
- Check for alerts in the SOC alert page.
Implementing Wazuh Rules and Detection Playbook plays to detect and alert on malicious activity can seem like a daunting task. It doesn’t have to be. Take some time to read up on the documentation. Plan out which Atomic Red Team tests you’d like to run. Start with trying to detect simple activity like Mimikatz via a Playbook. When you are confident in your log analysis skills start trying to find community Wazuh rules to implement. Eventually, you’ll feel confident enough to take a stab at writing your own.