Hayabusa
v2.18.0 ?
Hayabusa ist ein schneller Forensik-Timeline-Generator für Windows-Ereignisprotokolle und ein Tool zur Bedrohungssuche, das von der Yamato Security-Gruppe in Japan entwickelt wurde. Hayabusa bedeutet auf Japanisch „Wanderfalke“ und wurde ausgewählt, da Wanderfalken das schnellste Tier der Welt sind, großartig in der Jagd und gut trainierbar. Es ist in Rust geschrieben und unterstützt Multithreading, um so schnell wie möglich zu sein. Wir haben ein Tool zur Konvertierung von Sigma-Regeln in das Hayabusa-Regelformat bereitgestellt. Die Sigma-kompatiblen Hayabusa-Erkennungsregeln sind in YML geschrieben, um möglichst einfach anpassbar und erweiterbar zu sein. Hayabusa kann entweder auf einzelnen laufenden Systemen zur Live-Analyse ausgeführt werden, durch das Sammeln von Protokollen von einzelnen oder mehreren Systemen zur Offline-Analyse oder durch Ausführen des Hayabusa-Artefakts mit Velociraptor zur unternehmensweiten Bedrohungssuche und Reaktion auf Vorfälle. Die Ausgabe wird zur einfachen Analyse in LibreOffice, Timeline Explorer, Elastic Stack, Timesketch usw. in einer einzigen CSV-Zeitleiste konsolidiert.
evtx Kiste.-T )-H )-M Multiline-Ausgabe)computer-metrics Befehlcomputer-metrics Befehlecomputer-metricseid-metrics Befehleid-metrics Befehleeid-metrics Befehlskonfigurationsdateieid-metrics Screenshotlogon-summary Befehllogon-summarylogon-summary Screenshotspivot-keywords-listpivot-keywords-listpivot-keywords-list Konfigurationsdateisearchsearchsearchcsv-timeline Befehlcsv-timeline Befehlecsv-timeline Befehlskonfigurationsdateienjson-timeline Befehljson-timeline Befehlsbeispiele und Konfigurationsdateienlevel-tuninglevel-tuning -Befehlelevel-tuning Konfigurationsdateilist-profiles Befehlset-default-profile Befehlset-default-profile Befehleupdate-rules Befehlupdate-rulesminimal Profilausgabestandardverbose Profilausgabeall-field-infoall-field-info-verbose Profilausgabesuper-verbose Profilausgabetimesketch-minimal Profilausgabetimesketch-verbose ProfilausgabeHayabusa verfügt derzeit über über 4000 Sigma-Regeln und über 170 integrierte Hayabusa-Erkennungsregeln, wobei regelmäßig weitere Regeln hinzugefügt werden. Es kann für die unternehmensweite proaktive Bedrohungssuche sowie für DFIR (Digital Forensics and Incident Response) kostenlos mit dem Hayabusa-Artefakt von Velociraptor verwendet werden. Durch die Kombination dieser beiden Open-Source-Tools können Sie im Wesentlichen rückwirkend ein SIEM reproduzieren, wenn in der Umgebung kein SIEM-Setup vorhanden ist. Wie das geht, erfahren Sie in der exemplarischen Vorgehensweise zum Velociraptor von Eric Capuano.
Die Analyse von Windows-Ereignisprotokollen war traditionell ein sehr langer und mühsamer Prozess, da Windows-Ereignisprotokolle 1) in einem Datenformat vorliegen, das schwer zu analysieren ist und 2) die meisten Daten Rauschen sind und für Untersuchungen nicht nützlich sind. Ziel von Hayabusa ist es, nur nützliche Daten zu extrahieren und sie in einem möglichst prägnanten, leicht lesbaren Format darzustellen, das nicht nur von professionell ausgebildeten Analysten, sondern jedem Windows-Systemadministrator verwendet werden kann. Hayabusa hofft, dass Analysten im Vergleich zur herkömmlichen Windows-Ereignisprotokollanalyse 80 % ihrer Arbeit in 20 % der Zeit erledigen können.
-T ) 
-H ) 
-M Multiline-Ausgabe) 
Hier erfahren Sie, wie Sie CSV-Zeitleisten in Excel und im Timeline Explorer analysieren.
Hier erfahren Sie, wie Sie CSV-Dateien in Elastic Stack importieren.
Hier erfahren Sie, wie Sie CSV-Dateien in Timesketch importieren.
Hier erfahren Sie, wie Sie JSON-formatierte Ergebnisse mit jq analysieren.
|equalsfield und |endswithfield .0xc0000234 -> ACCOUNT LOCKED )Bitte laden Sie die neueste stabile Version von Hayabusa mit kompilierten Binärdateien herunter oder kompilieren Sie den Quellcode von der Seite „Releases“.
Wir stellen Binärdateien für die folgenden Architekturen bereit:
hayabusa-xxx-lin-aarch64-gnu )hayabusa-xxx-lin-x64-gnu )hayabusa-xxx-lin-x64-musl )hayabusa-xxx-mac-aarch64 )hayabusa-xxx-mac-x64 )hayabusa-xxx-win-aarch64.exe )hayabusa-xxx-win-x64.exe )hayabusa-xxx-win-x86.exe )Aus irgendeinem Grund läuft die Linux ARM MUSL-Binärdatei nicht ordnungsgemäß, daher stellen wir diese Binärdatei nicht zur Verfügung. Da das Problem außerhalb unserer Kontrolle liegt, planen wir, es in Zukunft bereitzustellen, sobald das Problem behoben ist.
Ab v2.18.0 stellen wir spezielle Windows-Pakete bereit, die XOR-codierte Regeln verwenden, die in einer einzigen Datei bereitgestellt werden, sowie alle Konfigurationsdateien, die in einer einzigen Datei zusammengefasst sind (gehostet im Repository „hayabusa-encoded-rules“). Laden Sie einfach die Zip-Pakete mit live-response im Namen herunter. Die ZIP-Dateien enthalten lediglich drei Dateien: die binäre, XOR-codierte Regeldatei von Hayabusa und die Konfigurationsdatei. Der Zweck dieser Live-Antwortpakete besteht darin, bei der Ausführung von Hayabusa auf Client-Endpunkten sicherzustellen, dass Antivirenscanner wie Windows Defender keine Fehlalarme für .yml Regeldateien ausgeben. Außerdem möchten wir die Menge der in das System geschriebenen Dateien minimieren, damit forensische Artefakte wie das USN Journal nicht überschrieben werden.
Sie können das Repository mit dem folgenden Befehl git clone und die Binärdatei aus dem Quellcode kompilieren:
Warnung: Der Hauptzweig des Repositorys dient Entwicklungszwecken, sodass Sie möglicherweise auf neue Funktionen zugreifen können, die noch nicht offiziell veröffentlicht wurden. Es können jedoch Fehler auftreten. Betrachten Sie es daher als instabil.
git clone https://github.com/Yamato-Security/hayabusa.git --recursiveHinweis: Wenn Sie vergessen, die Option --recursive zu verwenden, wird der
rules, der als Git-Submodul verwaltet wird, nicht geklont.
Sie können den rules synchronisieren und die neuesten Hayabusa-Regeln mit git pull --recurse-submodules abrufen oder den folgenden Befehl verwenden:
hayabusa.exe update-rules Wenn die Aktualisierung fehlschlägt, müssen Sie möglicherweise den rules umbenennen und es erneut versuchen.
Achtung: Bei der Aktualisierung werden Regeln und Konfigurationsdateien im
rulesdurch die neuesten Regeln und Konfigurationsdateien im hayabusa-rules-Repository ersetzt. Alle Änderungen, die Sie an vorhandenen Dateien vornehmen, werden überschrieben. Wir empfehlen Ihnen daher, vor der Aktualisierung Sicherungskopien aller von Ihnen bearbeiteten Dateien zu erstellen. Wenn Sie Level-Tuning mitlevel-tuningdurchführen, optimieren Sie bitte Ihre Regeldateien nach jedem Update neu. Wenn Sie imrulesneue Regeln hinzufügen, werden diese bei der Aktualisierung nicht überschrieben oder gelöscht.
Wenn Sie Rust installiert haben, können Sie mit dem folgenden Befehl aus dem Quellcode kompilieren:
Hinweis: Zum Kompilieren benötigen Sie in der Regel die neueste Version von Rust.
cargo build --releaseSie können die neueste instabile Version vom Hauptzweig oder die neueste stabile Version von der Seite „Releases“ herunterladen.
Stellen Sie sicher, dass Sie Rust regelmäßig aktualisieren mit:
rustup update stable Die kompilierte Binärdatei wird im Ordner ./target/release ausgegeben.
Sie können vor dem Kompilieren auf die neuesten Rust-Kisten aktualisieren:
cargo updateBitte teilen Sie uns mit, wenn nach dem Update etwas kaputt geht.
Sie können 32-Bit-Binärdateien auf 64-Bit-Windows-Systemen wie folgt erstellen:
rustup install stable-i686-pc-windows-msvc
rustup target add i686-pc-windows-msvc
rustup run stable-i686-pc-windows-msvc cargo build --releaseWarnung: Führen Sie unbedingt
rustup install stable-i686-pc-windows-msvcaus, wenn es eine neue stabile Version von Rust gibt, darustup update stableden Compiler für die Cross-Kompilierung nicht aktualisiert und Sie möglicherweise Build-Fehler erhalten.
Wenn Sie Kompilierungsfehler zu OpenSSL erhalten, müssen Sie Homebrew installieren und dann die folgenden Pakete installieren:
brew install pkg-config
brew install opensslWenn Sie Kompilierungsfehler zu OpenSSL erhalten, müssen Sie das folgende Paket installieren.
Ubuntu-basierte Distributionen:
sudo apt install libssl-devFedora-basierte Distributionen:
sudo yum install openssl-develInstallieren Sie auf einem Linux-Betriebssystem zunächst das Ziel.
rustup install stable-x86_64-unknown-linux-musl
rustup target add x86_64-unknown-linux-muslKompilieren mit:
cargo build --release --target=x86_64-unknown-linux-muslWarnung: Führen Sie unbedingt
rustup install stable-x86_64-unknown-linux-muslaus, wenn es eine neue stabile Version von Rust gibt, darustup update stableden Compiler für die Cross-Kompilierung nicht aktualisiert und Sie möglicherweise Build-Fehler erhalten.
Die MUSL-Binärdatei wird im Verzeichnis ./target/x86_64-unknown-linux-musl/release/ erstellt. MUSL-Binärdateien sind etwa 15 % langsamer als die GNU-Binärdateien, lassen sich jedoch besser auf verschiedene Linux-Versionen und -Distributionen übertragen.
Möglicherweise erhalten Sie eine Warnung von Antiviren- oder EDR-Produkten, wenn Sie versuchen, Hayabusa auszuführen oder auch nur, wenn Sie die .yml -Regeln herunterladen, da die Erkennungssignatur Schlüsselwörter wie mimikatz und verdächtige PowerShell-Befehle enthält. Da es sich dabei um Fehlalarme handelt, müssen Sie Ausschlüsse in Ihren Sicherheitsprodukten konfigurieren, damit Hayabusa ausgeführt werden kann. Wenn Sie Angst vor Malware oder Angriffen auf die Lieferkette haben, überprüfen Sie bitte den Hayabusa-Quellcode und kompilieren Sie die Binärdateien selbst.
Aufgrund des Echtzeitschutzes von Windows Defender kann es insbesondere beim ersten Start nach einem Neustart zu einer langsamen Laufzeit kommen. Sie können dies vermeiden, indem Sie den Echtzeitschutz vorübergehend deaktivieren oder einen Ausschluss zum Hayabusa-Laufzeitverzeichnis hinzufügen. (Bitte berücksichtigen Sie die Sicherheitsrisiken, bevor Sie dies tun.)
Führen Sie in einer Befehls-/PowerShell-Eingabeaufforderung oder einem Windows-Terminal einfach die entsprechende 32-Bit- oder 64-Bit-Windows-Binärdatei aus.
Wenn Sie die integrierte Befehls- oder PowerShell-Eingabeaufforderung in Windows verwenden, erhalten Sie möglicherweise eine Fehlermeldung, dass Hayabusa keine .evtx-Dateien laden konnte, wenn in Ihrer Datei oder Ihrem Verzeichnispfad ein Leerzeichen vorhanden ist. Um die .evtx-Dateien ordnungsgemäß zu laden, gehen Sie unbedingt wie folgt vor:
Sie müssen zunächst die Binärdatei ausführbar machen.
chmod +x ./hayabusaFühren Sie es dann aus dem Hayabusa-Stammverzeichnis aus:
./hayabusaVon Terminal oder iTerm2 aus müssen Sie zunächst die Binärdatei ausführbar machen.
chmod +x ./hayabusaVersuchen Sie dann, es aus dem Hayabusa-Stammverzeichnis auszuführen:
./hayabusaIn der neuesten Version von macOS erhalten Sie möglicherweise die folgende Sicherheitsfehlermeldung, wenn Sie versuchen, sie auszuführen:
Klicken Sie auf „Abbrechen“ und öffnen Sie dann in den Systemeinstellungen „Sicherheit und Datenschutz“ und klicken Sie auf der Registerkarte „Allgemein“ auf „Trotzdem zulassen“.
Versuchen Sie danach erneut, es auszuführen.
./hayabusaDie folgende Warnung wird angezeigt. Klicken Sie daher bitte auf „Öffnen“.
Sie sollten jetzt in der Lage sein, Hayabusa auszuführen.
computer-metrics : Gibt die Anzahl der Ereignisse basierend auf Computernamen aus.eid-metrics : Drucken Sie die Anzahl und den Prozentsatz der Ereignisse basierend auf der Ereignis-ID.logon-summary : Drucken Sie eine Zusammenfassung der Anmeldeereignisse.pivot-keywords-list : Drucken Sie eine Liste verdächtiger Schlüsselwörter zum Pivotieren.search : Durchsuchen Sie alle Ereignisse nach Schlüsselwörtern oder regulären Ausdrücken csv-timeline : Speichern Sie die Timeline im CSV-Format.json-timeline : Speichern Sie die Timeline im JSON/JSONL-Format.level-tuning : Passen Sie den level der Warnungen individuell an.list-profiles : Listet die verfügbaren Ausgabeprofile auf.set-default-profile : Ändern Sie das Standardprofil.update-rules : Synchronisieren Sie die Regeln mit den neuesten Regeln im GitHub-Repository „hayabusa-rules“. help : Diese Nachricht oder die Hilfe zu den angegebenen Unterbefehlen drucken.list-contributors : Drucken Sie die Liste der Mitwirkendencomputer-metrics Befehl Sie können den Befehl computer-metrics verwenden, um zu überprüfen, wie viele Ereignisse für jeden im Feld Computer verlassen können. Windows 11 verwendet beim Speichern in Ereignisprotokollen manchmal völlig andere Computer . Außerdem zeichnet Windows 10 manchmal den Computer in Kleinbuchstaben auf. Dieser Befehl verwendet keine Erkennungsregeln und analysiert daher alle Ereignisse. Dies ist ein guter Befehl, um schnell zu sehen, auf welchen Computern die meisten Protokolle vorhanden sind. Mit diesen Informationen können Sie dann beim Erstellen Ihrer Zeitleisten die Optionen --include-computer oder --exclude-computer verwenden, um Ihre Zeitleistengenerierung effizienter zu gestalten, indem Sie mehrere Zeitleisten je nach Computer erstellen oder Ereignisse von bestimmten Computern ausschließen.
Usage: computer-metrics [OPTIONS]
Input:
-d, --directory Directory of multiple .evtx files
-f, --file File path to one .evtx file
-l, --live-analysis Analyze the local C:WindowsSystem32winevtLogs 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)
-Q, --quiet-errors Quiet errors mode: do not save error logs
-x, --recover-records Carve evtx records from slack space (default: disabled)
-c, --rules-config Specify custom rule config directory (default: ./rules/config)
--target-file-ext Specify additional evtx file extensions (ex: evtx_data)
-t, --threads Number of threads (default: optimal number for performance)
Filtering:
--timeline-offset Scan recent events based on an offset (ex: 1y, 3M, 30d, 24h, 30m)
Output:
-o, --output Save the results in CSV format (ex: computer-metrics.csv)
Display Settings:
--no-color Disable color output
-q, --quiet Quiet mode: do not display the launch banner
-v, --verbose Output verbose information
computer-metrics Befehlehayabusa.exe computer-metrics -d ../logshayabusa.exe computer-metrics -d ../logs -o computer-metrics.csv computer-metrics 
eid-metrics Befehl Sie können den Befehl eid-metrics verwenden, um die Gesamtzahl und den Prozentsatz der Ereignis-IDs (Feld
Usage: eid-metrics [OPTIONS]
Input:
-d, --directory Directory of multiple .evtx files
-f, --file File path to one .evtx file
-l, --live-analysis Analyze the local C:WindowsSystem32winevtLogs 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)
-Q, --quiet-errors Quiet errors mode: do not save error logs
-x, --recover-records Carve evtx records from slack space (default: disabled)
-c, --rules-config Specify custom rule config directory (default: ./rules/config)
--target-file-ext Specify additional evtx file extensions (ex: evtx_data)
-t, --threads Number of threads (default: optimal number for performance)
Filtering:
--exclude-computer Do not scan specified computer names (ex: ComputerA) (ex: ComputerA,ComputerB)
--include-computer Scan only specified computer names (ex: ComputerA) (ex: ComputerA,ComputerB)
--timeline-offset Scan recent events based on an offset (ex: 1y, 3M, 30d, 24h, 30m)
Output:
-o, --output Save the Metrics in CSV format (ex: metrics.csv)
Display Settings:
--no-color Disable color output
-q, --quiet Quiet mode: do not display the launch banner
-v, --verbose Output verbose information
Time Format:
--European-time Output timestamp in European time format (ex: 22-02-2022 22:00:00.123 +02:00)
--ISO-8601 Output timestamp in 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)
--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)
-U, --UTC Output time in UTC format (default: local time)
eid-metrics Befehlehayabusa.exe eid-metrics -f Security.evtxhayabusa.exe eid-metrics -d ../logshayabusa.exe eid-metrics -f Security.evtx -o eid-metrics.csv eid-metrics Befehlskonfigurationsdatei Der Kanal, die Ereignis-IDs und die Titel der Ereignisse werden in rules/config/channel_eid_info.txt definiert.
Beispiel:
Channel,EventID,EventTitle
Microsoft-Windows-Sysmon/Operational,1,Process Creation.
Microsoft-Windows-Sysmon/Operational,2,File Creation Timestamp Changed. (Possible Timestomping)
Microsoft-Windows-Sysmon/Operational,3,Network Connection.
Microsoft-Windows-Sysmon/Operational,4,Sysmon Service State Changed.
eid-metrics Screenshot 
logon-summary Befehl Sie können den Befehl logon-summary verwenden, um eine Zusammenfassung der Anmeldeinformationen (Anmeldebenutzernamen sowie Anzahl erfolgreicher und fehlgeschlagener Anmeldungen) auszugeben. Sie können die Anmeldeinformationen für eine evtx-Datei mit -f oder für mehrere evtx-Dateien mit der Option -d anzeigen.
Usage: logon-summary [OPTIONS]
Input:
-d, --directory Directory of multiple .evtx files
-f, --file File path to one .evtx file
-l, --live-analysis Analyze the local C:WindowsSystem32winevtLogs 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)
-Q, --quiet-errors Quiet errors mode: do not save error logs
-x, --recover-records Carve evtx records from slack space (default: disabled)
-c, --rules-config Specify custom rule config directory (default: ./rules/config)
--target-file-ext Specify additional evtx file extensions (ex: evtx_data)
-t, --threads Number of threads (default: optimal number for performance)
Filtering:
--exclude-computer Do not scan specified computer names (ex: ComputerA) (ex: ComputerA,ComputerB)
--include-computer Scan only specified computer names (ex: ComputerA) (ex: ComputerA,ComputerB)
--timeline-end End time of the event logs to load (ex: "2022-02-22 23:59:59 +09:00")
--timeline-offset Scan recent events based on an offset (ex: 1y, 3M, 30d, 24h, 30m)
--timeline-start Start time of the event logs to load (ex: "2020-02-22 00:00:00 +09:00")
Output:
-o, --output Save the logon summary to two CSV files (ex: -o logon-summary)
Display Settings:
--no-color Disable color output
-q, --quiet Quiet mode: do not display the launch banner
-v, --verbose Output verbose information
Time Format:
--European-time Output timestamp in European time format (ex: 22-02-2022 22:00:00.123 +02:00)
--ISO-8601 Output timestamp in 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)
--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)
-U, --UTC Output time in UTC format (default: local time)
logon-summaryhayabusa.exe logon-summary -f Security.evtxhayabusa.exe logon-summary -d ../logs -o logon-summary.csv logon-summary Screenshots 
pivot-keywords-list Mit dem Befehl pivot-keywords-list können Sie eine Liste eindeutiger Pivot-Schlüsselwörter erstellen, um ungewöhnliche Benutzer, Hostnamen, Prozesse usw. schnell zu identifizieren und Ereignisse zu korrelieren.
Wichtig: Standardmäßig gibt Hayabusa Ergebnisse von allen Ereignissen (informativ und höher) zurück. Wir empfehlen daher dringend, den Befehl pivot-keywords-list mit der Option -m, --min-level zu kombinieren. Beginnen Sie beispielsweise damit, nur Schlüsselwörter für critical Warnungen mit -m critical zu erstellen, und fahren Sie dann mit -m high , -m medium usw. fort. In Ihren Ergebnissen werden höchstwahrscheinlich häufige Schlüsselwörter enthalten sein, die bei vielen normalen Ereignissen übereinstimmen. Nachdem Sie also die Ergebnisse manuell überprüft und eine Liste eindeutiger Schlüsselwörter in einer einzigen Datei erstellt haben, können Sie mit einem Befehl wie grep -f keywords.txt timeline.csv eine eingegrenzte Zeitleiste verdächtiger Aktivitäten erstellen.
Usage: pivot-keywords-list [OPTIONS]
Input:
-d, --directory Directory of multiple .evtx files
-f, --file File path to one .evtx file
-l, --live-analysis Analyze the local C:WindowsSystem32winevtLogs 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)
-c, --rules-config Specify custom rule config directory (default: ./rules/config)
--target-file-ext Specify additional evtx file extensions (ex: evtx_data)
-t, --threads Number of threads (default: optimal number for performance)
Filtering:
-E, --EID-filter Scan only common EIDs for faster speed (./rules/config/target_event_IDs.txt)
-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 Only load rules with a specific level (informational, low, medium, high, critical)
--exclude-computer Do not scan specified computer names (ex: ComputerA) (ex: ComputerA,ComputerB)
--exclude-eid Do not scan specific EIDs for faster speed (ex: 1) (ex: 1,4688)
--exclude-status Do not load rules according to status (ex: experimental) (ex: stable,test)
--exclude-tag Do not load rules with specific tags (ex: sysmon)
--include-computer Scan only specified computer names (ex: ComputerA) (ex: ComputerA,ComputerB)
--include-eid Scan only specified EIDs for faster speed (ex: 1) (ex: 1,4688)
--include-status Only load rules with specific status (ex: experimental) (ex: stable,test)
--include-tag Only load rules with specific tags (ex: attack.execution,attack.discovery)
-m, --min-level Minimum level for rules to load (default: informational)
--timeline-end End time of the event logs to load (ex: "2022-02-22 23:59:59 +09:00")
--timeline-offset Scan recent events based on an offset (ex: 1y, 3M, 30d, 24h, 30m)
--timeline-start Start time of the event logs to load (ex: "2020-02-22 00:00:00 +09:00")
Output:
-o, --output Save pivot words to separate files (ex: PivotKeywords)
Display Settings:
--no-color Disable color output
-q, --quiet Quiet mode: do not display the launch banner
-v, --verbose Output verbose information
pivot-keywords-listhayabusa.exe pivot-keywords-list -d ../logs -m criticalkeywords-Ip Addresses.txt , keywords-Users.txt usw. gespeichert): hayabusa.exe pivot-keywords-list -d ../logs -m critical -o keywords`
pivot-keywords-list Konfigurationsdatei Sie können anpassen, nach welchen Schlüsselwörtern Sie suchen möchten, indem Sie ./rules/config/pivot_keywords.txt bearbeiten. Diese Seite ist die Standardeinstellung.
Das Format ist KeywordName.FieldName . Wenn Sie beispielsweise die Liste der Users erstellen, listet hayabusa alle Werte in den Feldern SubjectUserName , TargetUserName und User auf.
search Mit dem search können Sie nach Schlüsselwörtern für alle Ereignisse suchen. (Nicht nur Hayabusa-Erkennungsergebnisse.) Dies ist nützlich, um festzustellen, ob es Beweise für Ereignisse gibt, die von Hayabusa nicht erkannt werden.
Usage: hayabusa.exe search <--keywords "" OR --regex ""> [OPTIONS]
Display Settings:
--no-color Disable color output
-q, --quiet Quiet mode: do not display the launch banner
-v, --verbose Output verbose information
General Options:
-C, --clobber Overwrite files when saving
-h, --help Show the help menu
-Q, --quiet-errors Quiet errors mode: do not save error logs
-x, --recover-records Carve evtx records from slack space (default: disabled)
-c, --rules-config Specify custom rule config directory (default: ./rules/config)
--target-file-ext Specify additional evtx file extensions (ex: evtx_data)
-t, --threads Number of threads (default: optimal number for performance)
Input:
-d, --directory Directory of multiple .evtx files
-f, --file File path to one .evtx file
-l, --live-analysis Analyze the local C:WindowsSystem32winevtLogs folder
Filtering:
-a, --and-logic Search keywords with AND logic (default: OR)
-F, --filter Filter by specific field(s)
-i, --ignore-case Case-insensitive keyword search
-k, --keyword Search by keyword(s)
-r, --regex Search by regular expression
--timeline-offset Scan recent events based on an offset (ex: 1y, 3M, 30d, 24h, 30m)
Output:
-J, --JSON-output Save the search results in JSON format (ex: -J -o results.json)
-L, --JSONL-output Save the search results in JSONL format (ex: -L -o results.jsonl)
-M, --multiline Output event field information in multiple rows for CSV output
-o, --output Save the search results in CSV format (ex: search.csv)
Time Format:
--European-time Output timestamp in European time format (ex: 22-02-2022 22:00:00.123 +02:00)
--ISO-8601 Output timestamp in 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)
--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)
-U, --UTC Output time in UTC format (default: local time)
search../hayabusa-sample-evtx nach dem Schlüsselwort mimikatz : hayabusa.exe search -d ../hayabusa-sample-evtx -k "mimikatz"
Hinweis: Das Schlüsselwort stimmt überein, wenn
mimikatzirgendwo in den Daten gefunden wird. Es handelt sich nicht um eine exakte Übereinstimmung.
../hayabusa-sample-evtx nach den Schlüsselwörtern mimikatz oder kali : hayabusa.exe search -d ../hayabusa-sample-evtx -k "mimikatz" -k "kali"
../hayabusa-sample-evtx nach dem Schlüsselwort mimikatz und ignorieren Sie die Groß-/Kleinschreibung: hayabusa.exe search -d ../hayabusa-sample-evtx -k "mimikatz" -i
../hayabusa-sample-evtx mithilfe regulärer Ausdrücke nach IP-Adressen: hayabusa.exe search -d ../hayabusa-sample-evtx -r "(?:[0-9]{1,3}.){3}[0-9]{1,3}"
../hayabusa-sample-evtx und zeigen Sie alle Ereignisse an, bei denen das Feld WorkstationName kali lautet: hayabusa.exe search -d ../hayabusa-sample-evtx -r ".*" -F WorkstationName:"kali"
Hinweis:
.*ist der reguläre Ausdruck, der bei jedem Ereignis abgeglichen wird.
search ./rules/config/channel_abbreviations.txt : Zuordnungen von Kanalnamen und ihren Abkürzungen.
Für die Befehle csv-timeline und json-timeline ist jetzt standardmäßig ein Scan-Assistent aktiviert. Dies soll Benutzern helfen, ganz einfach auszuwählen, welche Erkennungsregeln sie entsprechend ihren Bedürfnissen und Vorlieben aktivieren möchten. Die zu ladenden Erkennungsregelsätze 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 traditionelle Weise verwenden, indem Sie die Option -w, --no-wizard hinzufügen.
Der core ermöglicht Regeln mit dem Status test oder stable und der Stufe high oder critical . Hierbei handelt es sich um qualitativ hochwertige Regeln mit hoher Zuverlässigkeit und Relevanz, die nicht zu vielen Fehlalarmen führen sollten. Der Regelstatus ist test oder stable , was bedeutet, dass seit mehr als 6 Monaten keine falsch positiven Ergebnisse gemeldet wurden. Die Regeln stimmen auf Angreifertechniken, generische verdächtige Aktivitäten oder böswilliges Verhalten überein. Es ist dasselbe wie die Verwendung der Optionen --exclude-status deprecated,unsupported,experimental --min-level high .
Der Regelsatz core+ “ ermöglicht Regeln mit dem Status test oder stable und der Stufe medium oder höher. medium Regeln erfordern in den meisten Fällen eine zusätzliche Optimierung, da bestimmte Anwendungen, legitimes Benutzerverhalten oder Skripte einer Organisation möglicherweise übereinstimmen. Es ist dasselbe wie die Verwendung der --exclude-status deprecated,unsupported,experimental --min-level medium .
Der Regelsatz core++ ermöglicht Regeln mit dem Status experimental , test oder stable und der Stufe medium oder höher. Diese Regeln sind auf dem neuesten Stand. Sie werden anhand der im SigmaHQ-Projekt verfügbaren Basis-evtx-Dateien validiert und von mehreren Erkennungsingenieuren überprüft. Ansonsten sind sie zunächst so gut wie ungetestet. Verwenden Sie diese, wenn Sie Bedrohungen so früh wie möglich erkennen möchten, allerdings auf Kosten einer höheren Schwelle an Fehlalarmen. Dies entspricht der Verwendung der --exclude-status deprecated,unsupported --min-level medium .
Der Regelsatz Emerging Threats (ET) aktiviert Regeln, die das Tag detection.emerging_threats haben. Diese Regeln zielen auf bestimmte Bedrohungen ab und sind besonders nützlich für aktuelle Bedrohungen, zu denen noch nicht viele Informationen verfügbar sind. Diese Regeln sollten nicht viele Fehlalarme enthalten, werden aber mit der Zeit an Relevanz verlieren. Wenn diese Regeln nicht aktiviert sind, ist dies dasselbe wie die Verwendung der Option --exclude-tag detection.emerging_threats . Wenn Hayabusa traditionell ohne den Assistenten ausgeführt wird, sind diese Regeln standardmäßig enthalten.
Der Threat Hunting (TH) -Regelsatz ermöglicht Regeln mit dem Tag detection.threat_hunting . Diese Regeln können unbekannte böswillige Aktivitäten erkennen, führen jedoch in der Regel zu mehr Fehlalarmen. Wenn diese Regeln nicht aktiviert sind, ist dies dasselbe wie die Verwendung der Option --exclude-tag detection.threat_hunting . Wenn Hayabusa traditionell ohne den Assistenten ausgeführt wird, sind diese Regeln standardmäßig enthalten.
Ab Hayabusa v2.16.0 aktivieren wir einen kanalbasierten Filter beim Laden .evtx Dateien und .yml Regeln. Der Zweck besteht darin, das Scannen so effizient wie möglich zu gestalten, indem nur das geladen wird, was erforderlich ist. Während es möglich ist, dass in einem einzigen Ereignisprotokoll mehrere Anbieter vorhanden sind, ist es nicht üblich, mehrere Kanäle in einer einzigen evtx-Datei zu haben. (Das einzige Mal, dass wir dies gesehen haben, war, als jemand zwei verschiedene evtx-Dateien für das Projekt „sample-evtx“ künstlich zusammengeführt hat.) Wir können dies zu unserem Vorteil nutzen, indem wir zuerst das Feld Channel im ersten Datensatz jeder angegebenen .evtx Datei überprüfen gescannt werden. Wir prüfen auch, welche .yml -Regeln welche Kanäle verwenden, die im Feld Channel der Regel angegeben sind. Mit diesen beiden Listen laden wir nur Regeln, die Kanäle 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 macht keinen Sinn, andere Erkennungsregeln zu laden, zum Beispiel Regeln, die nur nach Ereignissen im Application usw. suchen. Beachten Sie, dass Kanalfelder (z. B. Channel: Security ) in den ursprünglichen Sigma-Regeln nicht explizit definiert sind. Für Sigma-Regeln werden Kanal- und Ereignis-ID-Felder implizit mit service und category unter logsource definiert. (Beispiel: service: security ) Beim Kuratieren von Sigma-Regeln im Hayabusa-Rules-Repository deabstrahieren wir das logsource Feld und definieren explizit die Kanal- und Ereignis-ID-Felder. Wie und warum wir das tun, erklären wir hier ausführlich.
Derzeit gibt es nur zwei Erkennungsregeln, für die kein Channel definiert ist und die alle .evtx Dateien scannen sollen: die folgenden:
Wenn Sie diese beiden Regeln verwenden und alle Regeln anhand geladener .evtx Dateien scannen möchten, müssen Sie die Option -A, --enable-all-rules in den Befehlen csv-timeline und json-timeline hinzufügen. In unseren Benchmarks führt die Regelfilterung in der Regel zu einer 20- bis 10-fachen Geschwindigkeitsverbesserung, je nachdem, welche Dateien gescannt werden, und verbraucht natürlich weniger Speicher.
Kanalfilterung wird auch beim Laden .evtx Dateien verwendet. Wenn Sie beispielsweise eine Regel angeben, die nach Ereignissen mit dem Kanal Security sucht, macht es keinen Sinn, .evtx Dateien zu laden, die nicht aus dem Security stammen. In unseren Benchmarks führt dies zu einem Geschwindigkeitsvorteil von etwa 10 % bei normalen Scans und einer Leistungssteigerung von bis zu 60 % und mehr beim Scannen mit einer einzigen Regel. Wenn Sie sicher sind, dass mehrere Kanäle in einer einzelnen .evtx Datei verwendet werden, beispielsweise wenn jemand ein Tool zum Zusammenführen mehrerer .evtx Dateien verwendet hat, deaktivieren Sie diese Filterung mit -a, --scan-all-evtx-files Option in den Befehlen csv-timeline und json-timeline .
Hinweis: Die Kanalfilterung funktioniert nur mit
.evtx-Dateien und Sie erhalten eine Fehlermeldung, wenn Sie versuchen, Ereignisprotokolle aus einer JSON-Datei mit-J, --json-inputzu laden und außerdem-Aoder-aanzugeben.
csv-timeline Befehl Der Befehl csv-timeline erstellt eine forensische Zeitleiste der Ereignisse im CSV-Format.
Usage: csv-timeline [OPTIONS]
Input:
-d, --directory Directory of multiple .evtx files
-f, --file File path to one .evtx file
-l, --live-analysis Analyze the local C:WindowsSystem32winevtLogs 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)
-s, --sort-events Sort events before saving the file. (warning: this uses much more memory!)
-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 Specify a custom rule directory or file (default: ./rules)
-c, --rules-config Specify custom rule config directory (default: ./rules/config)
--target-file-ext Specify additional evtx file extensions (ex: evtx_data)
-t, --threads Number of threads (default: optimal number for performance)
Filtering:
-E, --EID-filter Scan only common EIDs for faster speed (./rules/config/target_event_IDs.txt)
-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 Only load rules with a specific level (informational, low, medium, high, critical)
--exclude-category Do not load rules with specified logsource categories (ex: process_creation,pipe_created)
--exclude-computer Do not scan specified computer names (ex: ComputerA) (ex: ComputerA,ComputerB)
--exclude-eid Do not scan specific EIDs for faster speed (ex: 1) (ex: 1,4688)
--exclude-status Do not load rules according to status (ex: experimental) (ex: stable,test)
--exclude-tag Do not load rules with specific tags (ex: sysmon)
--include-category Only load rules with specified logsource categories (ex: process_creation,pipe_created)
--include-computer Scan only specified computer names (ex: ComputerA) (ex: ComputerA,ComputerB)
--include-eid Scan only specified EIDs for faster speed (ex: 1) (ex: 1,4688)
--include-status Only load rules with specific status (ex: experimental) (ex: stable,test)
--include-tag Only load rules with specific tags (ex: attack.execution,attack.discovery)
-m, --min-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)
--timeline-end End time of the event logs to load (ex: "2022-02-22 23:59:59 +09:00")
--timeline-offset Scan recent events based on an offset (ex: 1y, 3M, 30d, 24h, 30m)
--timeline-start Start time of the event logs to load (ex: "2020-02-22 00:00:00 +09:00")
Output:
-G, --GeoIP Add GeoIP (ASN, city, country) info to IP addresses
-H, --HTML-report Save Results Summary details to an HTML report (ex: results.html)
-M, --multiline Output event field information in multiple rows
-F, --no-field-data-mapping Disable field data mapping
--no-pwsh-field-extraction Disable field extraction of PowerShell classic logs
-o, --output Save the timeline in CSV format (ex: results.csv)
-p, --profile Specify output profile
-R, --remove-duplicate-data Duplicate field data will be replaced with "DUP"
-X, --remove-duplicate-detections Remove duplicate detections (default: disabled)
Display Settings:
--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)
Time Format:
--European-time Output timestamp in European time format (ex: 22-02-2022 22:00:00.123 +02:00)
--ISO-8601 Output timestamp in 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)
--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)
-U, --UTC Output time in UTC format (default: local time)
csv-timeline Befehlestandard aus: hayabusa.exe csv-timeline -f eventlog.evtx
hayabusa.exe csv-timeline -d .hayabusa-sample-evtx -p verbose
super-verbose Profil viel größer!): hayabusa.exe csv-timeline -d .hayabusa-sample-evtx -o results.csv -p super-verbose
Hinweis: Durch die Aktivierung des EID-Filters wird die Analyse in unseren Tests um etwa 10–15 % beschleunigt, es besteht jedoch die Möglichkeit, dass Warnungen übersehen werden.
hayabusa.exe csv-timeline -E -d .hayabusa-sample-evtx -o results.csv
-r .rules ausgeführt): hayabusa.exe csv-timeline -d .hayabusa-sample-evtx -r .ruleshayabusa -o results.csv -w
hayabusa.exe csv-timeline -d .hayabusa-sample-evtx -r .ruleshayabusabuiltin -o results.csv -w
hayabusa.exe csv-timeline -d .hayabusa-sample-evtx -r .ruleshayabusasysmon -o results.csv -w
hayabusa.exe csv-timeline -d .hayabusa-sample-evtx -r .rulessigma -o results.csv -w
status als deprecated markiert ist) und laute Regeln (diejenigen, deren Regel-ID in .rulesconfignoisy_rules.txt aufgeführt ist):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 ist es wahrscheinlich nicht erforderlich, veraltete Regeln zu aktivieren.
hayabusa.exe csv-timeline -d .hayabusa-sample-evtx --enable-noisy-rules --enable-deprecated-rules -o results.csv -w
hayabusa.exe csv-timeline -d .hayabusa-sample-evtx -r .ruleshayabusabuiltinSecurityLogonLogoffLogon -U -o results.csv -w
hayabusa.exe csv-timeline -l -m low
hayabusa.exe csv-timeline -d .hayabusa-sample-evtx -v
Laderegeln:
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 beim Scan:
[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.
hayabusa.exe csv-timeline -d ../hayabusa-sample-evtx --RFC-3339 -o timesketch-import.csv -p timesketch -U
-Q hinzu. Mit den kostenlosen GeoLite2-Geolocation-Daten können Sie GeoIP-Informationen (ASN-Organisation, Stadt und Land) zu SrcIP-Feldern (Quell-IP) und TgtIP-Feldern (Ziel-IP) hinzufügen.
Schritte:
.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 lauten.csv-timeline oder json-timeline die Option -G gefolgt vom Verzeichnis mit den MaxMind-Datenbanken hinzu. Bei Verwendung von csv-timeline werden zusätzlich die folgenden 6 Spalten ausgegeben: SrcASN , SrcCity , SrcCountry , TgtASN , TgtCity , TgtCountry .
Wenn json-timeline verwendet wird, werden dieselben SrcASN , SrcCity , SrcCountry , TgtASN , TgtCity und TgtCountry Felder zum Details Objekt hinzugefügt, jedoch nur, wenn sie Informationen enthalten.
Wenn SrcIP oder TgtIP localhost ist ( 127.0.0.1 , ::1 usw.), wird SrcASN oder TgtASN als Local ausgegeben.
Wenn SrcIP oder TgtIP eine private IP-Adresse ist ( 10.0.0.0/8 , fe80::/10 usw.), wird SrcASN oder TgtASN als Private ausgegeben.
Die Feldnamen, die Quell- und Ziel-IP-Adressen enthalten, die in den GeoIP-Datenbanken gesucht werden, sind in rules/config/geoip_field_mapping.yaml definiert. Sie können diese Liste bei Bedarf hinzufügen. In dieser Datei gibt es auch einen Filterabschnitt, in dem festgelegt wird, aus welchen Ereignissen IP -Adressinformationen extrahieren können.
MaxMind Geoip -Datenbanken werden alle 2 Wochen aktualisiert. Sie können das MaxMind geoipupdate -Tool hier installieren, um diese Datenbanken automatisch zu aktualisieren.
Schritte auf macOS:
brew install geoipupdate/usr/local/etc/GeoIP.conf : Geben Sie nach dem Anmelden auf der MaxMind -Website Ihre AccountID und LicenseKey ein. Stellen Sie sicher, dass die EditionIDs Linie sagt, EditionIDs GeoLite2-ASN GeoLite2-City GeoLite2-Country .geoipupdate aus.-G /usr/local/var/GeoIP hinzu, wenn Sie Geoip -Informationen hinzufügen möchten.Schritte unter Windows:
geoipupdate_4.10.0_windows_amd64.zip ) von der Seite "Releases" herunter.ProgramDataMaxMind/GeoIPUpdateGeoIP.conf : Geben Sie nach dem Anmelden auf der MaxMind -Website Ihre AccountID und LicenseKey , die Sie erstellen. Stellen Sie sicher, dass die EditionIDs Linie sagt, EditionIDs GeoLite2-ASN GeoLite2-City GeoLite2-Country .geoipupdate aus. csv-timeline Befehlskonfigurationsdateien ./rules/config/channel_abbreviations.txt : Zuordnungen von Kanalnamen und deren Abkürzungen.
./rules/config/default_details.txt : Die Konfigurationsdatei für welche Standardfeldinformationen ( %Details% Feld) sollte ausgegeben werden, wenn keine details: Zeile in einer Regel angegeben ist. Dies basiert auf Anbieternamen- und Ereignis -IDs.
./rules/config/eventkey_alias.txt : Diese Datei enthält die Zuordnungen von Shortnamen -Aliase für Felder und deren ursprüngliche längere Feldnamen.
Beispiel:
InstanceID,Event.UserData.UMDFHostDeviceArrivalBegin.InstanceId
IntegrityLevel,Event.EventData.IntegrityLevel
IpAddress,Event.EventData.IpAddress
Wenn hier ein Feld nicht definiert ist, prüft Hayabusa automatisch in Event.EventData für das Feld.
./rules/config/exclude_rules.txt : Diese Datei hat 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 überhaupt nicht verwendet werden kann. Wie bei Firewalls und IDSEs erfordert jedes Signaturbasis-Tool eine Stimmung, um Ihre Umgebung zu entsprechen, sodass Sie möglicherweise bestimmte Regeln dauerhaft oder vorübergehend ausschließen müssen. Sie können eine Regel-ID hinzufügen (Beispiel: 4fe151c2-ecf9-4fae-95ae-b88ec9c2fca6 ) TO ./rules/config/exclude_rules.txt , um eine Regel zu ignorieren, die Sie nicht benötigen oder nicht verwendet werden können.
./rules/config/noisy_rules.txt : Diese Datei Eine Liste von Regel-IDs, die standardmäßig deaktiviert sind, aber durch Aktivieren von lauten Regeln mit der -n, --enable-noisy-rules -Option aktiviert werden können. Diese Regeln sind normalerweise von Natur aus oder aufgrund falscher positiver Aspekte laut.
./rules/config/target_event_IDs.txt : Nur die in dieser Datei angegebenen Ereignis -IDs werden gescannt, wenn der EID -Filter aktiviert ist. Standardmäßig scannt Hayabusa alle Ereignisse. Wenn Sie jedoch die Leistung verbessern möchten, verwenden Sie bitte die Option -E, --EID-filter . Dies führt normalerweise zu einer Geschwindigkeitsverbesserung von 10 ~ 25%.
json-timeline Befehl Der Befehl json-timeline erstellt eine forensische Zeitleiste mit Ereignissen im JSON- oder JSONL-Format. Die Ausgabe an JSONL ist schneller und kleinerer Dateigröße als JSON. Wenn Sie also nur die Ergebnisse in ein anderes Tool wie den elastischen Stapel importieren möchten. JSON ist besser, wenn Sie die Ergebnisse manuell mit einem Texteditor analysieren möchten. Die CSV -Ausgabe ist gut zum Importieren kleinerer Zeitpläne (normalerweise weniger als 2 GB) in Tools wie LibreOffice oder Timeline Explorer. JSON eignet sich am besten für eine detailliertere Analyse von Daten (einschließlich großer Ergebnisdateien) mit Tools wie jq da die Details für die einfachere Analyse getrennt sind. (In der CSV -Ausgabe befinden sich alle Ereignisprotokollfelder in einer Spalte mit großen Details , die Daten sortieren usw. schwieriger.)
Usage: json-timeline [OPTIONS]
Input:
-d, --directory Directory of multiple .evtx files
-f, --file File path to one .evtx file
-l, --live-analysis Analyze the local C:WindowsSystem32winevtLogs 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)
-s, --sort-events Sort events before saving the file. (warning: this uses much more memory!)
-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 Specify a custom rule directory or file (default: ./rules)
-c, --rules-config Specify custom rule config directory (default: ./rules/config)
--target-file-ext Specify additional evtx file extensions (ex: evtx_data)
-t, --threads Number of threads (default: optimal number for performance)
Filtering:
-E, --EID-filter Scan only common EIDs for faster speed (./rules/config/target_event_IDs.txt)
-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 Only load rules with a specific level (informational, low, medium, high, critical)
--exclude-category Do not load rules with specified logsource categories (ex: process_creation,pipe_created)
--exclude-computer Do not scan specified computer names (ex: ComputerA) (ex: ComputerA,ComputerB)
--exclude-eid Do not scan specific EIDs for faster speed (ex: 1) (ex: 1,4688)
--exclude-status Do not load rules according to status (ex: experimental) (ex: stable,test)
--exclude-tag Do not load rules with specific tags (ex: sysmon)
--include-category Only load rules with specified logsource categories (ex: process_creation,pipe_created)
--include-computer Scan only specified computer names (ex: ComputerA) (ex: ComputerA,ComputerB)
--include-eid Scan only specified EIDs for faster speed (ex: 1) (ex: 1,4688)
--include-status Only load rules with specific status (ex: experimental) (ex: stable,test)
--include-tag Only load rules with specific tags (ex: attack.execution,attack.discovery)
-m, --min-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)
--timeline-end End time of the event logs to load (ex: "2022-02-22 23:59:59 +09:00")
--timeline-offset Scan recent events based on an offset (ex: 1y, 3M, 30d, 24h, 30m)
--timeline-start Start time of the event logs to load (ex: "2020-02-22 00:00:00 +09:00")
Output:
-G, --GeoIP Add GeoIP (ASN, city, country) info to IP addresses
-H, --HTML-report Save Results Summary details to an HTML report (ex: results.html)
-L, --JSONL-output Save the timeline in JSONL format (ex: -L -o results.jsonl)
-F, --no-field-data-mapping Disable field data mapping
--no-pwsh-field-extraction Disable field extraction of PowerShell classic logs
-o, --output Save the timeline in JSON format (ex: results.json)
-p, --profile Specify output profile
-R, --remove-duplicate-data Duplicate field data will be replaced with "DUP"
-X, --remove-duplicate-detections Remove duplicate detections (default: disabled)
Display Settings:
--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)
Time Format:
--European-time Output timestamp in European time format (ex: 22-02-2022 22:00:00.123 +02:00)
--ISO-8601 Output timestamp in 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)
--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)
-U, --UTC Output time in UTC format (default: local time)
json-timeline und Konfigurationsdateien Die Optionen und Konfigurationsdateien für json-timeline sind mit csv-timeline übereinstimmen, aber eine zusätzliche Option -L, --JSONL-output für die Ausgabe an das JSONL-Format.
level-tuning Mit dem Befehl level-tuning können Sie die Warnstufen für Regeln einstellen, entweder das Risikoniveau entsprechend Ihrer Umgebung erhöhen oder verringert.
Usage: level-tuning [OPTIONS]
Display Settings:
--no-color Disable color output
-q, --quiet Quiet mode: do not display the launch banner
General Options:
-f, --file Tune alert levels (default: ./rules/config/level_tuning.txt)
level-tuninghayabusa.exe level-tuninghayabusa.exe level-tuning -f my_level_tuning.txt level-tuning Die Autoren von Hayabusa und Sigma -Regel bestimmen das Risikoniveau der Warnung beim Schreiben ihrer Regeln. Das tatsächliche Risikoniveau kann jedoch je nach Umwelt unterschiedlich sein. Sie können die Risikostufe der Regeln einstellen, indem Sie sie zu ./rules/config/level_tuning.txt addieren und hayabusa.exe level-tuning ausführen, die die Ebene level in der Regeldatei aktualisiert. Bitte beachten Sie, dass die Regeldatei direkt aktualisiert wird.
WARNUNG: Jedes Mal, wenn Sie
update-rulesausführen, überschreiben die ursprüngliche Warnstufe alle Einstellungen, die Sie geändert haben, sodass Sie den Befehllevel-tuningnach jedem Ausführen vonupdate-rulesausführen müssen, wenn Sie die Levels ändern möchten.
./rules/config/level_tuning.txt Beispielzeile:
id,new_level
00000000-0000-0000-0000-000000000000,informational # sample level tuning line
In diesem Fall wird das Risikoniveau der Regel mit einer id informational 00000000-0000-0000-0000-000000000000 im Rules-Verzeichnis seine level umgeschrieben. Die möglichen Werte sind critical , high , medium , low und informational .
list-profiles Usage: list-profiles [OPTIONS]
Display Settings:
--no-color Disable color output
-q, --quiet Quiet mode: do not display the launch banner
set-default-profile Usage: set-default-profile [OPTIONS]
Display Settings:
--no-color Disable color output
-q, --quiet Quiet mode: do not display the launch banner
General Options:
-p, --profile Specify output profile
set-default-profileminimal ein: hayabusa.exe set-default-profile minimalsuper-verbose fest: hayabusa.exe set-default-profile super-verboseupdate-rules Der Befehl update-rules synchronisiert den rules mit dem Hayabusa Rules GitHub-Repository und aktualisiert die Regeln und Konfigurationsdateien.
Usage: update-rules [OPTIONS]
Display Settings:
--no-color Disable color output
-q, --quiet Quiet mode: do not display the launch banner
General Options:
-r, --rules Specify a custom rule directory or file (default: ./rules)
update-rules Normalerweise werden Sie dies nur ausführen: hayabusa.exe update-rules
Hayabusa verfügt über 5 vordefinierte Ausgabeprofile, die in config/profiles.yaml verwendet werden können. Yaml:
minimalstandard (Standard)verboseall-field-infoall-field-info-verbosesuper-verbosetimesketch-minimaltimesketch-verbose Sie können Ihre eigenen Profile problemlos anpassen oder hinzufügen, indem Sie diese Datei bearbeiten. Sie können das Standardprofil auch einfach mit set-default-profile --profile ändern. Verwenden Sie den Befehl list-profiles um die verfügbaren Profile und deren Feldinformationen anzuzeigen.
minimal %Timestamp%, %Computer%, %Channel%, %EventID%, %Level%, %RecordID%, %RuleTitle%, %Details%
standard %Timestamp%, %Computer%, %Channel%, %EventID%, %Level%, %RecordID%, %RuleTitle%, %Details%, %ExtraFieldInfo%
verbose Profils %Timestamp%, %Computer%, %Channel%, %EventID%, %Level%, %MitreTactics%, %MitreTags%, %OtherTags%, %RecordID%, %RuleTitle%, %Details%, %ExtraFieldInfo%, %RuleFile%, %EvtxFile%
all-field-info Profils Anstatt die minimalen details auszugeben, werden alle Feldinformationen in den Abschnitten EventData und UserData zusammen mit ihren ursprünglichen Feldnamen ausgegeben.
%Timestamp%, %Computer%, %Channel%, %EventID%, %Level%, %RecordID%, %RuleTitle%, %AllFieldInfo%, %RuleFile%, %EvtxFile%
all-field-info-verbose -Profilausgabe %Timestamp%, %Computer%, %Channel%, %EventID%, %Level%, %MitreTactics%, %MitreTags%, %OtherTags%, %RecordID%, %RuleTitle%, %AllFieldInfo%, %RuleFile%, %EvtxFile%
super-verbose -Profilausgabe %Timestamp%, %Computer%, %Channel%, %EventID%, %Level%, %RuleTitle%, %RuleAuthor%, %RuleModifiedDate%, %Status%, %RecordID%, %Details%, %ExtraFieldInfo%, %MitreTactics%, %MitreTags%, %OtherTags%, %Provider%, %RuleCreationDate%, %RuleFile%, %EvtxFile%
timesketch-minimal -ProfilausgabeAusgabe in ein Format, das mit dem Import in Timesketch kompatibel ist.
%Timestamp%, hayabusa, %RuleTitle%, %Computer%, %Channel%, %EventID%, %Level%, %MitreTactics%, %MitreTags%, %OtherTags%, %RecordID%, %Details%, %RuleFile%, %EvtxFile%
timesketch-verbose -Profilausgabe %Timestamp%, hayabusa, %RuleTitle%, %Computer%, %Channel%, %EventID%, %Level%, %MitreTactics%, %MitreTags%, %OtherTags%, %RecordID%, %Details%, %ExtraFieldInfo%, %RuleFile%, %EvtxFile%
Die folgenden Benchmarks wurden auf einem 2018 Lenovo P51 (Xeon 4 Core CPU / 64 GB RAM) mit 3 GB EVTX -Daten und 3891 -Regeln durchgeführt. (2023/06/01)
| Profil | Verarbeitungszeit | Ausgabedateisize | Zunahme der Dateigröße |
|---|---|---|---|
| minimal | 8 Minuten 50 Sekunden | 770 MB | -30% |
| Standard (Standard) | 9 Minuten 00 Sekunden | 1,1 GB | Keiner |
| ausführlich | 9 Minuten 10 Sekunden | 1,3 GB | +20 % |
| Allfeld-Info | 9 Minuten 3 Sekunden | 1,2 GB | +10% |
| Allfeldinfo-Verbose | 9 Minuten 10 Sekunden | 1,3 GB | +20 % |
| Super-Verbose | 9 Minuten 12 Sekunden | 1,5 GB | +35% |
Die folgenden Informationen können mit integrierten Ausgangsprofilen ausgegeben werden:
| Alias Name | Hayabusa -Ausgabeinformationen |
|---|---|
| %AllfieldInfo% | Alle Feldinformationen. |
| %Kanal% | Der Name des Protokolls. |
| %Computer% | Das Feld |
| %Details% | Das details in der YML -Erkennungsregel, aber nur Hayabusa -Regeln haben dieses Feld. Dieses Feld enthält zusätzliche Informationen über die Warnung oder das Ereignis und kann nützliche Daten aus den Feldern in Ereignisprotokollen extrahieren. Beispielsweise, Benutzernamen, Befehlszeileninformationen, Prozessinformationen usw., wenn ein Platzhalter auf ein Feld verweist, das nicht existiert oder eine falsche Alias -Zuordnung vorliegt, wird er als n/a ausgegeben (nicht verfügbar). Wenn das Feld details nicht angegeben ist (dh Sigma -Regeln), werden die in ./rules/config/default_details.txt definierten details zum Extrahieren von Feldern ausgegeben. Sie können weitere Standardmeldungen für details hinzufügen, indem Sie den Provider Name , EventID und details -Nachricht von Anbietern hinzufügen, die Sie in default_details.txt ausgeben möchten. Wenn kein details in einer Regel oder in default_details.txt definiert ist, werden alle Felder in die Spalte details ausgegeben. |
| %ExtrafieldInfo% | Drucken Sie die Feldinformationen aus, die nicht in %Details %ausgegeben wurden. |
| %EventId% | Das Feld |
| %Evtxfile% | Der EVTX -Dateiname, der den Alarm oder das Ereignis verursachte. |
| %Ebene% | Das level in der YML -Erkennungsregel. ( informational , low , medium , high , critical ) |
| %Mitretaktik% | Gehrung Att & CK -Taktik (Ex: Erstzugriff, seitliche Bewegung usw.). |
| %Mitetags% | MITRE ATT & CK -Gruppen -ID, Technik -ID und Software -ID. |
| %OtherTags% | Jedes Schlüsselwort im Feld tags in einer YML -Erkennungsregel, die nicht in MitreTactics oder MitreTags enthalten ist. |
| %Anbieter% | Das Name in |
| %Rekord% | Die Ereignisrekord -ID von |
| %RELEAUTHOR% | Das Feld author in der YML -Erkennungsregel. |
| %Sturlecreationdate% | Das date in der YML -Erkennungsregel. |
| %Regeldatei% | Der Dateiname der Erkennungsregel, die den Alarm oder das Ereignis generierte. |
| %RulemodifiedDate% | Das modified Feld in der YML -Erkennungsregel. |
| %Ruletitle% | Das title in der YML -Erkennungsregel. |
| %Status% | Das status in der YML -Erkennungsregel. |
| %Zeitstempel% | Standard ist YYYY-MM-DD HH:mm:ss.sss +hh:mm Format. --UTC in UTC ändern. |
Sie können diese zusätzlichen Aliase auch Ihrem Ausgabeprofil hinzufügen, wenn Sie sie benötigen:
| Alias Name | Hayabusa -Ausgabeinformationen |
|---|---|
| %RenderedMessage% | Das Feld |
| %REGELID% | Das id -Feld in der YML -Erkennungsregel. |
HINWEIS: Diese sind in keiner integrierten Profile enthalten, sodass Sie die Datei config/default_profile.yaml manuell bearbeiten und die folgenden Zeilen hinzufügen müssen:
Message: "%RenderedMessage%"
RuleID: "%RuleID%"
Sie können auch Ereignisschlüssel Aliase definieren, um andere Felder auszugeben.
Um Speicherplatz zu sparen, verwenden wir die folgenden Abkürzungen bei der Anzeige der level .
crit : criticalhigh : highmed : mediumlow : lowinfo : informational Um Platz zu sparen, verwenden wir die folgenden Abkürzungen bei der Anzeige von MITRE ATT & CK -Taktik -Tags. Sie können diese Abkürzungen frei in der Konfigurationsdatei ./config/mitre_tactics.txt bearbeiten.
Recon : AufklärungResDev : RessourcenentwicklungInitAccess : ErstzugriffExec : AusführungPersis : PersistenzPrivEsc : Privileg eskalationEvas : VerteidigungsausweisCredAccess : AnmeldeinformationszugriffDisc : EntdeckungLatMov : SeitenbewegungCollect : SammlungC2 : Befehl und KontrolleExfil : ExfiltrationImpact : Auswirkungen Um Platz zu sparen, verwenden wir die folgenden Abkürzungen beim Anzeigen von Kanal. Sie können diese Abkürzungen frei in der ./rules/config/channel_abbreviations.txt .
App : ApplicationAppLocker : Microsoft-Windows-AppLocker/*BitsCli : Microsoft-Windows-Bits-Client/OperationalCodeInteg : Microsoft-Windows-CodeIntegrity/OperationalDefender : Microsoft-Windows-Windows Defender/OperationalDHCP-Svr : Microsoft-Windows-DHCP-Server/OperationalDNS-Svr : DNS ServerDvrFmwk : Microsoft-Windows-DriverFrameworks-UserMode/OperationalExchange : MSExchange ManagementFirewall : Microsoft-Windows-Windows Firewall With Advanced Security/FirewallKeyMgtSvc : Key Management ServiceLDAP-Cli : Microsoft-Windows-LDAP-Client/DebugNTLM Microsoft-Windows-NTLM/OperationalOpenSSH : OpenSSH/OperationalPrintAdm : Microsoft-Windows-PrintService/AdminPrintOp : Microsoft-Windows-PrintService/OperationalPwSh : Microsoft-Windows-PowerShell/OperationalPwShClassic : Windows PowerShellRDP-Client : Microsoft-Windows-TerminalServices-RDPClient/OperationalSec : SecuritySecMitig : Microsoft-Windows-Security-Mitigations/*SmbCliSec : Microsoft-Windows-SmbClient/SecuritySvcBusCli : Microsoft-ServiceBus-ClientSys : SystemSysmon : Microsoft-Windows-Sysmon/OperationalTaskSch : Microsoft-Windows-TaskScheduler/OperationalWinRM : Microsoft-Windows-WinRM/OperationalWMI : Microsoft-Windows-WMI-Activity/Operational Die folgenden Abkürzungen werden in Regeln verwendet, um die Ausgabe so präzise wie möglich zu gestalten:
Acct -> KontoAddr -> AdresseAuth -> AuthentifizierungCli -> KundeChan -> KanalCmd -> BefehlCnt -> countComp -> ComputerConn -> Verbindung/verbundenCreds -> AnmeldeinformationenCrit -> kritischDisconn -> Trennung/getrenntDir -> VerzeichnisDrv -> TreiberDst -> ZielEID -> Ereignis -IDErr -> FehlerExec -> AusführungFW -> FirewallGrp -> GruppeImg -> BildInj -> InjektionKrb -> KerberosLID -> Anmelde -IDMed -> MediumNet -> NetzwerkObj -> ObjektOp -> Betrieb/BetriebProto -> ProtokollPW -> PasswortReconn -> WiederverbindungReq -> AnfrageRsp -> AntwortSess -> SitzungSig -> SignaturSusp -> misstrauischSrc -> QuelleSvc -> ServiceSvr -> ServerTemp -> vorübergehendTerm -> Kündigung/KündigungTkt -> TicketTgt -> ZielUnkwn -> UnbekanntUsr -> BenutzerPerm -> PermamentPkg -> PaketPriv -> privilegProc -> ProzessPID -> Prozess -IDPGUID -> Prozessguid (globale eindeutige ID)Ver -> Version Die Fortschrittsleiste funktioniert nur mit mehreren EVTX -Dateien. In Echtzeit wird die Anzahl und der Prozentsatz der EVTX -Dateien angezeigt, die es analysiert hat.
Die Warnungen werden in Farbe basierend auf der level ausgegeben. Sie können die Standardfarben in der Konfigurationsdatei unter ./config/level_color.txt im Format von level,(RGB 6-digit ColorHex) ändern. Wenn Sie die Farbausgabe deaktivieren möchten, können Sie eine Option --no-color verwenden.
Gesamtereignisse, die Anzahl der Ereignisse mit Hits, Datenreduzierungsmetriken, Gesamt- und eindeutige Erkennungen, stammt aus den meisten Erkennungen, Top -Computer mit Erkennungen und Top -Warnungen werden nach jedem Scan angezeigt.
Wenn Sie die Option -T, --visualize-timeline -Option hinzufügen, zeigt die Ereignisfrequenz -Timeline -Funktion eine Zeitleiste der Sparkline -Frequenz von erkannten Ereignissen an. Hinweis: Es muss mehr als 5 Ereignisse geben. Außerdem werden die Zeichen nicht korrekt in der Standardeingabeaufforderung oder der PowerShell -Eingabeaufforderung rendern. Verwenden Sie daher bitte ein Terminal wie Windows Terminal, ITM22 usw.
Die Hayabusa-Erkennungsregeln werden in einem sigma-ähnlichen YML-Format geschrieben und befinden sich im Ordner rules . Die Regeln finden Sie unter https://github.com/yamato-security/hayabusa-rules. Senden Sie also bitte alle Probleme und ziehen Sie Anfragen für Regeln anstelle des Haupt-Hayabusa-Repositorys an.
Bitte lesen Sie das Hayabusa-Rules-Repository Readme, um das Regelformat und das Erstellen von Regeln zu verstehen.
Alle Regeln aus dem Hayabusa-Rules-Repository sollten im Ordner rules platziert werden. Regeln der informational werden events angesehen, während alles mit einem low und höheren level als alerts gelten.
Die Hayabusa -Regelverzeichnisstruktur wird in 2 Verzeichnisse unterteilt:
builtin : Protokolle, die durch Windows-integrierte Funktionen erzeugt werden können.sysmon : Protokolle, die von Sysmon erzeugt werden.Die Regeln werden nach Protokolltypen (Beispiel: Sicherheit, System usw.) in Verzeichnisse unterteilt und im folgenden Format benannt:
Bitte überprüfen Sie die aktuellen Regeln als Vorlage beim Erstellen neuer oder zur Überprüfung der Erkennungslogik.
Hayabusa unterstützt die Sigma -Regeln nativ mit einer Ausnahme der internationalen Behandlung der logsource -Felder. Um Fehlalarme zu reduzieren, sollten die hier erklärten Sigma -Regeln durch unseren Caboror durchgeführt werden. Dadurch wird der richtige Channel und EventID hinzugefügt und Feldzuordnung für bestimmte Kategorien wie process_creation durchführt.
Fast alle Hayabusa -Regeln sind mit dem Sigma -Format kompatibel, sodass Sie sie genauso wie die Sigma -Regeln verwenden können, um in andere Siem -Formate zu konvertieren. Die Hayabusa -Regeln sind ausschließlich für die Windows -Event -Protokollanalyse konzipiert und haben die folgenden Vorteile:
details , um zusätzliche Informationen anzuzeigen, die nur aus den nützlichen Feldern im Protokoll entnommen wurden.|equalsfield und |endswithfield .Nach unserem Kenntnisstand bietet Hayabusa die größte native Unterstützung für Sigma Regeln für jedes Open -Source -Windows -Event -Protokollanalyse -Tool.
Um böswillige Aktivitäten auf Windows -Maschinen ordnungsgemäß zu erkennen, müssen Sie die Standardprotokolleinstellungen verbessern. Wir haben ein separates Projekt erstellt, um zu dokumentieren, welche Protokolleinstellungen aktiviert werden müssen, sowie Skripte, um die richtigen Einstellungen unter https://github.com/yamato-security/enablewindowsLogSettings automatisch zu aktivieren.
Wir empfehlen auch die folgenden Websites, um Anleitungen zu erhalten:
Um die forensischen Beweise zu erstellen und mit der höchsten Genauigkeit zu erkennen, müssen Sie Sysmon installieren. Wir empfehlen die folgenden Websites und Konfigurationsdateien:
Wir würden jede Form des Beitrags lieben. Pull -Anfragen, Regelerstellung und Beispiele EVTX -Protokolle sind die besten, aber Feature -Anfragen, die Benachrichtigung über Fehler usw. sind ebenfalls sehr willkommen.
Zumindest, wenn Sie unser Tool mögen, geben Sie uns bitte einen Stern auf Github und zeigen Sie Ihre Unterstützung!
Bitte senden Sie alle Fehler, die Sie hier finden. Dieses Projekt ist derzeit aktiv gepflegt und wir freuen uns, alle gemeldeten Fehler zu beheben.
Wenn Sie Probleme (falsch positive Ergebnisse, Fehler usw.) mit Hayabusa-Regeln finden, melden Sie sie bitte der Seite mit Hayabusa-Rules Github hier.
Wenn Sie Probleme (falsch positive Ergebnisse, Fehler usw.) mit Sigma -Regeln finden, melden Sie sie bitte der vorgelagerten Sigmahq Github -Ausgabenseite hier.
Hayabusa wird unter AGPLV3 veröffentlicht und alle Regeln werden unter der Erkennungsregel -Lizenz (DRL) 1.1 veröffentlicht.
Hayabusa verwendet Geolith2 -Daten, die von MaxMind erstellt wurden und unter https://www.maxmind.com verfügbar sind.
Sie können die neuesten Nachrichten über Hayabusa, Regel Updates, andere Yamato -Sicherheitstools usw. erhalten, indem Sie uns auf Twitter unter @securityyamato folgen.
