Defense Spotlight: Hayabusa and Sigma Rules

Please check out the SOC Hackthebox module for more examples: https://faresbltagy.gitbook.io/footprintinglabs/soc-hackthebox-notes-and-labs/yara-and-sigma-for-soc-analysts-module.

In this module, we'll explore the Hayabusa tool and Sigma rule analysis for threat hunting. Sigma, created by Thomas Patzke and supported by a community, is an open standard used by many Security Information Event Monitoring (SIEM) platforms to describe threats. Unlike proprietary rules used by SIEM products, Sigma is platform-independent and works across different tools, both commercial and open-source.

Snort detects network threats with signatures, YARA detects file system threats, and Sigma defines threat signatures using log data. Hayabusa, from Yamato Security, uses Sigma and custom rules to find threats in Windows event logs. It provides outputs like text reports, timelines, CSVs, and HTML summaries, and can analyze logs from one or many Windows systems for threat hunting.

Hayabusa works on Windows, macOS, and Linux. It’s available at https://github.com/Yamato-Security/hayabusa, and Sigma rules are at https://github.com/SigmaHQ/sigma. This module covers how Sigma rules define threats and how Hayabusa uses them for detection. We’ll learn how Hayabusa helps with threat hunting on Windows by analyzing event logs, creating a timeline, and summarizing data into alerts for analysis.

Sigma: Growing Repository of Detectors

The Sigma rule specification helps identify threats by defining patterns from log files. It makes threat detection compatible across different tools. There are over 3000 open-source rules for detecting threats, useful for incident response, threat hunting, and finding indicators of compromise on various systems like Windows, Linux, macOS, and cloud platforms.

Long PowerShell CommandLine

Here's a Sigma rule example to detect long PowerShell command lines, a method attackers use to bypass script controls on compromised Windows systems.

title: Unusually Long PowerShell CommandLine
id: d0d28567-4b9a-45e2-8bbc-fb1b66a1f7f6
status: test
description: Detects unusually long PowerShell command lines with a length of 1000 characters or more
references:
    - https://speakerdeck.com/heirhabarov/hunting-for-powershell-abuse
author: oscd.community, Natalia Shornikova
date: 2020/10/06
modified: 2023/04/14
tags:
    - attack.execution
    - attack.t1059.001
logsource:
    category: process_creation
    product: windows
detection:
    selection_powershell:
        - Image|endswith:
            - '\powershell.exe'
            - '\pwsh.exe'
        - OriginalFileName:
            - 'PowerShell.EXE'
            - 'pwsh.dll'
        - Description: 'Windows Powershell'
        - Product: 'PowerShell Core 6'
    selection_length:
        CommandLine|re: '.{1000,}'
    condition: all of selection_*
falsepositives:
    - Unknown
level: low

Sigma rules are written in YAML format. At the start, they include required fields like title, id, status, description, and author, each followed by a value. Some fields, like references and tags, contain lists. The logsource field tells which product (like Windows) the rule applies to and what kind of log data to use.

The detection block in a Sigma rule sets the rules that must be met to trigger the rule. Each key in this block defines a matching rule. For example, the selection_powershell group identifies PowerShell by its file name (powershell.exe, pwsh.exe, PowerShell.EXE, or pwsh.dll) and uses keywords for description and product. The selection_length key checks if the command line is 1000 characters or longer using a regular expression. The condition block shows which detection blocks need to match to activate the rule, using a wildcard (*) to include all starting with "condition_".

For details on Sigma rules' format and syntax, check out the Sigma rules specification here. Hardik Manocha's helpful guide for beginners can be found here or here. Understanding these rules is important if you want to create or adjust them, but you can also use the many existing Sigma rules for threat hunting. Just ensure you have a tool that supports Sigma rules to apply them to your log data.

About Hayabusa

Hayabusa is a tool from Yamato Security for detecting threats and analyzing event timelines on Windows. It reads Windows event logs (EVTX files or converted JSON) and uses both Sigma and its own rules to find threats.

Hayabusa is a tool that runs as a standalone program (hayabusa.exe on Windows, or similar on Linux and macOS) but can also work with the Velociraptor monitoring system. It reads Windows event logs from the local system, saved files, or directories, using rules to spot threats. It produces reports in CSV, HTML, or JSON formats. It's quick, easy to use, and helps find threats using event log data.

Updating Hayabusa Rules

.\hayabusa.exe update-rules

Hayabusa can use different command-line options. To update its rules, we can use the update-rules command, which fetches the latest rules from the Hayabusa GitHub repository. The repository is regularly updated with new Sigma rules and tested for compatibility. This feature helps analysts get the newest threat detection rules before analyzing log data. For example, Hayabusa can quickly download and apply 28 updated Sigma rules.

Hayabusa: Report from Local Event Logs

.\hayabusa.exe csv-timeline -l -o results.csv

The Hayabusa command csv-timeline checks EVTX data from a local system (-l), a single EVTX file (-f filename.evtx), or a directory of EVTX files (-d directoryname). It shows the results on screen and can save the details to a CSV file if you use the -o option.

In this example, we use Hayabusa’s csv-timeline to check login events from the local system and save the details to results.csv. This helps us quickly apply all rules to find threats on the local system, with more details in the CSV file.

Hayabusa can create an HTML summary of assessment results with the -H argument and an output file name. In the example here, we run Hayabusa again on the local system, this time to get an HTML report. This report provides a summary but doesn't show which alerts are the most important. Clicking on links in the report shows the rule file that triggered the alert, but not extra details about the system. Detailed info about the alerts is in the output CSV file.

.\hayabusa.exe csv-timeline -l -o results.csv -H results.html

In this module, we explored how Hayabusa and Sigma rules work together for threat hunting. Sigma rules, an open-source project, use logging data to describe threats and are supported by a community. Hayabusa, another open-source tool, uses Sigma rules and internal ones to find threats in Windows event logs. It works on Windows, macOS, and Linux, and can analyze local logs or EVTX files.

Hayabusa offers different output options based on the command used. The update-rules command updates threat hunting rules, and csv-timeline generates a CSV report and terminal summaries. It can read local or specified event log files, or entire directories. Hayabusa evaluates multiple systems at once and includes system details in the CSV output. Analysts can then use a spreadsheet tool or Timeline Explorer to organize and view the data easily.

Lab 2.5: Windows Threat Analysis with Hayabusa

In this exercise, we will use Hayabusa to evaluate the Windows 10 event log records following the SMB Sessions exercise where we conducted a password spray attack using Invoke-LocalPasswordSpray . We will be able to use the output of Hayabusa in Timeline Explorer to identify the accounts whose password were successfully compromised as part of the attack.

Let's run hayabusa.exe without any arguments to get a summary of usage and command info.

.\hayabusa.exe

Hayabusa can analyze Windows event logs with different commands. In this lab, we'll use the csv-timeline command. Let's run .\hayabusa csv-timeline to get help on how to use it.

.\hayabusa csv-timeline

Let's begin with a valuable Hayabusa use case, let's check local Windows event logs with Hayabusa and Sigma rules. Run Hayabusa to create a CSV timeline of threats.

.\hayabusa.exe csv-timeline -l -o win10-threatdetect.csv

Let's break down the code:

• hayabusa.exe csv-timeline: Runs Hayabusa to apply threat detection rules and create a CSV file with the results.

• -l: Reads Windows event logs from the local machine.

• -o win10-threatdetect.csv: Saves the results in a file named win10-threatdetect.csv.

In the Hayabusa results, there’s a lot of information, but we can quickly check the threat hunting assessment by looking at the lines that start with "Total."

Hayabusa found 45 unique detections (referring to single rules, not the total count of events). None are critical risk, but there are 5 high-risk, 498 medium-risk, and many low or informational detections.

In the Hayabusa output, there's a table showing alerts by risk level, including the number of alerts and their rules.

This output helps us understand what's happening on the Windows system. We don't have major alerts, but we do see signs of anti-forensics measures like cleared event logs. There are some medium alerts for suspicious PowerShell use and possible password attacks. Additionally, there are low alerts showing many login failures.

For additional insight into these events, we will continue to review the Hayabusa CSV output file.

Get-Content .\win10-threatdetect.csv

The CSV file from Hayabusa is too big to handle easily in PowerShell. It's better to use a tool that can better manage and make sense of large CSV logs. Let's open the CSV file in the Timeline Explorer

By default, Timeline Explorer shows Hayabusa alerts in order of time. We can adjust how the alerts are grouped to better organize the data. Let's change the grouping.

In Timeline Explorer, click to select the column header marked Level and drag it into the area above the column headers marked Drag a column header here to group by that column. Release the mouse to have Timeline Explorer change the grouping to display alerts grouped by severity level, as shown here.

Next, let's expand the group of high-risk alerts.

To refine the grouping, let's add more column headers. Let's drag the Rule Title column above the header row. Timeline Explorer will use it as a secondary grouping after the level.

Let's look at Hayabusa's high-risk alerts. There are three types: "Important Log File Cleared" (2 times), "Important Windows Service Terminated With Error" (2 times) and "Log Cleared" (1 time). These could be signs of an attacker trying to hide their tracks. Check the date and time for each alert to get more details.

Let's keep checking the medium-risk findings. Collapse the high-risk alerts and expand the medium-risk alerts.

Here are alerts related to the password spray attack from the last lab. Hayabusa's alerts might show extra details, like the attacker's source code. Let's open the alert group for the "Potentially Malicious PwSh" rule to see more.

We can double-click the Details field of any alert to see the PowerShell script flagged as potentially harmful by the Hayabusa rule.

Using Hayabusa and Timeline Explorer, we can quickly investigate local systems to find important events. These tools are useful for threat detection and provide a fast, easy way to analyze data using Sigma rules.