[Day 18] Sigma Lumberjack Lenny Learns New Rules

Le Cours

Threat Detection

Cyber threats and criminals have advanced tactics to ensure that they steal information and cause havoc. As you have already seen through the previous days, there are many ways in which this can be done. There are also ways for security teams to prepare their defences and identify these threats. What would be evident is that most of the blue-team activities will require proactive approaches to analysing different logs, malware and network traffic. This brings about the practice of threat detection.

Threat detection involves proactively pursuing and analysing abnormal activity within an ecosystem to identify malicious signs of compromise or intrusion within a network. Attack Scenario

Elf McBlue obtained logs and information concerning the attack on the Best Festival Company by the Bandit Yeti. Through the various analysis of the previous days, it was clear that the logs pointed to a likely attack chain that the adversary may have followed and can be mapped to the Unified Kill Chain. Among the known phases of the UKC that were observed include the following:

• Persistence: The adversary established persistence by creating a local user account they could use during their attack.

• Discovery: The adversary sought to gather information about their target by running commands to learn about the processes and software on Santa’s devices to search for potential vulnerabilities.

• Execution: Scheduled jobs were created to provide an initial means of executing malicious code. This may also provide them with persistence or be part of elevating their privileges.

The attack chain report included indicators of compromise (IOCs) and necessary detection parameters, as listed below. Additionally, the attack techniques have been linked to the MITRE ATT&CK framework for further reading.

Attack Technique	Indicators of Compromise	Required Detection Fields
Account Creation	EventID: 4720 ; Service: Security	Service ; EventID
Software Discovery	Category: Process Creation; EventID: 1; Service: Sysmon; Image: C:\Windows\System32\reg.exe ; CommandLine: reg query “HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer” /v svcVersion	Category; EventID ; Image ; CommandLine strings
Scheduled Task	Category: Process Creation; EventID: 1; Service: Sysmon; Image: C:\Windows\System32\schtasks.exe ; Parent Image : C:\Windows\System32\cmd.exe ; CommandLine: schtasks /create /tn "T1053_005_OnLogon" /sc onlogon /tr "cmd.exe /c calc.exe"	Category; EventID ; Image ; CommandLine strings

Before we proceed to the next section, deploy the attached machine and give it up to 5 minutes to launch its services. Once launched, use the AttackBox or VPN to access the link http://MACHINE_IP to our Sigma application, which constitutes the following features:

• Run - Submit your Sigma rule and see if it detects the malicious IOC.

• Text Editor - Write your Sigma rule in this section.

• Create Rule - Create a Sigma rule for the malicious IOC.

• View Log - View the log details associated with the malicious IOC.

Chopping Logs with Sigma Rules

Sigma is an open-source generic signature language developed by Florian Roth & Thomas Patzke to describe log events in a structured format. The format involves using a markup language called YAML, a designed syntax that allows for quick sharing of detection methods by security analysts. The common factors to note about YAML files include the following:

• YAML is case-sensitive.

• Files should have the .yml extension.

• Spaces are used for indentation and not tabs.

• Comments are attributed using the # character.

• Key-value pairs are denoted using the colon : character.

• Array elements are denoted using the dash - chartitle: Suspicious Local Account Creation id: 0f06a3a5-6a09-413f-8743-e6cf35561297 status: experimental description: Detects the creation of a local user account on a computer. author: me date: « 25 12 2022 » modified: « 25 12 2022 » logsource: product: windows service: security category:

  • process_creation detection: selection: EventID: # This shows the search identifier value

    • 4720 # This shows the search’s list value condition: selection

falsepositives:

• unknown level: low tags:

• attack.persistence # Points to the MITRE Tactic

• attack.T1136.001 # Points to theacter.

Sigma makes it easy to perform content matching based on collected logs to raise threat alerts for analysts to investigate. Log files are usually collected and stored in a database or a Security Information and Event Management (SIEM) solution for further analysis. Sigma is vendor-agnostic; therefore, the rules can be converted to a format that fits the target SIEM.

Sigma was developed to satisfy the following scenarios:

• To make detection methods and signatures shareable alongside IOCs and Yara rules.

• To write SIEM searches that avoid vendor lock-in.

• To share signatures with threat intelligence communities.

• To write custom detection rules for malicious behaviour based on specific conditions.

Sigma Rule Syntax

Sigma Rule StructureSigma rules are guided by a given order of required/optional fields and values that create the structure for mapping needed queries. The attached image provides a skeletal view of a Sigma rule.

Let’s use the first attack step challenge to define the syntax requirements, fill in the details into our skeletal rule, and detect the creation of local accounts. Use the text editor section of the SigHunt application to follow along. with the knowledge about Sigma rules, your task is to complete the remaining two challenges by writing rules corresponding to the attack chain phases and IOCs. Santa is relying on you to beef up his security against adversaries attempting to stop Christmas this year. As a reminder, the required fields for the attacks are below:

• Title: Names the rule based on what it is supposed to detect.

• ID: A globally unique identifier that the developers of Sigma mainly use to maintain the order of identification for the rules submitted to the public repository, found in UUID format.

• Status: Describes the stage in which the rule maturity is at while in use. There are five declared statuses that you can use:

  • Stable: The rule may be used in production environments and dashboards.

  • Test: Trials are being done to the rule and could require fine-tuning.

  • Experimental: The rule is very generic and is being tested. It could lead to false results, be noisy, and identify exciting events.

  • Deprecated: The rule has been replaced and would no longer yield accurate results.

  • Unsupported: The rule is not usable in its current state (unique correlation log, homemade fields).

• Description: Provides more context about the rule and its intended purpose. Here, you can be as detailed as possible to provide information about the detected activity.

• Logsource: Describes the log data to be used for the detection. It consists of other optional attributes:

  • Product: Selects all log outputs of a certain product. Examples are Windows, Apache

  • Category: Selects the log files written by the selected product. Examples are firewalls, web, and antivirus.

  • Service: Selects only a subset of the logs. Examples are sshd on Linux or Security on Windows.

  • Definition: Describes the log source and its applied configurations.

• Detection: A required field in the detection rule describes the parameters of the malicious activity we need an alert for. He can be multiplious detection rules. The parameters are divided into two main parts:

  • The search identifiers are the fields and values the detection should search for.

  • The condition expression - sets the action to be taken on the detection, such as selection or filtering. The critical thing to look out for account creation on Windows is the Event ID associated with user accounts. In this case, Event ID: 4720 was provided for us on the IOC list, which will be our search identifier.

• FalsePositives: A list of known false positives that may occur based on log data.

• Level: Describes the severity with which the security team should take the activity under the written rule. The attribute comprises five levels: Informational -> Low -> Medium -> High -> Critical

• Tags: Adds information that can be used to categorise the rule. Common tags are associated with tactics and techniques from the MITRE ATT&CK framework. Sigma developers have defined a list of predefined tags.

Soit l’exemple :

title: Suspicious Local Account Creation
id: 0f06a3a5-6a09-413f-8743-e6cf35561297
status: experimental
description: Detects the creation of a local user account on a computer.
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID:  # This shows the search identifier value
      - 4720    # This shows the search's list value
    Image|endswith:
      - '\svchost.exe'
    CommandLine|contains|all:
      - bash.exe
      - '-c '
condition: selection
falsepositives:
  - unknown
level: low
tags:
  - attack.persistence # Points to the MITRE Tactic
  - attack.T1136.001 # Points to the MITRE Technique

Voila!! We have written our first Sigma rule and can run it on the AoC Sigma Hunting application to see if we can get a match. As mentioned before, Sigma rules are converted to fit the desired SIEM query, and in our case, it should be known that they are being transformed into Elastic Queries on the backend. Various resources perform this task, with the native tool being Sigmac, which is being deprecated and replaced with a more stable python library, pySigma. Another notable tool to check out is Uncoder.io. Uncoder.IO is an open-source web Sigma converter for numerous SIEM and EDR platforms. It is easy to use as it allows you to copy your Sigma rule on the platform and select your preferred backend application for translation.

Le Chall

Équipé de ce savoir sur les règles sigma, notre tâche est donc d’écrire les deux dernière règles du challenge. Pour rappel, celles ci s’expliquent comme ça :

• Software Discovery: Category, EventID, Image, CommandLine.

• Scheduled Jobs: Category, EventID, Image, CommandLine.

Question 1 : What is the Challenge #1 flag?

Il faut donc faire l’ensemble des règles pour la chaine d’attaque vu plus haut dans le challenge soit l”account_creation, Software Discovery et Scheluded Task La première concerne donc la partie création de compte. On a donc comme info : dans les logs de sécurité, on trouve l'event 4720

title: Suspicious Local Account Creation
id: 0f06a3a5-6a09-413f-8743-e6cf35561297
status: experimental
description: Detects the creation of a local user account on a computer.
author: me
date: "25 12 2022"
modified: "25 12 2022"
logsource:
  product: windows
  service: security
  category:
    - process_creation
detection:
  selection:
    EventID:  # This shows the search identifier value
      - 4720    # This shows the search's list value
  condition: selection

falsepositives:
  - unknown
level: low
tags:
  - attack.persistence # Points to the MITRE Tactic
  - attack.T1136.001 # Points to the

En la rentrant dans l’outil de la page web, on a le message suivant :

Successfully detected Suspicious Local Account Creation. Here is your flag - THM{n0t_just_your_u$ser}

Question 2 : From the Challenge 1 log, what user account was created?

Comme la règle a matché, il nous est désormais possible de voir les logs en question. En cliquant sur le bouton view logs, on se retrouve avec les informations du compte. On trouve très vite que le compte qui a été créé est donc BanditYetiMini

Question 3 : What is the Challenge #2 flag?

Pour la seconde règle, on connait donc les informations suivantes : Process Creation; EventID: 1; Service: Sysmon; Image: C:\Windows\System32\reg.exe ; CommandLine: reg query “HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer” /v svcVersion

title: AoC 2022 - Software Discover
id:
status: test
description: Check software version discovery with registry
author: me
date: "25 12 2022"
modified: "25 12 2022"
logsource:
  product: windows
  service: sysmon
  category: process_creation
detection:
  selection:
    EventID:
      - 1
    Image|endswith:
      - reg.exe
    CommandLine|contains|all:
      - reg
      - query
      - /v
      - svcVersion
  condition: selection
falsepositive:
  - unknown
level: low
tags:
  - attack.discovery
  - attack.T1518.001

J’ai eu un soucis avec ma règle du dessus, je ne sais pas ce qui bug, et je n’ai pas pu continuer mes test. Celle du dessous devait marcher.

title:
id: # UUID
status: # experimental, test, stable, deprecated, unsupported.
description:
author:
date:
modified:

logsource:
  product: windows
  service: sysmon
  category: process_creation
detection:
  selection:
    EventID:
      - 1
    Image|endswith:
    - reg.exe
    CommandLine|contains|all:
    - reg
    - query
    - /v
    - svcVersion
  condition: selection # Action to be taken. Can use condition operators such as OR, AND, NOT when using multiple search identifiers.

falsepositives: # Legitimate services or use.

level:  # informational, low, medium, high or critical.

tags: # Associated TTPs from MITRE ATT&CK
  - {attack.tactic} # MITRE Tactic
  - {attack.technique} # MITRE Technique

On récupère donc le flag : THM{wh@t_1s_Runn1ng_H3r3}

Question 4 : What was the User’s path in the Challenge #2 log file?

On regarde cette fois-ci encore la sortie des logs, on remarque que l’utilisateur est SIGMA_AOC2022\Bandit Yeti

Question 5 : What is the Challenge #3 flag?

Cette fois là, on a encore plus d’informations pour construire notre règle, voyons tout ça. La partie la plus compliquée est sans doute de trouver les informations pertinante.

Category: Process Creation; EventID: 1; Service: Sysmon; Image: C:\Windows\System32\schtasks.exe ; Parent Image : C:\Windows\System32\cmd.exe ; CommandLine: schtasks /create /tn "T1053_005_OnLogon" /sc onlogon /tr "cmd.exe /c calc.exe" On comprends par là que le /tn et le T1053_005_OnLogon correspondent au nommage du fichier et ne nous intéressent pas. Idem pour le cmd.exe /c calc.exe qui n’est autre que la ligne de commande à exécuter. Mais il faut également enlever le /sc onlogon qui correspond à la périodicité !

title: AoC 2022 - Scheduled Task
id:
status: test
description: Check scheduled task
author: me
date: "25 12 2022"
modified: "25 12 2022"
logsource:
  product: windows
  service: sysmon
  category: process_creation
detection:
  selection:
    EventID:
      - 1
    Image|endswith:
      - schtasks.exe
    CommandLine|contains|all:
      - schtasks
      - /create
  condition: selection
falsepositive:
  - unknown
level: low
tags:
  - attack.execution
  - attack.persistence
  - attack.privilege escalation
  - attack.T1053.005

Ce qui nous donne : THM{sch3dule_0npo1nt_101}

Question 6 : What was the MD5 hash associated with Challenge #3 logs?

Il s’agit encore une fois d’ouvrir le log et de trouver la bonne valeur soit : 2F6CE97FAF2D5EEA919E4393BDD416A7