Sigma Rules as MISP galaxies

A threat intelligence analyst's brief

In the threat intelligence world, we are continuously analyzing threat actors and threats in general that impact different sectors. From a threat intelligence analyst's point of view, it is important to know the motivations, objectives, TTPs and the overall context of the intrusion.

The results produced by these analysts are usually well defined. Frequently, a report is generated with a series of sections, where some of them are usually conclusions, recommendations, countermeasures.... Perhaps the least fun part for a threat intelligence analyst.

Also, in many cases additional products are generated and sent along with the report, such as STIX files with the analysis information, CSV files with IOCs, YARA rules and others. Another thing that most threat intelligence teams do is to dump all the information from the report into MISP including TTPs, IOCs and context information to help categorize, filter and relate the events.

From a threat intelligence point of view, our work should stop there. However, when it comes to generating a good security strategy, it is important to be able to map the techniques and behaviors identified in each intrusion with different types of rules, whether they are network or behavior-based endpoint rules.

From threat intelligence w/ detection engineering

Many threat intelligence analysts are in fact in charge of creating such detection rules based on their own research or intrusion analysis. Realistically, however, this need not be the job of these analysts.

Detection engineers are the responsible for creating these rules to improve detections and, in some cases, visibility. Although it is true, they sometimes need help from threat intelligence analysts to understand and have context about what they want to detect and know what is happening in the wild.

Add more value to your MISP events

As mentioned in previous points, surely as a threat intelligence analyst you usually create MISP events with IOCs and context information, such as MITRE techniques, malware families, affected countries, etc... All using MISP galaxies.

Adding galaxy-like sigma rules to your event would add value? Imagine analyzing an intrusion, identifying that there are multiple sigma rules that could have detected different behaviors, then adding those rules as galaxies.

Just for this purpose I have created a script that allows to generate galaxies in MISP from Sigma Rules. A few months ago, I generated a script and published to create taxonomies in MISP from Sigma Rules, however, I realized that there was some context information about the rule that was missing, and I had to go into the repository itself to get it. Also, it used the rule name as the taxonomy value instead of the rule title.

Unlike MISP taxonomies, galaxies were created just for that, they allow to add more context than taxonomies, and that is why I decided to improve the previous script to create galaxies instead of taxonomies.

The idea is that from a path that you indicate to the script with the place where you have stored the rules, this begins to look for them and begins to parse them to generate two types of files. The reason of doing it through a path and not from the oficial repository is because it could be the case that there are private sigma rules that have not been shared and you want to generate the galaxy in MISP in the same way.

• Sigma-rules.json (cluster): This file must be placed inside the /var/www/MISP/app/ files/misp-galaxy/clusters directory as it contains the Sigma-rules information itself. A part of this JSON is the one we can see below.

{
    "authors": [
        "@Joseliyo_Jstnk"
    ],
    "category": "rules",
    "description": "MISP galaxy cluster based on Sigma Rules.",
    "name": "Sigma-Rules",
    "source": "https://github.com/jstnk9/MISP/tree/main/misp-galaxy/sigma",
    "type": "sigma-rules",
    "uuid": "9cf7cd2e-d5f1-48c4-9909-7896ba1c96b2",
    "values": [
        {
            "description": "Detects a highly relevant Antivirus alert that reports an exploitation framework",
            "uuid": "238527ad-3c2c-4e4f-a1f6-92fd63adb864",
            "value": "Antivirus Exploitation Framework Detection",
            "meta": {
                "refs": [
                    "https://www.nextron-systems.com/2018/09/08/antivirus-event-analysis-cheat-sheet-v1-4/",
                    "https://github.com/SigmaHQ/sigma/tree/master/rules/application/antivirus/av_exploiting.yml"
                ],
                "tags": [
                    "attack.execution",
                    "attack.t1203",
                    "attack.command_and_control",
                    "attack.t1219"
                ],
                "creation_date": "2018/09/09",
                "filename": "av_exploiting.yml",
                "author": "Florian Roth",
                "level": "critical",
                "falsepositive": [
                    "Unlikely"
                ],
                "logsource.category": "antivirus",
                "logsource.product": "No established product"
            }
        }
        .......

As can be seen in the above code fragment, most of the fields in the sigma rules are mapped. For those cases where the text Not established [something] appears, it is because the field doesn't exist in the rule.

Something that I didn't want to map (because I wanna think more about it) but I'm dealing with is the logic of the rule for itself. It can be difficult because the fields are dynamic.

• Sigma-rules.json (galaxies): This file must be placed inside the /var/www/MISP/app/files/misp-galaxy/galaxies directory and simply contains information about the galaxy, which will be required later in order to be used.

{
    "description": "Sigma Rules are used to detect suspicious behaviors related to threat actors, malware and tools",
    "icon": "link",
    "name": "Sigma-Rules",
    "namespace": "misp",
    "type": "sigma-rules",
    "uuid": "9cf7cd2e-d5f1-48c4-9909-7896ba1c96b2",
    "version": 1
}

If you want to learn more about how galaxies work and how to create one, you can do it here https://www.misp-project.org/2020/07/31/MISP-galaxy-101.html/.

How it looks?

Once we have the imported galaxy in our MISP, if we navigate to it we can see something like this.

The value of each item is the name of the rule, not the name of the file. This may help us in the future to do some extra implementation as well as give us much more context.

If we see the detail of any of these items, we can obtain the fields of the rule with the context information.

The more events we have stored with galaxy values on sigma rules, the more interesting the actions and statistics we can execute in the future with this information. Questions like... Which rules are detecting the most behaviors? Which logsource is giving me more information? Where do I have less visibility because I have less mapped rules? They could be answered, based on the events that are analyzed by the CTI teams in MISP.

An example could be to identify the Sigma rules that are detecting more behaviors, in order to improve them or to see the data sources that are giving us more detection value. This can be achieved using a script called stats_report.py which can be found here. By running it and filtering by the dates we are interested in, we can obtain a list of sigma rules and the number of events where they appear.

(myenv) misp@misp:/opt/scripts/misp_statistics# python3 stats_report.py -f 2022-09-01 -u 2022-11-16 | grep sigma
misp-galaxy:sigma-rules="Failed Code Integrity Checks"   6
misp-galaxy:sigma-rules="Wow6432Node CurrentVersion Autorun Keys Modification"   4
misp-galaxy:sigma-rules="Creation of an Executable by an Executable"     4
misp-galaxy:sigma-rules="Suspicious Execution of Taskkill"       3
misp-galaxy:sigma-rules="Process Creation Using Sysnative Folder"        3
misp-galaxy:sigma-rules="Powershell Create Scheduled Task"       3
misp-galaxy:sigma-rules="CurrentVersion Autorun Keys Modification"       3
misp-galaxy:sigma-rules="Windows Processes Suspicious Parent Directory"          2
misp-galaxy:sigma-rules="Windows Cmd Delete File"        2
misp-galaxy:sigma-rules="User with Privileges Logon"     2
misp-galaxy:sigma-rules="Use Remove-Item to Delete File"         2
misp-galaxy:sigma-rules="System File Execution Location Anomaly"         2
misp-galaxy:sigma-rules="Rundll32 With Suspicious Parent Process"        2
misp-galaxy:sigma-rules="Remote Thread Creation in Suspicious Targets"   2
misp-galaxy:sigma-rules="Reg Add RUN Key"        2
misp-galaxy:sigma-rules="Python Initiated Connection"    2
misp-galaxy:sigma-rules="Process Start From Suspicious Folder"   2
misp-galaxy:sigma-rules="Execution from Suspicious Folder"       2

In case you want to consult the information in JSON format, you can always visit the following URL to obtain it http://yourmisp.com/users/statistics/tags.json.

Next steps

MISP incorporates a very interesting functionality that allows to add relationships to several clusters. That is why, in future updates, I would like to add different relationships to the Sigma galaxy such as MITRE Techniques, Software, Groups, etc.

More information about relationships and galaxies here: https://www.misp-project.org/misp-training/a.10-galaxy-2.0.pdf

Contact

Twitter: https://twitter.com/Joseliyo_Jstnk

LinkedIn: https://www.linkedin.com/in/joseluissm/

GitHub Project: https://github.com/jstnk9/MISP

Mastodon: @Joseliyo_Jstnk@infosec.exchange

References

• https://www.misp-project.org/misp-training/a.10-galaxy-2.0.pdf
• https://www.vanimpe.eu/2019/07/13/generating-misp-data-statistical-reports/
• https://github.com/SigmaHQ/sigma
• https://github.com/MISP/misp-galaxy
• https://www.misp-project.org/galaxy.html