Here is a fact for you, the SigmaHQ rule repository is one of the biggest vendor agnostic repository for detection rules today, with hundreds of yearly contributions and thousands of detection rules to maintain, hence, setting a standard is a requirement.

In this blog I will be showcasing how the SigmaHQ rule repository set this standard via various tooling and CI pipelines, in order to make sure that rule quality is consistent and deployment ready. Let’s get started.

It all starts with the specification

The first step in setting a standard for rule writing is actually defining that standard. We host a repository called Sigma-Specification where we describe exactly the constituents of a Sigma rule and its different type.

GitHub - SigmaHQ/sigma-specification: Sigma rule specification

The specification goes into details on what fields are required vs optional, how do these fields have to be written, for example either lists or strings. We also define what are the allowed tags, modifiers and taxonomy of field names.

All of this helps define how a rule should look like at a minimum, and avoid any confusion while writing them. While the Sigma specification aims to offer a maximum of compatibility, flexibility and customization (you can add all the meta data you want), offering a big rule repository as well, we need to be more strict there.

An Additional Layer of Enforcement — SigmaHQ Convention

The SigmaHQ rule repository is technically an implementation of the specification and targeted towards a much larger community of contributors. Therefore we extend the specification with a bunch of conventions that make sure all rules look the same at a format level. These conventions are only applicable to the rules repository and shouldn’t be confused with the Sigma specification which is only a subset of the requirements imposed on the rules repository.

These conventions can be found in the same specification repo in a dedicated folder.

sigma-specification/sigmahq at main · SigmaHQ/sigma-specification

Currently we define 3 types of conventions.

• Filename Convention - That ensures that files can easily be identified via their filename and sorted accurately in their respected folders according to the logsource they target.
• Title Convention - This convention ensures that rules do not have random titles but instead, the aim is convey exactly what the rule is detecting by using the appropriate language
• Rule Convention - Basically enforces certain aspects that the general specification leaves either optional or not defined intentionally. Such as the expected indentation the actual order of the fields, and how should a description, false positives sections should look like.

Validators Are Here To Validate

Having all of that defined in a repository somewhere is nice and all, but how do we make sure its enforced? The answer is CI.

Sigma-Rules-Validator Action

The first piece of CI we use is called sigma-rules-validator which takes the specification JSON schemas we provide and validate all rules against them via check-jsonschema

This GitHub Action is available here for anyone to use

GitHub - SigmaHQ/sigma-rules-validator: Validates Sigma rules using the JSON schema

PySigma Core Validators

As we’ve described above, the specification defines certain rules about required fields, the way certain field should be written, etc. These rules are coded into the sigma library pySigma into something called Validators .

pySigma/sigma/validators/core at main · SigmaHQ/pySigma

If you leverage the Sigma Command Line Interface sigma-cli you can call validate those rules via the sigma check command.

Some of these validators include

• Identifier Existence.
• Duplicate Title.
• Duplicate Reference.
• Invalid Tag Format.
• Dangling Conditions.

PySigma SigmaHQ Validators

For those astute readers, you might ask yourself what about the SigmaHQ convention how are those enforced, since they are not part of the specification.

Well, for that we created a new repository called pySigma-validators-sigmaHQ that extends the list of validators with ones that enforce the conventions we define at SigmaHQ rule repo.

GitHub - SigmaHQ/pySigma-validators-sigmaHQ

These might include:

• Filename enforcement.
• Field <-> Logsource Check.
• Presence of certain tags.

Good Log Validation

Now all of the syntax and conventions are validated, time to validate the logic.

One of the tests we integrated a couple of years ago is what we call a good-log test. The idea is simple at its core. Test the sigma logic against benign logs where if a match occurs than we know the logic needs updating.

For this we use a dataset that contains benign system process and every day application execution. The dataset is stored in the following repository.

GitHub - NextronSystems/evtx-baseline: A repository hosting example goodware evtx logs containing sample software installation and basic user interaction

We currently test against the following baselines.

• Windows 10 Client.
• Windows 11 Client.
• Windows 7.
• Windows Server 2022 Base.
• Windows Server 2022 With AD Role.
• Windows Server 2022 Azure Image.
• Windows 11 Client.

You can read more on how the data was generated in the repo itself. We highly encourage contributions ;)

We leverage the evtx-sigma-checker binary to test sigma rules against these logs. The example below showcase the CI job for testing against the Windows 7 dataset.

check-baseline-win7:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v5
    - name: Download evtx-sigma-checker
      run: wget --no-verbose https://github.com/NextronSystems/evtx-baseline/releases/download/$EVTX_BASELINE_VERSION/evtx-sigma-checker
    - name: Download and extract Windows 7 32-bit baseline
      run: |
        wget --no-verbose https://github.com/NextronSystems/evtx-baseline/releases/download/$EVTX_BASELINE_VERSION/win7-x86.tgz
        tar xzf win7-x86.tgz
    - name: Check for Sigma matches in baseline
      run: |
        chmod +x evtx-sigma-checker
        ./evtx-sigma-checker --log-source tests/thor.yml --evtx-path win7_x86/ --rule-path rules/windows/ --rule-path rules-emerging-threats/ --rule-path rules-threat-hunting/ > findings.json
    - name: Show findings excluding known FPs
      run: |
        chmod +x .github/workflows/matchgrep.sh
        ./.github/workflows/matchgrep.sh findings.json .github/workflows/known-FPs.csv

Regression Testing

The most recent addition to our pipelines is regression testing. Here we validate a rule against a “malicious” log where we are expecting a match. We use this in order to make sure that a rule is always working as it supposed to.

Currently we support only matching against EVTX but this will be extended to other types in the future.

The idea is very simple. A sigma rule contain a regression_tests_path field that points to an info.yml file.

id: 6f781d8b-1b6c-408b-a90d-08aceb2a14d0
description: N/A
date: 2025-10-24
author: SigmaHQ Team
rule_metadata:
    - id: d7662ff6-9e97-4596-a61d-9839e32dee8d
      title: Add SafeBoot Keys Via Reg Utility
regression_tests_info:
    - name: Positive Detection Test
      type: evtx
      provider: Microsoft-Windows-Sysmon
      match_count: 1
      path: regression_data/windows/process_creation/proc_creation_win_reg_add_safeboot/d7662ff6-9e97-4596-a61d-9839e32dee8d.evtx

This file will contain a list pointing to the logs we have to match against. In the example above we only have one.

The CI will then parse this and call evtx-sigma-checker (because of type: evtx ).

jobs:
  true-positive-tests:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    
    - name: Set up Python
      uses: actions/setup-python@v4
      with:
        python-version: '3.11'
        
    - name: Install Python dependencies
      run: |
        python -m pip install --upgrade pip
        pip install pyyaml
        
    - name: Download evtx-sigma-checker
      run: |
        wget --no-verbose https://github.com/NextronSystems/evtx-baseline/releases/download/$EVTX_BASELINE_VERSION/evtx-sigma-checker
        chmod +x evtx-sigma-checker
        
    - name: Run regression tests
      run: |
        python tests/regression_tests_runner.py --rules-paths "rules/,rules-emerging-threats/,rules-threat-hunting/" --evtx-checker ./evtx-sigma-checker --thor-config tests/thor.yml --ignore-validation

Four-Eyes Principle

While we’ve concluded the automated part of the Sigma validation, one final part that is equally as important is the reviewers actually looking at the rules. This has always been an important part of SigmaHQ.

We apply a four eye principal meaning we require at least 2 reviewers in order to merge a PR. (except in some cases, we like bureaucracy only so much).

These reviewers are some of the best in terms of detection engineering knowledge and with varying level experiences and expertise.

And its not about just looking at raw YAMLs

• We strive to replicate most attacks that are contributed (especially on Windows) to make sure logic is reflected in the logs.
• We investigate linked references to their fullest and often pivot via utilities like VT or ANY.RUN to find more samples leveraging the same techniques and help extend coverage in the same PR.

Let me just say that its more than just a “LGTM” review ;)

Conclusion & Future Plans

Hope this gave you a better understanding on how Sigma strive to maintain high quality of rules.

We’re always trying to improve. Happy to hear any feedback or suggestions. Hit me up on socials Twitter / LinkedIn or join the discussion on our Sigma discord group.

Join the SigmaHQ Community Discord Server!

A lot of exciting automation and additional features are coming in the next few months that will elevate the quality and trust in rules and open source to the next level. I will keep you posted :D

SigmaHQ Quality Assurance Pipeline was originally published in Sigma_HQ on Medium, where people are continuing the conversation by highlighting and responding to this story.

The SigmaHQ team is pleased to announce the latest update to the Sigma specification, the long awaited version 2.0 is now available for all Sigma users and creators. This release marks an important milestone for the Sigma project, it introduces new features as well as many enhancements.

Let’s dive into the motivation behind v2.0 and some of the biggest changes introduced.

Motivation Behind v2.0

Since its inception, Sigma has always strived to be as user-friendly as possible while maintaining an expandable feature set. Over the years, both the vision of the project and the needs of its users have grown, necessitating the project’s evolution. This led to the creation of pySigma, a complete rewrite of the sigmac library, which introduced many new features and enhancements. Consequently, the specification had to evolve as well, resulting in the release of v2.0, an exciting milestone full of new ideas, features and enhancements.

Breaking Changes

As with any major version, some breaking changes are to be expected. Fortunately for Sigma users, there aren’t many to note here. You can check out a list of the important differences between v1 and v2 of the specs here.

New Set of Fields and Modifiers

In our continuous efforts to improve the Sigma rule format, we’ve added a bunch of new metadata fields and modifiers to allow users more flexibility and easier ways to write, enrich and effectively share/integrate their detection rules.

Check out the Sigma Rule Specification and the accompanying Sigma Modifiers Appendix for the full list and details.

New and Enhanced Correlation Specification

Sigma introduced the concept of correlation (aggregation) early in its development of the now deprecated (EOL) sigmac library. While the aggregation expression was fine at the time, it never really was designed to be easily extended, but with the introduction of pySigma a full re-write of the sigma library, we took the time to create a dedicated specification for correlation rules that not only enhances the expression of writing correlation rules for users, it is also easily extensible for future use cases.

Check out the recent Introducing Sigma Correlations blog to get a small taste and the Sigma Correlation Rules Specification for full details.

Sigma Filters a New Frontier

Recently we announced the release of a new feature called Sigma Filters that allows for the creation of dedicated sigma filter rules that acts as centralized false positive exclusions for detection rules.

A dedicated specification has been created for this feature that you can check out here.

New JSON Schemata

In our efforts to provide a better structure for the Sigma project and ease automation efforts to validate Sigma rules against the specification, JSON schemata files are being added for all currently available specification documents. You can check them here.

New Repository Structure and Faster Release Cycle

In addition to this release, we took the time to update the Sigma Specification repository structure to reflect this new milestone. This restructuring will allows us to be more efficient, and improve our release cycle.

Help Shape the Future of the Sigma Standard

Additional enhancements are already in the works so stay tuned. If you want to shape the future of the Sigma standard, join the discussion and start contributing today to the specification.

Introducing Sigma Specification v2.0 was originally published in Sigma_HQ on Medium, where people are continuing the conversation by highlighting and responding to this story.

As any Security Operations Center (SOC) analyst or engineer will tell you, there are two big challenges faced when hunting for threats within an environment.

The first is making sure you’re detecting the right thing. This covers everything from making sure your logsource is on-boarded properly, to all fields and values are named and mapped correctly, to testing and validating true-positive scenarios to ensure your detection rules are working as intended. This also entails designing your rule in such a way that it can’t be easily evaded by an attacker — so ensuring that the rule is wide enough to catch them given a wide range of circumstances and situations.*

The second — and arguably more frustrating — is minimising time triaging the wrong thing. This essentially entails filtering our “false-positives” detections, or alerts that have fired that are found to be benign.

Striking this balance is an art form.

Build rules too specific, and attackers might evade your detections. Build rules too generic, you and the rest of your SOC are going to grow linearly in accordance with the amount of triage needing to be done.

And casting a wide enough net of detection rules in order to ensure that attackers are promptly found vs ensuring your SOC isn’t ballooning with staff due to the number of incoming alerts requiring triage — is a challenge very often & easily under-estimated.**

Exclusions in Sigma

Within the Sigma Detection ecosystem, these exclusions or “filters” are often represented as a not conditions applied to the initial detection.

title: Network Connection Initiated Via Notepad.EXE
author: EagleEye Team
logsource:
    category: network_connection
    product: windows
detection:
    selection:
        Image|endswith: '\notepad.exe'
    filter:
        DestinationPort: 9100
    condition: selection and not filter
falsepositives:
    - Printing documents via notepad might cause communication with the printer via port 9100 or similar.

Detects a network connection that is initiated by the “notepad.exe” process.

In this example, we want to filter out port 9100 as it's a commonly used print protocol called AppSocket.

But what if you don’t use AppSocket (9100) at your organisation, and instead use the more secure Internet Printing Protocol (631)? Will this mean this alert will continue to fire every time someone prints from notepad? What if they open a document on a network drive?

The real problem with this approach is that filters that apply to everyone won’t capture the reality of your unique environment.

One other understated concern with publicising these filters as Sigma becomes more popular, attackers will attempt to use these excluded file paths, patterns and behaviours more and more over time — to hide from detection.

If you’re like most, you’ll download the Sigma rule into your SIEM, intertwine your own environments’ concerns with the concern of the detection itself — making some hybrid creature of detection and exclusion.

# ...
detection:
    selection:
        Image|endswith: '\notepad.exe'
    filter_printing:
        DestinationPort: 631
        DestinationIp|cidr: 
            - 192.168.24.0/24   # Printer Network
    filter_file_share:
        DestinationPort: 
            - 445
            - 139
        DestinationIp|cidr: 
            - 192.168.32.0/24   # Fileshare Network
    condition: selection and not (filter_printing or filter_file_share)
# ...

An updated Sigma rule with new custom exclusions added

Now you’ve “tuned” this rule for your organisation, you’re now unable to share this Sigma rule with anyone else, as they may use a different technologies, network address allocations etc.

The other issue is that now you’ve written this explicitly for a single rule, you might have to update 10s of other rules with the same kind of filter.

We wanted to fix this.

Introducing Sigma Filters

This is where Sigma Filters rules — or simply “Sigma Filters” — are designed to help with this. Sigma Filter rules are built as an extension on the Sigma rule format — that allow you to build filters that sit independently from your Sigma rules.

Made possible from the development around pySigma — a full re-write of the Sigma conversion strategy — we designed Filters to re-think how SOCs write, develop and integrate exclusions into their Sigma detection-as-code strategy.

Let’s start with a simplified detection of the Sigma rule above.

title: Network Connection Initiated Via Notepad.EXE
name: network_connection_initiated_via_notepad_exe
author: EagleEye Team
logsource:
    category: network_connection
    product: windows
detection:
    selection:
        Image|endswith: '\notepad.exe'
    condition: selection
falsepositives:
    - Printing documents via notepad might cause communication with the printer via port 9100, 631.
    - Loading files from the internet, or an SMB share.

We can combine this Sigma rule with a “Sigma Filter” rule to ensure that these concerns remain separate. The goal of this is to ensure that the initial Sigma rule remains as generically applicable as possible.

Let’s store this file in a new folder called filters at ./filters/windows/filter_out_file_sharing_and_printer_networks.yml

title: Filter out File Sharing and Printer Networks
description: >
    Filters out Company XXXXXXXXX file sharing servers and printer servers. These are often visted by our MS Office (Word) and notepad.txt users.
logsource:
    product: windows
filter:
    rules:
      - network_connection_initiated_via_notepad_exe
    filter_printing:
        DestinationPort: 631
        DestinationIp|cidr:
            - 192.168.24.0/24   # Printer Network
    filter_file_share:
        DestinationPort:
            - 445
            - 139
        DestinationIp|cidr:
            - 192.168.32.0/24   # Fileshare Network
    condition: not filter_printing and not filter_file_share

A Sigma Filter for excluding File Sharing and Printer Networks

Note that we now supply the filter keyword instead of the detection keyword, and we supply a list of rule references in a list, either by the rule's name , or by the rule's id .

When we convert this using the sigma-cli command, we end up with the following query:

$ sigma convert -t lucene -p ecs_windows \
    --filter ./filters \
    ./rules/windows/network_connection/net_connection_win_notepad.yml

process.executable:*\\notepad.exe AND ((NOT (destination.port:631 AND destination.ip:192.168.24.0\/24)) AND (NOT ((destination.port:(445 OR 139)) AND destination.ip:192.168.32.0\/24)))

🎉 We’ve just applied our very first Filter to our detection rule.

The advantages of this at first don’t seem to be very obvious, but as SOCs mature, over time, each detection rule becomes fairly unwieldy, eventually becoming an unmanageable mess in some situations.**

We’re now also free to update the rules folder within our Sigma detection-as-code repo with any of the available rule-pack update releases, without having to worry about merge-conflicts or our exclusion lists being removed.

With this addition, Sigma Filters can also be applied to more than one of our existing Sigma rules. This happens to be extremely useful for excluding or only-including certain hosts, users, or software from an entire list of detection rules — so no more copying the filter into each Sigma rule.

We hope you are as excited as we are about this release, and as of sigma-cli release v1.0.3, you can start using them today.

If you’re curious about some of the details, you can head over to the docs where we outline more about filters and how to use them.

Future Steps

Whilst this is an amazing first step for Sigma Meta Rules –with the announcement of Sigma Correlations not too long ago – there’s a lot that Sigma HQ and the wider the community is going to have to do to make this feature really wonderful to use.

The first by-far — in my opinion — is to start work on a sigma list rules command, in which Sigma Filters are listed in tree structure alongside their rule references. This would be to help debug some resultant queries – as it's no longer obvious or transparent how a query comes together at conversion time.

$ sigma list rules ./rules

┬ Network Connection Initiated Via Notepad.EXE
├── Filter out File Sharing and Printer Networks
└── Filter out Service Accounts

Footnotes:

* For further context → It’s important to note that most of these rules will return no results — as the behaviour the SOC is looking for only triggers when these malicious behaviours are enacted.

** Not only this — so often have I seen SOCs update a rule to exclude some behaviour — either in-SIEM or defined within a Github Pull Request — only to later find out that that same exclusion broke the initial detection, either by a typo or a badly escaped character

Introducing Sigma Filters was originally published in Sigma_HQ on Medium, where people are continuing the conversation by highlighting and responding to this story.

One of the most requested features for Sigma in the last years was the ability to express correlation searches. Since Sigma was introduced, its main focus was set on matching single log events. The first version of the Sigma specification defined a syntax for piped aggregation expressions, but this first approach to match multiple events in defined combinations had various issues and some important aspects were underspecified. Furthermore, sigmac didn’t provided much support in implementing conversion support for this kind of expressions and such, only few backends implemented this feature.

To overcome the shortcomings of the aggregation expressions, a new Sigma rule type dedicated to correlation of events was specified by the Sigma project core team and community members. It was released in pySigma in the beginning of 2024 and two backends, Splunk and Elasticsearch ES|QL, support converting correlation rules to queries at the time of writing this post.

Correlation Basics

Generally, event correlation search first matches events that belong somehow together, e.g. failed logon events. These singular events are aggregated into buckets which are defined at least by a time frame where events should be considered as belonging together. In addition, field values can form additional grouping criteria. In the example above, the failed logons could be grouped by the source IP or by the target user name or for both.

Finally, a condition must be defined, which of these event buckets are relevant. Your SOC possibly shouldn’t care about a single failed logon, but ten failed logons for a single user are of interest because this could be a brute force attack against a user as well as failed logons for hundred different users from the same source address which could be a password spraying attack.

Sigma Correlation rules have the goal to express such rules in a generic way that allows to convert these rules into target query languages that support all required features.

One remark on the time frame used: while the Sigma specification recommends a sliding time window, this is not a hard requirement. In many query languages and data analysis platforms it’s more efficient to slice the time into static chunks, e.g. full minutes. Some are only capable to do this. Such implementation is also legitimate.

Correlation Rule Example

Lets starts with a basic example of a correlation rule:

title: Failed logon
name: failed_logon
status: test
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4625
    condition: selection
---
title: Multiple failed logons for a single user (possible brute force attack)
status: test
correlation:
    type: event_count
    rules:
        - failed_logon
    group-by:
        - TargetUserName
        - TargetDomainName
    timespan: 5m
    condition:
        gte: 10

A correlation rule shares lots of fields like title, id, status and many others with basic Sigma rules. Instead of defining a single event with alogsource and detection attribute, a correlation element defines the properties of the correlation.

As described in the basics above, a correlation rule doesn’t exist for itself but always refers to Sigma rules as we already know them from its rules attribute by referring rules by their nameor their id. Reference by name is preferred because of its better readability.

Because correlation rules define relationships between events, a time span must be defined in which the relationship occurs. This highly depends on the kind of correlation. While malware execution behavior often occurs within few seconds (e.g. writing a file and executing it), user behavior or brute force attacks can span across minutes or even hours.

The group-by attribute can be used to define additional fields by which the matched events are grouped. In the example above the events are counted by a user account and its domain.

The conditionattribute finally defines together with the other attributes of the correlation the condition under which the correlation of events matches. In the above example the matched events are aggregated by five minute slots in addition to the grouping fields TargetUserName and TargetDomainName. Only if more than 10 events with the same field values appear within the given time frame it is a match and possibly a brute force attack on a specific user that should be investigated.

Four Flavors of Correlations

Sigma currently supports four different correlation types that are described in the following sections. Please be aware that not all backends support all of these correlation types. Especially the ordered temporal correlation is widely unsupported at the moment.

Event Count Correlations

The event count correlation simply counts the events in the aggregation bucket. This correlation type is usually chosen if it is just relevant if an event happens often or rarely in a given time frame. Some examples are:

• Brute force attacks where a logon failure count exceeds a given threshold.
• Denial of Service attacks where a connection count threshold is exceeded.
• Log source reliability issues, when the amount of events falls below a threshold.

Value Count Correlations

A value count correlation counts the distinct values of a given field in the aggregation bucket. This correlation type is useful to detect if multiple events of the same kind occur with a specific high or low amount of entities. Examples:

• Network scans where a single source IP tries to connect to many destination IPs and/or ports.
• Password spraying attacks, where a single source fails to authenticate with many different users.
• Some tools like BloodHound can be detected by enumeration of certain high-privilege AD groups within a short time frame. This correlation rule reliably detects BloodHound scans conducted with default options:

title: High-privilege group enumeration
name: privileged_group_enumeration
status: stable
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4799
        CallerProcessId: 0x0
        TargetUserName:
            - Administrators
            - Remote Desktop Users
            - Remote Management Users
            - Distributed COM Users
    condition: selection
level: informational
falsepositives:
    - Administrative activity
    - Directory assessment tools
---
title: Enumeration of multiple high-privilege groups by tools like BloodHound
status: stable
correlation:
    type: value_count
    rules:
        - privileged_group_enumeration
    group-by:
        - SubjectUserName
    timespan: 15m
    condition:
        gte: 4
        field: TargetUserName
level: high
falsepositives:
    - Administrative activity
    - Directory assessment tools

Temporal Event Correlations

A temporal event correlation determines if multiple different event types occur in temporal proximity. Examples:

• A brute force or password spraying attack where failed logon events appear together with successful logons from the same source could mean that the attack was successful and should be handled with increased priority.
• Vulnerability exploitation by detecting a connection to a vulnerable API endpoint together with a process creation:

title: CVE-2023-22518 Exploit Chain
description: Access to endpoint vulnerable to CVE-2023-22518 with suspicious process creation.
status: experimental
correlation:
    type: temporal
    rules:
        - a902d249-9b9c-4dc4-8fd0-fbe528ef965c
        - 1ddaa9a4-eb0b-4398-a9fe-7b018f9e23db
    timespan: 10s
level: high

This rule correlates two existing medium-severity rules for the confluence vulnerability CVE-2023–22518 from the SigmaHQ rule repository. The first rule web_exploit_cve_2023_22518_confluence_auth_bypass.yml detects an access to the vulnerable web endpoint that is not sufficient for detection of a successful exploit because the endpoints also have legitimate use cases. The second rule proc_creation_win_exploit_cve_2023_22518_confluence_tomcat_child_proc.yml detects a suspicious shell execution by the Confluence Tomcat process. This event can also happen legitimately for various reasons and therefore only has a medium severity.

The correlation rule is triggered if both events appear within ten seconds. The severity of the aggregated event was raised to high because both events together are more likely a successful exploitation than just the single events this correlation consists from.

Ordered Temporal Correlations

The ordered temporal correlation is similar to the former, but adds the order of the events as another condition. Generally, the usage of this correlation type should be considered very carefully because of various reasons:

• Often, the appearance of certain events in a specific time frame is already sufficient for the detection. E.g. the famous example of multiple failed logons followed by a successful one delivers mostly the same results if the failed and successful logon just appear within the same time frame.
• Compared to the temporal correlation the queries required to check the order are usually more complex and less efficient.
• Some backends don’t implement support for ordered temporal correlation or it’s even not possible to implement this within a query language.
• Especially when events appear very near to each other and events from different log sources are correlated, different time resolutions and clock skews can cause that the events appear in a different order as they occurred.

Altogether, this correlation type should only be used if really required.

Field Aliases

Sometimes it is required to correlate fields that have different names in their respective log sources. This can even happen in cases where field names are normalized. One example of such a situation is when the correlation rule must aggregate by source IP with the destination IP in another event type. This can be achieved with field aliases that form another attribute within the correlation attribute:

correlation:
    type: temporal
    rules:
        - rule_with_src_ip
        - rule_with_dest_ip
    aliases:
        ip:
            rule_with_src_ip: src_ip
            rule_with_dest_ip: dest_ip
    group-by:
        - ip
    timespan: 5m

The aliases attribute defines a virtual field ip that is mapped from the field src_ip in the events matched by rule rule_with_src_ip and from dest_ip in the vents matched by the rule rule_with_dest_ip. The defined field ip is then used in the group-by field list as aggregation field name.

Conversion

Conversion of correlation rules is pretty straightforward. Just a version of pySigma with correlation support is required. Because the rule file contains the base event Sigma rule as well as the correlation rule, the first example can simply be converted by specifying it on the command line:

sigma convert -t splunk -p crowdstrike_fdr .\susp_privileged_group_enumeration.yml

And results in the following query:

EventID=4799 CallerProcessId=0 TargetUserName IN ("Administrators", "Remote Desktop Users", "Remote Management Users", "Distributed COM Users")

| bin _time span=15m
| stats dc(TargetUserName) as value_count by _time SubjectUserName

| search value_count >= 4

Because the correlation rule in the second example is not self-contained in the same way as in the first, the rules referred from the correlation rules must also be specified on the command line:

sigma convert -t esql -p sysmon ..\sigma\rules-emerging-threats\2023\Exploits\CVE-2023–22518 .\exploit_chain_cve-2023–22518.yml

In this command line, the whole directory containing all rules related to CVE-2023–22518 was specified. It is also possible to put all rules into the same directory. All directories and files given on the command line are treated as one Sigma rule collection. The result contains the ES|QL query resulting from the correlation rule:

from * | where (`cs-method`=="POST" and (`cs-uri-query` like "*/json/setup-restore-local.action*" or `cs-uri-query` like "*/json/setup-restore-progress.action*" or `cs-uri-query` like "*/json/setup-restore.action*" or `cs-uri-query` like "*/server-info.action*" or `cs-uri-query` like "*/setup/setupadministrator.action*") and (`sc-status` in (200, 302, 405))) or (EventID==1 and (ends_with(ParentImage, "\\tomcat8.exe") or ends_with(ParentImage, "\\tomcat9.exe") or ends_with(ParentImage, "\\tomcat10.exe")) and ParentCommandLine like "*confluence*" and (ends_with(Image, "\\cmd.exe") or ends_with(Image, "\\powershell.exe") or OriginalFileName in ("Cmd.Exe", "PowerShell.EXE")))
| eval event_type=case(`cs-method`=="POST" and (`cs-uri-query` like "*/json/setup-restore-local.action*" or `cs-uri-query` like "*/json/setup-restore-progress.action*" or `cs-uri-query` like "*/json/setup-restore.action*" or `cs-uri-query` like "*/server-info.action*" or `cs-uri-query` like "*/setup/setupadministrator.action*") and (`sc-status` in (200, 302, 405)), "a902d249-9b9c-4dc4-8fd0-fbe528ef965c", EventID==1 and (ends_with(ParentImage, "\\tomcat8.exe") or ends_with(ParentImage, "\\tomcat9.exe") or ends_with(ParentImage, "\\tomcat10.exe")) and ParentCommandLine like "*confluence*" and (ends_with(Image, "\\cmd.exe") or ends_with(Image, "\\powershell.exe") or OriginalFileName in ("Cmd.Exe", "PowerShell.EXE")), "1ddaa9a4-eb0b-4398-a9fe-7b018f9e23db")
| eval timebucket=date_trunc(10seconds, @timestamp) | stats event_type_count=count_distinct(event_type) by timebucket
| where event_type_count >= 2

In addition, the result contains the queries from Sigma rules contained in the specified directory that were not referred by the correlation rule. The rules referred by the correlation rule don’t appear anymore as standalone queries in the conversion result. This behavior can be controlled with the generate attribute of a correlation rule. If this is set to true then the referred rules are also converted into stand-alone queries. This is useful to emit events from the single events with a lower severity as well as high-severity events if the correlation is triggered.

The example shows also that it is possible to define custom correlation rules referring to rules from a third-party repository and can be useful in situations where third-party rules cause too many false positives.

Final Thoughts

Sigma Correlations add the long awaited capability to express detections correlating multiple events in an open and vendor-agnostic way to Sigma. This enables various use cases:

• Writing detections where a single event is not sufficient to detect a notable event like a file write to a suspicious location together with a process creation within a short timeframe.
• Correlating multiple existing detections that detect suspicious behaviors only with a low or medium confidence or with a high false positive rate into a high-confidence detection.
• Aggregating multiple informational events that are normally not suitable for raising cases to analysts into a behavioral “super-rule” that raises a case when multiple of such events appear together in a short timeframe.

As usual with new features it is tempting to use correlations for detections, possibly in cases where they are don’t provide any gain or their usage could be even counterproductive. Therefore, the usage of correlation rules should be well considered. A detection engineer should ask the following questions before a detection is expressed as correlation rule:

• Are the single events already sufficient to detect a malicious behavior? A high-confidence single-event detection with a low false positive rate doesn’t needs any further correlation with other events. It could even get worse if a critical even is missed because one of the other expected events don’t occur.
• Are there possibilities to miss events? Can the attacker control the events in a way that the correlation rule doesn’t detects the event anymore? Correlations often include an assumption about attacker behavior, e.g. the attacker directly uses a web shell after it was dropped. But what is if the attacker defers the steps from each others or slows down to stay below a specific rate of events? Are there still detections left that catch the malicious behavior or one of the likely subsequent behaviors?
• Is less more? Does the additional condition possibly cause more false negatives than reducing false positives? It should be the goal of a detection to minimize the conditions it has. Or the other way around: each condition that is added to a detection should reduce false positives while ideally adding no possibility to miss true positives. Using correlations is nothing more than adding another condition

If one or multiple questions were answered with yes, correlations could be the wrong detection technique and detecting a singular event could be the better way to go. Or choose something in between and detect the singular events with a lower severity and the correlation with a higher one.

And now: start to write the correlation rules you had in mind but wasn’t able to write them as Sigma rule! Soon we will open the open source SigmaHQ repository for sharing correlation rules. If you have any questions or suggestions, feel free to join the SigmaHQ Community on Discord or start a discussion on GitHub.

Introducing Sigma Correlations was originally published in Sigma_HQ on Medium, where people are continuing the conversation by highlighting and responding to this story.

Sigma Rule Packages for 13–05–2024 are released and available for download. This release saw the addition of 16 new rules, 7 rule updates and 1 rule fix by 7 contributors.

New Rules

Some highlights for the newer rules include, rules covering different cases on how Wbadmin can be abused to dump/restore sensitive files and delete backups.

title: File Recovery From Backup Via Wbadmin.EXE
id: 6fe4aa1e-0531-4510-8be2-782154b73b48
related:
    - id: 84972c80-251c-4c3a-9079-4f00aad93938
      type: derived
status: experimental
description: |
    Detects the recovery of files from backups via "wbadmin.exe".
    Attackers can restore sensitive files such as NTDS.DIT or Registry Hives from backups in order to potentially extract credentials.
references:
    - https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/wbadmin-start-recovery
    - https://lolbas-project.github.io/lolbas/Binaries/Wbadmin/
author: Nasreddine Bencherchali (Nextron Systems), frack113
date: 2024/05/10
tags:
    - attack.impact
    - attack.t1490
logsource:
    category: process_creation
    product: windows
detection:
    selection_img:
        - Image|endswith: '\wbadmin.exe'
        - OriginalFileName: 'WBADMIN.EXE'
    selection_cli:
        CommandLine|contains|all:
            - ' recovery'
            - 'recoveryTarget'
            - 'itemtype:File'
    condition: all of selection_*
falsepositives:
    - Unknown
level: medium

title: Sensitive File Dump Via Wbadmin.EXE
id: 8b93a509-1cb8-42e1-97aa-ee24224cdc15
status: experimental
description: |
    Detects the dump of highly sensitive files such as "NTDS.DIT" and "SECURITY" hive.
    Attackers can leverage the "wbadmin" utility in order to dump sensitive files that might contain credential or sensitive information.
references:
    - https://github.com/LOLBAS-Project/LOLBAS/blob/2cc01b01132b5c304027a658c698ae09dd6a92bf/yml/OSBinaries/Wbadmin.yml
    - https://lolbas-project.github.io/lolbas/Binaries/Wbadmin/
    - https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/wbadmin-start-recovery
    - https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/wbadmin-start-backup
author: Nasreddine Bencherchali (Nextron Systems), frack113
date: 2024/05/10
tags:
    - attack.credential_access
    - attack.t1003.003
logsource:
    category: process_creation
    product: windows
detection:
    selection_img:
        - Image|endswith: '\wbadmin.exe'
        - OriginalFileName: 'WBADMIN.EXE'
    selection_backup:
        CommandLine|contains:
            - 'start'
            - 'backup'
    selection_path:
        CommandLine|contains:
            - '\config\SAM'
            - '\config\SECURITY'
            - '\config\SYSTEM'
            - '\Windows\NTDS\NTDS.dit'
    condition: all of selection_*
falsepositives:
    - Legitimate backup operation by authorized administrators. Matches must be investigated and allowed on a case by case basis.
level: high

New rules covering usage of the PowerShell cmdlets “Start-NetEventSession” and “New-NetFirewallRule” which allows attacker to capture packets and create new firewall rules respectively.

title: New Windows Firewall Rule Added Via New-NetFirewallRule Cmdlet - ScriptBlock
id: 8d31dd2e-b582-48ca-826e-dcaa2c1ca264
related:
    - id: 51483085-0cba-46a8-837e-4416496d6971
      type: similar
status: experimental
description: |
    Detects when a powershell script contains calls to the "New-NetFirewallRule" cmdlet in order to add a new firewall rule with an "Allow" action.
references:
    - https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1562.004/T1562.004.md#atomic-test-24---set-a-firewall-rule-using-new-netfirewallrule
    - https://malware.news/t/the-rhysida-ransomware-activity-analysis-and-ties-to-vice-society/72170
    - https://cybersecuritynews.com/rhysida-ransomware-attacking-windows/
author: frack113
date: 2024/05/10
tags:
    - attack.defense_evasion
    - attack.t1562.004
    - detection.threat_hunting
logsource:
    product: windows
    category: ps_script
    definition: 'Requirements: Script Block Logging must be enabled'
detection:
    selection:
        ScriptBlockText|contains: 'New-NetFirewallRule*-Action*Allow'
    condition: selection
falsepositives:
    - Administrator script
level: low

title: Potential Packet Capture Activity Via Start-NetEventSession - ScriptBlock
id: da34e323-1e65-42db-83be-a6725ac2caa3
status: experimental
description: |
    Detects the execution of powershell scripts with calls to the "Start-NetEventSession" cmdlet. Which allows an attacker to start event and packet capture for a network event session.
    Adversaries may attempt to capture network to gather information over the course of an operation.
    Data captured via this technique may include user credentials, especially those sent over an insecure, unencrypted protocol.
references:
    - https://github.com/redcanaryco/atomic-red-team/blob/5f866ca4517e837c4ea576e7309d0891e78080a8/atomics/T1040/T1040.md#atomic-test-16---powershell-network-sniffing
    - https://github.com/0xsyr0/Awesome-Cybersecurity-Handbooks/blob/7b8935fe4c82cb64d61343de1a8b2e38dd968534/handbooks/10_post_exploitation.md
    - https://github.com/forgottentq/powershell/blob/9e616363d497143dc955c4fdce68e5c18d28a6cb/captureWindows-Endpoint.ps1#L13
author: frack113
date: 2024/05/12
tags:
    - attack.credential_access
    - attack.discovery
    - attack.t1040
logsource:
    product: windows
    category: ps_script
    definition: 'Requirements: Script Block Logging must be enabled'
detection:
    selection:
        ScriptBlockText|contains: 'Start-NetEventSession'
    condition: selection
falsepositives:
    - Legitimate network diagnostic scripts.
level: medium

In addition to this a new rule covering potentially suspicious child processes of “KeyScrambler.exe”.

title: Potentially Suspicious Child Process of KeyScrambler.exe
id: ca5583e9-8f80-46ac-ab91-7f314d13b984
related:
    - id: d2451be2-b582-4e15-8701-4196ac180260
      type: similar
status: experimental
description: Detects potentially suspicious child processes of KeyScrambler.exe
references:
    - https://twitter.com/DTCERT/status/1712785421845790799
author: Swachchhanda Shrawan Poudel
date: 2024/05/13
tags:
    - attack.execution
    - attack.defense_evasion
    - attack.privilege_escalation
    - attack.t1203
    - attack.t1574.002
logsource:
    category: process_creation
    product: windows
detection:
    selection_parent:
        ParentImage|endswith: '\KeyScrambler.exe'
    selection_binaries:
        # Note: add additional binaries that the attacker might use
        - Image|endswith:
              - '\cmd.exe'
              - '\cscript.exe'
              - '\mshta.exe'
              - '\powershell.exe'
              - '\pwsh.exe'
              - '\regsvr32.exe'
              - '\rundll32.exe'
              - '\wscript.exe'
        - OriginalFileName:
              - 'Cmd.Exe'
              - 'cscript.exe'
              - 'mshta.exe'
              - 'PowerShell.EXE'
              - 'pwsh.dll'
              - 'regsvr32.exe'
              - 'RUNDLL32.EXE'
              - 'wscript.exe'
    condition: all of selection_*
falsepositives:
    - Unknown
level: medium

Check the full release changelog for a complete list of new rules.

New Updates

Some older rules have seen improvements in coverage and metadata as well.

First a couple of rules that leverage the “Microsoft-Windows-Windows Firewall With Advanced Security” have seen the addition of the EID 2097 to increase coverage.

title: New Firewall Rule Added In Windows Firewall Exception List For Potential Suspicious Application
id: 9e2575e7-2cb9-4da1-adc8-ed94221dca5e
related:
    - id: cde0a575-7d3d-4a49-9817-b8004a7bf105
      type: derived
status: experimental
description: Detects the addition of a new rule to the Windows Firewall exception list for an application located in a potentially suspicious location.
references:
    - https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/dd364427(v=ws.10)
    - https://app.any.run/tasks/7123e948-c91e-49e0-a813-00e8d72ab393/#
author: frack113
date: 2023/02/26
modified: 2024/05/10
tags:
    - attack.defense_evasion
    - attack.t1562.004
logsource:
    product: windows
    service: firewall-as
detection:
    selection:
        EventID:
            - 2004 # A rule has been added to the Windows Defender Firewall exception list. (Windows 10)
            - 2071 # A rule has been added to the Windows Defender Firewall exception list. (Windows 11)
            - 2097
        ApplicationPath|contains:
            - ':\PerfLogs\'
            - ':\Temp\'
            - ':\Tmp\'
            - ':\Users\Public\'
            - ':\Windows\Tasks\'
            - ':\Windows\Temp\'
            - '\AppData\Local\Temp\'
    filter_main_block:
        Action: 2 # Block
    condition: selection and not 1 of filter_main_*
falsepositives:
    - Unknown
level: high

title: Uncommon New Firewall Rule Added In Windows Firewall Exception List
id: cde0a575-7d3d-4a49-9817-b8004a7bf105
status: experimental
description: Detects when a rule has been added to the Windows Firewall exception list
references:
    - https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/dd364427(v=ws.10)
author: frack113
date: 2022/02/19
modified: 2024/05/10
tags:
    - attack.defense_evasion
    - attack.t1562.004
logsource:
    product: windows
    service: firewall-as
detection:
    selection:
        EventID:
            - 2004 # A rule has been added to the Windows Defender Firewall exception list
            - 2071 # A rule has been added to the Windows Defender Firewall exception list. (Windows 11)
            - 2097
    filter_main_block:
        Action: 2 # Block
    filter_main_generic:
        ApplicationPath|contains:
            - ':\Program Files (x86)\'
            - ':\Program Files\'
            - ':\Windows\System32\'
            - ':\Windows\SysWOW64\'
            - ':\Windows\WinSxS\'
    filter_optional_msmpeng:
        ModifyingApplication|contains|all:
            - ':\ProgramData\Microsoft\Windows Defender\Platform\'
            - '\MsMpEng.exe'
    filter_main_covered_paths:
        # This filter is added to avoid duplicate alerting from 9e2575e7-2cb9-4da1-adc8-ed94221dca5e
        ApplicationPath|contains:
            - ':\PerfLogs\'
            - ':\Temp\'
            - ':\Tmp\'
            - ':\Users\Public\'
            - ':\Windows\Tasks\'
            - ':\Windows\Temp\'
            - '\AppData\Local\Temp\'
    condition: selection and not 1 of filter_main_* and not 1 of filter_optional_*
level: medium

Additional paths and processes were added to the rule “Potentially Suspicious Execution Of PDQDeployRunner”. Which is a utility often leveraged by some ransomware threat actors to deploy malware accross the evinronement.

title: Potentially Suspicious Execution Of PDQDeployRunner
id: 12b8e9f5-96b2-41e1-9a42-8c6779a5c184
related:
    - id: d679950c-abb7-43a6-80fb-2a480c4fc450
      type: similar
status: test
description: Detects suspicious execution of "PDQDeployRunner" which is part of the PDQDeploy service stack that is responsible for executing commands and packages on a remote machines
references:
    - https://twitter.com/malmoeb/status/1550483085472432128
author: Nasreddine Bencherchali (Nextron Systems)
date: 2022/07/22
modified: 2024/05/02
tags:
    - attack.execution
logsource:
    category: process_creation
    product: windows
detection:
    selection_parent:
        ParentImage|contains: '\PDQDeployRunner-'
    selection_child:
        # Improve this section by adding other suspicious processes, commandlines or paths
        - Image|endswith:
              # If you use any of the following processes legitimately comment them out
              - '\bash.exe'
              - '\certutil.exe'
              - '\cmd.exe'
              - '\csc.exe'
              - '\cscript.exe'
              - '\dllhost.exe'
              - '\mshta.exe'
              - '\msiexec.exe'
              - '\regsvr32.exe'
              - '\rundll32.exe'
              - '\scriptrunner.exe'
              - '\wmic.exe'
              - '\wscript.exe'
              - '\wsl.exe'
        - Image|contains:
              - ':\ProgramData\'
              - ':\Users\Public\'
              - ':\Windows\TEMP\'
              - '\AppData\Local\Temp'
        - CommandLine|contains:
              - ' -decode '
              - ' -enc '
              - ' -encodedcommand '
              - ' -w hidden'
              - 'DownloadString'
              - 'FromBase64String'
              - 'http'
              - 'iex '
              - 'Invoke-'
    condition: all of selection_*
falsepositives:
    - Legitimate use of the PDQDeploy tool to execute these commands
level: medium

Check the full release changelog for a complete list of updates.

Fixes

This release have seen a single fix regarding a missing modifier which made the rule “Forest Blizzard APT — Process Creation Activity” broken.

Please check the full change-log on the release page below for the complete list of changes and additions

Release Release r2024-05-13 · SigmaHQ/sigma

Contributors

This release was possible thanks to the many Sigma community contributors. A big thanks goes to following people

• @ahmedfarou22
• @frack113
• @hasselj
• @joshnck
• @nasbench
• @pratinavchandra
• @swachchhanda000

SigmaHQ Rules Release Highlights — r2024–05–13 was originally published in Sigma_HQ on Medium, where people are continuing the conversation by highlighting and responding to this story.

Sigma Rule Packages for 29–04–2024 are released and available for download. This release saw the addition of 17 new rules, 35 rule updates and 8 rule fixes by 19 contributors.

New Rules

Some highlights for the newer rules include, rules covering exploitation indicators of CVE-2024–3400.

title: Potential CVE-2024-3400 Exploitation - Palo Alto GlobalProtect OS Command Injection - File Creation
id: bcd95697-e3e7-4c6f-8584-8e3503e6929f
status: experimental
description: |
    Detects suspicious file creations in the Palo Alto Networks PAN-OS' parent telemetry folder, which are processed by the vulnerable 'dt_curl' script if device telemetry is enabled.
    As said script overrides the shell-subprocess restriction, arbitrary command execution may occur by carefully crafting filenames that are escaped through this function.
references:
    - https://labs.watchtowr.com/palo-alto-putting-the-protecc-in-globalprotect-cve-2024-3400/
    - https://nvd.nist.gov/vuln/detail/CVE-2024-3400
author: Andreas Braathen (mnemonic.io)
date: 2024/04/25
tags:
    - attack.execution
    - cve.2024.3400
    - detection.emerging_threats
logsource:
    product: paloalto
    service: globalprotect
    category: file_event
    definition: 'Requirements: file creation events need to be ingested from the Palo Alto GlobalProtect appliance'
detection:
    selection:
        TargetFilename|contains:
            - '{IFS}'
            - 'base64'
            - 'bash'
            - 'curl'
            - 'http'
        TargetFilename|startswith: '/opt/panlogs/tmp/device_telemetry/'
    condition: selection
falsepositives:
    - The PAN-OS device telemetry function does not enforce a standard filename convention, but observations are unlikely.
level: medium

title: Potential CVE-2024-3400 Exploitation - Palo Alto GlobalProtect OS Command Injection
id: f130a5f1-73ba-42f0-bf1e-b66a8361cb8f
status: experimental
description: |
    Detects potential exploitation attempts of CVE-2024-3400 - an OS command injection in Palo Alto GlobalProtect.
    This detection looks for suspicious strings that indicate a potential directory traversal attempt or command injection.
references:
    - https://security.paloaltonetworks.com/CVE-2024-3400
    - https://labs.watchtowr.com/palo-alto-putting-the-protecc-in-globalprotect-cve-2024-3400/
    - https://attackerkb.com/topics/SSTk336Tmf/cve-2024-3400/rapid7-analysis
author: Nasreddine Bencherchali (Nextron Systems)
date: 2024/04/18
modified: 2024/04/25
tags:
    - attack.initial_access
    - attack.persistence
    - attack.privilege_escalation
    - attack.defense_evasion
    - cve.2024.3400
logsource:
    category: appliance
    product: paloalto
    service: globalprotect
    definition: 'Requirements: Palo Alto GlobalProtect "mp-log" and "gpsvc.log" log files need to be ingested'
detection:
    keywords_generic:
        - 'failed to unmarshal session(../'
        - 'failed to unmarshal session(./../'
        - 'failed to unmarshal session(/..'
        - 'failed to unmarshal session(%2E%2E%2F'
        - 'failed to unmarshal session(%2F%2E%2E'
        - 'failed to unmarshal session(%2E%2F%2E%2E%2F'
        - 'failed to unmarshal session(%252E%252E%252F'
        - 'failed to unmarshal session(%252F%252E%252E'
        - 'failed to unmarshal session(%252E%252F%252E%252E%252F'
    keywords_telemetry_exploit:
        - '{IFS}'
        - 'base64'
        - 'bash'
        - 'curl'
        - 'http'
    keywords_telemetry_path:
        - '/opt/panlogs/tmp/device_telemetry/'
    condition: keywords_generic or all of keywords_telemetry_*
falsepositives:
    - Unknown
level: high

As well as CVE-2024–3094 exploitation indicator.

title: Potential Exploitation of CVE-2024-3094 - Suspicious SSH Child Process
id: 9aa27839-e8ba-4d7a-ac1a-746c22c3d1e5
status: experimental
description: |
    Detects potentially suspicious child process of SSH process (sshd) with a specific execution user. This could be a sign of potential exploitation of CVE-2024-3094.
references:
    - https://github.com/amlweems/xzbot?tab=readme-ov-file#backdoor-demo
author: Arnim Rupp, Nasreddine Bencherchali, Thomas Patzke
date: 2024/04/01
modified: 2024/04/12
tags:
    - attack.execution
    - cve.2024.3094
logsource:
    category: process_creation
    product: linux
detection:
    selection_1:
        ParentImage|endswith: '/sshd'
        CommandLine|startswith:
            - 'bash -c'
            - 'sh -c'
        User: 'root'
    selection_2:
        ParentImage|endswith: '/sshd'
        Image|endswith: '/sshd'
        User: 'sshd'
        CommandLine|contains: 'root'
    condition: 1 of selection_*
falsepositives:
    - Administrative activity directly with root authentication might trigger selection_1 if it's unnecessarily prefixed with "sh -c" or "bash -c"
level: high

Rules covering recent activity observed by MSFT for the Forest Blizzard APT.

Note: Existing Sigma rules already cover most of the activity reported. The additional coverage is for this specific campaing(s)

title: Forest Blizzard APT - File Creation Activity
id: b92d1d19-f5c9-4ed6-bbd5-7476709dc389
status: experimental
description: |
    Detects the creation of specific files inside of ProgramData directory.
    These files were seen being created by Forest Blizzard as described by MSFT.
references:
    - https://www.microsoft.com/en-us/security/blog/2024/04/22/analyzing-forest-blizzards-custom-post-compromise-tool-for-exploiting-cve-2022-38028-to-obtain-credentials/
author: Nasreddine Bencherchali (Nextron Systems)
date: 2024/04/23
tags:
    - attack.defense_evasion
    - attack.t1562.002
logsource:
    category: file_event
    product: windows
detection:
    selection_programdata_driver_store:
        TargetFilename|startswith:
            - 'C:\ProgramData\Microsoft\v'
            - 'C:\ProgramData\Adobe\v'
            - 'C:\ProgramData\Comms\v'
            - 'C:\ProgramData\Intel\v'
            - 'C:\ProgramData\Kaspersky Lab\v'
            - 'C:\ProgramData\Bitdefender\v'
            - 'C:\ProgramData\ESET\v'
            - 'C:\ProgramData\NVIDIA\v'
            - 'C:\ProgramData\UbiSoft\v'
            - 'C:\ProgramData\Steam\v'
        TargetFilename|contains:
            - '\pnms003.inf_'
            - '\pnms009.inf_'
    selection_programdata_main:
        TargetFilename|startswith: 'C:\ProgramData\'
    selection_programdata_files_1:
        TargetFilename|endswith:
            - '.save'
            - '\doit.bat'
            - '\execute.bat'
            - '\servtask.bat'
        # Hashes|contains: '7d51e5cc51c43da5deae5fbc2dce9b85c0656c465bb25ab6bd063a503c1806a9' # Uncommon this if you collect hash information inf file events
    selection_programdata_files_2:
        TargetFilename|contains: '\wayzgoose'
        TargetFilename|endswith: '.dll'
    condition: selection_programdata_driver_store or (selection_programdata_main and 1 of selection_programdata_files_*)
falsepositives:
    - Unlikely
level: high

title: Forest Blizzard APT - Custom Protocol Handler Creation
id: 5cdeb555-65de-4767-99fe-e26807465148
status: experimental
description: |
    Detects the setting of a custom protocol handler with the name "rogue".
    Seen being created by Forest Blizzard APT as reported by MSFT.
references:
    - https://www.microsoft.com/en-us/security/blog/2024/04/22/analyzing-forest-blizzards-custom-post-compromise-tool-for-exploiting-cve-2022-38028-to-obtain-credentials/
author: Nasreddine Bencherchali (Nextron Systems)
date: 2024/04/23
tags:
    - attack.persistence
    - attack.t1547.001
logsource:
    category: registry_set
    product: windows
detection:
    selection:
        TargetObject|contains: '\PROTOCOLS\\Handler\rogue\CLSID'
        Details: '{026CC6D7-34B2-33D5-B551-CA31EB6CE345}'
    condition: selection
falsepositives:
    - Unlikely
level: high

Check the full release changelog for a complete list of new rules.

New Updates

Some older rules have seen improvements in coverage and metadata as well.

By default the pySigma implementation ensure that selections using the “re” modifier are matched as a “contains”. Which means no need to include a wildcard in at the start or end of the regex. The first is an update to multiple rules using taking care of this edge case

title: Invoke-Obfuscation Via Stdin
id: 9c14c9fa-1a63-4a64-8e57-d19280559490
status: test
description: Detects Obfuscated Powershell via Stdin in Scripts
references:
    - https://github.com/SigmaHQ/sigma/issues/1009 # (Task28)
author: Nikita Nazarov, oscd.community
date: 2020/10/12
modified: 2024/04/16
tags:
    - attack.defense_evasion
    - attack.t1027
    - attack.execution
    - attack.t1059.001
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        CommandLine|re: '(?i)(set).*&&\s?set.*(environment|invoke|\$\{?input).*&&.*"'
    condition: selection
falsepositives:
    - Unknown
level: high

The next set of updates is part of the first batch aiming to refactor LOLBIN based rules (unified filename convention, enhanced metadata and updated logic).

title: C# IL Code Compilation Via Ilasm.EXE
id: 850d55f9-6eeb-4492-ad69-a72338f65ba4
status: test
description: Detects the use of "Ilasm.EXE" in order to compile C# intermediate (IL) code to EXE or DLL.
references:
    - https://lolbas-project.github.io/lolbas/Binaries/Ilasm/
    - https://www.echotrail.io/insights/search/ilasm.exe
author: frack113, Nasreddine Bencherchali (Nextron Systems)
date: 2022/05/07
modified: 2022/05/16
tags:
    - attack.defense_evasion
    - attack.t1127
logsource:
    product: windows
    category: process_creation
detection:
    selection_img:
        - Image|endswith: '\ilasm.exe'
        - OriginalFileName: 'ilasm.exe'
    selection_cli:
        CommandLine|contains:
            - ' /dll'
            - ' /exe'
    condition: all of selection_*
falsepositives:
    - Unknown
level: medium

Check the full release changelog for a complete list of updates.

Fixes

This release includes a couple of false positives fixes and tuning of older rules to enhance their quality.

Please check the full change-log on the release page below for the complete list of changes and additions

Release Release r2024-04-29 · SigmaHQ/sigma

Contributors

This release was possible thanks to the many Sigma community contributors. A big thanks goes to following people

• @CertainlyP
• @dan21san
• @frack113
• @fukusuket
• @jamesc-grafana
• @nasbench
• @Neo23x0
• @netgrain
• @nikitah4x
• @phantinuss
• @PiRomant
• @pratinavchandra
• @ruppde
• @signalblur
• @swachchhanda000
• @TheLawsOfChaos
• @thomaspatzke
• @X-Junior
• @ya0guang

SigmaHQ Rules Release Highlights — r2024–04–29 was originally published in Sigma_HQ on Medium, where people are continuing the conversation by highlighting and responding to this story.

Sigma Rule Packages for 26–03–2024 are released and available for download. This release saw the addition of 21 new rules, 64 rule updates and 5 rule fixes by 9 contributors.

New Rules

Some highlights for the newer rules include rule for CVE-2024–1212 a “Progress Kemp LoadMaster Unauthenticated Command Injection”

title: CVE-2024-1212 Exploitation - Progress Kemp LoadMaster Unauthenticated Command Injection
id: eafb8bd5-7605-4bfe-a9ec-0442bc151f15
status: experimental
description: |
    Detects potential exploitation of CVE-2024-1709 an unauthenticated command injection in Progress Kemp LoadMaster.
    It looks for GET requests to '/access/set' API with the parameters 'param=enableapi' and 'value=1' as well as an "Authorization" header with a base64 encoded value with an uncommon character.
references:
    - https://github.com/RhinoSecurityLabs/CVEs/blob/15cf4d86c83daa57b59eaa2542a0ed47ad3dc32d/CVE-2024-1212/CVE-2024-1212.py
    - https://rhinosecuritylabs.com/research/cve-2024-1212unauthenticated-command-injection-in-progress-kemp-loadmaster/
author: Nasreddine Bencherchali (Nextron Systems)
date: 2024/03/20
tags:
    - attack.initial_access
    - cve.2024.1212
logsource:
    category: webserver
detection:
    selection_path:
        cs-method: 'GET'
        cs-uri-stem|contains|all:
            - '/access/set'
            - 'param=enableapi'
            - 'value=1'
    selection_keywords:
        - 'Basic Jz'
        - 'Basic c7'
        - 'Basic nO'
        - "Basic ';"
    condition: all of selection_*
falsepositives:
    - Unlikely
level: high

New set of rules covering activity related to KamiKakaBot.

title: Potential KamiKakaBot Activity - Lure Document Execution
id: 24474469-bd80-46cc-9e08-9fbe81bfaaca
status: experimental
description: |
    Detects the execution of a Word document via the WinWord Start Menu shortcut.
    This behavior was observed being used by KamiKakaBot samples in order to initiate the 2nd stage of the infection.
references:
    - https://www.nextron-systems.com/2024/03/22/unveiling-kamikakabot-malware-analysis/
author: Nasreddine Bencherchali (Nextron Systems), X__Junior (Nextron Systems)
date: 2024/03/22
tags:
    - attack.execution
    - attack.t1059
    - detection.emerging_threats
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '\cmd.exe'
        CommandLine|contains|all:
            - '/c '
            - '.lnk ~'
            - 'Start Menu\Programs\Word'
        CommandLine|endswith: '.doc'
    condition: selection
falsepositives:
    - Unknown
level: medium

title: Potential KamiKakaBot Activity - Shutdown Schedule Task Creation
id: fe9e8ba9-4419-41e6-a574-bd9f7b3af961
status: experimental
description: |
    Detects the creation of a schedule task that runs weekly and execute the "shutdown /l /f" command.
    This behavior was observed being used by KamiKakaBot samples in order to achieve persistence on a system.
references:
    - https://www.nextron-systems.com/2024/03/22/unveiling-kamikakabot-malware-analysis/
    - https://tria.ge/240123-rapteaahhr/behavioral1
author: Nasreddine Bencherchali (Nextron Systems), X__Junior (Nextron Systems)
date: 2024/03/22
tags:
    - attack.persistence
    - detection.emerging_threats
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '\schtasks.exe'
        CommandLine|contains|all:
            - ' /create '
            - 'shutdown /l /f'
            - 'WEEKLY'
    filter_main_system_user:
        User|contains: # covers many language settings
            - 'AUTHORI'
            - 'AUTORI'
    condition: selection and not 1 of filter_main_*
falsepositives:
    - Unknown
level: medium

A new set of rules leveraging native Kubernetes logs.

title: Potential Remote Command Execution In Pod Container
id: a1b0ca4e-7835-413e-8471-3ff2b8a66be6
status: experimental
description: |
    Detects attempts to execute remote commands, within a Pod's container using e.g. the "kubectl exec" command.
references:
    - https://microsoft.github.io/Threat-Matrix-for-Kubernetes/techniques/Exec%20into%20container/
author: Leo Tsaousis (@laripping)
date: 2024/03/26
tags:
    - attack.t1609
logsource:
    category: application
    product: kubernetes
    service: audit
detection:
    selection:
        verb: 'create'
        objectRef.resource: 'pods'
        objectRef.subresource: 'exec'
    condition: selection
falsepositives:
    - Legitimate debugging activity. Investigate the identity performing the requests and their authorization.
level: medium

title: Privileged Container Deployed
id: c5cd1b20-36bb-488d-8c05-486be3d0cb97
status: experimental
description: |
    Detects the creation of a "privileged" container, an action which could be indicative of a threat actor mounting a container breakout attacks.
    A privileged container is a container that can access the host with all of the root capabilities of the host machine. This allows it to view, interact and modify processes, network operations, IPC calls, the file system, mount points, SELinux configurations etc. as the root user on the host.
    Various versions of "privileged" containers can be specified, e.g. by setting the securityContext.privileged flag in the resource specification, setting non-standard Linux capabilities, or configuring the hostNetwork/hostPID fields
references:
    - https://microsoft.github.io/Threat-Matrix-for-Kubernetes/techniques/Privileged%20container/
    - https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-kubernetes.html#privilegeescalation-kubernetes-privilegedcontainer
    - https://www.elastic.co/guide/en/security/current/kubernetes-pod-created-with-hostnetwork.html
    - https://www.elastic.co/guide/en/security/current/kubernetes-container-created-with-excessive-linux-capabilities.html
author: Leo Tsaousis (@laripping)
date: 2024/03/26
tags:
    - attack.t1611
logsource:
    category: application
    product: kubernetes
    service: audit
detection:
    selection:
        verb: 'create'
        objectRef.resource: 'pods'
        capabilities: '*' # Note: Add the "exists" when it's implemented in SigmaHQ/Aurora
    condition: selection
falsepositives:
    - Unknown
level: low

New Updates

Some older rules have seen improvements in coverage and metadata as well.

The first big set of update is related to enhancing the registry rule so that they don’t use the hard coded “HKLM”, “HKCU” or similar prefixes.

The reason behind such an update is that not all logging utilities use that notation. And depending on how you use the rule either in a SIEM or doing registry parsing for DFIR related tasks. The output might change.

To account for this, we dropped the prefixes where possible.

title: New PortProxy Registry Entry Added
id: a54f842a-3713-4b45-8c84-5f136fdebd3c
status: test
description: Detects the modification of the PortProxy registry key which is used for port forwarding.
references:
    - https://www.fireeye.com/blog/threat-research/2019/01/bypassing-network-restrictions-through-rdp-tunneling.html
    - https://adepts.of0x.cc/netsh-portproxy-code/
    - https://www.dfirnotes.net/portproxy_detection/
author: Andreas Hunkeler (@Karneades)
date: 2021/06/22
modified: 2024/03/25
tags:
    - attack.lateral_movement
    - attack.defense_evasion
    - attack.command_and_control
    - attack.t1090
logsource:
    category: registry_event
    product: windows
detection:
    selection:
        # Example: HKLM\System\CurrentControlSet\Services\PortProxy\v4tov4\tcp\0.0.0.0/1337
        TargetObject|contains: '\Services\PortProxy\v4tov4\tcp\'
    condition: selection
falsepositives:
    - WSL2 network bridge PowerShell script used for WSL/Kubernetes/Docker (e.g. https://github.com/microsoft/WSL/issues/4150#issuecomment-504209723)
    - Synergy Software KVM (https://symless.com/synergy)
level: medium

Another set of update include the migration of rules to use the “windash” modifier. This modifier tells the sigma converter utility to use both permutation of a commandline flag.

For example many utilities accept both CLI flags with “/” (slash) and “-” (dash). This modifier abstracts this idea and let the user only care about one.

title: Potential Reconnaissance For Cached Credentials Via Cmdkey.EXE
id: 07f8bdc2-c9b3-472a-9817-5a670b872f53
status: test
description: Detects usage of cmdkey to look for cached credentials on the system
references:
    - https://www.peew.pw/blog/2017/11/26/exploring-cmdkey-an-edge-case-for-privilege-escalation
    - https://technet.microsoft.com/en-us/library/cc754243(v=ws.11).aspx
    - https://github.com/redcanaryco/atomic-red-team/blob/b27a3cb25025161d49ac861cb216db68c46a3537/atomics/T1003.005/T1003.005.md#atomic-test-1---cached-credential-dump-via-cmdkey
author: jmallette, Florian Roth (Nextron Systems), Nasreddine Bencherchali (Nextron Systems)
date: 2019/01/16
modified: 2024/03/05
tags:
    - attack.credential_access
    - attack.t1003.005
logsource:
    category: process_creation
    product: windows
detection:
    selection_img:
        - Image|endswith: '\cmdkey.exe'
        - OriginalFileName: 'cmdkey.exe'
    selection_cli:
        CommandLine|contains|windash: ' -l'
    condition: all of selection*
fields:
    - CommandLine
    - ParentCommandLine
    - User
falsepositives:
    - Legitimate administrative tasks
level: high

We also migrated all rules that make use of the CIDR notation in their logic. To use the “cidr” modifier. Which allows rule authors to write IP ranges in CIDR format.

title: Dllhost.EXE Initiated Network Connection To Non-Local IP Address
id: cfed2f44-16df-4bf3-833a-79405198b277
status: test
description: |
    Detects dllhost initiating a network connection to a non-local IP address.
    Aside from Microsoft own IP range that needs to be excluded. Network communication from Dllhost will depend entirely on the hosted DLL.
    An initial baseline is recommended before deployment.
references:
    - https://redcanary.com/blog/child-processes/
    - https://nasbench.medium.com/what-is-the-dllhost-exe-process-actually-running-ef9fe4c19c08
author: bartblaze
date: 2020/07/13
modified: 2024/03/12
tags:
    - attack.defense_evasion
    - attack.t1218
    - attack.execution
    - attack.t1559.001
logsource:
    category: network_connection
    product: windows
detection:
    selection:
        Image|endswith: '\dllhost.exe'
        Initiated: 'true'
    filter_main_local_ranges:
        DestinationIp|cidr:
            - '::1/128'  # IPv6 loopback
            - '10.0.0.0/8'
            - '127.0.0.0/8'
            - '172.16.0.0/12'
            - '192.168.0.0/16'
            - '169.254.0.0/16'
            - 'fc00::/7'  # IPv6 private addresses
            - 'fe80::/10'  # IPv6 link-local addresses
    filter_main_msrange:
        DestinationIp|cidr:
            - '20.184.0.0/13' # Microsoft Corporation
            - '20.192.0.0/10' # Microsoft Corporation
            - '23.72.0.0/13'  # Akamai International B.V.
            - '51.10.0.0/15'  # Microsoft Corporation
            - '51.103.0.0/16' # Microsoft Corporation
            - '51.104.0.0/15' # Microsoft Corporation
            - '52.224.0.0/11'  # Microsoft Corporation
            - '204.79.197.0/24' # Microsoft Corporation'
    condition: selection and not 1 of filter_main_*
falsepositives:
    - Communication to other corporate systems that use IP addresses from public address spaces
level: medium

Multiple rules also saw update to their logic in order to increase coverage. A couple of example include.

New domains added for the rule “Suspicious DNS Query for IP Lookup Service APIs”.

title: Suspicious DNS Query for IP Lookup Service APIs
id: ec82e2a5-81ea-4211-a1f8-37a0286df2c2
status: test
description: Detects DNS queries for IP lookup services such as "api.ipify.org" originating from a non browser process.
references:
    - https://www.binarydefense.com/analysis-of-hancitor-when-boring-begets-beacon
    - https://twitter.com/neonprimetime/status/1436376497980428318
    - https://www.trendmicro.com/en_us/research/23/e/managed-xdr-investigation-of-ducktail-in-trend-micro-vision-one.html
author: Brandon George (blog post), Thomas Patzke
date: 2021/07/08
modified: 2024/03/22
tags:
    - attack.reconnaissance
    - attack.t1590
logsource:
    product: windows
    category: dns_query
detection:
    selection:
        - QueryName:
              - 'www.ip.cn'
              - 'l2.io'
        - QueryName|contains:
              - 'api.2ip.ua'
              - 'api.bigdatacloud.net'
              - 'api.ipify.org'
              - 'bot.whatismyipaddress.com'
              - 'canireachthe.net'
              - 'checkip.amazonaws.com'
              - 'checkip.dyndns.org'
              - 'curlmyip.com'
              - 'db-ip.com'
              - 'edns.ip-api.com'
              - 'eth0.me'
              - 'freegeoip.app'
              - 'geoipy.com'
              - 'getip.pro'
              - 'icanhazip.com'
              - 'ident.me'
              - 'ifconfig.io'
              - 'ifconfig.me'
              - 'ip-api.com'
              - 'ip.360.cn'
              - 'ip.anysrc.net'
              - 'ip.taobao.com'
              - 'ip.tyk.nu'
              - 'ipaddressworld.com'
              - 'ipapi.co'
              - 'ipconfig.io'
              - 'ipecho.net'
              - 'ipinfo.io'
              - 'ipip.net'
              - 'ipof.in'
              - 'ipv4.icanhazip.com'
              - 'ipv4bot.whatismyipaddress.com'
              - 'ipv6-test.com'
              - 'ipwho.is'
              - 'jsonip.com'
              - 'myexternalip.com'
              - 'seeip.org'
              - 'wgetip.com'
              - 'whatismyip.akamai.com'
              - 'whois.pconline.com.cn'
              - 'wtfismyip.com'
    filter_optional_brave:
        Image|endswith: '\brave.exe'
    filter_optional_chrome:
        Image:
            - 'C:\Program Files\Google\Chrome\Application\chrome.exe'
            - 'C:\Program Files (x86)\Google\Chrome\Application\chrome.exe'
    filter_optional_firefox:
        Image:
            - 'C:\Program Files\Mozilla Firefox\firefox.exe'
            - 'C:\Program Files (x86)\Mozilla Firefox\firefox.exe'
    filter_optional_ie:
        Image:
            - 'C:\Program Files (x86)\Internet Explorer\iexplore.exe'
            - 'C:\Program Files\Internet Explorer\iexplore.exe'
    filter_optional_maxthon:
        Image|endswith: '\maxthon.exe'
    filter_optional_edge_1:
        - Image|startswith: 'C:\Program Files (x86)\Microsoft\EdgeWebView\Application\'
        - Image|endswith: '\WindowsApps\MicrosoftEdge.exe'
        - Image:
              - 'C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe'
              - 'C:\Program Files\Microsoft\Edge\Application\msedge.exe'
    filter_optional_edge_2:
        Image|startswith:
            - 'C:\Program Files (x86)\Microsoft\EdgeCore\'
            - 'C:\Program Files\Microsoft\EdgeCore\'
        Image|endswith:
            - '\msedge.exe'
            - '\msedgewebview2.exe'
    filter_optional_opera:
        Image|endswith: '\opera.exe'
    filter_optional_safari:
        Image|endswith: '\safari.exe'
    filter_optional_seamonkey:
        Image|endswith: '\seamonkey.exe'
    filter_optional_vivaldi:
        Image|endswith: '\vivaldi.exe'
    filter_optional_whale:
        Image|endswith: '\whale.exe'
    condition: selection and not 1 of filter_optional_*
falsepositives:
    - Legitimate usage of IP lookup services such as ipify API
level: medium

Enhanced logic for “Potentially Suspicious CMD Shell Output Redirect”

title: Potentially Suspicious CMD Shell Output Redirect
id: 8e0bb260-d4b2-4fff-bb8d-3f82118e6892
related:
    - id: aa2efee7-34dd-446e-8a37-40790a66efd7
      type: derived
    - id: 4f4eaa9f-5ad4-410c-a4be-bc6132b0175a
      type: similar
status: experimental
description: |
    Detects inline Windows shell commands redirecting output via the ">" symbol to a suspicious location.
    This technique is sometimes used by malicious actors in order to redirect the output of reconnaissance commands such as "hostname" and "dir" to files for future exfiltration.
references:
    - https://thedfirreport.com/2022/07/11/select-xmrig-from-sqlserver/
author: Nasreddine Bencherchali (Nextron Systems)
date: 2022/07/12
modified: 2024/03/19
tags:
    - attack.defense_evasion
    - attack.t1218
logsource:
    category: process_creation
    product: windows
detection:
    selection_img:
        - Image|endswith: '\cmd.exe'
        - OriginalFileName: 'Cmd.Exe'
    selection_cli_1:
        CommandLine|contains:
            # Note: Add more suspicious locations as you find them
            # Note: The space from the start is missing to cover append operations ">>"
            # Note: We use the "?" to account for both a single and a double quote
            # Note: If you want to account for more spaces which is still a valid bypass option. Use a regex with "\s"
            - '>?%APPDATA%\'
            - '>?%TEMP%\'
            - '>?%TMP%\'
            - '>?%USERPROFILE%\'
            - '>?C:\ProgramData\'
            - '>?C:\Temp\'
            - '>?C:\Users\Public\'
            - '>?C:\Windows\Temp\'
    selection_cli_2:
        CommandLine|contains:
            - ' >'
            - '">'
            - "'>"
        CommandLine|contains|all:
            - 'C:\Users\'
            - '\AppData\Local\'
    condition: selection_img and 1 of selection_cli_*
falsepositives:
    - Legitimate admin or third party scripts used for diagnostic collection might generate some false positives
level: medium

Fixes

This release includes a couple of false positives fixes and tuning of older rules to enhance their quality.

Please check the full change-log on the release page below for the complete list of changes and additions.

Release Release r2024-03-26 · SigmaHQ/sigma

Contributors

This release was possible thanks to the many Sigma community contributors. A big thanks goes to following people:

• @cyb3rjy0t
• @frack113
• @joshnck
• @LAripping
• @nasbench
• @phantinuss
• @security-companion
• @xiangchen96
• @X-Junior

SigmaHQ Rules Release Highlights — r2024–03–26 was originally published in Sigma_HQ on Medium, where people are continuing the conversation by highlighting and responding to this story.

Originally posted: https://grafana.com/blog/2024/03/25/how-to-validate-sigma-rules-with-github-actions-for-improved-security-monitoring/

Monitoring your identity provider’s logs is critical to identify potential security threats. These logs are vital for a security team, who may store them in a specialized tool like Grafana Loki for enhanced accessibility and analysis. The ability to pinpoint specific patterns within these logs is key — and by crafting these patterns into Loki queries, you can conduct focused searches across the logs. You can set alerts to streamline this process, but conducting checks manually can become cumbersome over time.

Enter Sigma, an open standard for defining pattern detection rules. By employing YAML-formatted rules, Sigma allows you to specify the exact log patterns you’re searching for, thereby optimizing your security operations. What makes Sigma rules particularly powerful is their versatility; they’re generic and can be converted into queries for various backends. An example of this is the pySigma-backend-loki project, which translates Sigma rules into LogQL queries, further enhancing the efficiency and effectiveness of your security monitoring strategy.

This blog post introduces a new GitHub Action developed by the Grafana Security Operations team designed to automate the validation of Sigma rules against our previously developed JSON Schema. We’ll delve into the tool’s history and how it came to be, and then walk through how to integrate it into GitHub Actions’ workflows.

A (little more than a) bit of history

In the summer of 2023, the Grafana SecOps team was working on an internal project that integrated pySigma and pySigma-backend-loki, building on the foundational work of the Sigma contributors.

During the project’s progression, we identified a need for better validation within the Sigma repository, where all Sigma rules are stored and maintained. The existing schema, crafted from the Sigma specification repository, required updates. Moreover, it was formatted in Rx Schema, a standard that was quite unfamiliar to me at the time. Upon investigation, we found the Rx Schema format to be outdated and seemingly no longer maintained.

Based on our experience with JSON Schema, we decided to contribute to the Sigma project by creating a JSON Schema for Sigma rules, building on top of the Sigma specification. Sigma rules are written in YAML, so the JSON Schema can help validate their contents. This work involved significant collaboration and iteration with the Sigma maintainers, leading up to the successful merging of our contributions.

JSON schema for Sigma specification by mostafa · Pull Request #4367 · SigmaHQ/sigma

The schema is also available on the Schema Store, which is a collection of independent JSON Schemas that can be used in your IDE or JSON tooling. For more information, visit the Schema Store website.

Included in our contribution was a small Bash script, alongside the check-jsonschema project, which allowed us to validate all the rules against the newly introduced JSON Schema. This process surfaced two Sigma rules with invalid related UUIDs, which we promptly addressed. Now, every new commit that alters the rules undergoes validation against this JSON Schema.

A few months ago, in a team discussion, the idea emerged to develop a GitHub Action for workflows to validate Sigma rules, including those in private repositories. None of us had prior experience in this area, so we embarked on a learning journey, eventually creating a GitHub Action. Initially, we expanded the Bash script for use in GitHub Actions, but faced a few challenges in its functionality and maintainability. Ultimately, we rewrote the script in Python to utilize the pathlib module and other features, enhancing the script’s effectiveness.

Our efforts received positive feedback from the Sigma maintainers, particularly Nasreddine Bencherchali, who supported the idea of keeping the script within the Sigma rules repository and fetching the schema directly from the Sigma specification repository. This collaborative effort took time to refine, but ultimately succeeded.

Update validate script by mostafa · Pull Request #4724 · SigmaHQ/sigma

We donated the sigma-rules-validator project to SigmaHQ, and after some revisions and bug fixes, it was officially published and is now available to the community.

Sigma Rules Validator - GitHub Marketplace

How to validate Sigma rules

Now, we’ll walk through an example of how to validate Sigma rules using the sigma-rules-validator project. The project’s README provides comprehensive instructions, and the Sigma repository itself serves as an excellent example of the action’s application.

steps:
    - uses: SigmaHQ/sigma-rules-validator@v1

The process involves enumerating .yml files in the repository’s root directory, validating them against the JSON Schema file, and then outputting the validation results. For a more focused approach, placing Sigma files in a specific directory, like rules, and specifying this directory for validation can streamline the process, and helps prevent non-Sigma rules from being enumerated.

steps:
    - uses: SigmaHQ/sigma-rules-validator@v1
      with:
        paths: './rules'

You can also pass multiple directories, if you happen to organize different rules in different directories:

steps:
    - uses: SigmaHQ/sigma-rules-validator@v1
      with:
        paths: |-
          ./rules
          ./custom-rules

For those with a JSON Schema within their Sigma rules repository or intending to validate against a custom JSON Schema, the action offers the flexibility to accommodate these scenarios. The following examples show how this can be done:

steps:
    - uses: SigmaHQ/sigma-rules-validator@v1
      with:
        paths: './'
        schemaFile: './sigma-schema.json'

steps:
    - uses: SigmaHQ/sigma-rules-validator@v1
      with:
        paths: './'
        schemaURL: 'https://raw.githubusercontent.com/SigmaHQ/sigma-specification/main/sigma-schema.json'

We hope this initiative will aid in crafting valid Sigma rules and we welcome any feedback, feature requests, or contributions through issues or pull requests. You can also reach out to us in the #security channel of our Grafana Community Slack.

How to validate Sigma rules with GitHub Actions for improved security monitoring was originally published in Sigma_HQ on Medium, where people are continuing the conversation by highlighting and responding to this story.

Sigma Rule Packages for 11–03–2024 are released and available for download. This release saw the addition of 28 new rules, 5 rule updates and 5 rule fixes by 12 contributors.

New Rules

Some highlights for the newer rules include new rules targeting logs from GitHub based on the secret scanning feature released early this month.

title: Github Push Protection Bypass Detected
id: 02cf536a-cf21-4876-8842-4159c8aee3cc
status: experimental
description: Detects when a user bypasses the push protection on a secret detected by secret scanning.
references:
    - https://docs.github.com/en/enterprise-cloud@latest/code-security/secret-scanning/push-protection-for-repositories-and-organizations
    - https://thehackernews.com/2024/03/github-rolls-out-default-secret.html
author: Muhammad Faisal (@faisalusuf)
date: 2024/03/07
tags:
    - attack.defense_evasion
    - attack.t1562.001
logsource:
    product: github
    service: audit
    definition: 'Requirements: The audit log streaming feature must be enabled to be able to receive such logs. You can enable following the documentation here: https://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/streaming-the-audit-log-for-your-enterprise#setting-up-audit-log-streaming'
detection:
    selection:
        action|contains: 'secret_scanning_push_protection.bypass'
    condition: selection
falsepositives:
    - Allowed administrative activities.
level: low

title: Github Push Protection Disabled
id: ccd55945-badd-4bae-936b-823a735d37dd
status: experimental
description: Detects if the push protection feature is disabled for an organization, enterprise, repositories or custom pattern rules.
references:
    - https://docs.github.com/en/enterprise-cloud@latest/code-security/secret-scanning/push-protection-for-repositories-and-organizations
    - https://thehackernews.com/2024/03/github-rolls-out-default-secret.html
author: Muhammad Faisal (@faisalusuf)
date: 2024/03/07
tags:
    - attack.defense_evasion
    - attack.t1562.001
logsource:
    product: github
    service: audit
    definition: 'Requirements: The audit log streaming feature must be enabled to be able to receive such logs. You can enable following the documentation here: https://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/streaming-the-audit-log-for-your-enterprise#setting-up-audit-log-streaming'
detection:
    selection:
        action:
            - 'business_secret_scanning_custom_pattern_push_protection.disabled'
            - 'business_secret_scanning_push_protection.disable'
            - 'business_secret_scanning_push_protection.disabled_for_new_repos'
            - 'org.secret_scanning_custom_pattern_push_protection_disabled'
            - 'org.secret_scanning_push_protection_disable'
            - 'org.secret_scanning_push_protection_new_repos_disable'
            - 'repository_secret_scanning_custom_pattern_push_protection.disabled'
    condition: selection
falsepositives:
    - Allowed administrative activities.
level: high

A new log source has been added targeting OpenCanary logs and with it a couple of new rules (18 specifically) that are meant to trigger on canary matches.

title: OpenCanary - MSSQL Login Attempt Via SQLAuth
id: 3ec9a16d-0b4f-4967-9542-ebf38ceac7dd
status: experimental
description: |
    Detects instances where an MSSQL service on an OpenCanary node has had a login attempt using SQLAuth.
references:
    - https://opencanary.readthedocs.io/en/latest/starting/configuration.html#services-configuration
    - https://github.com/thinkst/opencanary/blob/a0896adfcaf0328cfd5829fe10d2878c7445138e/opencanary/logger.py#L52
author: Security Onion Solutions
date: 2024/03/08
tags:
    - attack.credential_access
    - attack.collection
    - attack.t1003
    - attack.t1213
logsource:
    category: application
    product: opencanary
detection:
    selection:
        logtype: 9001
    condition: selection
falsepositives:
    - Unlikely
level: high

title: OpenCanary - SMB File Open Request
id: 22777c9e-873a-4b49-855f-6072ab861a52
status: experimental
description: Detects instances where an SMB service on an OpenCanary node has had a file open request.
references:
    - https://opencanary.readthedocs.io/en/latest/starting/configuration.html#services-configuration
    - https://github.com/thinkst/opencanary/blob/a0896adfcaf0328cfd5829fe10d2878c7445138e/opencanary/logger.py#L52
author: Security Onion Solutions
date: 2024/03/08
tags:
    - attack.lateral_movement
    - attack.collection
    - attack.t1021
    - attack.t1005
logsource:
    category: application
    product: opencanary
detection:
    selection:
        logtype: 5000
    condition: selection
falsepositives:
    - Unlikely
level: high

Other rules include “Shell Context Menu Command Tampering” and “Potential Raspberry Robin CPL Execution Activity” covering the tampering of shell context menus as reported recently, and new activity seen used by recent raspberry samples respectively.

title: Potential Raspberry Robin CPL Execution Activity
id: 92020b88-9caf-464f-bad8-cd0fb0aa2a81
status: experimental
description: |
    Detects the execution of a ".CPL" file located in the user temp directory via the Shell32 DLL "Control_RunDLL" export function.
    This behavior was observed in multiple Raspberry-Robin variants.
references:
    - https://tria.ge/240226-fhbe7sdc39/behavioral1
    - https://bazaar.abuse.ch/browse/signature/RaspberryRobin/
author: Swachchhanda Shrawan Poudel
date: 2024/03/07
tags:
    - detection.emerging_threats
    - attack.defense_evasion
    - attack.execution
    - attack.t1218.011
logsource:
    category: process_creation
    product: windows
detection:
    # Example: "C:\Windows\system32\rundll32.exe" Shell32.dll,Control_RunDLL "C:\Users\xxxx\AppData\Local\Temp\xxxx.CPL"
    selection_parent_img:
        ParentImage|endswith:
            - '\rundll32.exe'
            - '\control.exe'
    selection_img:
        - Image|endswith: '\rundll32.exe'
        - OriginalFileName: 'RUNDLL32.EXE'
    selection_cli:
        CommandLine|contains|all:
            - 'shell32.dll'
            - 'Control_RunDLL'
            - '.CPL'
    selection_path:
        CommandLine|contains: '\AppData\Local\Temp\'
    condition: all of selection_*
falsepositives:
    - Unknown
level: high 

title: Shell Context Menu Command Tampering
id: 868df2d1-0939-4562-83a7-27408c4a1ada
status: experimental
description: Detects changes to shell context menu commands. Use this rule to hunt for potential anomalies and suspicious shell commands.
references:
    - https://mrd0x.com/sentinelone-persistence-via-menu-context/
author: Nasreddine Bencherchali (Nextron Systems)
date: 2024/03/06
tags:
    - attack.persistence
    - detection.threat_hunting
logsource:
    category: registry_set
    product: windows
detection:
    selection:
        TargetObject|contains|all:
            - '\Software\Classes\'
            - '\shell\'
            - '\command\'
    condition: selection
falsepositives:
    - Likely from new software installation suggesting to add context menu items. Such as "PowerShell", "Everything", "Git", etc.
level: low

New Updates

Some older rules have seen improvements in coverage and metadata as well. Some examples include

Addition of “regsvr32” to increase coverage

title: Potential PowerShell Execution Via DLL
id: 6812a10b-60ea-420c-832f-dfcc33b646ba
status: test
description: |
    Detects potential PowerShell execution from a DLL instead of the usual PowerShell process as seen used in PowerShdll.
    This detection assumes that PowerShell commands are passed via the CommandLine.
references:
    - https://github.com/p3nt4/PowerShdll/blob/62cfa172fb4e1f7f4ac00ca942685baeb88ff356/README.md
author: Markus Neis, Nasreddine Bencherchali (Nextron Systems)
date: 2018/08/25
modified: 2024/03/07
tags:
    - attack.defense_evasion
    - attack.t1218.011
logsource:
    category: process_creation
    product: windows
detection:
    selection_img:
        - Image|endswith:
              - '\InstallUtil.exe'
              - '\RegAsm.exe'
              - '\RegSvcs.exe'
              - '\regsvr32.exe'
              - '\rundll32.exe'
        - OriginalFileName:
              - 'InstallUtil.exe'
              - 'RegAsm.exe'
              - 'RegSvcs.exe'
              - 'REGSVR32.EXE'
              - 'RUNDLL32.EXE'
    selection_cli:
        CommandLine|contains:
            - 'Default.GetString'
            - 'DownloadString'
            - 'FromBase64String'
            - 'ICM '
            - 'IEX '
            - 'Invoke-Command'
            - 'Invoke-Expression'
    condition: all of selection_*
falsepositives:
    - Unknown
level: high

Addition of “InstallUtil”, “RegAsm” and “RegSvcs” as additional process.

title: Unsigned DLL Loaded by Windows Utility
id: b5de0c9a-6f19-43e0-af4e-55ad01f550af
status: experimental
description: |
    Detects windows utilities loading an unsigned or untrusted DLL.
    Adversaries often abuse those programs to proxy execution of malicious code.
references:
    - https://www.elastic.co/security-labs/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion
    - https://akhere.hashnode.dev/hunting-unsigned-dlls-using-kql
    - https://unit42.paloaltonetworks.com/unsigned-dlls/?web_view=true
author: Swachchhanda Shrawan Poudel
date: 2024/02/28
modified: 2024/03/07
tags:
    - attack.t1218.011
    - attack.t1218.010
    - attack.defense_evasion
logsource:
    product: windows
    category: image_load
detection:
    selection:
        Image|endswith:
            # Note: Add additional utilities that allow the loading of DLLs
            - '\InstallUtil.exe'
            - '\RegAsm.exe'
            - '\RegSvcs.exe'
            - '\regsvr32.exe'
            - '\rundll32.exe'
    filter_main_signed:
        Signed: 'true'
    filter_main_sig_status:
        SignatureStatus:
            - 'errorChaining'
            - 'errorCode_endpoint'
            - 'errorExpired'
            - 'trusted'
    filter_main_signed_null:
        Signed: null
    filter_main_signed_empty:
        Signed:
            - ''
            - '-'
    filter_main_sig_status_null:
        SignatureStatus: null
    filter_main_sig_status_empty:
        SignatureStatus:
            - ''
            - '-'
    condition: selection and not 1 of filter_main_*
falsepositives:
    - Unknown
level: medium

Fixes

This release includes a couple of false positives fixes and tuning of older rules to enhance their quality.

Please check the full changelog on the release page below for the complete list of changes and additions.

Release Release r2024-03-11 · SigmaHQ/sigma

Contributors

This release was possible thanks to the many Sigma community contributors. A big thanks goes to following people:

• @benmontour
• @CrimpSec
• @defensivedepth
• @faisalusuf
• @frack113
• @nasbench
• @qasimqlf
• @secDre4mer
• @snajafov
• @swachchhanda000
• @tr0mb1r
• @X-Junior

SigmaHQ Rules Release Highlights — r2024–03–11 was originally published in Sigma_HQ on Medium, where people are continuing the conversation by highlighting and responding to this story.

Sigma Rule Packages for 26–02–2024 are released and available for download. This release saw the addition of 31 new rules, 16 rule updates by 9 contributors.

New Rules

Some highlights for the newer rules include new rules related to the ScreenConnect “Slash and Grab” exploit CVE-2024–1708 and CVE-2024–1709.

title: CVE-2024-1709 - ScreenConnect Authentication Bypass Exploitation
id: d27eabad-9068-401a-b0d6-9eac744d6e67
status: experimental
description: |
    Detects GET requests to '/SetupWizard.aspx/[anythinghere]' that indicate exploitation of the ScreenConnect vulnerability CVE-2024-1709.
references:
    - https://www.connectwise.com/company/trust/security-bulletins/connectwise-screenconnect-23.9.8
    - https://www.huntress.com/blog/a-catastrophe-for-control-understanding-the-screenconnect-authentication-bypass
    - https://www.cve.org/CVERecord?id=CVE-2024-1709
author: Matt Anderson, Huntress
date: 2024/02/20
tags:
    - attack.initial_access
    - attack.persistence
    - cve.2024.1709
logsource:
    category: webserver
detection:
    selection:
        cs-uri-stem|contains: '/SetupWizard.aspx/'
    condition: selection
falsepositives:
    - Unknown
level: critical

title: CVE-2024-1708 - ScreenConnect Path Traversal Exploitation
id: 44d7af7e-88e6-4490-be11-55f7ff4d9fc1
related:
    - id: 4c198a60-7d05-4daf-8bf7-4136fb6f5c62
      type: similar
status: experimental
description: |
    This detects file modifications to ASPX and ASHX files within the root of the App_Extensions directory, which is allowed by a ZipSlip vulnerability in versions prior to 23.9.8. This occurs during exploitation of CVE-2024-1708.
references:
    - https://www.connectwise.com/company/trust/security-bulletins/connectwise-screenconnect-23.9.8
    - https://www.cve.org/CVERecord?id=CVE-2024-1709
    - https://www.huntress.com/blog/a-catastrophe-for-control-understanding-the-screenconnect-authentication-bypass
author: Matt Anderson, Andrew Schwartz, Caleb Stewart, Huntress
date: 2024/02/21
tags:
    - attack.persistence
    - cve.2024.1708
logsource:
    product: windows
    category: file_event
detection:
    selection:
        Image|endswith: '\ScreenConnect.Service.exe'
        TargetFilename|endswith:
            - 'ScreenConnect\\App_Extensions\\*.ashx'
            - 'ScreenConnect\\App_Extensions\\*.aspx'
    filter_main_legit_extension:
        TargetFilename|contains: 'ScreenConnect\App_Extensions\\*\\'
    condition: selection and not 1 of filter_main_*
falsepositives:
    - This will occur legitimately as well and will result in some benign activity.
level: medium

As well as generic rules for exploitation indicator of the ScreenConnect client and server.

title: Remote Access Tool - ScreenConnect Potential Suspicious Remote Command Execution
id: 7b582f1a-b318-4c6a-bf4e-66fe49bf55a5
related:
    - id: d1a401ab-8c47-4e86-a7d8-2460b6a53e4a
      type: derived
status: test
description: |
    Detects potentially suspicious child processes launched via the ScreenConnect client service.
references:
    - https://www.mandiant.com/resources/telegram-malware-iranian-espionage
    - https://docs.connectwise.com/ConnectWise_Control_Documentation/Get_started/Host_client/View_menu/Backstage_mode
    - https://www.huntress.com/blog/slashandgrab-screen-connect-post-exploitation-in-the-wild-cve-2024-1709-cve-2024-1708
author: Florian Roth (Nextron Systems), Nasreddine Bencherchali (Nextron Systems), @Kostastsale
date: 2022/02/25
modified: 2024/02/26
tags:
    - attack.command_and_control
    - attack.t1219
logsource:
    product: windows
    category: process_creation
detection:
    selection:
        ParentCommandLine|contains|all:
            - ':\Windows\TEMP\ScreenConnect\'
            - 'run.cmd'
        Image|endswith:
            - '\cmd.exe'
            - '\curl.exe'
            - '\powershell.exe'
            - '\pwsh.exe'
            - '\wevtutil.exe'
    condition: selection
falsepositives:
    - If the script being executed make use of any of the utilities mentioned in the detection then they should filtered out or allowed.
level: medium

title: Remote Access Tool - ScreenConnect Server Web Shell Execution
id: b19146a3-25d4-41b4-928b-1e2a92641b1b
status: experimental
description: Detects potential web shell execution from the ScreenConnect server process.
references:
    - https://blackpointcyber.com/resources/blog/breaking-through-the-screen/
    - https://www.connectwise.com/company/trust/security-bulletins/connectwise-screenconnect-23.9.8
author: Jason Rathbun (Blackpoint Cyber)
date: 2024/02/26
tags:
    - attack.initial_access
    - attack.t1190
logsource:
    product: windows
    category: process_creation
detection:
    selection:
        ParentImage|endswith: '\ScreenConnect.Service.exe'
        Image|endswith:
            - '\cmd.exe'
            - '\csc.exe'
    condition: selection
falsepositives:
    - Unlikely
level: high

Another major contribution this release was the addition of the first set of Bitbucket related rules based on Audit logs generated by Bitbucket. These include

• Full data export
• Global permission tampering
• Project scanning rules deletion

and much more

title: Bitbucket Full Data Export Triggered
id: 195e1b9d-bfc2-4ffa-ab4e-35aef69815f8
status: experimental
description: Detects when full data export is attempted.
references:
    - https://confluence.atlassian.com/bitbucketserver/audit-log-events-776640423.html
    - https://confluence.atlassian.com/adminjiraserver0811/importing-and-exporting-data-1019391889.html
author: Muhammad Faisal (@faisalusuf)
date: 2024/02/25
tags:
    - attack.collection
    - attack.t1213.003
logsource:
    product: bitbucket
    service: audit
    definition: 'Requirements: "Advance" log level is required to receive these audit events.'
detection:
    selection:
        auditType.category: 'Data pipeline'
        auditType.action: 'Full data export triggered'
    condition: selection
falsepositives:
    - Legitimate user activity.
level: high

title: Bitbucket Global Permission Changed
id: aac6c4f4-87c7-4961-96ac-c3fd3a42c310
status: experimental
description: Detects global permissions change activity.
references:
    - https://confluence.atlassian.com/bitbucketserver/audit-log-events-776640423.html
    - https://confluence.atlassian.com/bitbucketserver/global-permissions-776640369.html
author: Muhammad Faisal (@faisalusuf)
date: 2024/02/25
tags:
    - attack.persistence
    - attack.privilege_escalation
    - attack.t1098
logsource:
    product: bitbucket
    service: audit
    definition: 'Requirements: "Advance" log level is required to receive these audit events.'
detection:
    selection:
        auditType.category: 'Permissions'
        auditType.action:
            - 'Global permission remove request'
            - 'Global permission removed'
            - 'Global permission granted'
            - 'Global permission requested'
    condition: selection
falsepositives:
    - Legitimate user activity.
level: medium

New Updates

A couple of the older rules have seen some improvements in coverage and metadata as well. Some examples include

New User-Agent to the APT UA hunting rule related to RedCurl APT

title: APT User Agent
id: 6ec820f2-e963-4801-9127-d8b2dce4d31b
status: test
description: Detects suspicious user agent strings used in APT malware in proxy logs
references:
    - Internal Research
author: Florian Roth (Nextron Systems), Markus Neis
date: 2019/11/12
modified: 2024/02/15
tags:
    - attack.command_and_control
    - attack.t1071.001
logsource:
    category: proxy
detection:
    selection:
        c-useragent:
         # APT Related
            - 'SJZJ (compatible; MSIE 6.0; Win32)' # APT Backspace
            - 'Mozilla/5.0 (Windows NT 6.; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0' # APT GrizzlySteppe - ChopStick - US CERT https://goo.gl/1DTHwi
            - 'User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC' # Comment Crew Miniasp
            - 'Mozilla/4.0 (compatible; MSIE 7.4; Win32;32-bit)' # Comment Crew Miniasp
            - 'webclient' # Naikon APT
            - 'Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-EN; rv:1.7.12) Gecko/200' # Naikon APT
            - 'Mozilla/4.0 (compatible; MSI 6.0;' # SnowGlobe Babar - yes, it is cut
            - 'Mozilla/5.0 (Windows NT 6.3; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0' # Sofacy - Xtunnel
            - 'Mozilla/5.0 (Windows NT 6.2; WOW64; rv:20.0) Gecko/20100101 Firefox/' # Sofacy - Xtunnel
            - 'Mozilla/5.0 (Windows NT 6.; WOW64; rv:20.0) Gecko/20100101 Firefox/2' # Sofacy - Xtunnel
            - 'Mozilla/4.0' # Derusbi backdoor ELF https://github.com/fideliscyber/indicators/tree/master/FTA-1021
            - 'Netscape' # Unit78020 Malware
            - 'Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-EN; rv:1.7.12) Gecko/20100719 Firefox/1.0.7' # Unit78020 Malware
            - 'Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Firefox/3.6.13 GTB7.1' # Winnti related
            - 'Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)' # Winnti related
            - 'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NETCLR 2.0.50727)' # APT17
            - 'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; SV1)' # Bronze Butler - Daserf
            - 'Mozilla/4.0 (compatible; MSIE 11.0; Windows NT 6.1; SV1)' # Bronze Butler - Daserf
            - 'Mozilla/4.0 (compatible; MSIE 8.0; Win32)' # TSCookie https://app.any.run/tasks/0996b314-5133-491b-8d23-d431ffdec597
            - 'Mozilla v5.1 (Windows NT 6.1; rv:6.0.1) Gecko/20100101 Firefox/6.0.1' # Delphi downloader https://www.welivesecurity.com/2018/04/24/sednit-update-analysis-zebrocy/
            - 'Mozilla/6.1 (compatible; MSIE 9.0; Windows NT 5.3; Trident/5.0)' # VPNFilter https://blog.talosintelligence.com/2018/05/VPNFilter.html
            - 'Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; InfoPath.1)' # Sofacy User-Agent https://researchcenter.paloaltonetworks.com/2018/06/unit42-sofacy-groups-parallel-attacks/
            - 'Mozilla/5.0 (Windows NT 6.1; WOW64) WinHttp/1.6.3.8 (WinHTTP/5.1) like Gecko' # Sofacy User-Agent https://researchcenter.paloaltonetworks.com/2018/06/unit42-sofacy-groups-parallel-attacks/
            - 'Mozilla v5.1 *' # Sofacy Zebrocy samples
            - 'MSIE 8.0' # Sofacy Azzy Backdoor  from https://www.hybrid-analysis.com/sample/a80e29c0757bee05338fd5c22a542d852ad86c477068e3eb4aacc1c3e59e2eef?environmentId=100
            - 'Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; InfoPath.2)' # https://www.fireeye.com/blog/threat-research/2018/07/microsoft-office-vulnerabilities-used-to-distribute-felixroot-backdoor.html
            - 'Mozilla/4.0 (compatible; RMS)' # Attacks on industrial enterprises using RMS and TeamViewer https://goo.gl/GthvTw
            - 'Mozilla/4.0 (compatible; MSIE 6.0; DynGate)' # Attacks on industrial enterprises using RMS and TeamViewer https://goo.gl/GthvTw
            - 'O/9.27 (W; U; Z)' # Cmstar https://www.virustotal.com/#/file/e4328011bb2b04abc856ccd04404c9f95d67167f6c291d343e8ffa8aa2aa2099/details
            - 'Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0;  Trident/5.0*' # KerrDown UA https://goo.gl/s2WU6o
            - 'Mozilla/5.0 (Windows NT 9; *' # Suspicious 'Windows NT 9' user agent - used by APT33 malware in 2018
            - 'hots scot' # Unknown iOS zero-day implant https://twitter.com/craiu/status/1176437994288484352?s=20
            - 'Mozilla/5.0 (compatible; MSIE 10.0; Windows NT)' # https://blog.telsy.com/meeting-powerband-the-apt33-net-powerton-variant/
            - 'Mozilla/5.0 (Windows NT 6.1; WOW64) Chrome/28.0.1500.95 Safari/537.36' # Hidden Cobra malware
            - 'Mozilla/5.0 (Windows NT 6.2; Win32; rv:47.0)' # Strong Pity loader https://twitter.com/VK_Intel/status/1264185981118406657
            - 'Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;SV1;' # Mustang Panda https://insights.oem.avira.com/new-wave-of-plugx-targets-hong-kong/
            - 'Mozilla/5.0 (X11; Linux i686; rv:22.0) Firefox/22.0' # BackdoorDiplomacy https://www.welivesecurity.com/2021/06/10/backdoordiplomacy-upgrading-quarian-turian/
            - 'Mozilla/5.0 Chrome/72.0.3626.109 Safari/537.36' # SideWalk malware used by Sparkling Goblin
            - 'Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:FTS_06) Gecko/22.36.35.06 Firefox/2.0' # LitePower stager used by WRITE https://securelist.com/wirtes-campaign-in-the-middle-east-living-off-the-land-since-at-least-2019/105044/
            - 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.63 Safari/537.36 Edg/100.0.1185.39' # https://www.microsoft.com/security/blog/2022/09/29/zinc-weaponizing-open-source-software/
            - 'Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; InfoPath.3; .NET4.0C; .NET4.0E)' # https://www.microsoft.com/security/blog/2022/09/29/zinc-weaponizing-open-source-software/
            - 'Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 10.0; .NET4.0C; .NET4.0E; Tablet PC 2.0)' # PlugX backdoor https://unit42.paloaltonetworks.com/thor-plugx-variant/
            - 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.246001'  # RedCurl Downloader APT https://www.facct.ru/blog/redcurl-2024
    condition: selection
fields:
    - ClientIP
    - c-uri
    - c-useragent
falsepositives:
    - Old browsers
level: high

Add commandline flag variation of / and - to Windows based rules such as

• Curl
• Chcp
• Cmdkey

And more.

Update and merging of rules that covered the potential abuse of the “RunHTMLApplication” export, in order to cover the newly reported Windows Defender bypass

title: Mshtml.DLL RunHTMLApplication Suspicious Usage
id: 4782eb5a-a513-4523-a0ac-f3082b26ac5c
related:
    - id: 9f06447a-a33a-4cbe-a94f-a3f43184a7a3
      type: obsoletes
    - id: 73fcad2e-ff14-4c38-b11d-4172c8ac86c7
      type: obsoletes
status: test
description: |
    Detects execution of commands that leverage the "mshtml.dll" RunHTMLApplication export to run arbitrary code via different protocol handlers (vbscript, javascript, file, http...)
references:
    - https://twitter.com/n1nj4sec/status/1421190238081277959
    - https://hyp3rlinx.altervista.org/advisories/MICROSOFT_WINDOWS_DEFENDER_TROJAN.WIN32.POWESSERE.G_MITIGATION_BYPASS_PART2.txt
    - http://hyp3rlinx.altervista.org/advisories/MICROSOFT_WINDOWS_DEFENDER_DETECTION_BYPASS.txt
author: Nasreddine Bencherchali (Nextron Systems),  Florian Roth (Nextron Systems), Josh Nickels, frack113, Zaw Min Htun (ZETA)
date: 2022/08/14
modified: 2024/02/23
tags:
    - attack.defense_evasion
    - attack.execution
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        CommandLine|contains|all:
            - '\..\'
            - 'mshtml'
        CommandLine|contains:
            - '#135'
            - 'RunHTMLApplication'
    condition: selection
falsepositives:
    - Unlikely
level: high

Please check the full changelog on the release page below for the complete list of changes and additions.

Release Release r2024-02-26 · SigmaHQ/sigma

Contributors

This release was possible thanks to the many Sigma community contributors. A big thanks goes to following people:

• @clebron23
• @faisalusuf
• @frack113
• @joshnck
• @MalGamy
• @MATTANDERS0N
• @nasbench
• @qasimqlf
• @RG9n

SigmaHQ Rules Release Highlights — r2024–02–26 was originally published in Sigma_HQ on Medium, where people are continuing the conversation by highlighting and responding to this story.