Hayabusa
v2.18.0 ?
Hayabusa est un générateur de chronologie d'investigation rapide de journaux d'événements Windows et un outil de chasse aux menaces créé par le groupe Yamato Security au Japon. Hayabusa signifie « faucon pèlerin » en japonais et a été choisi car les faucons pèlerins sont les animaux les plus rapides du monde, excellents pour la chasse et faciles à dresser. Il est écrit en Rust et supporte le multi-threading afin d'être le plus rapide possible. Nous avons fourni un outil pour convertir les règles Sigma au format de règles Hayabusa. Les règles de détection Hayabusa compatibles Sigma sont écrites en YML afin d'être aussi facilement personnalisables et extensibles que possible. Hayabusa peut être exécuté soit sur un seul système en cours d'exécution pour une analyse en direct, en collectant les journaux d'un ou de plusieurs systèmes pour une analyse hors ligne, ou en exécutant l'artefact Hayabusa avec Velociraptor pour la recherche de menaces et la réponse aux incidents à l'échelle de l'entreprise. La sortie sera consolidée dans une seule chronologie CSV pour une analyse facile dans LibreOffice, Timeline Explorer, Elastic Stack, Timesketch, etc...
evtx .-T )-H )-M )computer-metricscomputer-metricscomputer-metricseid-metricseid-metricseid-metricseid-metricslogon-summarylogon-summarylogon-summarypivot-keywords-listpivot-keywords-listpivot-keywords-listsearchsearchsearch les fichiers de configuration de la commandecsv-timelinecsv-timelinecsv-timelinejson-timelinejson-timeline et fichiers de configurationlevel-tuninglevel-tuninglevel-tuninglist-profilesset-default-profileset-default-profileupdate-rulesupdate-rulesminimalstandardverboseall-field-infoall-field-info-verbosesuper-verbosetimesketch-minimaltimesketch-verboseHayabusa dispose actuellement de plus de 4 000 règles Sigma et de plus de 170 règles de détection intégrées Hayabusa, d'autres règles étant ajoutées régulièrement. Il peut être utilisé gratuitement pour la chasse proactive aux menaces à l'échelle de l'entreprise ainsi que pour le DFIR (Digital Forensics and Incident Response) avec l'artefact Hayabusa de Velociraptor. En combinant ces deux outils open source, vous pouvez essentiellement reproduire rétroactivement un SIEM lorsqu'il n'y a pas de configuration SIEM dans l'environnement. Vous pouvez apprendre comment procéder en regardant la procédure pas à pas du Velociraptor d'Eric Capuano ici.
L'analyse des journaux d'événements Windows est traditionnellement un processus très long et fastidieux car les journaux d'événements Windows sont 1) dans un format de données difficile à analyser et 2) la majorité des données sont du bruit et ne sont pas utiles pour les enquêtes. L'objectif de Hayabusa est d'extraire uniquement les données utiles et de les présenter dans un format aussi concis que possible, facile à lire et utilisable non seulement par des analystes professionnellement formés, mais aussi par tout administrateur système Windows. Hayabusa espère permettre aux analystes d'effectuer 80 % de leur travail en 20 % du temps par rapport à l'analyse traditionnelle des journaux d'événements Windows.
-T ) 
-H ) 
-M ) 
Vous pouvez apprendre à analyser les chronologies CSV dans Excel et Timeline Explorer ici.
Vous pouvez apprendre à importer des fichiers CSV dans Elastic Stack ici.
Vous pouvez apprendre comment importer des fichiers CSV dans Timesketch ici.
Vous pouvez apprendre à analyser les résultats au format JSON avec jq ici.
|equalsfield et |endswithfield .0xc0000234 -> ACCOUNT LOCKED )Veuillez télécharger la dernière version stable de Hayabusa avec les binaires compilés ou compiler le code source à partir de la page Releases.
Nous fournissons des binaires pour les architectures suivantes :
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 )Pour une raison quelconque, le binaire Linux ARM MUSL ne fonctionne pas correctement, nous ne fournissons donc pas ce binaire. C'est hors de notre contrôle, nous prévoyons donc de le fournir à l'avenir lorsqu'il sera réparé.
Depuis la version 2.18.0, nous fournissons des packages Windows spéciaux qui utilisent des règles codées XOR fournies dans un seul fichier ainsi que tous les fichiers de configuration combinés dans un seul fichier (hébergé dans le référentiel hayabusa-encoded-rules). Téléchargez simplement les packages zip avec live-response dans le nom. Les fichiers zip ne comprennent que trois fichiers : le binaire Hayabusa, le fichier de règles codées XOR et le fichier de configuration. Le but de ces packages de réponse en direct est lors de l'exécution de Hayabusa sur les points de terminaison clients, nous voulons nous assurer que les analyseurs antivirus comme Windows Defender ne donnent pas de faux positifs sur les fichiers de règles .yml . Nous souhaitons également minimiser la quantité de fichiers écrits sur le système afin que les artefacts médico-légaux tels que le USN Journal ne soient pas écrasés.
Vous pouvez git clone le référentiel avec la commande suivante et compiler le binaire à partir du code source :
Attention : la branche principale du référentiel est destinée à des fins de développement. Vous pourrez donc peut-être accéder à de nouvelles fonctionnalités qui ne sont pas encore officiellement publiées. Cependant, il peut y avoir des bugs, alors considérez-le comme instable.
git clone https://github.com/Yamato-Security/hayabusa.git --recursiveRemarque : Si vous oubliez d'utiliser l'option --recursive, le dossier
rules, qui est géré en tant que sous-module git, ne sera pas cloné.
Vous pouvez synchroniser le dossier rules et obtenir les dernières règles Hayabusa avec git pull --recurse-submodules ou utiliser la commande suivante :
hayabusa.exe update-rules Si la mise à jour échoue, vous devrez peut-être renommer le dossier rules et réessayer.
Attention : lors de la mise à jour, les règles et les fichiers de configuration du dossier
rulessont remplacés par les dernières règles et fichiers de configuration du référentiel hayabusa-rules. Toutes les modifications que vous apportez aux fichiers existants seront écrasées. Nous vous recommandons donc de faire des sauvegardes de tous les fichiers que vous modifiez avant la mise à jour. Si vous effectuez un réglage de niveau aveclevel-tuning, veuillez réajuster vos fichiers de règles après chaque mise à jour. Si vous ajoutez de nouvelles règles dans le dossierrules, elles ne seront ni écrasées ni supprimées lors de la mise à jour.
Si Rust est installé, vous pouvez compiler à partir des sources avec la commande suivante :
Remarque : Pour compiler, vous avez généralement besoin de la dernière version de Rust.
cargo build --releaseVous pouvez télécharger la dernière version instable depuis la branche principale ou la dernière version stable depuis la page Releases.
Assurez-vous de mettre régulièrement à jour Rust avec :
rustup update stable Le binaire compilé sera affiché dans le dossier ./target/release .
Vous pouvez mettre à jour vers les dernières caisses Rust avant de compiler :
cargo updateS'il vous plaît laissez-nous savoir si quelque chose se casse après la mise à jour.
Vous pouvez créer des binaires 32 bits sur des systèmes Windows 64 bits avec les éléments suivants :
rustup install stable-i686-pc-windows-msvc
rustup target add i686-pc-windows-msvc
rustup run stable-i686-pc-windows-msvc cargo build --releaseAvertissement : assurez-vous d'exécuter
rustup install stable-i686-pc-windows-msvcchaque fois qu'il existe une nouvelle version stable de Rust, carrustup update stablene mettra pas à jour le compilateur pour la compilation croisée et vous pourriez recevoir des erreurs de construction.
Si vous recevez des erreurs de compilation concernant openssl, vous devrez installer Homebrew puis installer les packages suivants :
brew install pkg-config
brew install opensslSi vous recevez des erreurs de compilation concernant openssl, vous devrez installer le package suivant.
Distributions basées sur Ubuntu :
sudo apt install libssl-devDistributions basées sur Fedora :
sudo yum install openssl-develSur un système d'exploitation Linux, installez d'abord la cible.
rustup install stable-x86_64-unknown-linux-musl
rustup target add x86_64-unknown-linux-muslCompiler avec :
cargo build --release --target=x86_64-unknown-linux-muslAvertissement : assurez-vous d'exécuter
rustup install stable-x86_64-unknown-linux-muslchaque fois qu'il existe une nouvelle version stable de Rust, carrustup update stablene mettra pas à jour le compilateur pour la compilation croisée et vous pourriez recevoir des erreurs de construction.
Le binaire MUSL sera créé dans le répertoire ./target/x86_64-unknown-linux-musl/release/ . Les binaires MUSL sont environ 15 % plus lents que les binaires GNU, cependant, ils sont plus portables entre différentes versions et distributions de Linux.
Vous pouvez recevoir une alerte de produits antivirus ou EDR lorsque vous essayez d'exécuter hayabusa ou même simplement lors du téléchargement des règles .yml , car il y aura des mots-clés tels que mimikatz et des commandes PowerShell suspectes dans la signature de détection. Il s'agit de faux positifs et vous devrez donc configurer des exclusions dans vos produits de sécurité pour permettre à Hayabusa de s'exécuter. Si vous vous inquiétez des logiciels malveillants ou des attaques de la chaîne d'approvisionnement, veuillez vérifier le code source d'hayabusa et compiler les binaires vous-même.
Vous pouvez rencontrer un temps d'exécution lent, en particulier lors de la première exécution après un redémarrage, en raison de la protection en temps réel de Windows Defender. Vous pouvez éviter cela en désactivant temporairement la protection en temps réel ou en ajoutant une exclusion au répertoire d'exécution hayabusa. (Veuillez prendre en considération les risques de sécurité avant de procéder ainsi.)
Dans une invite de commande/PowerShell ou un terminal Windows, exécutez simplement le binaire Windows 32 bits ou 64 bits approprié.
Lorsque vous utilisez l'invite de commande ou PowerShell intégrée dans Windows, vous pouvez recevoir une erreur indiquant que Hayabusa n'a pas pu charger de fichiers .evtx s'il y a un espace dans le chemin de votre fichier ou de votre répertoire. Afin de charger correctement les fichiers .evtx, assurez-vous de procéder comme suit :
Vous devez d'abord rendre le binaire exécutable.
chmod +x ./hayabusaEnsuite, exécutez-le depuis le répertoire racine de Hayabusa :
./hayabusaDepuis Terminal ou iTerm2, vous devez d’abord rendre le binaire exécutable.
chmod +x ./hayabusaEnsuite, essayez de l'exécuter depuis le répertoire racine de Hayabusa :
./hayabusaSur la dernière version de macOS, vous pouvez recevoir l'erreur de sécurité suivante lorsque vous essayez de l'exécuter :
Cliquez sur "Annuler", puis dans les Préférences Système, ouvrez "Sécurité et confidentialité" et depuis l'onglet Général, cliquez sur "Autoriser quand même".
Après cela, essayez de l'exécuter à nouveau.
./hayabusaL'avertissement suivant apparaîtra, veuillez donc cliquer sur "Ouvrir".
Vous devriez maintenant pouvoir exécuter hayabusa.
computer-metrics : imprime le nombre d'événements en fonction des noms d'ordinateurs.eid-metrics : imprime le nombre et le pourcentage d'événements en fonction de l'ID d'événement.logon-summary : Imprime un résumé des événements de connexion.pivot-keywords-list : Imprimez une liste de mots-clés suspects sur lesquels pivoter.search : recherchez tous les événements par mot-clé(s) ou expressions régulières csv-timeline : Enregistrez la chronologie au format CSV.json-timeline : Enregistrez la chronologie au format JSON/JSONL.level-tuning : Ajustez de manière personnalisée le level des alertes.list-profiles : Répertorie les profils de sortie disponibles.set-default-profile : modifiez le profil par défaut.update-rules : synchronisez les règles avec les dernières règles dans le référentiel GitHub hayabusa-rules. help : Imprimer ce message ou l'aide de la ou des sous-commande(s) donnée(s)list-contributors : Imprimer la liste des contributeurscomputer-metrics Vous pouvez utiliser la commande computer-metrics pour vérifier le nombre d'événements en fonction de chaque ordinateur défini dans le champ Computer pour séparer les événements en fonction de leur ordinateur d'origine. Windows 11 utilisera parfois des noms Computer complètement différents lors de l'enregistrement dans les journaux d'événements. De plus, Windows 10 enregistrera parfois le nom Computer en minuscules. Cette commande n'utilise aucune règle de détection et analysera donc tous les événements. C'est une bonne commande à exécuter pour voir rapidement quels ordinateurs ont le plus de journaux. Avec ces informations, vous pouvez ensuite utiliser les options --include-computer ou --exclude-computer lors de la création de vos chronologies pour rendre votre génération de chronologie plus efficace en créant plusieurs chronologies en fonction de l'ordinateur ou en excluant des événements de certains ordinateurs.
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-metricshayabusa.exe computer-metrics -d ../logshayabusa.exe computer-metrics -d ../logs -o computer-metrics.csv computer-metrics 
eid-metrics Vous pouvez utiliser la commande eid-metrics pour imprimer le nombre total et le pourcentage d'ID d'événement (champ
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-metricshayabusa.exe eid-metrics -f Security.evtxhayabusa.exe eid-metrics -d ../logshayabusa.exe eid-metrics -f Security.evtx -o eid-metrics.csv eid-metrics Le canal, les ID d'événement et les titres des événements sont définis dans rules/config/channel_eid_info.txt .
Exemple:
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 
logon-summary Vous pouvez utiliser la commande logon-summary pour afficher un résumé des informations de connexion (noms d'utilisateur de connexion et nombre de connexions réussies et échouées). Vous pouvez afficher les informations de connexion pour un fichier evtx avec -f ou plusieurs fichiers evtx avec l'option -d .
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 
pivot-keywords-list Vous pouvez utiliser la commande pivot-keywords-list pour créer une liste de mots-clés pivot uniques afin d'identifier rapidement les utilisateurs anormaux, les noms d'hôte, les processus, etc... ainsi que de corréler les événements.
Important : par défaut, hayabusa renverra les résultats de tous les événements (informatifs et supérieurs), nous vous recommandons donc fortement de combiner la commande pivot-keywords-list avec l'option -m, --min-level . Par exemple, commencez par créer uniquement des mots-clés à partir d'alertes critical avec -m critical , puis continuez avec -m high , -m medium , etc... Il y aura très probablement des mots-clés courants dans vos résultats qui correspondront à de nombreux événements normaux, Ainsi, après avoir vérifié manuellement les résultats et créé une liste de mots-clés uniques dans un seul fichier, vous pouvez ensuite créer une chronologie réduite des activités suspectes avec une commande telle que grep -f keywords.txt timeline.csv .
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 , etc...) : hayabusa.exe pivot-keywords-list -d ../logs -m critical -o keywords`
pivot-keywords-list Vous pouvez personnaliser les mots-clés que vous souhaitez rechercher en modifiant ./rules/config/pivot_keywords.txt . Cette page est le paramètre par défaut.
Le format est KeywordName.FieldName . Par exemple, lors de la création de la liste des Users , hayabusa répertoriera toutes les valeurs dans les champs SubjectUserName , TargetUserName et User .
search La commande search vous permettra de rechercher par mot-clé tous les événements. (Pas seulement les résultats de détection d'Hayabusa.) Ceci est utile pour déterminer s'il existe des preuves d'événements qui ne sont pas détectés par Hayabusa.
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 le mot-clé mimikatz : hayabusa.exe search -d ../hayabusa-sample-evtx -k "mimikatz"
Remarque : Le mot-clé correspondra si
mimikatzest trouvé n'importe où dans les données. Ce n'est pas une correspondance exacte.
../hayabusa-sample-evtx les mots-clés mimikatz ou kali : hayabusa.exe search -d ../hayabusa-sample-evtx -k "mimikatz" -k "kali"
../hayabusa-sample-evtx le mot-clé mimikatz et ignorez la casse : hayabusa.exe search -d ../hayabusa-sample-evtx -k "mimikatz" -i
../hayabusa-sample-evtx les adresses IP à l'aide d'expressions régulières : hayabusa.exe search -d ../hayabusa-sample-evtx -r "(?:[0-9]{1,3}.){3}[0-9]{1,3}"
../hayabusa-sample-evtx et affichez tous les événements où le champ WorkstationName est kali : hayabusa.exe search -d ../hayabusa-sample-evtx -r ".*" -F WorkstationName:"kali"
Remarque :
.*est l'expression régulière qui doit correspondre à chaque événement.
search les fichiers de configuration de la commande ./rules/config/channel_abbreviations.txt : Mappages des noms de canaux et de leurs abréviations.
Les commandes csv-timeline et json-timeline disposent désormais d'un assistant d'analyse activé par défaut. Ceci est destiné à aider les utilisateurs à choisir facilement les règles de détection qu'ils souhaitent activer en fonction de leurs besoins et préférences. Les ensembles de règles de détection à charger sont basés sur les listes officielles du projet Sigma. Les détails sont expliqués dans cet article de blog. Vous pouvez facilement désactiver l'assistant et utiliser Hayabusa de manière traditionnelle en ajoutant l'option -w, --no-wizard .
L'ensemble de règles core active les règles qui ont un statut test ou stable et un niveau high ou critical . Il s’agit de règles de haute qualité, très fiables et pertinentes, qui ne devraient pas produire de nombreux faux positifs. Le statut de la règle est test ou stable , ce qui signifie qu'aucun faux positif n'a été signalé pendant plus de 6 mois. Les règles correspondent aux techniques des attaquants, aux activités suspectes génériques ou aux comportements malveillants. Cela revient à utiliser les options --exclude-status deprecated,unsupported,experimental --min-level high .
L’ensemble de règles core+ active les règles qui ont un statut de test ou stable et un niveau medium ou supérieur. les règles medium nécessitent le plus souvent des ajustements supplémentaires, car certaines applications, le comportement légitime des utilisateurs ou les scripts d'une organisation peuvent correspondre. Cela revient à utiliser les options --exclude-status deprecated,unsupported,experimental --min-level medium .
L'ensemble de règles core++ active les règles qui ont un statut experimental , test ou stable et un niveau medium ou supérieur. Ces règles sont à la pointe de la technologie. Ils sont validés par rapport aux fichiers evtx de base disponibles sur le projet SigmaHQ et examinés par plusieurs ingénieurs de détection. A part ça, ils n’ont pratiquement pas été testés au début. Utilisez-les si vous souhaitez pouvoir détecter les menaces le plus tôt possible au prix de la gestion d'un seuil plus élevé de faux positifs. Cela revient à utiliser les options --exclude-status deprecated,unsupported --min-level medium .
L’ensemble de règles Emerging Threats (ET) active les règles qui ont une balise detection.emerging_threats . Ces règles ciblent des menaces spécifiques et sont particulièrement utiles pour les menaces actuelles pour lesquelles peu d’informations sont encore disponibles. Ces règles ne devraient pas comporter beaucoup de faux positifs, mais leur pertinence diminuera avec le temps. Lorsque ces règles ne sont pas activées, cela revient à utiliser l'option --exclude-tag detection.emerging_threats . Lors de l'exécution traditionnelle de Hayabusa sans l'assistant, ces règles seront incluses par défaut.
Le jeu de règles Threat Hunting (TH) active les règles qui ont une balise de detection.threat_hunting . Ces règles peuvent détecter des activités malveillantes inconnues, mais elles comportent généralement davantage de faux positifs. Lorsque ces règles ne sont pas activées, cela revient à utiliser l'option --exclude-tag detection.threat_hunting . Lors de l'exécution traditionnelle de Hayabusa sans l'assistant, ces règles seront incluses par défaut.
Depuis Hayabusa v2.16.0, nous activons un filtre basé sur le canal lors du chargement des fichiers .evtx et des règles .yml . Le but est de rendre la numérisation aussi efficace que possible en ne chargeant que ce qui est nécessaire. Bien qu'il soit possible d'avoir plusieurs fournisseurs dans un seul journal d'événements, il n'est pas courant d'avoir plusieurs canaux dans un seul fichier evtx. (La seule fois où nous avons vu cela, c'est lorsque quelqu'un a fusionné artificiellement deux fichiers evtx différents pour le projet sample-evtx.) Nous pouvons utiliser cela à notre avantage en vérifiant d'abord le champ Channel dans le premier enregistrement de chaque fichier .evtx spécifié. à scanner. Nous vérifions également quelles règles .yml utilisent quels canaux spécifiés dans le champ Channel de la règle. Avec ces deux listes, nous chargeons uniquement les règles qui utilisent les canaux réellement présents dans les fichiers .evtx .
Ainsi, par exemple, si un utilisateur souhaite analyser Security.evtx , seules les règles qui spécifient Channel: Security seront utilisées. Cela ne sert à rien de charger d'autres règles de détection, par exemple des règles qui recherchent uniquement des événements dans le journal Application , etc... Notez que les champs de canal (Ex : Channel: Security ) ne sont pas explicitement définis dans les règles Sigma d'origine. Pour les règles Sigma, les champs d'ID de canal et d'événement sont implicitement définis avec les champs service et category sous logsource . (Ex : service: security ) Lors de la conservation des règles Sigma dans le référentiel hayabusa-rules, nous désabstrayons le champ logsource et définissons explicitement les champs de canal et d'ID d'événement. Nous expliquons ici comment et pourquoi nous procédons cela en profondeur.
Actuellement, il n'existe que deux règles de détection pour lesquelles aucun Channel n'est défini et qui sont destinées à analyser tous les fichiers .evtx :
Si vous souhaitez utiliser ces deux règles et analyser toutes les règles par rapport aux fichiers .evtx chargés, vous devrez ajouter l'option -A, --enable-all-rules dans les commandes csv-timeline et json-timeline . Dans nos tests, le filtrage des règles améliore généralement la vitesse de 20 % à 10 x en fonction des fichiers analysés et utilise bien sûr moins de mémoire.
Le filtrage des canaux est également utilisé lors du chargement de fichiers .evtx . Par exemple, si vous spécifiez une règle qui recherche des événements avec un canal Security , cela ne sert à rien de charger des fichiers .evtx qui ne proviennent pas du journal Security . Dans nos tests, cela donne un gain de vitesse d'environ 10 % avec des analyses normales et jusqu'à 60 % d'augmentation des performances lors d'une analyse avec une seule règle. Si vous êtes sûr que plusieurs canaux sont utilisés dans un seul fichier .evtx , par exemple quelqu'un a utilisé un outil pour fusionner plusieurs fichiers .evtx ensemble, alors vous désactivez ce filtrage avec -a, --scan-all-evtx-files option dans les commandes csv-timeline et json-timeline .
Remarque : le filtrage des canaux ne fonctionne qu'avec les fichiers
.evtxet vous recevrez une erreur si vous essayez de charger les journaux d'événements à partir d'un fichier JSON avec-J, --json-inputet spécifiez également-Aou-a.
csv-timeline La commande csv-timeline créera une chronologie médico-légale des événements au format CSV.
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-timelinestandard par défaut : hayabusa.exe csv-timeline -f eventlog.evtx
hayabusa.exe csv-timeline -d .hayabusa-sample-evtx -p verbose
super-verbose !) : hayabusa.exe csv-timeline -d .hayabusa-sample-evtx -o results.csv -p super-verbose
Remarque : L'activation du filtre EID accélérera l'analyse d'environ 10 à 15 % dans nos tests, mais il existe une possibilité de manquer des alertes.
hayabusa.exe csv-timeline -E -d .hayabusa-sample-evtx -o results.csv
-r .rules ) : 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 est marqué comme deprecated ) et les règles bruyantes (celles dont l'ID de règle est répertorié dans .rulesconfignoisy_rules.txt ) :Remarque : Depuis peu, les règles obsolètes se trouvent désormais dans un répertoire distinct du référentiel sigma et ne sont donc plus incluses par défaut dans Hayabusa. Par conséquent, vous n’avez probablement pas besoin d’activer les règles obsolètes.
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
Règles de chargement :
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
Erreurs lors de l'analyse :
[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 . Vous pouvez ajouter des informations GeoIP (organisation ASN, ville et pays) aux champs SrcIP (IP source) et TgtIP (IP cible) avec les données de géolocalisation GeoLite2 gratuites.
Mesures:
.mmdb depuis la page de téléchargement et enregistrez-les dans un répertoire. Les noms de fichiers doivent être appelés GeoLite2-ASN.mmdb , GeoLite2-City.mmdb et GeoLite2-Country.mmdb .csv-timeline ou json-timeline , ajoutez l'option -G suivie du répertoire contenant les bases de données MaxMind. Lorsque csv-timeline est utilisé, les 6 colonnes suivantes seront en outre affichées : SrcASN , SrcCity , SrcCountry , TgtASN , TgtCity , TgtCountry .
Lorsque json-timeline est utilisé, les mêmes champs SrcASN , SrcCity , SrcCountry , TgtASN , TgtCity , TgtCountry seront ajoutés à l'objet Details , mais uniquement s'ils contiennent des informations.
Lorsque SrcIP ou TgtIP est localhost ( 127.0.0.1 , ::1 , etc...), SrcASN ou TgtASN sera affiché comme Local .
Lorsque SrcIP ou TgtIP est une adresse IP privée ( 10.0.0.0/8 , fe80::/10 , etc...), SrcASN ou TgtASN sera affiché comme Private .
Les noms de champs contenant les adresses IP source et cible recherchées dans les bases de données GeoIP sont définis dans rules/config/geoip_field_mapping.yaml . Vous pouvez ajouter à cette liste si nécessaire. Il existe également une section de filtre dans ce fichier qui détermine les événements à laquelle extraire les informations d'adresse IP.
Les bases de données Maxmind GEOIP sont mises à jour toutes les 2 semaines. Vous pouvez installer l'outil Maxmind geoipupdate ici afin de mettre à jour automatiquement ces bases de données.
Étapes sur macOS:
brew install geoipupdate/usr/local/etc/GeoIP.conf : Mettez votre AccountID et LicenseKey que vous créez après vous être connecté au site Web MaxMind. Assurez-vous que la ligne EditionIDs indique EditionIDs GeoLite2-ASN GeoLite2-City GeoLite2-Country .geoipupdate .-G /usr/local/var/GeoIP lorsque vous souhaitez ajouter des informations GEOIP.Étapes sur les fenêtres:
geoipupdate_4.10.0_windows_amd64.zip ) de la page des versions.ProgramDataMaxMind/GeoIPUpdateGeoIP.conf : mettez votre AccountID et LicenseKey vous créez après vous être connecté au site Web Maxmind. Assurez-vous que la ligne EditionIDs indique EditionIDs GeoLite2-ASN GeoLite2-City GeoLite2-Country .geoipupdate . csv-timeline ./rules/config/channel_abbreviations.txt : mappings des noms de canaux et leurs abréviations.
./rules/config/default_details.txt : Le fichier de configuration pour les informations de champ par défaut ( %Details% champ) ne doit être sorti si aucun details: la ligne n'est spécifiée dans une règle. Ceci est basé sur le nom du fournisseur et les ID d'événement.
./rules/config/eventkey_alias.txt : Ce fichier a les mappages des alias de nom court pour les champs et leurs noms de champ plus longs d'origine.
Exemple:
InstanceID,Event.UserData.UMDFHostDeviceArrivalBegin.InstanceId
IntegrityLevel,Event.EventData.IntegrityLevel
IpAddress,Event.EventData.IpAddress
Si un champ n'est pas défini ici, Hayabusa vérifiera automatiquement sous Event.EventData pour le champ.
./rules/config/exclude_rules.txt : Ce fichier a une liste des ID de règle qui seront exclus de l'utilisation. Habituellement, c'est parce qu'une règle a remplacé une autre ou que la règle ne peut pas être utilisée en premier lieu. Comme les pare-feu et les identifiants, tout outil basé sur la signature nécessitera un réglage pour s'adapter à votre environnement, vous devrez peut-être exclure définitivement ou temporairement certaines règles. Vous pouvez ajouter un ID de règle (exemple: 4fe151c2-ecf9-4fae-95ae-b88ec9c2fca6 ) à ./rules/config/exclude_rules.txt afin d'ignorer toute règle dont vous n'avez pas besoin ou ne pouvez pas être utilisée.
./rules/config/noisy_rules.txt : Ce fichier une liste des ID de règle qui sont désactivés par défaut mais peuvent être activés en activant les règles bruyantes avec l'option -n, --enable-noisy-rules . Ces règles sont généralement bruyantes par nature ou en raison de faux positifs.
./rules/config/target_event_IDs.txt : seuls les ID d'événement spécifiés dans ce fichier seront analysés si le filtre EID est activé. Par défaut, Hayabusa analysera tous les événements, mais si vous souhaitez améliorer les performances, veuillez utiliser l'option -E, --EID-filter . Cela se traduit généralement par une amélioration de 10 à 25% de vitesse.
json-timeline La commande json-timeline créera une chronologie médico-légale des événements au format JSON ou JSONL. La sortie vers JSONL sera plus rapide et plus petite de la taille du fichier que JSON, donc vous allez simplement importer les résultats dans un autre outil comme Elastic Stack. JSON est mieux si vous allez analyser manuellement les résultats avec un éditeur de texte. La sortie CSV est bonne pour importer des délais plus petits (généralement moins de 2 Go) dans des outils tels que LibreOffice ou Explorer Timeline. JSON est le meilleur pour une analyse plus détaillée des données (y compris de grands fichiers de résultats) avec des outils comme jq car les champs Details sont séparés pour une analyse plus facile. (Dans la sortie CSV, tous les champs de journal des événements se trouvent dans une colonne Details importante, ce qui réalise le tri des données, etc ... plus difficile.)
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 et fichiers de configuration Les options et les fichiers de configuration pour json-timeline sont les mêmes que csv-timeline mais une option supplémentaire -L, --JSONL-output pour la sortie au format JSONL.
level-tuning La commande level-tuning vous permettra de régler les niveaux d'alerte pour les règles, soit augmenter ou diminuer le niveau de risque en fonction de votre environnement.
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 Les auteurs de règles de Hayabusa et Sigma détermineront le niveau de risque de l'alerte lors de la rédaction de leurs règles. Cependant, le niveau de risque réel peut différer en fonction de l'environnement. Vous pouvez régler le niveau de risque des règles en les ajoutant à ./rules/config/level_tuning.txt et en exécutant hayabusa.exe level-tuning qui mettra à jour la ligne level dans le fichier de règles. Veuillez noter que le fichier de règle sera mis à jour directement.
AVERTISSEMENT: Chaque fois que vous exécutez
update-rules, le niveau d'alerte d'origine écrasera tous les paramètres que vous avez changés, vous devrez donc exécuter la commandelevel-tuningaprès chaque fois que vous exécutezupdate-rulessi vous souhaitez modifier les niveaux.
./rules/config/level_tuning.txt Ligne d'échantillon:
id,new_level
00000000-0000-0000-0000-000000000000,informational # sample level tuning line
Dans ce cas, le niveau de risque de la règle avec un id de 00000000-0000-0000-0000-000000000000 dans le répertoire des règles aura son level réécrit à informational . Les niveaux possibles à fixer sont critical , high , medium , low et 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 : hayabusa.exe set-default-profile minimalsuper-verbose : hayabusa.exe set-default-profile super-verboseupdate-rules La commande update-rules synchronisera le dossier rules avec le référentiel GitHub Règles Hayabusa, mise à jour des règles et des fichiers de configuration.
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 Vous allez normalement exécuter ceci: hayabusa.exe update-rules
Hayabusa a 5 profils de sortie prédéfinis à utiliser dans config/profiles.yaml :
minimalstandard (par défaut)verboseall-field-infoall-field-info-verbosesuper-verbosetimesketch-minimaltimesketch-verbose Vous pouvez facilement personnaliser ou ajouter vos propres profils en modifiant ce fichier. Vous pouvez également modifier facilement le profil par défaut avec set-default-profile --profile . Utilisez la commande list-profiles pour afficher les profils disponibles et leurs informations sur le terrain.
minimal %Timestamp%, %Computer%, %Channel%, %EventID%, %Level%, %RecordID%, %RuleTitle%, %Details%
standard %Timestamp%, %Computer%, %Channel%, %EventID%, %Level%, %RecordID%, %RuleTitle%, %Details%, %ExtraFieldInfo%
verbose %Timestamp%, %Computer%, %Channel%, %EventID%, %Level%, %MitreTactics%, %MitreTags%, %OtherTags%, %RecordID%, %RuleTitle%, %Details%, %ExtraFieldInfo%, %RuleFile%, %EvtxFile%
all-field-info Au lieu de diffuser les informations minimales details , toutes les informations sur le terrain dans les sections EventData et UserData seront publiées avec leurs noms de champ d'origine.
%Timestamp%, %Computer%, %Channel%, %EventID%, %Level%, %RecordID%, %RuleTitle%, %AllFieldInfo%, %RuleFile%, %EvtxFile%
all-field-info-verbose %Timestamp%, %Computer%, %Channel%, %EventID%, %Level%, %MitreTactics%, %MitreTags%, %OtherTags%, %RecordID%, %RuleTitle%, %AllFieldInfo%, %RuleFile%, %EvtxFile%
super-verbose %Timestamp%, %Computer%, %Channel%, %EventID%, %Level%, %RuleTitle%, %RuleAuthor%, %RuleModifiedDate%, %Status%, %RecordID%, %Details%, %ExtraFieldInfo%, %MitreTactics%, %MitreTags%, %OtherTags%, %Provider%, %RuleCreationDate%, %RuleFile%, %EvtxFile%
timesketch-minimalSortie dans un format compatible avec l'importation dans Timesketch.
%Timestamp%, hayabusa, %RuleTitle%, %Computer%, %Channel%, %EventID%, %Level%, %MitreTactics%, %MitreTags%, %OtherTags%, %RecordID%, %Details%, %RuleFile%, %EvtxFile%
timesketch-verbose %Timestamp%, hayabusa, %RuleTitle%, %Computer%, %Channel%, %EventID%, %Level%, %MitreTactics%, %MitreTags%, %OtherTags%, %RecordID%, %Details%, %ExtraFieldInfo%, %RuleFile%, %EvtxFile%
Les repères suivants ont été réalisés sur un Lenovo P51 2018 (CPU de base Xeon 4/64 Go de RAM) avec 3 Go de données EVTX et 3891 règles activées. (2023/06/01)
| Profil | Temps de traitement | Sortie des fichiers | Augmentation de la taille des fichiers |
|---|---|---|---|
| minimal | 8 minutes 50 secondes | 770 Mo | -30% |
| Standard (par défaut) | 9 minutes 00 secondes | 1,1 Go | Aucun |
| verbeux | 9 minutes 10 secondes | 1,3 Go | +20% |
| en tout-terrain | 9 minutes 3 secondes | 1,2 Go | +10% |
| tout-terrain verbal | 9 minutes 10 secondes | 1,3 Go | +20% |
| super-verbeux | 9 minutes 12 secondes | 1,5 Go | + 35% |
Les informations suivantes peuvent être publiées avec des profils de sortie intégrés:
| Nom d'alias | Informations sur la sortie de Hayabusa |
|---|---|
| % Allfieldinfo% | Toutes les informations sur le terrain. |
| %Canal% | Le nom du journal. |
| %Ordinateur% | Le champ |
| %Détails% | Le champ details dans la règle de détection YML, cependant, seules les règles de Hayabusa ont ce champ. Ce champ offre des informations supplémentaires sur l'alerte ou l'événement et peut extraire des données utiles des champs dans les journaux d'événements. Par exemple, noms d'utilisateur, informations sur la ligne de commande, informations sur le processus, etc ... Lorsqu'un espace réservé pointe vers un champ qui n'existe pas ou qu'il existe un mappage d'alias incorrect, il sera sorti en n/a (non disponible). Si le champ details n'est pas spécifié (c.-à-d. Règles Sigma), les détails details par défaut pour extraire les champs définis dans ./rules/config/default_details.txt seront publiés. Vous pouvez ajouter plus de messages details par défaut en ajoutant le Provider Name , EventID et details que vous souhaitez publier dans default_details.txt . Lorsqu'aucun champ details n'est défini dans une règle ni dans default_details.txt , tous les champs seront sortis dans la colonne details . |
| % Extrafieldinfo% | Imprimez les informations sur le terrain qui n'ont pas été publiées en% de détails%. |
| % EventID% | Le champ |
| % Evtxfile% | Le nom de fichier EVTX qui a provoqué l'alerte ou l'événement. |
| %Niveau% | Le champ level dans la règle de détection YML. ( informational , low , medium , high , critical ) |
| % Mitretactique% | Tactiques d'attr & ck mitre (ex: accès initial, mouvement latéral, etc ...). |
| % Mitretags% | ID de groupe MITER ATT & CK, ID de technique et ID logiciel. |
| % Autre Tags% | Tout mot-clé dans le champ tags dans une règle de détection YML qui n'est pas inclus dans MitreTactics ou MitreTags . |
| %Fournisseur% | L'attribut Name dans le champ |
| % De disques% | L'ID d'enregistrement de l'événement à partir du champ |
| % De règlement% | Le champ author dans la règle de détection YML. |
| % RuleCreationDate% | Le champ date dans la règle de détection YML. |
| % RuleFile% | Le nom de fichier de la règle de détection qui a généré l'alerte ou l'événement. |
| % RuleModifiedDate% | Le champ modified dans la règle de détection YML. |
| % De réglementation | Le champ title de la règle de détection YML. |
| %Statut% | Le champ status dans la règle de détection YML. |
| % Horodat% | La valeur par défaut est YYYY-MM-DD HH:mm:ss.sss +hh:mm FORMAT. --UTC . |
Vous pouvez également ajouter ces alias supplémentaires à votre profil de sortie si vous en avez besoin:
| Nom d'alias | Informations sur la sortie de Hayabusa |
|---|---|
| % Rendu de rendu% | Le champ |
| % Ruleid% | Le champ id dans la règle de détection YML. |
Remarque: Ceux-ci ne sont inclus dans aucun profil intégré, vous devrez donc modifier manuellement le fichier config/default_profile.yaml et ajouter les lignes suivantes:
Message: "%RenderedMessage%"
RuleID: "%RuleID%"
Vous pouvez également définir les alias de clés de l'événement pour produire d'autres champs.
Afin d'économiser de l'espace, nous utilisons les abrévations suivantes lors de l'affichage du level d'alerte.
crit : criticalhigh : highmed : mediumlow : lowinfo : informational Afin d'économiser de l'espace, nous utilisons les abréviations suivantes lors de l'affichage des balises tactiques d'attr & ck. Vous pouvez éditer librement ces abréviations dans le fichier de configuration ./config/mitre_tactics.txt .
Recon : ReconnaissanceResDev : développement des ressourcesInitAccess : Accès initialExec : exécutionPersis : persévérancePrivEsc : Escalade des privilègesEvas : Évasion de la défenseCredAccess : accès aux informations d'identificationDisc : découverteLatMov : mouvement latéralCollect : collectionC2 : commande et contrôleExfil : exfiltrationImpact : impact Afin d'économiser de l'espace, nous utilisons les abréviations suivantes lors de l'affichage du canal. Vous pouvez éditer librement ces abréviations dans le fichier de configuration ./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 : pare- 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 Les abréviations suivantes sont utilisées dans les règles afin de rendre la sortie aussi concise que possible:
Acct -> compteAddr -> AdresseAuth -> AuthentificationCli -> ClientChan -> canalCmd -> CommandeCnt -> CountComp -> ordinateurConn -> connexion / connectéCreds ->Crit -> critiqueDisconn -> déconnexion / déconnectéDir -> répertoireDrv -> ConducteurDst -> DestinationEID -> ID d'événementErr -> ErreurExec -> exécutionFW -> pare-feuGrp -> GroupeImg -> ImageInjKrb -> kerberosLID -> ID de connexionMed -> MediumNet -> réseauObj -> objetOp -> opérationnel / opérationProto -> protocolePW -> Mot de passeReconn -> reconnexionReq -> demandeRsp -> RéponseSess -> SessionSig -> signatureSuspSrc -> sourceSvc -> ServiceSvr -> serveurTemp -> temporaireTerm -> résiliation / terminéTkt -> TICKETTgt -> TargetUnkwn -> inconnuUsr -> utilisateurPerm -> permanmentPkg -> packagePriv -> privilègeProc -> processusPID -> ID de processusPGUID -> Process Guid (Global Unique ID)Ver -> version La barre de progrès ne fonctionnera qu'avec plusieurs fichiers EVTX. Il affichera en temps réel le nombre et le pourcentage de fichiers EVTX qu'il a terminé l'analyse.
Les alertes seront publiées en couleur en fonction du level d'alerte. Vous pouvez modifier les couleurs par défaut dans le fichier de configuration à ./config/level_color.txt dans le format de level,(RGB 6-digit ColorHex) . Si vous souhaitez désactiver la sortie des couleurs, vous pouvez utiliser l'option --no-color .
Événements totaux, le nombre d'événements avec des hits, les mesures de réduction des données, les détections totales et uniques, les dates avec le plus de détections, les principaux ordinateurs avec des détections et les alertes supérieures sont affichées après chaque analyse.
Si vous ajoutez l'option -T, --visualize-timeline , la fonctionnalité de chronologie de la fréquence des événements affiche un calendrier de fréquence de ligne d'étincelle des événements détectés. Remarque: il doit y avoir plus de 5 événements. De plus, les caractères ne seront pas correctement rendues sur l'invite de commande par défaut ou l'invite PowerShell, veuillez donc utiliser un terminal comme Windows Terminal, Iterm2, etc ...
Les règles de détection de Hayabusa sont écrites dans un format YML de type Sigma et sont situées dans le dossier rules . Les règles sont hébergées sur https://github.com/yamato-security/hayabusa---LIVEZ donc envoyer des problèmes et d'extraire les demandes de règles là-bas au lieu du principal référentiel Hayabusa.
Veuillez lire le ReadMe du référentiel Hayabusa-Rules pour comprendre le format de règles et comment créer des règles.
Toutes les règles du référentiel Hayabusa-Rules doivent être placées dans le dossier rules . Les règles de niveau informational sont considérées comme events , tandis que tout ce qui avec un level de low et de plus élevé est considéré comme alerts .
La structure du répertoire des règles de Hayabusa est séparée en 2 répertoires:
builtin : journaux qui peuvent être générés par la fonctionnalité intégrée Windows.sysmon : Journaux générés par Sysmon.Les règles sont en outre séparées en répertoires par type de journal (exemple: sécurité, système, etc ...) et sont nommés dans le format suivant:
Veuillez consulter les règles actuelles à utiliser comme modèle pour en créer de nouvelles ou pour vérifier la logique de détection.
Hayabusa prend en charge les règles Sigma nativement à une seule exception de la gestion des champs logsource en interne. Afin de réduire les faux positifs, les règles Sigma devraient être exécutées par notre convertisseur expliqué ici. Cela ajoutera le Channel et EventID appropriés, et effectuera un mappage de champ pour certaines catégories comme process_creation .
Presque toutes les règles de Hayabusa sont compatibles avec le format Sigma afin que vous puissiez les utiliser comme les règles Sigma pour convertir en d'autres formats SIEM. Les règles de Hayabusa sont conçues uniquement pour l'analyse du journal des événements Windows et ont les avantages suivants:
details supplémentaires pour afficher des informations supplémentaires tirées uniquement des champs utiles du journal.|equalsfield et |endswithfield .À notre connaissance, Hayabusa fournit la plus grande prise en charge native pour les règles Sigma de tout outil d'analyse du journal des événements Windows open source.
Afin de détecter correctement l'activité malveillante sur les machines Windows, vous devrez améliorer les paramètres du journal par défaut. Nous avons créé un projet séparé pour documenter les paramètres du journal à activer ainsi que les scripts pour activer automatiquement les paramètres appropriés à https://github.com/yamato-security/enablewindowslogsettings.
Nous recommandons également les sites suivants pour obtenir des conseils:
Pour créer les preuves les plus médico-légales et détecter avec la plus grande précision, vous devez installer Sysmon. Nous recommandons les sites et fichiers de configuration suivants:
Nous aimerions toute forme de contribution. Les demandes de traction, la création de règles et les exemples de journaux EVTX sont les meilleures, mais les demandes de fonctionnalités, nous informer des bogues, etc ... sont également les bienvenus.
Au moins, si vous aimez notre outil, veuillez nous donner une étoile sur GitHub et montrer votre support!
Veuillez soumettre tous les bogues que vous trouvez ici. Ce projet est actuellement activement maintenu et nous sommes heureux de corriger tous les bogues signalés.
Si vous trouvez des problèmes (faux positifs, bugs, etc ...) avec des règles Hayabusa, veuillez les signaler à la page Hayabusa-Rules Github Ici.
Si vous trouvez des problèmes (faux positifs, bogues, etc ...) avec des règles Sigma, veuillez les signaler à la page des problèmes de GitHub Sigmahq en amont ici.
Hayabusa est libéré en vertu de l'AGPLV3 et toutes les règles sont publiées en vertu de la licence de règle de détection (DRL) 1.1.
Hayabusa utilise des données Geolite2 créées par MaxMind, disponibles sur https://www.maxmind.com.
Vous pouvez recevoir les dernières nouvelles sur Hayabusa, les mises à jour de règles, d'autres outils de sécurité Yamato, etc ... en nous suivant sur Twitter à @securityyamato.
