Writing Sigma Rules Flashcards
Writing Sigma Rules
In this activity you’re going to be taking a look at some Sigma rules and writing your own by editing a pre-built rule. The purpose of this activity is to get you familiar with a vendor-agnostic detection format that can be applied to major SIEM providers, but also to develop your ability to think logically about detections.
First, you’ll need to go download the Sigma master ZIP file from the Github:
Once you have the .ZIP file we need to extract the contents. To make things easier create a folder on your Desktop called ‘BTL1-SIGMA’, move the downloaded ZIP file to this folder, then extract it.
Writing Sigma Rules 2
Open the ‘rules’ folder – we’re presented with a number of sub-folders that contain some basic rules:
Writing Sigma Rules 3
Now go into the ‘network folder’ and then open ‘net_dns_c2_detection.yml’ in Sublime Text 2 (or your text editor of choice):
Writing sigma rules 4
Before we start customing this rule to suit our own needs, let’s recap exactly what this rule is doing and how it’s formatted. Take note of the different rows explained below, as you’ll be editing some of these very soon!
Writing sigma rules 5
title is a custom descriptive value that is used to provide a very brief explanation of what the rule is looking for.
id is used as a unique identifier for this rule.
status is a custom descriptive value used to explain the state of the rule. Some examples could include ‘incomplete’, ‘experimental’, or ‘production’.
description is a custom descriptive value used to provide a more detailed explanation of what the rule is trying to detect and how.
See above.
author is a custom value used to hold the author(s) of this SIGMA rule.
date is a custom value used to hold the date the rule was first created.
modified is a custom value used to hold the date when the rule was last edited by an author.
references is a custom list that holds URLs that help to explain what the rule is trying to detect
see above
see above
logsource is used to explain what logs are required in the SIEM for the rule to function
the logsource category is dns, showing that the security team will need to be pulling dns logs into their SIEM for the rule to work
detection explains the logic behind the rule including conditions that, when met, can generate an alert.
selection states that something must be selected from the DNS logs. In this case it’s the parent domain (or root domain, such as Google.com).
parent_domain states the log field that should be selected. The * asterisk symbol represents a ‘wildcard’ meaning that any value can be used. This means that ANY domain should be selected.
condition states the actual detection logic. For this rule it will retrieve all parent_domain values and count the number of queries to that domain. If the count is over 1000 (> 1000 meaning greater than 1000) then it will alert.
falsepositives is a custom list that states how false positives could occur.
falsepositives 2 – The author explains that legitimate software that uses dns to transfer data would generate an alert, even though it is not malicious activity.
level is a custom descriptive value that in this rule appears to be stating how urgent this alert should be.
tags is a custom list that includes different MITRE ATT&CK techniques that can be detected using this rule.
So, we know that this rule is used to detect potential DNS tunneling for command-and-control communication by looking for a large number of queries to domains, and will alert when 1001 or more requests have been observed by looking at DNS logs.
Now it’s your turn to make some changes, allowing us to detect some specific activity. Read the intelligence briefing below and try to make changes to this existing rule file to reflect the information provided.
Intelligence Briefing
We’ve recently observed a new type of malware that we have named ‘TRANSPORTER’ which uses DNS tunneling to provide a command-and-control channel across the internet, allowing an attacker to send commands to infected systems. As DNS traffic is extremely common in environments this traffic blends in and does not immediately look suspicious. DNS packets contain many fields and headers in which data can be concealed.
At the time of writing, we have only observed one domain name that is being used to send and receive C2 traffic, which we have included below. Speaking with one victim we observed that their SIEM did not detect this activity as they were not monitoring for excessive DNS queries to domains.
Domain Name: redhunt.net
Average Number of Requests: 500
MITRE ATT&CK Techniques Used: T1071.004 (Application Layer Protocol: DNS)
Tips
You can remove the ‘id’ and ‘modified’ lines from the existing rule as they are not required.
Use the ‘title’ and ‘description’ lines to include information from the above intel briefing.
Consider the average number of requests, we should alert on something that is lower than this to catch any infections where the traffic count falls below this average.
