What Are SIGMA Rules: Beginner’s Guide

WRITTEN BY

Adam Swan

Threat Hunting Engineering Lead

[post-views]

May 16, 2022 · 14 min read

Table of contents:

This blog post argues for SIGMA as a detection language, covers the most critical SIGMA rule components (logsource & detection), SIGMA taxonomy, testing SIGMA Rules, and generally prepares analysts who are new to SIGMA to write their first rules. A short discussion on detection engineering with SIGMA is also provided regarding noise, ideas, log sources, etc.

The Case for SIGMA Rules

In the past, SIEM detections existed in vendor / platform specific silos. Partners wishing to share detection content often had to translate a query from one vendor into another. This is not sustainable, the defensive cyber security community must improve how we share detections to keep pace with our ever-evolving adversaries.

Much like YARA, or Snort Rules, SIGMA is another tool for the open sharing of detection, except focused on SIEM instead of files or network traffic. SIGMA allows defenders to share detections (alerts, use cases) in a common language.

First released in 2017 by Florian Roth and Thomas Patzke, SIGMA is paving the way forward for platform agnostic search. With SIGMA, defenders are freed from vendor & platform specific detection language and repositories and can harness the power of the community to respond timely to critical threats and new adversary tradecraft.

There are many reasons to use SIGMA:

Researchers and intelligence teams who identify new adversary behaviors and want an agnostic way of sharing detections
MSSP / MDR responsible for multiple SIEM / EDR / Log Analytics solutions & data taxonomies/schemas (ECS, CEF, CIM, etc)
Avoid vendor-lock in, by defining rules in a SIGMA we can more easily move between platforms.
Researchers in the offensive security space wanting to create detections based on their research

Note: In this blog SIEM is used to describe any platform used to collect and search on logs. I accept that many of the platforms listed may not fit your definition of “SIEM”. However, using the terms “platform” or “log platform” is too ambiguous.

Creating SIGMA Rules

Writing SIGMA rules requires having basic knowledge on the SIGMA schema and taxonomy, having an idea, fitting that idea to SIGMA, testing, sharing, and potentially maintaining the rule.

Recommended Background & Context

Despite the length of this blog, thanks to YAML and forward thinking by the creators, SIGMA is easy to understand and write. At SOC Prime we like to say “anyone can learn SIGMA”. The art of detection engineering is where things can get more complicated.

There are many other resources such as the official wiki and some guides written by SIGMA experts (listed below). There are certain traps such as proper handling of wildcards or incorrect field names that can cause broken rules and many of these are addressed in these resources.

If you are a researcher looking to get into SIGMA, SOC Prime’s Threat Bounty Program is a great opportunity to get started and earn a little bit of cash. Submitted rules go through a thorough review process where we can guide you and help you understand mistakes and grow as an analyst.

Recommend Reads:

How To Write SIGMA Rules, Florian Roth 2018
A Guide to Generic Log Sources, Thomas Patzke 2019

Recommended Watch:

All About SIGMA – Adam Swan

Types of Detections SIGMA Rules Сan Express

Today there exist currently two basic types of rules:

SIGMA Rules based on matching, widely supported, easiest to write
SIGMA Rules based on matching and simple correlations, limited support, less easy to write

Note: There are also multi-yaml SIGMA rules, however these have generally fallen out of favor for log source specific rules. The SOC Prime Team generally doesn’t create multi-yaml rules because they add unnecessary complexity to rule maintenance and deployment. Someone can create a multi-yaml SIGMA rule if they can create two SIGMA rules.

Let’s Create a Simple SIGMA Rule!

An idea (and some thoughts on detection engineering with SIGMA)

Users and administrators often keep sensitive passwords in plaintext documents such as text files, excel, word, etc. I am concerned that adversaries may identify these files before I do in an environment. We want to instruct our users on how to properly store passwords before they are discovered by a criminal hacker.

For many SIGMA rules it is at the author’s benefit to abstract the idea and broaden the target ‘reasonably’. For ideas such as this we can take educated guesses of what the behavior may look like, not only what we have observed. For instance, we may make educated guesses on additional terms and extensions that users may use to store passwords in plaintext.

The idea of ‘broadening’ a rule is counterintuitive to many analysts’ instincts. Killing all ‘false positives’ is not necessarily the goal of the original author when a rule will be consumed in unknown and unfamiliar environments. We can let the EDR and Anti-Virus vendors worry about creating detections that can’t have any false positives. With SIGMA rules can be tested in environments, and tuned easily.

SIGMA is easily understood, testable, and tunable. If a term like ‘details’ is too noisy for an environment, the person implementing the rule should feel empowered to tune the rule. Deploying all rules at once without testing is a recipe for disaster. Turning rules off instead of digesting and tuning their intentions for an environment will cause a shop to miss out on solid detection content.

I like to give the example of psexec. In some environments, psexec is completely normal and the status-quo for administrators remotely administer hosts. In other environments, psexec is (probably rightfully) unapproved, blocked, and an actionable offense for administrators to use. So, is a SIGMA rule to detect any psexec usage usage ‘noisy’ or just better for some environments than others. If you deploy content without testing, tuning noise will always be a problem. Only those rules identified as “critical” are meant to be safe to use without testing.

Back to creating our password exposure SIGMA rule.. we can expand the idea to include additional file names such as:

pw
psw
pass
password
passwords
accounts
account
info

Created with software like:

Notepad
Notepad++
Wordpad
Office Applications

A data source / A log source

Once we have an idea, we will need a log source. SIGMA supports any log source theoretically, however we should identify a log source that most folks have. For instance, we might be able to write a rule for a Data Loss Prevention log source but Data Loss Prevention is rarely parsed and ingested into SIEMs, and the industry hasn’t a clear favorite. So, we can create a valid rule, but it will not be as easily adopted.

For Windows endpoint rules, Sysmon is a great place to start. Sysmon is commonly deployed in environments, and many log sources provide synonymous data (EDRs, etc). With Sysmon there are two main options, process creation (process_creation in SIGMA) and file create (file_event in SIGMA).

We will build our detection off of process creation as it is more broadly adopted, thus ensuring our rule is as useful as possible. Process creation is a great log source to learn from and it is one of the most useful / popular log sources used in endpoint detections.

Note: Often ideas come directly from data sources themselves. By reviewing the types of data available to you in your SIEM / Lab one can easily identify SIGMA rules worth writing. We can also use other sources like vendor documentation.

With sysmon process creation events (Event ID 1), a user accessing a file containing passwords may contain these interesting fields:

Image: C:\Windows\System32\notepad.exe
CommandLine: “C:\Windows\System32\NOTEPAD.EXE” C:\Users\John\Desktop\password.txt

Fitting the detection idea to SIGMA

Now that we have an idea, and a data source to work with, we can begin to build our rule.

This isn’t documented but the true minimal components required to translate a rule are just logsource & detection (for some backends like Splunk, just detection is enough). Everything else is ‘just’ metadata to help the SIGMA rule consumer. When you start it is in your interest to start with these minimal fields, confirm your logic is working and then add additional SIGMA fields & data. If you want to publish your rule to the public SIGMA repo it is worth checking previous submissions and emulating their formatting.

A basic SIGMA rule with minimal components for potential password exposure:

title: Potential Password Exposure (via cmdline)
author: Adam Swan
tags:
  - attack.t1552.001 
  - attack.credential_access
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    Image|endswith: 
      - '\notepad.exe'
      - '\word.exe'
      - '\excel.exe'
      - '\wordpad.exe'
      - '\notepad++.exe'
    CommandLine|contains:
      - 'pass' #pass will match on password, including password is redundant
      - 'pwd'
      - 'pw.' #pw.txt, etc. 
      - 'account' #accounts, 
      - 'secret'
      - 'details' #I included plural details based on experience
  condition: selection

Logsource component

The logsource component helps the SIGMA backend translator (SIGMAC) know what type of data the rule should be acted against. It empowers the rule creator to create more generic rules. For instance, with logsource being “product: windows, category: process_creation” we do not need to specify EventIDs (Sysmon 1, Windows 4688, ProcessRollup, etc). The consumer of the rule can specify what event ids, indexes, etc they want to be associated with log sources in the SIGMA Config. Without specifying indexes, event ids, etc rules will likely be unnecessarily expensive (performance) for the consumer.

Additionally, often telemetry can contain similar fields but imply entirely different behaviors. For instance, Sysmon network connection events (Event Id 3) and process creation (Event ID 1) share the Image field. The existence of explorer.exe in the Image field of a Sysmon network connection event is completely different from the existence of explorer.exe in a process creation event. By providing the proper logsource component we provide invaluable context to the detection.

Detection component

The detection component is where the author defines their detection criteria. This includes at least one selection component and a condition component. There is an optional timeframe component which is required for correlation based rules.

Selection sub component(s):

Generally, this will take the form Field A contains/startswith/endswith/equals Value B. Of course, as observed in the example rule above, if an author needs they can expand and include logic such as Field A contains/startswith/endswith/equals Values X, Y, or Z. This logic is always case insensitive.

There are more advanced ‘modifiers’ that increase the complexity of the rule, or enable authors to be more precise. For instance, regular expressions are handled through the operator re and enable authors to do things such as write case sensitive queries. For compatibility purposes it is best to stick to only the basic regular expression operators . ? + * | { } [ ] () “ \.

Selections are named (e.g. selection, selection2, selection3, filter). Selections can be named (almost) anything you want. Often a variation of selection is used, but one can just as easily name their selection banana and the rule would still work. Generally, the term filter is used for selections that will be excluded (e.g. selection AND NOT filter).

Condition sub component:

The condition component contains boolean logic (AND, OR, NOT) defining how each selection should be included in the final query.

E.G. (selection_a OR selection_b) AND NOT filter

Condition component with correlation:

There are two types of correlations supported by backends today. There are other correlations supported by the SIGMA schema.. but not yet by the available backends.

Count() by Y:

Count the unique instances of Y field value and compare (greater than, less than) it to a static number.

Example: Count() by src_ip > 2

Count(X) by Y:

Count the unique instances of X field value per Y value and compare (greater than, less than) the count of X to a static number.

Example: Count(EventID) by src_ip > 2

Common Correlation Use Cases:

Count() by src_ip > 10	Count unique matching events by the source IP.
Count() by dst_ip > 10	Count unique matching events by the destination IP
Count(EventID) by ComputerName	This will let you search for unique instances of eventid. For instance, if you want to chain sysmon event ids 1 (process creation) AND event id 5. e.g. a process is created and terminated in less than 1 min.

Timeframe Sub Component:

The timeframe component is used in conjunction with conditions that include a correlation. Many backends ignore the timeframe, however, it is generally always included and required to be included in most repositories including SOC Prime’s.

Complete Examples Using Splunk:

Here are some examples of SIGMA and their translations for Splunk. If you are not familiar with Splunk, asterisks are a wildcard so a term surrounded by asterisks (e.g. *term*) is ‘contains’, a term with a leading asterisk (e.g. *term) is endswith, a term with a trailing asterisk is ‘endswith’ (e.g. term*).

SIGMA detection component	Splunk Translation (Asterisk is a wildcard)
detection: selection: fieldX: 'suspicious' condition: selection	fieldX="suspicious"


detection: selection: fieldY\|contains: - 'suspicious' - 'malicious' - 'pernicious' condition: selection	(fieldY="suspicious" OR fieldY="malicious" OR fieldY="pernicious")


detection: selection: - fieldX: 'icious' - fieldX: - 'susp' - 'mal' - 'pern' condition: selection	(FieldX="icious" AND (FieldX="susp" OR FieldX="mal" OR FieldX="pern"))
detection: selection: - FieldX\|endswith: 'icious' - FieldX\|startswith: - 'susp' - 'mal' - 'pern' condition: selection	(FieldX="icious" AND (FieldX="susp" OR FieldX="mal" OR FieldX="pern"))
detection: selection: FieldX\|endswith: 'icious' filter: FieldX\|startswith: - 'del' - 'ausp' condition: selection AND NOT filter	(FieldX="icious" AND NOT ((FieldX="del" OR FieldX="ausp*")))
detection: selection: FieldX: 'suspicious' timeframe: 1m condition: selection \| count by src_ip > 3	FieldX="suspicious" \| eventstats count as val by src_ip\| search val > 3 #notice splunk ignores the timeframe value, the value must be set at search by the user
detection: selection: FieldX: 'suspicious' condition: selection \| count(ComputerName) by src_ip > 3	FieldX="suspicious" \| eventstats dc(ComputerName) as val by src_ip \| search val > 3

Taxonomy Questions (e.g. what field names to use)

Theoretically you can use whatever field names you wish, as long as someone is willing to put in the time to write a SIGMA Config to translate from your fields.. to theirs.

Note: Field names are case sensitive! CommandLine and commandline are two different values. CommandLine is part of the existing taxonomy, commandline is not.

That being said, it is best to use field names that are documented by SIGMA. There are three places the public SIGMA repository documents the taxonomy.

As a general rule we use the SIGMA field names specified in the wiki for categories
- https://github.com/SigmaHQ/sigma/wiki/Taxonomy
- The wiki will reveal to readers that SIGMA uses
  - SYSMON fields for endpoint rules
  - W3C Extended Log File Format for webserver & proxy rules
  - The fields for firewall, antivirus
Followed by SIGMA field names specified in existing rules & SIGMA config files
- https://github.com/SigmaHQ/sigma/tree/master/tools/config
  - Really the official documentation for fields. Users can create / modify these as required when they translate rules.
  - https://github.com/SigmaHQ/sigma/tree/master/rules

Then finally if no config or rules exist we use the original field names from the originating log source. If field names come from nested values (e.g. userIdentity nested under accountId in aws cloudtrail) we use a period to indicate that the field is nested as this is relatively consistent across different SIEMS (e.g. userIdentity -> accountId becomes userIdentity.accountId).

Testing SIGMA Rules

Testing SIGMA rules is simple. Often folks are even able to submit content without directly testing it themselves. Most public researchers do not have access to diverse environments to test rules against ‘the set of all SIEMs’. Instead, one can rely on public feedback, feedback from trusted parties, etc. Even Florian Roth, a co-creator of SIGMA regularly pushes rules to the public for feedback via his Twitter. I’ve also seen folks publish straight to their personal blogs and LinkedIn, etc. If you think you have a good rule to share, put it out there, trust me if it is wrong (or not) the lovely folks on the internet will let you know! Don’t take yourself too seriously and be prepared to make changes and learn something.

There are some basic steps you can take:

Ensure the rule translates (uncoder or by using SIGMAC)
Sanity checking (e.g. ensuring the rule meets your original expectation, follows the correct taxonomy, etc) – see pitfalls: https://github.com/SigmaHQ/sigma/wiki/Rule-Creation-Guide
Checking the rule in a lab environment
Sharing the rule broadly for testing / sharing the rule with the SOC Prime Team via the Treat Bounty Program

Note: From a rule author perspective, generally you should not worry about the backend implementations of rules. It is up to the SIGMA backend authors, and folks like SOC Prime to ensure that the translations meet the original intention of a valid rule. If a bug is identified, it is always worth submitting an issue to GitHub.

Call to Action & Future Work

If you made it this far, you are more than prepared to write and share your first rule! If you enjoyed this blog, you may enjoy another one coming soon about using SIGMAC to customize content.

Was this article helpful?

Like and share it with your peers.

Join SOC Prime's Detection as Code platform to improve visibility into threats most relevant to your business. To help you get started and drive immediate value, book a meeting now with SOC Prime experts.

Join for Free Book a Meeting

Blog, Latest Threats — 4 min read

UAC-0125 Attack Detection: Hackers Use Fake Websites on Cloudflare Workers to Exploit the “Army+” Application

Veronika Telychko

Blog, Latest Threats — 3 min read

DarkGate Malware Attack Detection: Voice Phishing via Microsoft Teams Leads to Malware Distribution

Veronika Telychko

Blog, Latest Threats — 4 min read

UAC-0099 Attack Detection: Cyber-Espionage Activity Against Ukrainian State Agencies Using WinRAR Exploit and LONEPAGE Malware

Veronika Telychko

SIGMA detection component	Splunk Translation (Asterisk is a wildcard)
detection: selection: fieldX: 'suspicious' condition: selection	fieldX="suspicious"


detection: selection: fieldY\|contains: - 'suspicious' - 'malicious' - 'pernicious' condition: selection	(fieldY="suspicious" OR fieldY="malicious" OR fieldY="pernicious")


detection: selection: - fieldX: 'icious' - fieldX: - 'susp' - 'mal' - 'pern' condition: selection	(FieldX="icious" AND (FieldX="susp" OR FieldX="mal" OR FieldX="pern"))
detection: selection: - FieldX\|endswith: 'icious' - FieldX\|startswith: - 'susp' - 'mal' - 'pern' condition: selection	(FieldX="icious" AND (FieldX="susp" OR FieldX="mal" OR FieldX="pern"))
detection: selection: FieldX\|endswith: 'icious' filter: FieldX\|startswith: - 'del' - 'ausp' condition: selection AND NOT filter	(FieldX="icious" AND NOT ((FieldX="del" OR FieldX="ausp*")))
detection: selection: FieldX: 'suspicious' timeframe: 1m condition: selection \| count by src_ip > 3	FieldX="suspicious" \| eventstats count as val by src_ip\| search val > 3 #notice splunk ignores the timeframe value, the value must be set at search by the user
detection: selection: FieldX: 'suspicious' condition: selection \| count(ComputerName) by src_ip > 3	FieldX="suspicious" \| eventstats dc(ComputerName) as val by src_ip \| search val > 3

Name	Descripiton
PHPSESSID	Preserves user session state across page requests. Cookie generated by applications based on the PHP language. This is a general purpose identifier used to maintain user session variables. It is normally a random generated number, how it is used can be specific to the site, but a good example is maintaining a logged-in status for a user between pages.
sp_i	Used to store information about authenticated User.
sp_r	Used to store information about authenticated User.
sp_a	Used to store information about authenticated User.

Name	Descripiton
tuuid	Collects anonymous data related to the user's visits to the website, such as the number of visits, average time spent on the website and what pages have been loaded.
tuuid_last_update	Collects anonymous data related to the user's visits to the website, such as the number of visits, average time spent on the website and what pages have been loaded.
um	Collects anonymous data related to the user's visits to the website, such as the number of visits, average time spent on the website and what pages have been loaded.
umeh	Collects anonymous data related to the user's visits to the website, such as the number of visits, average time spent on the website and what pages have been loaded.
na_sc_x	Used by the social sharing platform AddThis to keep a record of parts of the site that has been visited in order to recommend other parts of the site.
APID	Collects anonymous data related to the user's visits to the website.
IDSYNC	Collects anonymous data related to the user's visits to the website.
_cc_aud	Collects anonymous statistical data related to the user's website visits, such as the number of visits, average time spent on the website and what pages have been loaded. The purpose is to segment the website's users according to factors such as demographics and geographical location, in order to enable media and marketing agencies to structure and understand their target groups to enable customised online advertising.
_cc_cc	Collects anonymous statistical data related to the user's website visits, such as the number of visits, average time spent on the website and what pages have been loaded. The purpose is to segment the website's users according to factors such as demographics and geographical location, in order to enable media and marketing agencies to structure and understand their target groups to enable customised online advertising.
_cc_dc	Collects anonymous statistical data related to the user's website visits, such as the number of visits, average time spent on the website and what pages have been loaded. The purpose is to segment the website's users according to factors such as demographics and geographical location, in order to enable media and marketing agencies to structure and understand their target groups to enable customised online advertising.
_cc_id	Collects anonymous statistical data related to the user's website visits, such as the number of visits, average time spent on the website and what pages have been loaded. The purpose is to segment the website's users according to factors such as demographics and geographical location, in order to enable media and marketing agencies to structure and understand their target groups to enable customised online advertising.
dpm	Via a unique ID that is used for semantic content analysis, the user's navigation on the website is registered and linked to offline data from surveys and similar registrations to display targeted ads.
acs	Collects anonymous data related to the user's visits to the website, such as the number of visits, average time spent on the website and what pages have been loaded, with the purpose of displaying targeted ads.
clid	Collects anonymous data related to the user's visits to the website, such as the number of visits, average time spent on the website and what pages have been loaded, with the purpose of displaying targeted ads.
KRTBCOOKIE_#	Registers a unique ID that identifies the user's device during return visits across websites that use the same ad network. The ID is used to allow targeted ads.
PUBMDCID	Registers a unique ID that identifies the user's device during return visits across websites that use the same ad network. The ID is used to allow targeted ads.
PugT	Registers a unique ID that identifies the user's device during return visits across websites that use the same ad network. The ID is used to allow targeted ads.
ssi	Registers a unique ID that identifies a returning user's device. The ID is used for targeted ads.
_tmid	Registers a unique ID that identifies the user's device upon return visits. The ID is used to target ads in video clips.
wam-sync	Used by the advertising platform Weborama to determine the visitor's interests based on pages visits, content clicked and other actions on the website.
wui	Used by the advertising platform Weborama to determine the visitor's interests based on pages visits, content clicked and other actions on the website.
AFFICHE_W	Used by the advertising platform Weborama to determine the visitor's interests based on pages visits, content clicked and other actions on the website.
B	Collects anonymous data related to the user's website visits, such as the number of visits, average time spent on the website and what pages have been loaded. The registered data is used to categorise the users' interest and demographical profiles with the purpose of customising the website content depending on the visitor.
1P_JAR	These cookies are used to gather website statistics, and track conversion rates.
APISID	Google set a number of cookies on any page that includes a Google reCAPTCHA. While we have no control over the cookies set by Google, they appear to include a mixture of pieces of information to measure the number and behaviour of Google reCAPTCHA users.
HSID	Google set a number of cookies on any page that includes a Google reCAPTCHA. While we have no control over the cookies set by Google, they appear to include a mixture of pieces of information to measure the number and behaviour of Google reCAPTCHA users.
NID	Google set a number of cookies on any page that includes a Google reCAPTCHA. While we have no control over the cookies set by Google, they appear to include a mixture of pieces of information to measure the number and behaviour of Google reCAPTCHA users.
SAPISID	Google set a number of cookies on any page that includes a Google reCAPTCHA. While we have no control over the cookies set by Google, they appear to include a mixture of pieces of information to measure the number and behaviour of Google reCAPTCHA users.
SID	Google set a number of cookies on any page that includes a Google reCAPTCHA. While we have no control over the cookies set by Google, they appear to include a mixture of pieces of information to measure the number and behaviour of Google reCAPTCHA users.
SIDCC	Security cookie to protect users data from unauthorised access.
SSID	Google set a number of cookies on any page that includes a Google reCAPTCHA. While we have no control over the cookies set by Google, they appear to include a mixture of pieces of information to measure the number and behaviour of Google reCAPTCHA users.
__utmx	This cookie is associated with Google Website Optimizer, a tool designed to help site owners improve their wbesites. It is used to distinguish between two varaitions a webpage that might be shown to a visitor as part of an A/B split test. This helps site owners to detemine which version of a page performs better, and therefore helps to improve the website.
__utmxx	This cookie is associated with Google Website Optimizer, a tool designed to help site owners improve their wbesites. It is used to distinguish between two varaitions a webpage that might be shown to a visitor as part of an A/B split test. This helps site owners to detemine which version of a page performs better, and therefore helps to improve the website.

Name	Descripiton
_hjid	Hotjar cookie. This cookie is set when the customer first lands on a page with the Hotjar script. It is used to persist the random user ID, unique to that site on the browser. This ensures that behavior in subsequent visits to the same site will be attributed to the same user ID.
_hjIncludedInSample	This cookie is associated with web analytics functionality and services from Hot Jar, a Malta based company. It uniquely identifies a visitor during a single browser session and indicates they are included in an audience sample.
intercom-id-[xxx]	This cookie is used by Intercom as a session so that users can continue a chat as they move through the site.
intercom-session-[xxx]	Used to keeping track of sessions and remember logins and conversations.
demdex	Via a unique ID that is used for semantic content analysis, the user's navigation on the website is registered and linked to offline data from surveys and similar registrations to display targeted ads.
CookieConsent	Stores the user's cookie consent state for the current domain.
__cfduid	Used by the content network, Cloudflare, to identify trusted web traffic.
ss	These cookies enable the website to provide enhanced functionality and personalisation . They may be set by us or by third party providers whose services we have added to our pages. These services may include the Live Chat facility, Contact Us form(s), the Product Quotation forms and submission process, and the Email Newsletter sign up functionality .

Name	Descripiton
_ga	This cookie name is asssociated with Google Universal Analytics - which is a significant update to Google's more commonly used analytics service. This cookie is used to distinguish unique users by assigning a randomly generated number as a client identifier. It is included in each page. Registers a unique ID that is used to generate statistical data on how the visitor uses the website. request in a site and used to calculate visitor, session and campaign data for the sites analytics reports. By default it is set to expire after 2 years, although this is customisable by website owners.
_gat	Used by Google Analytics to throttle request rate. This cookie name is associated with Google Universal Analytics, according to documentation it is used to throttle the request rate - limiting the collection of data on high traffic sites. It expires after 10 minutes.
_gid	This cookie name is asssociated with Google Universal Analytics. This appears to be a new cookie and as of Spring 2017 no information is available from Google. It appears to store and update a unique value for each page visited. Registers a unique ID that is used to generate statistical data on how the visitor uses the website.
IDE	Used by Google DoubleClick to register and report the website user's actions after viewing or clicking one of the advertiser's ads with the purpose of measuring the efficacy of an ad and to present targeted ads to the user.
r/collect	Used by Google DoubleClick to register and report the website user's actions after viewing or clicking one of the advertiser's ads with the purpose of measuring the efficacy of an ad and to present targeted ads to the user.
test_cookie	Used to check if the user's browser supports cookies.
collect	Used to send data to Google Analytics about the visitor's device and behaviour. Tracks the visitor across devices and marketing channels.
ads/user-lists/#	These cookies may be set through our site by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant adverts on other sites.
c	Registers anonymised user data, such as IP address, geographical location, visited websites, and what ads the user has clicked, with the purpose of optimising ad display based on the user's movement on websites that use the same ad network.
khaos	Registers anonymised user data, such as IP address, geographical location, visited websites, and what ads the user has clicked, with the purpose of optimising ad display based on the user's movement on websites that use the same ad network.
put_#	Registers anonymised user data, such as IP address, geographical location, visited websites, and what ads the user has clicked, with the purpose of optimising ad display based on the user's movement on websites that use the same ad network.
rpb	Registers anonymised user data, such as IP address, geographical location, visited websites, and what ads the user has clicked, with the purpose of optimising ad display based on the user's movement on websites that use the same ad network.
rpx	Registers anonymised user data, such as IP address, geographical location, visited websites, and what ads the user has clicked, with the purpose of optimising ad display based on the user's movement on websites that use the same ad network.
tap.php	Registers anonymised user data, such as IP address, geographical location, visited websites, and what ads the user has clicked, with the purpose of optimising ad display based on the user's movement on websites that use the same ad network.

What Are SIGMA Rules: Beginner’s Guide

The Case for SIGMA Rules