Zum Inhalt

DFIR-Timeline-Befehle

Scan-Assistent

Der Befehl dfir-timeline verfügt jetzt standardmäßig über einen aktivierten Scan-Assistenten. Dieser soll Benutzern helfen, je nach ihren Bedürfnissen und Vorlieben einfach auszuwählen, welche Erkennungsregeln sie aktivieren möchten. Die zu ladenden Sätze von Erkennungsregeln basieren auf den offiziellen Listen im Sigma-Projekt. Details werden in diesem Blogbeitrag erläutert. Sie können den Assistenten einfach ausschalten und Hayabusa auf herkömmliche Weise verwenden, indem Sie die Option -w, --no-wizard hinzufügen.

Core-Regeln

Der Regelsatz core aktiviert Regeln mit dem Status test oder stable und einem Level von high oder critical. Dies sind qualitativ hochwertige Regeln mit hoher Zuverlässigkeit und Relevanz, die nicht viele Fehlalarme erzeugen sollten. Der Regelstatus ist test oder stable, was bedeutet, dass über 6 Monate lang keine Fehlalarme gemeldet wurden. Regeln passen auf Angreifertechniken, allgemein verdächtige Aktivitäten oder bösartiges Verhalten. Es entspricht der Verwendung der Optionen --exclude-status deprecated,unsupported,experimental --min-level high.

Core+-Regeln

Der Regelsatz core+ aktiviert Regeln mit dem Status test oder stable und einem Level von medium oder höher. medium-Regeln benötigen meist eine zusätzliche Feinabstimmung, da bestimmte Anwendungen, legitimes Benutzerverhalten oder Skripte einer Organisation übereinstimmen könnten. Es entspricht der Verwendung der Optionen --exclude-status deprecated,unsupported,experimental --min-level medium.

Core++-Regeln

Der Regelsatz core++ aktiviert Regeln mit dem Status experimental, test oder stable und einem Level von medium oder höher. Diese Regeln sind topaktuell. Sie werden gegen die im SigmaHQ-Projekt verfügbaren Basis-Evtx-Dateien validiert und von mehreren Detection Engineers überprüft. Abgesehen davon sind sie zunächst weitgehend ungetestet. Verwenden Sie diese, wenn Sie Bedrohungen so früh wie möglich erkennen möchten, allerdings um den Preis, eine höhere Schwelle an Fehlalarmen zu verwalten. Es entspricht der Verwendung der Optionen --exclude-status deprecated,unsupported --min-level medium.

Emerging Threats (ET) Add-On-Regeln

Der Regelsatz Emerging Threats (ET) aktiviert Regeln mit dem Tag detection.emerging_threats. Diese Regeln zielen auf bestimmte Bedrohungen ab und sind besonders nützlich bei aktuellen Bedrohungen, zu denen noch nicht viele Informationen verfügbar sind. Diese Regeln sollten nicht viele Fehlalarme erzeugen, werden aber mit der Zeit an Relevanz verlieren. Wenn diese Regeln nicht aktiviert sind, entspricht dies der Verwendung der Option --exclude-tag detection.emerging_threats. Wenn Sie Hayabusa herkömmlich ohne den Assistenten ausführen, werden diese Regeln standardmäßig einbezogen.

Threat Hunting (TH) Add-On-Regeln

Der Regelsatz Threat Hunting (TH) aktiviert Regeln mit dem Tag detection.threat_hunting. Diese Regeln können unbekannte bösartige Aktivitäten erkennen, weisen jedoch typischerweise mehr Fehlalarme auf. Wenn diese Regeln nicht aktiviert sind, entspricht dies der Verwendung der Option --exclude-tag detection.threat_hunting. Wenn Sie Hayabusa herkömmlich ohne den Assistenten ausführen, werden diese Regeln standardmäßig einbezogen.

Channel-basierte Filterung von Ereignisprotokollen und Regeln

Seit Hayabusa v2.16.0 aktivieren wir einen Channel-basierten Filter beim Laden von .evtx-Dateien und .yml-Regeln. Der Zweck besteht darin, das Scannen so effizient wie möglich zu gestalten, indem nur das geladen wird, was notwendig ist. Es ist zwar möglich, dass es mehrere Provider in einem einzigen Ereignisprotokoll gibt, aber es ist nicht üblich, mehrere Channels innerhalb einer einzigen evtx-Datei zu haben. (Das einzige Mal, dass wir dies gesehen haben, war, als jemand zwei verschiedene evtx-Dateien für das sample-evtx-Projekt künstlich zusammengeführt hat.) Wir können uns dies zunutze machen, indem wir zuerst das Channel-Feld im ersten Datensatz jeder zum Scannen angegebenen .evtx-Datei überprüfen. Wir prüfen außerdem, welche .yml-Regeln welche im Channel-Feld der Regel angegebenen Channels verwenden. Mit diesen beiden Listen laden wir nur Regeln, die Channels verwenden, die tatsächlich in den .evtx-Dateien vorhanden sind.

Wenn ein Benutzer beispielsweise Security.evtx scannen möchte, werden nur Regeln verwendet, die Channel: Security angeben. Es hat keinen Sinn, andere Erkennungsregeln zu laden, zum Beispiel Regeln, die nur nach Ereignissen im Application-Protokoll suchen usw. Beachten Sie, dass Channel-Felder (z. B. Channel: Security) nicht explizit in den originalen Sigma-Regeln definiert sind. Bei Sigma-Regeln werden die Channel- und Event-ID-Felder implizit mit den Feldern service und category unter logsource definiert. (z. B. service: security) Bei der Kuratierung von Sigma-Regeln im hayabusa-rules-Repository entabstrahieren wir das logsource-Feld und definieren die Channel- und Event-ID-Felder explizit. Wie und warum wir das tun, erklären wir ausführlich hier.

Derzeit gibt es nur zwei Erkennungsregeln, bei denen kein Channel definiert ist und die alle .evtx-Dateien scannen sollen, nämlich die folgenden:

Wenn Sie diese beiden Regeln verwenden und alle Regeln gegen geladene .evtx-Dateien scannen möchten, müssen Sie die Option -A, --enable-all-rules im Befehl dfir-timeline hinzufügen. In unseren Benchmarks bringt die Regelfilterung je nach gescannten Dateien in der Regel eine Geschwindigkeitsverbesserung von 20 % bis zum 10-Fachen und verbraucht natürlich weniger Speicher.

Die Channel-Filterung wird auch beim Laden von .evtx-Dateien verwendet. Wenn Sie beispielsweise eine Regel angeben, die nach Ereignissen mit einem Channel von Security sucht, dann hat es keinen Sinn, .evtx-Dateien zu laden, die nicht aus dem Security-Protokoll stammen. In unseren Benchmarks bringt dies bei normalen Scans einen Geschwindigkeitsvorteil von etwa 10 % und bei Scans mit einer einzigen Regel eine Leistungssteigerung von bis zu über 60 %. Wenn Sie sicher sind, dass innerhalb einer einzigen .evtx-Datei mehrere Channels verwendet werden, zum Beispiel weil jemand ein Tool verwendet hat, um mehrere .evtx-Dateien zusammenzuführen, dann deaktivieren Sie diese Filterung mit der Option -a, --scan-all-evtx-files im Befehl dfir-timeline.

Hinweis: Die Channel-Filterung funktioniert nur mit .evtx-Dateien und Sie erhalten einen Fehler, wenn Sie versuchen, Ereignisprotokolle aus einer JSON-Datei mit -J, --json-input zu laden und gleichzeitig -A oder -a angeben.

dfir-timeline-Befehl

Der Befehl dfir-timeline erstellt eine forensische Zeitleiste von Ereignissen. Wählen Sie das Ausgabeformat mit -t, --output-type: csv (die Standardeinstellung), json oder jsonl. Der Wert ist nicht case-sensitiv (z. B. -t JSONL).

  • CSV eignet sich gut zum Importieren kleinerer Zeitleisten (in der Regel weniger als 2 GB) in Tools wie LibreOffice oder Timeline Explorer (alle Ereignisfelder werden in einer großen Details-Spalte abgelegt).
  • JSON eignet sich am besten für eine detailliertere Analyse großer Ergebnisse mit Tools wie jq, da die Details-Felder getrennt sind.
  • JSONL ist schneller und erzeugt eine kleinere Datei als JSON, was ideal für den Import in Tools wie den Elastic Stack ist.

Die CSV-Ausgabe-Optionen -M, --multiline und -S, --tab-separator gelten nur für die CSV-Ausgabe und erzeugen einen Fehler, wenn sie mit einem Nicht-CSV--t kombiniert werden.

Usage:
  hayabusa.exe dfir-timeline <INPUT> [OPTIONS]

Input:
  -d, --directory <DIR>  Directory of multiple .evtx files
  -f, --file <FILE>      File path to one .evtx file
  -l, --live-analysis    Analyze the local C:\Windows\System32\winevt\Logs folder

General Options:
  -C, --clobber                        Overwrite files when saving
  -h, --help                           Show the help menu
  -J, --json-input                     Scan JSON formatted logs instead of .evtx (.json or .jsonl)
  -w, --no-wizard                      Do not ask questions. Scan for all events and alerts
  -Q, --quiet-errors                   Quiet errors mode: do not save error logs
  -x, --recover-records                Carve evtx records from slack space (default: disabled)
  -r, --rules <DIR/FILE>               Specify a custom rule directory or file (default: ./rules)
  -c, --rules-config <DIR>             Specify custom rule config directory (default: ./rules/config)
  -s, --sort                           Sort results before saving the file (warning: this uses much more memory!)
      --target-file-ext <FILE-EXT...>  Specify additional evtx file extensions (ex: evtx_data)
      --threads <NUMBER>               Number of threads (default: optimal number for performance)
  -V, --validate-checksums             Enable checksum validation

Filtering:
  -E, --eid-filter                      Scan only common EIDs for faster speed (./rules/config/target_event_IDs.txt)
  -A, --enable-all-rules                Enable all rules regardless of loaded evtx files (disable channel filter for rules)
  -D, --enable-deprecated-rules         Enable rules with a status of deprecated
  -n, --enable-noisy-rules              Enable rules set to noisy (./rules/config/noisy_rules.txt)
  -u, --enable-unsupported-rules        Enable rules with a status of unsupported
  -e, --exact-level <LEVEL>             Only load rules with a specific level (informational, low, medium, high, critical)
      --exclude-category <CATEGORY...>  Do not load rules with specified logsource categories (ex: process_creation,pipe_created)
      --exclude-computer <COMPUTER...>  Do not scan specified computer names (ex: ComputerA) (ex: ComputerA,ComputerB)
      --exclude-eid <EID...>            Do not scan specific EIDs for faster speed (ex: 1) (ex: 1,4688)
      --exclude-status <STATUS...>      Do not load rules according to status (ex: experimental) (ex: stable,test)
      --exclude-tag <TAG...>            Do not load rules with specific tags (ex: sysmon)
      --include-category <CATEGORY...>  Only load rules with specified logsource categories (ex: process_creation,pipe_created)
      --include-computer <COMPUTER...>  Scan only specified computer names (ex: ComputerA) (ex: ComputerA,ComputerB)
      --include-eid <EID...>            Scan only specified EIDs for faster speed (ex: 1) (ex: 1,4688)
      --include-status <STATUS...>      Only load rules with specific status (ex: experimental) (ex: stable,test)
      --include-tag <TAG...>            Only load rules with specific tags (ex: attack.execution,attack.discovery)
  -m, --min-level <LEVEL>               Minimum level for rules to load (default: informational)
  -P, --proven-rules                    Scan with only proven rules for faster speed (./rules/config/proven_rules.txt)
  -a, --scan-all-evtx-files             Scan all evtx files regardless of loaded rules (disable channel filter for evtx files)
      --time-offset <OFFSET>            Scan recent events based on an offset (ex: 1y, 3M, 30d, 24h, 30m)
      --timeline-end <DATE>             End time of the event logs to load (ex: "2022-02-22 23:59:59 +09:00")
      --timeline-start <DATE>           Start time of the event logs to load (ex: "2020-02-22 00:00:00 +09:00")

Output:
  -b, --disable-abbreviations        Disable abbreviations
  -G, --geo-ip <MAXMIND-DB-DIR>      Add GeoIP (ASN, city, country) info to IP addresses
  -H, --html-report <FILE>           Save Results Summary details to an HTML report (ex: results.html)
  -F, --no-field-data-mapping        Disable field data mapping
      --no-pwsh-field-extraction     Disable field extraction of PowerShell classic logs
  -o, --output <FILE>                Save the timeline to a file (ex: results.csv)
  -t, --output-type <OUTPUT_FORMAT>  Output format: csv (default), json, or jsonl
  -p, --profile <PROFILE>            Specify output profile
  -R, --remove-duplicate-data        Duplicate field data will be replaced with "DUP" (sort required)
  -X, --remove-duplicate-detections  Remove duplicate detections (sort required)

Display Settings:
  -K, --no-color            Disable color output
  -N, --no-summary          Do not display Results Summary for faster speed
  -q, --quiet               Quiet mode: do not display the launch banner
  -v, --verbose             Output verbose information
  -T, --visualize-timeline  Output event frequency timeline (terminal needs to support unicode, sort required)

Time Format:
      --european-time     Output timestamp in European time format (ex: 22-02-2022 22:00:00.123 +02:00)
  -O, --iso-8601          Output timestamp in original ISO-8601 format (ex: 2022-02-22T10:10:10.1234567Z) (Always UTC)
      --rfc-2822          Output timestamp in RFC 2822 format (ex: Fri, 22 Feb 2022 22:00:00 -0600)
      --rfc-3339          Output timestamp in RFC 3339 format (ex: 2022-02-22 22:00:00.123456-06:00)
  -U, --utc               Output time in UTC format (default: local time)
      --us-military-time  Output timestamp in US military time format (ex: 02-22-2022 22:00:00.123 -06:00)
      --us-time           Output timestamp in US time format (ex: 02-22-2022 10:00:00.123 PM -06:00)

CSV Output:
  -M, --multiline      Separate event field information by newline characters (CSV output only)
  -S, --tab-separator  Separate event field information by tabs (CSV output only)

dfir-timeline-Befehlsbeispiele

  • Hayabusa gegen eine einzelne Windows-Ereignisprotokolldatei mit dem standardmäßigen standard-Profil ausführen:
hayabusa.exe dfir-timeline -f eventlog.evtx
  • Hayabusa gegen das sample-evtx-Verzeichnis mit mehreren Windows-Ereignisprotokolldateien mit dem verbose-Profil ausführen:
hayabusa.exe dfir-timeline -d .\hayabusa-sample-evtx -p verbose
  • In eine einzige CSV-Datei zur weiteren Analyse mit LibreOffice, Timeline Explorer, Elastic Stack usw. exportieren und alle Feldinformationen einbeziehen (Warnung: Ihre Ausgabedateigröße wird mit dem super-verbose-Profil deutlich größer!):
hayabusa.exe dfir-timeline -d .\hayabusa-sample-evtx -o results.csv -p super-verbose
  • JSON statt CSV ausgeben (zur Analyse mit jq usw.):
hayabusa.exe dfir-timeline -d .\hayabusa-sample-evtx -t json -o results.json
  • JSONL ausgeben (zum Import in den Elastic Stack usw.; -t ist nicht case-sensitiv):
hayabusa.exe dfir-timeline -d .\hayabusa-sample-evtx -t JSONL -o results.jsonl
  • Den EID-Filter (Event ID) aktivieren:

Hinweis: Das Aktivieren des EID-Filters beschleunigt die Analyse in unseren Tests um etwa 10-15 %, aber es besteht die Möglichkeit, dass Alarme übersehen werden.

hayabusa.exe dfir-timeline -E -d .\hayabusa-sample-evtx -o results.csv
  • Nur Hayabusa-Regeln ausführen (standardmäßig werden alle Regeln in -r .\rules ausgeführt):
hayabusa.exe dfir-timeline -d .\hayabusa-sample-evtx -r .\rules\hayabusa -o results.csv -w
  • Nur Hayabusa-Regeln für Protokolle ausführen, die unter Windows standardmäßig aktiviert sind:
hayabusa.exe dfir-timeline -d .\hayabusa-sample-evtx -r .\rules\hayabusa\builtin -o results.csv -w
  • Nur Hayabusa-Regeln für Sysmon-Protokolle ausführen:
hayabusa.exe dfir-timeline -d .\hayabusa-sample-evtx -r .\rules\hayabusa\sysmon -o results.csv -w
  • Nur Sigma-Regeln ausführen:
hayabusa.exe dfir-timeline -d .\hayabusa-sample-evtx -r .\rules\sigma -o results.csv -w
  • Veraltete Regeln (solche mit status als deprecated markiert) und laute Regeln (solche, deren Regel-ID in .\rules\config\noisy_rules.txt aufgeführt ist) aktivieren:

Hinweis: Seit kurzem befinden sich veraltete Regeln in einem separaten Verzeichnis im Sigma-Repository und sind daher nicht mehr standardmäßig in Hayabusa enthalten. Daher haben Sie wahrscheinlich keinen Grund, veraltete Regeln zu aktivieren.

hayabusa.exe dfir-timeline -d .\hayabusa-sample-evtx --enable-noisy-rules --enable-deprecated-rules -o results.csv -w
  • Nur Regeln zur Analyse von Anmeldungen ausführen und in der UTC-Zeitzone ausgeben:
hayabusa.exe dfir-timeline -d .\hayabusa-sample-evtx -r .\rules\hayabusa\builtin\Security\LogonLogoff\Logon -U -o results.csv -w
  • Auf einem Live-Windows-Computer ausführen (erfordert Administratorrechte) und nur Alarme (potenziell bösartiges Verhalten) erkennen:
hayabusa.exe dfir-timeline -l -m low
  • Ausführliche Informationen ausgeben (nützlich, um zu ermitteln, welche Dateien lange zur Verarbeitung benötigen, Parsing-Fehler usw.):
hayabusa.exe dfir-timeline -d .\hayabusa-sample-evtx -v
  • Beispiel für ausführliche Ausgabe:

Laden von Regeln:

Loaded rule: rules/sigma/builtin/deprecated/proc_creation_win_susp_run_folder.yml
Loaded rule: rules/sigma/builtin/deprecated/proc_creation_win_execution_mssql_xp_cmdshell_stored_procedure.yml
Loaded rule: rules/sigma/builtin/deprecated/proc_creation_win_susp_squirrel_lolbin.yml
Loaded rule: rules/sigma/builtin/win_alert_mimikatz_keywords.yml

Fehler während des Scans: 

[ERROR] Failed to parse event file.
EventFile: ../logs/Microsoft-Rdms-UI%4Operational.evtx
Error: Failed to parse record number 58471

[ERROR] Failed to parse event file.
EventFile: ../logs/Microsoft-Rdms-UI%4Operational.evtx
Error: Failed to parse record number 58470

[ERROR] Failed to parse event file.
EventFile: ../logs/Microsoft-Windows-AppxPackaging%4Operational.evtx
Error: An error occurred while trying to serialize binary xml to output.

  • In ein CSV-Format ausgeben, das zum Import in Timesketch kompatibel ist:
hayabusa.exe dfir-timeline -d ../hayabusa-sample-evtx --rfc-3339 -o timesketch-import.csv -p timesketch -U
  • Stiller Fehlermodus: Standardmäßig speichert Hayabusa Fehlermeldungen in Fehlerprotokolldateien. Wenn Sie keine Fehlermeldungen speichern möchten, fügen Sie bitte -Q hinzu.

Erweitert - GeoIP-Protokollanreicherung

Sie können GeoIP-Informationen (ASN-Organisation, Stadt und Land) zu SrcIP-Feldern (Quell-IP) und TgtIP-Feldern (Ziel-IP) mit den kostenlosen GeoLite2-Geolokalisierungsdaten hinzufügen.

Schritte:

  1. Melden Sie sich zuerst hier für ein MaxMind-Konto an.
  2. Laden Sie die drei .mmdb-Dateien von der Download-Seite herunter und speichern Sie sie in einem Verzeichnis. Die Dateinamen sollten GeoLite2-ASN.mmdb, GeoLite2-City.mmdb und GeoLite2-Country.mmdb heißen.

  3. Fügen Sie beim Ausführen des Befehls dfir-timeline die Option -G gefolgt vom Verzeichnis mit den MaxMind-Datenbanken hinzu.

  4. Bei der CSV-Ausgabe werden die folgenden 6 Spalten zusätzlich ausgegeben: SrcASN, SrcCity, SrcCountry, TgtASN, TgtCity, TgtCountry.

  5. Bei der JSON/JSONL-Ausgabe werden dieselben Felder SrcASN, SrcCity, SrcCountry, TgtASN, TgtCity, TgtCountry zum Details-Objekt hinzugefügt, aber nur, wenn sie Informationen enthalten.

  6. Wenn SrcIP oder TgtIP localhost ist (127.0.0.1, ::1 usw.), wird SrcASN oder TgtASN als Local ausgegeben.

  7. Wenn SrcIP oder TgtIP eine private IP-Adresse ist (10.0.0.0/8, fe80::/10 usw.), wird SrcASN oder TgtASN als Private ausgegeben.

GeoIP-Konfigurationsdatei

Die Feldnamen, die Quell- und Ziel-IP-Adressen enthalten, die in den GeoIP-Datenbanken nachgeschlagen werden, sind in rules/config/geoip_field_mapping.yaml definiert. Sie können diese Liste bei Bedarf erweitern. Es gibt in dieser Datei auch einen Filterabschnitt, der bestimmt, aus welchen Ereignissen IP-Adressinformationen extrahiert werden.

Automatische Aktualisierungen der GeoIP-Datenbanken

MaxMind-GeoIP-Datenbanken werden alle 2 Wochen aktualisiert. Sie können das MaxMind-Tool geoipupdate hier installieren, um diese Datenbanken automatisch zu aktualisieren.

Schritte unter macOS:

  1. brew install geoipupdate
  2. Bearbeiten Sie /usr/local/etc/GeoIP.conf oder /opt/homebrew/etc/GeoIP.conf: Tragen Sie Ihre AccountID und Ihren LicenseKey ein, die Sie nach dem Anmelden auf der MaxMind-Website erstellen. Stellen Sie sicher, dass die EditionIDs-Zeile EditionIDs GeoLite2-ASN GeoLite2-City GeoLite2-Country lautet.
  3. Führen Sie geoipupdate aus.
  4. Fügen Sie -G /usr/local/var/GeoIP oder -G /opt/homebrew/var/GeoIP hinzu, wenn Sie GeoIP-Informationen hinzufügen möchten.

Schritte unter Windows:

  1. Laden Sie die neueste Windows-Binärdatei (z. B. geoipupdate_4.10.0_windows_amd64.zip) von der Releases-Seite herunter.
  2. Bearbeiten Sie \ProgramData\MaxMind/GeoIPUpdate\GeoIP.conf: Tragen Sie Ihre AccountID und Ihren LicenseKey ein, die Sie nach dem Anmelden auf der MaxMind-Website erstellen. Stellen Sie sicher, dass die EditionIDs-Zeile EditionIDs GeoLite2-ASN GeoLite2-City GeoLite2-Country lautet.
  3. Führen Sie die ausführbare Datei geoipupdate aus.

Schritte unter Linux:

  1. Installieren Sie mit sudo apt install geoip-update.
  2. Bearbeiten Sie die Konfigurationsdatei mit sudo nano /etc/GeoIP.conf.
  3. Aktualisieren Sie die Datenbankdateien mit sudo geoipupdate.
  4. Fügen Sie -G /var/lib/GeoIP/ hinzu, wenn Sie GeoIP-Informationen hinzufügen möchten.

dfir-timeline-Befehlskonfigurationsdateien

./rules/config/channel_abbreviations.txt: Zuordnungen von Channel-Namen und ihren Abkürzungen.

./rules/config/default_details.txt: Die Konfigurationsdatei dafür, welche Standard-Feldinformationen (%Details%-Feld) ausgegeben werden sollen, wenn keine details:-Zeile in einer Regel angegeben ist. Dies basiert auf dem Provider-Namen und den Event-IDs.

./rules/config/eventkey_alias.txt: Diese Datei enthält die Zuordnungen von Kurznamen-Aliassen für Felder und ihren ursprünglichen längeren Feldnamen.

Beispiel: 

InstanceID,Event.UserData.UMDFHostDeviceArrivalBegin.InstanceId
IntegrityLevel,Event.EventData.IntegrityLevel
IpAddress,Event.EventData.IpAddress

Wenn ein Feld hier nicht definiert ist, prüft Hayabusa automatisch unter Event.EventData nach dem Feld.

./rules/config/exclude_rules.txt: Diese Datei enthält eine Liste von Regel-IDs, die von der Verwendung ausgeschlossen werden. Normalerweise liegt dies daran, dass eine Regel eine andere ersetzt hat oder die Regel von vornherein nicht verwendet werden kann. Wie Firewalls und IDSe erfordert jedes signaturbasierte Tool eine gewisse Feinabstimmung, um zu Ihrer Umgebung zu passen, sodass Sie bestimmte Regeln möglicherweise dauerhaft oder vorübergehend ausschließen müssen. Sie können eine Regel-ID (Beispiel: 4fe151c2-ecf9-4fae-95ae-b88ec9c2fca6) zu ./rules/config/exclude_rules.txt hinzufügen, um jede Regel zu ignorieren, die Sie nicht benötigen oder die nicht verwendet werden kann.

./rules/config/noisy_rules.txt: Diese Datei enthält eine Liste von Regel-IDs, die standardmäßig deaktiviert sind, aber durch das Aktivieren lauter Regeln mit der Option -n, --enable-noisy-rules aktiviert werden können. Diese Regeln sind in der Regel von Natur aus oder aufgrund von Fehlalarmen laut.

./rules/config/target_event_IDs.txt: Nur die in dieser Datei angegebenen Event-IDs werden gescannt, wenn der EID-Filter aktiviert ist. Standardmäßig scannt Hayabusa alle Ereignisse, aber wenn Sie die Leistung verbessern möchten, verwenden Sie bitte die Option -E, --eid-filter. Dies führt in der Regel zu einer Geschwindigkeitsverbesserung von 10~25 %.

level-tuning-Befehl

Mit dem Befehl level-tuning können Sie die Alarmlevel für Regeln feinabstimmen und das Risikolevel nach Belieben anheben oder senken. Dieser Befehl verwendet eine Konfigurationsdatei, um die Risikolevel (das level-Feld) der Regeln im Ordner rules zu überschreiben.

Warnung: Jedes Mal, wenn Sie den Befehl update-rules ausführen, wird das Risikolevel auf den ursprünglichen Wert zurückgesetzt, sodass Sie den Befehl level-tuning danach erneut ausführen müssen.

Usage:
  hayabusa.exe level-tuning [OPTIONS]

Display Settings:
  -K, --no-color  Disable color output
  -q, --quiet     Quiet mode: do not display the launch banner

General Options:
  -f, --file <FILE>  Tune alert levels (default: ./rules/config/level_tuning.txt)
  -h, --help         Show the help menu

level-tuning-Befehlsbeispiele

  • Normale Verwendung: hayabusa.exe level-tuning
  • Regel-Alarmlevel basierend auf Ihrer benutzerdefinierten Konfigurationsdatei feinabstimmen: hayabusa.exe level-tuning -f ./config/level_tuning.txt

level-tuning-Konfigurationsdatei

Hayabusa- und Sigma-Regelautoren schätzen beim Schreiben ihrer Regeln das angemessene Risikolevel des Alarms ein. Allerdings sind die Risikolevel manchmal nicht konsistent und das tatsächliche Risikolevel kann sich je nach Ihrer Umgebung unterscheiden. Yamato Security stellt eine Konfigurationsdatei unter ./rules/config/level_tuning.txt bereit und pflegt sie, die Sie ebenfalls zur Feinabstimmung Ihrer Regeln verwenden können.

./rules/config/level_tuning.txt-Beispiel:

id,new_level
570ae5ec-33dc-427c-b815-db86228ad43e,informational # 'Application Uninstalled' - Originally low.
b6ce0b2f-593b-5e1c-e137-d30b2974e30e,high # 'Suspicious Double Extension File Execution' - Sysmon 1 - Originally critical
452b2159-5e6e-c494-63b9-b385d6195f58,high # 'Suspicious Double Extension File Execution' - Security 4688 - Originally critical
51ba8477-86a4-6ff0-35fa-7b7f1b1e3f83,high # 'CobaltStrike Service Installations - System' - System 7045 - Originally critical
daad2203-665f-294c-6d2f-f9272c3214f2,critical # 'Mimikatz DC Sync' - Security 4662 - Originally high
8b061ac2-31c7-659d-aa1b-36ceed1b03f1,high # 'HackTool - Rubeus Execution' - Sysmon 1 - Originally critical
be670d5c-31eb-7391-4d2e-d122c89cd5bb,high # 'HackTool - Rubeus Execution' - Security 4688 - Originally critical

In diesem Fall wird das Risikolevel der Regel mit einer id von 570ae5ec-33dc-427c-b815-db86228ad43e im Regelverzeichnis sein level auf informational umgeschrieben bekommen. Die möglichen einzustellenden Level sind critical, high, medium, low und informational.

Warnung: Die Konfigurationsdatei ./rules/config/level_tuning.txt wird ebenfalls jedes Mal, wenn Sie update-rules ausführen, auf die neueste Version im hayabusa-rules-Repository aktualisiert. Wenn Sie also Änderungen an dieser Datei vornehmen, gehen diese Änderungen verloren! Wenn Sie eine Konfigurationsdatei für sich behalten möchten, dann erstellen Sie eine Konfigurationsdatei in ./config/level_tuning.txt und führen Sie hayabusa.exe level-tuning -f ./config/level_tuning.txt aus. Sie können auch zuerst die Feinabstimmung mit der von Yamato Security bereitgestellten Konfigurationsdatei durchführen und dann mit Ihrer eigenen Konfigurationsdatei weiter feinabstimmen.

list-profiles-Befehl

Usage:
  hayabusa.exe list-profiles [OPTIONS]

Display Settings:
  -K, --no-color  Disable color output
  -q, --quiet     Quiet mode: do not display the launch banner

General Options:
  -h, --help  Show the help menu

set-default-profile-Befehl

Usage:
  hayabusa.exe set-default-profile [OPTIONS]

Display Settings:
  -K, --no-color  Disable color output
  -q, --quiet     Quiet mode: do not display the launch banner

General Options:
  -h, --help               Show the help menu
  -p, --profile <PROFILE>  Specify output profile

set-default-profile-Befehlsbeispiele

  • Das Standardprofil auf minimal setzen: hayabusa.exe set-default-profile minimal
  • Das Standardprofil auf super-verbose setzen: hayabusa.exe set-default-profile super-verbose

update-rules-Befehl

Der Befehl update-rules synchronisiert den Ordner rules mit dem Hayabusa-rules-GitHub-Repository und aktualisiert die Regeln und Konfigurationsdateien.

Usage:
  hayabusa.exe update-rules [OPTIONS]

Display Settings:
  -K, --no-color  Disable color output
  -q, --quiet     Quiet mode: do not display the launch banner

General Options:
  -h, --help              Show the help menu
  -r, --rules <DIR/FILE>  Specify a custom rule directory or file (default: ./rules)

update-rules-Befehlsbeispiel

Normalerweise führen Sie einfach dies aus: hayabusa.exe update-rules