SigmaHQ Essentials - Building Robust Detection Capabilities

Intro

We advocate and discuss SigmaHQ repository of detections frequently on Thursday Defensive, but we never go into too much detail. There are always lingering questions of what type of detections do we use? How do you tune those rules? What other tools use these rules? So as one of the detection engineers at Recon, I figured I would share some of the knowledge I’ve obtained over the last 6 years of dealing with SigmaHQ detections in my day-to-day operations.

This series of blog posts should cover the basics to get you started. What is SigmaHQ? How are detections written? How can detection engineering be integrated into your tools/soc/security team? And a few other fancy uses you can get out of this free and amazing repository of detections.

What exactly is a SigmaHQ detection, who uses this and why do I care?

SigmaHQ is a GitHub repository where detection engineers, threat hunters, and defensive security practitioners collaborate on detection rules. This open-source approach to detection engineering has allowed for greater collaboration within the community and much faster response to finding malicious activity. Having a singular format used by the community allows for easy integration/query building for other platforms like Splunk, Elasticsearch, Microsoft365 Defender, and CarbonBlack to name a few. If you are interested in testing the conversion tool or doing a deeper dive later, you can visit their readme, which provides wonderful documentation and tools to get started with Sigma.

Now that we know what Sigma is, who is out there using this tool? Well, the answer is many large companies use these detections to bolster the effectiveness of in-house tools, public tools, and SIEM platforms. Some commonly used tools include: MISP, JoeSandbox, Lima Charlie, and IBM (now Palo Alto) QRadar. VirusTotal is a perfect example of a database where many users may have uploaded a file or hash and may have scrolled right past the open-source detections.

Now you understand what Sigma is and who uses it. That leaves us with why you should care? While there is a laundry list of reasons, I will list some of the top ones for Recon InfoSec.

1. Sigma is consistently updated by some of the top professionals in the field, especially the emerging threat rules. (The amount of times I’ve seen a CVE being reported followed shortly by a new rule posted by Florian Roth is crazy.)
2. The ease of writing detections or using detections as code with various tools (I have taught people to use the format, and they were writing detections within the same day!)
3. Integration with various log sources from O365, Okta, and sysmon, along with being able to function across the spectrum of current operating systems (SigmaHQ process creation rules + sysmon = huge wins).
4. They can be used in single-tenant and multi-tenant environments.
5. The ability to do research with the information and data contained within references and descriptions of the detections is a huge help for getting more context.
6. Ability to integrate queries with conversion tools into threat hunts across multiple platforms.
7. Allows smaller SOCs/security teams to have more firepower and be more flexible while combating threats on a daily basis.
8. Easy to maintain once implemented. Tuning and updates are a simple matter of checking for updates against the repository or adding exclusions.

Alright, you have sold me on using Sigma. It is the best thing since 50 cent taco Tuesday. So how do I go about building one of these rules?

Writing a Sigma detection rule involves a structured approach using YAML syntax. Each rule is made up of several key components that define the behavior or activity you want to detect in your SIEM system. Here's a breakdown of a rule we use and its main components:

1. Title

• Example: Pass the Hash Activity
• This is a brief, descriptive name for the rule that indicates what it detects.

2. ID

• Example: f8d98d6c-7a07-4d74-b064-dd4a3c244528
• This is a UUID which is used to uniquely identify the detection and make it easier to find.

3. Description

• Example: Detects the attack technique pass the hash which is used to move laterally inside the network.
• Provides additional details about what the rule is meant to detect.

4. Logsource

5. Detection

• Selection: Specifies the conditions that must be met for the rule to trigger.
• Filter: Optional part used to exclude certain log entries that would otherwise match the selection.
• Condition: Defines the logical relationship between the selection and filter (e.g., selection and not filter).

6. False Positives

• Example: false positives: - Administrator activity
• Lists scenarios where the rule might trigger, but the activity is benign.

7. Level

• Example: level: medium
• Indicates the severity or priority of the alert (e.g., low, medium, high).

8. References

• (Optional) This section includes links or citations to external sources, such as security advisories or documentation, that provide context or justification for the rule.

9. Tags

• (Optional) Tags categorize the rule for easier management and retrieval.

Example Sigma Rule:

Yaml

Tools for Writing Sigma Rules

Tools like pySigma and sigma-cli can be used to convert these YAML-based Sigma rules into the native query language of your SIEM system, making deployment straightforward. (GitHub)​ (Explore Sigma).

While I can go on a tangent about rule creation, the example above is a general, solid rule. Stay tuned for more content and blogs to come in the future. In part 2, we’ll cover how to write a detection from scratch, tuning these rules, and where to implement/use them.

SigmaHQ allows you to be versatile against most platforms that aggregate log data. Recon has become incredibly adept at taking existing rules that have been shared with the community along with creating our own to leverage them against log data to find bad actors. We hope by publishing this information, we can contribute to elevating the art of security operations.

If you have any questions or would like to discuss further, please contact info@reconinfosec.com