hayabusa
v2.18.0 ?
Hayabusa es un generador de línea de tiempo forense rápido de registro de eventos de Windows y una herramienta de búsqueda de amenazas creada por el grupo Yamato Security en Japón. Hayabusa significa "halcón peregrino" en japonés y fue elegido porque los halcones peregrinos son el animal más rápido del mundo, excelentes para la caza y altamente entrenables. Está escrito en Rust y admite subprocesos múltiples para ser lo más rápido posible. Hemos proporcionado una herramienta para convertir las reglas de Sigma al formato de reglas de Hayabusa. Las reglas de detección de Hayabusa compatibles con Sigma están escritas en YML para que sean lo más fácilmente personalizables y extensibles posible. Hayabusa se puede ejecutar en sistemas en ejecución únicos para análisis en vivo, recopilando registros de uno o varios sistemas para análisis fuera de línea, o ejecutando el artefacto Hayabusa con Velociraptor para la búsqueda de amenazas y respuesta a incidentes en toda la empresa. El resultado se consolidará en una única línea de tiempo CSV para facilitar el análisis en 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-listsearchsearchsearchcsv-timelinecsv-timelinecsv-timelinejson-timelinejson-timeline y archivos de configuraciónlevel-tuninglevel-tuninglevel-tuninglist-profilesset-default-profileset-default-profileupdate-rulesupdate-rulesminimalstandardverboseall-field-infoall-field-info-verbosesuper-verbosetimesketch-minimaltimesketch-verboseActualmente, Hayabusa tiene más de 4000 reglas Sigma y más de 170 reglas de detección integradas de Hayabusa y se agregan más reglas periódicamente. Se puede utilizar para la búsqueda proactiva de amenazas en toda la empresa, así como para DFIR (Digital Forensics and Incident Response) de forma gratuita con el artefacto Hayabusa de Velociraptor. Al combinar estas dos herramientas de código abierto, esencialmente puede reproducir un SIEM de forma retroactiva cuando no hay una configuración de SIEM en el entorno. Puede aprender cómo hacer esto viendo el tutorial sobre Velociraptor de Eric Capuano aquí.
El análisis del registro de eventos de Windows ha sido tradicionalmente un proceso muy largo y tedioso porque los registros de eventos de Windows están 1) en un formato de datos que es difícil de analizar y 2) la mayoría de los datos son ruido y no son útiles para las investigaciones. El objetivo de Hayabusa es extraer sólo datos útiles y presentarlos en un formato lo más conciso posible y fácil de leer que sea utilizable no sólo por analistas capacitados profesionalmente sino también por cualquier administrador de sistemas Windows. Hayabusa espera permitir a los analistas realizar el 80% de su trabajo en el 20% del tiempo en comparación con el análisis tradicional de registros de eventos de Windows.
-T ) 
-H ) 
-M ) 
Puede aprender a analizar líneas de tiempo CSV en Excel y Timeline Explorer aquí.
Puede aprender cómo importar archivos CSV al Elastic Stack aquí.
Puede aprender cómo importar archivos CSV a Timesketch aquí.
Puede aprender cómo analizar resultados con formato JSON con jq aquí.
|equalsfield y |endswithfield .0xc0000234 -> ACCOUNT LOCKED )Descargue la última versión estable de Hayabusa con binarios compilados o compile el código fuente desde la página de Lanzamientos.
Proporcionamos binarios para las siguientes arquitecturas:
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 )Por alguna razón, el binario ARM MUSL de Linux no se ejecuta correctamente, por lo que no proporcionamos ese binario. Está fuera de nuestro control, por lo que planeamos brindarlo en el futuro cuando se solucione.
A partir de v2.18.0, proporcionamos paquetes especiales de Windows que utilizan reglas codificadas con XOR proporcionadas en un solo archivo, así como todos los archivos de configuración combinados en un solo archivo (alojado en el repositorio de reglas codificadas de hayabusa). Simplemente descargue los paquetes zip con live-response en el nombre. Los archivos zip solo incluyen tres archivos: el binario Hayabusa, el archivo de reglas codificado en XOR y el archivo de configuración. El propósito de estos paquetes de respuesta en vivo es que, cuando ejecutamos Hayabusa en los puntos finales del cliente, queremos asegurarnos de que los escáneres antivirus como Windows Defender no den falsos positivos en los archivos de reglas .yml . Además, queremos minimizar la cantidad de archivos que se escriben en el sistema para que los artefactos forenses como el USN Journal no se sobrescriban.
Puedes git clone el repositorio con el siguiente comando y compilar el binario desde el código fuente:
Advertencia: La rama principal del repositorio es para fines de desarrollo, por lo que es posible que pueda acceder a nuevas funciones que aún no se han lanzado oficialmente; sin embargo, puede haber errores, así que considérelo inestable.
git clone https://github.com/Yamato-Security/hayabusa.git --recursiveNota: Si olvida utilizar la opción --recursive, la carpeta
rules, que se administra como un submódulo de git, no se clonará.
Puede sincronizar la carpeta rules y obtener las últimas reglas de Hayabusa con git pull --recurse-submodules o usar el siguiente comando:
hayabusa.exe update-rules Si la actualización falla, es posible que deba cambiar el nombre de la carpeta rules e intentarlo nuevamente.
Precaución: Al actualizar, las reglas y los archivos de configuración en la carpeta
rulesse reemplazan con las reglas y archivos de configuración más recientes en el repositorio hayabusa-rules. Cualquier cambio que realice en los archivos existentes se sobrescribirá, por lo que le recomendamos que haga copias de seguridad de cualquier archivo que edite antes de actualizar. Si está realizando un ajuste de nivel conlevel-tuning, vuelva a ajustar sus archivos de reglas después de cada actualización. Si agrega nuevas reglas dentro de la carpetarules, no se sobrescribirán ni eliminarán durante la actualización.
Si tiene Rust instalado, puede compilar desde el código fuente con el siguiente comando:
Nota: Para compilar, normalmente necesitas la última versión de Rust.
cargo build --releasePuede descargar la última versión inestable desde la rama principal o la última versión estable desde la página de Lanzamientos.
Asegúrese de actualizar Rust periódicamente con:
rustup update stable El binario compilado se generará en la carpeta ./target/release .
Puede actualizar a las últimas cajas de Rust antes de compilar:
cargo updateHáganos saber si algo se rompe después de actualizar.
Puede crear archivos binarios de 32 bits en sistemas Windows de 64 bits con lo siguiente:
rustup install stable-i686-pc-windows-msvc
rustup target add i686-pc-windows-msvc
rustup run stable-i686-pc-windows-msvc cargo build --releaseAdvertencia: asegúrese de ejecutar
rustup install stable-i686-pc-windows-msvcsiempre que haya una nueva versión estable de Rust, ya querustup update stableno actualizará el compilador para la compilación cruzada y puede recibir errores de compilación.
Si recibe errores de compilación sobre openssl, deberá instalar Homebrew y luego instalar los siguientes paquetes:
brew install pkg-config
brew install opensslSi recibe errores de compilación sobre openssl, deberá instalar el siguiente paquete.
Distribuciones basadas en Ubuntu:
sudo apt install libssl-devDistribuciones basadas en Fedora:
sudo yum install openssl-develEn un sistema operativo Linux, primero instale el destino.
rustup install stable-x86_64-unknown-linux-musl
rustup target add x86_64-unknown-linux-muslCompilar con:
cargo build --release --target=x86_64-unknown-linux-muslAdvertencia: asegúrese de ejecutar
rustup install stable-x86_64-unknown-linux-muslsiempre que haya una nueva versión estable de Rust, ya querustup update stableno actualizará el compilador para la compilación cruzada y puede recibir errores de compilación.
El binario MUSL se creará en el directorio ./target/x86_64-unknown-linux-musl/release/ . Los binarios MUSL son aproximadamente un 15% más lentos que los binarios GNU; sin embargo, son más portátiles en diferentes versiones y distribuciones de Linux.
Es posible que reciba una alerta de productos antivirus o EDR cuando intente ejecutar hayabusa o incluso simplemente cuando descargue las reglas .yml , ya que habrá palabras clave como mimikatz y comandos sospechosos de PowerShell en la firma de detección. Estos son falsos positivos, por lo que deberá configurar exclusiones en sus productos de seguridad para permitir que hayabusa se ejecute. Si le preocupa el malware o los ataques a la cadena de suministro, verifique el código fuente de hayabusa y compile los binarios usted mismo.
Es posible que experimente un tiempo de ejecución lento, especialmente en la primera ejecución después de reiniciar, debido a la protección en tiempo real de Windows Defender. Puede evitar esto desactivando temporalmente la protección en tiempo real o agregando una exclusión al directorio de ejecución de hayabusa. (Tenga en cuenta los riesgos de seguridad antes de realizar esto).
En un símbolo del sistema/PowerShell o en una terminal de Windows, simplemente ejecute el binario de Windows apropiado de 32 o 64 bits.
Al utilizar el comando integrado o el símbolo de PowerShell en Windows, es posible que reciba un error indicando que Hayabusa no pudo cargar ningún archivo .evtx si hay un espacio en la ruta de su archivo o directorio. Para cargar los archivos .evtx correctamente, asegúrese de hacer lo siguiente:
Primero necesitas hacer que el binario sea ejecutable.
chmod +x ./hayabusaLuego ejecútelo desde el directorio raíz de Hayabusa:
./hayabusaDesde Terminal o iTerm2, primero debe hacer que el binario sea ejecutable.
chmod +x ./hayabusaLuego, intenta ejecutarlo desde el directorio raíz de Hayabusa:
./hayabusaEn la última versión de macOS, es posible que reciba el siguiente error de seguridad cuando intente ejecutarlo:
Haga clic en "Cancelar" y luego desde Preferencias del Sistema, abra "Seguridad y Privacidad" y desde la pestaña General, haga clic en "Permitir de todos modos".
Después de eso, intenta ejecutarlo nuevamente.
./hayabusaAparecerá la siguiente advertencia, así que haga clic en "Abrir".
Ahora deberías poder ejecutar hayabusa.
computer-metrics : imprime el número de eventos según los nombres de las computadoras.eid-metrics : imprime el número y porcentaje de eventos según el ID del evento.logon-summary : imprime un resumen de los eventos de inicio de sesión.pivot-keywords-list : imprime una lista de palabras clave sospechosas sobre las que girar.search : busca todos los eventos por palabra clave o expresiones regulares csv-timeline : guarda la línea de tiempo en formato CSV.json-timeline : guarda la línea de tiempo en formato JSON/JSONL.level-tuning : ajuste personalizado del level de las alertas.list-profiles : enumera los perfiles de salida disponibles.set-default-profile : cambia el perfil predeterminado.update-rules : sincroniza las reglas con las reglas más recientes en el repositorio de GitHub de hayabusa-rules. help : imprime este mensaje o la ayuda de los subcomandos proporcionados.list-contributors : imprime la lista de contribuyentescomputer-metrics Puede utilizar el comando computer-metrics para comprobar cuántos eventos hay según cada computadora definida en el campo Computer para separar eventos según su computadora original. Windows 11 a veces utilizará nombres Computer completamente diferentes al guardar en registros de eventos. Además, Windows 10 a veces registrará el nombre Computer en minúsculas. Este comando no utiliza ninguna regla de detección, por lo que analizará todos los eventos. Este es un buen comando para ejecutar para ver rápidamente qué computadoras tienen la mayor cantidad de registros. Con esta información, puede usar las opciones --include-computer o --exclude-computer al crear sus líneas de tiempo para hacer que su generación de líneas de tiempo sea más eficiente al crear múltiples líneas de tiempo según la computadora o excluir eventos de ciertas computadoras.
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 Puede utilizar el comando eid-metrics para imprimir el número total y el porcentaje de ID de eventos (campo
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 El canal, los ID de eventos y los títulos de los eventos se definen en rules/config/channel_eid_info.txt .
Ejemplo:
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 Puede utilizar el comando logon-summary para generar un resumen de la información de inicio de sesión (nombres de usuario de inicio de sesión y recuento de inicios de sesión exitosos y fallidos). Puede mostrar la información de inicio de sesión para un archivo evtx con -f o varios archivos evtx con la opción -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 Puede utilizar el comando pivot-keywords-list para crear una lista de palabras clave dinámicas únicas para identificar rápidamente usuarios, nombres de host, procesos, etc. anormales, así como correlacionar eventos.
Importante: de forma predeterminada, hayabusa devolverá resultados de todos los eventos (informativos y superiores), por lo que recomendamos combinar el comando pivot-keywords-list con la opción -m, --min-level . Por ejemplo, comience creando únicamente palabras clave a partir de alertas critical con -m critical y luego continúe con -m high , -m medium , etc... Lo más probable es que haya palabras clave comunes en sus resultados que coincidan en muchos eventos normales. Entonces, después de verificar manualmente los resultados y crear una lista de palabras clave únicas en un solo archivo, puede crear una línea de tiempo reducida de actividad sospechosa con un comando como 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 Puede personalizar las palabras clave que desea buscar editando ./rules/config/pivot_keywords.txt . Esta página es la configuración predeterminada.
El formato es KeywordName.FieldName . Por ejemplo, al crear la lista de Users , hayabusa enumerará todos los valores en los campos SubjectUserName , TargetUserName y User .
search El comando search le permitirá buscar palabras clave en todos los eventos. (No solo los resultados de detección de Hayabusa). Esto es útil para determinar si hay alguna evidencia en eventos que no son detectados por 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 la palabra clave mimikatz : hayabusa.exe search -d ../hayabusa-sample-evtx -k "mimikatz"
Nota: La palabra clave coincidirá si se encuentra
mimikatzen cualquier parte de los datos. No es una coincidencia exacta.
../hayabusa-sample-evtx las palabras clave mimikatz o kali : hayabusa.exe search -d ../hayabusa-sample-evtx -k "mimikatz" -k "kali"
../hayabusa-sample-evtx la palabra clave mimikatz e ignore mayúsculas y minúsculas: hayabusa.exe search -d ../hayabusa-sample-evtx -k "mimikatz" -i
../hayabusa-sample-evtx utilizando expresiones regulares: hayabusa.exe search -d ../hayabusa-sample-evtx -r "(?:[0-9]{1,3}.){3}[0-9]{1,3}"
../hayabusa-sample-evtx y muestre todos los eventos donde el campo WorkstationName es kali : hayabusa.exe search -d ../hayabusa-sample-evtx -r ".*" -F WorkstationName:"kali"
Nota:
.*es la expresión regular que debe coincidir con cada evento.
search ./rules/config/channel_abbreviations.txt : Asignaciones de nombres de canales y sus abreviaturas.
Los comandos csv-timeline y json-timeline ahora tienen un asistente de escaneo habilitado de forma predeterminada. Esto tiene como objetivo ayudar a los usuarios a elegir fácilmente qué reglas de detección desean habilitar según sus necesidades y preferencias. Los conjuntos de reglas de detecciones para cargar se basan en las listas oficiales del proyecto Sigma. Los detalles se explican en esta publicación de blog. Puedes desactivar fácilmente el asistente y usar Hayabusa en su forma tradicional agregando la opción -w, --no-wizard .
El conjunto de reglas core habilita reglas que tienen un estado de test o stable y un nivel high o critical . Estas son reglas de alta calidad, de alta confianza y relevancia y no deberían producir muchos falsos positivos. El estado de la regla es test o stable , lo que significa que no se informaron falsos positivos durante más de 6 meses. Las reglas coincidirán con las técnicas del atacante, la actividad sospechosa genérica o el comportamiento malicioso. Es lo mismo que usar las opciones --exclude-status deprecated,unsupported,experimental --min-level high .
El conjunto de reglas core+ habilita reglas que tienen un estado de test o stable y un nivel medium o superior. Las reglas medium suelen necesitar ajustes adicionales, ya que ciertas aplicaciones, el comportamiento legítimo del usuario o los scripts de una organización pueden coincidir. Es lo mismo que usar las opciones --exclude-status deprecated,unsupported,experimental --min-level medium .
El conjunto de reglas core++ habilita reglas que tienen un estado experimental , test o stable y un nivel medium o superior. Estas reglas son vanguardistas. Se validan con los archivos evtx de referencia disponibles en el proyecto SigmaHQ y son revisados por varios ingenieros de detección. Aparte de eso, al principio prácticamente no se han probado. Utilícelos si desea poder detectar amenazas lo antes posible a costa de gestionar un umbral más alto de falsos positivos. Es lo mismo que usar las opciones --exclude-status deprecated,unsupported --min-level medium .
El conjunto de reglas Emerging Threats (ET) habilita reglas que tienen una etiqueta de detection.emerging_threats . Estas reglas se dirigen a amenazas específicas y son especialmente útiles para amenazas actuales donde aún no hay mucha información disponible. Estas reglas no deberían tener muchos falsos positivos, pero su relevancia disminuirá con el tiempo. Cuando estas reglas no están habilitadas, es lo mismo que usar la opción --exclude-tag detection.emerging_threats . Cuando se ejecuta Hayabusa tradicionalmente sin el asistente, estas reglas se incluirán de forma predeterminada.
El conjunto de reglas Threat Hunting (TH) habilita reglas que tienen una etiqueta de detection.threat_hunting . Estas reglas pueden detectar actividad maliciosa desconocida; sin embargo, normalmente tendrán más falsos positivos. Cuando estas reglas no están habilitadas, es lo mismo que usar la opción --exclude-tag detection.threat_hunting . Cuando se ejecuta Hayabusa tradicionalmente sin el asistente, estas reglas se incluirán de forma predeterminada.
A partir de Hayabusa v2.16.0, habilitamos un filtro basado en canales al cargar archivos .evtx y reglas .yml . El objetivo es hacer que el escaneo sea lo más eficiente posible cargando solo lo necesario. Si bien es posible que haya varios proveedores en un único registro de eventos, no es común tener varios canales dentro de un único archivo evtx. (La única vez que hemos visto esto es cuando alguien fusionó artificialmente dos archivos evtx diferentes para el proyecto sample-evtx). Podemos usar esto a nuestro favor verificando primero el campo Channel en el primer registro de cada archivo .evtx especificado. para ser escaneado. También comprobamos qué reglas .yml utilizan qué canales especificados en el campo Channel de la regla. Con estas dos listas, solo cargamos reglas que usan canales que realmente están presentes dentro de los archivos .evtx .
Entonces, por ejemplo, si un usuario desea escanear Security.evtx , solo se utilizarán reglas que especifiquen Channel: Security . No tiene sentido cargar otras reglas de detección, por ejemplo reglas que solo buscan eventos en el registro Application , etc. Tenga en cuenta que los campos de canal (Ej: Channel: Security ) no están definidos explícitamente dentro de las reglas originales de Sigma. Para las reglas de Sigma, los campos de ID de canal y evento se definen implícitamente con los campos service y category en logsource . (Ej: service: security ) Al seleccionar reglas de Sigma en el repositorio de hayabusa-rules, eliminamos la abstracción del campo logsource y definimos explícitamente los campos de canal e ID de evento. Explicamos cómo y por qué hacemos esto en profundidad aquí.
Actualmente, solo hay dos reglas de detección que no tienen Channel definido y están destinadas a escanear todos los archivos .evtx :
Si desea utilizar estas dos reglas y escanear todas las reglas con los archivos .evtx cargados, deberá agregar la opción -A, --enable-all-rules en los comandos csv-timeline y json-timeline . En nuestros puntos de referencia, el filtrado de reglas generalmente ofrece una mejora de velocidad de 20% a 10 veces dependiendo de los archivos que se estén escaneando y, por supuesto, utiliza menos memoria.
El filtrado de canales también se utiliza al cargar archivos .evtx . Por ejemplo, si especifica una regla que busca eventos con un canal de Security , entonces no tiene sentido cargar archivos .evtx que no sean del registro Security . En nuestras pruebas comparativas, esto proporciona un beneficio de velocidad de alrededor del 10 % con escaneos normales y un aumento de rendimiento de hasta un 60 % más cuando escanea con una sola regla. Si está seguro de que se están utilizando varios canales dentro de un solo archivo .evtx , por ejemplo, alguien usó una herramienta para fusionar varios archivos .evtx , entonces deshabilite este filtrado con -a, --scan-all-evtx-files opción en los comandos csv-timeline y json-timeline .
Nota: El filtrado de canales solo funciona con archivos
.evtxy recibirá un error si intenta cargar registros de eventos desde un archivo JSON con-J, --json-inputy también especifica-Ao-a.
csv-timeline El comando csv-timeline creará una línea de tiempo forense de eventos en formato 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 predeterminado: 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
Nota: Habilitar el filtro EID acelerará el análisis entre un 10 y un 15 % en nuestras pruebas, pero existe la posibilidad de que se pierdan alertas.
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 marcado como deprecated ) y reglas ruidosas (aquellas cuyo ID de regla aparece en .rulesconfignoisy_rules.txt ):Nota: Recientemente, las reglas obsoletas ahora se encuentran en un directorio separado en el repositorio sigma, por lo que ya no se incluyen de forma predeterminada en Hayabusa. Por lo tanto, probablemente no sea necesario habilitar reglas obsoletas.
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
Reglas de carga:
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
Errores durante el escaneo:
[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 . Puede agregar información GeoIP (organización ASN, ciudad y país) a los campos SrcIP (IP de origen) y TgtIP (IP de destino) con los datos de geolocalización gratuitos de GeoLite2.
Pasos:
.mmdb de la página de descarga y guárdelos en un directorio. Los nombres de los archivos deben llamarse GeoLite2-ASN.mmdb , GeoLite2-City.mmdb y GeoLite2-Country.mmdb .csv-timeline o json-timeline , agregue la opción -G seguida del directorio con las bases de datos de MaxMind. Cuando se utiliza csv-timeline , se generarán adicionalmente las siguientes 6 columnas: SrcASN , SrcCity , SrcCountry , TgtASN , TgtCity , TgtCountry .
Cuando se utiliza json-timeline , los mismos campos SrcASN , SrcCity , SrcCountry , TgtASN , TgtCity , TgtCountry se agregarán al objeto Details , pero solo si contienen información.
Cuando SrcIP o TgtIP es localhost ( 127.0.0.1 , ::1 , etc...), SrcASN o TgtASN se generarán como Local .
Cuando SrcIP o TgtIP es una dirección IP privada ( 10.0.0.0/8 , fe80::/10 , etc...), SrcASN o TgtASN se generarán como Private .
Los nombres de los campos que contienen direcciones IP de origen y destino que se buscan en las bases de datos GeoIP se definen en rules/config/geoip_field_mapping.yaml . Puede agregar a esta lista si es necesario. También hay una sección de filtro en este archivo que determina de qué eventos extraer información de la dirección IP.
Las bases de datos GeoIP de MaxMind se actualizan cada 2 semanas. Puede instalar la herramienta MaxMind geoipupdate aquí para actualizar automáticamente estas bases de datos.
Pasos en MacOS:
brew install geoipupdate/usr/local/etc/GeoIP.conf : Ponga su AccountID y LicenseKey que cree después de iniciar sesión en el sitio web de MaxMind. Asegúrese de que la línea EditionIDs diga EditionIDs GeoLite2-ASN GeoLite2-City GeoLite2-Country .geoipupdate .-G /usr/local/var/GeoIP cuando desee agregar información geoip.Pasos en Windows:
geoipupdate_4.10.0_windows_amd64.zip ) de la página de comunicados.ProgramDataMaxMind/GeoIPUpdateGeoIP.conf : Ponga su AccountID y LicenseKey que cree después de iniciar sesión en el sitio web de MaxMind. Asegúrese de que la línea EditionIDs diga EditionIDs GeoLite2-ASN GeoLite2-City GeoLite2-Country .geoipupdate . csv-timeline ./rules/config/channel_abbreviations.txt : asignaciones de nombres de canales y sus abreviaturas.
./rules/config/default_details.txt : el archivo de configuración para qué información de campo predeterminada ( %Details% campo) debe generarse si no hay details: la línea se especifica en una regla. Esto se basa en el nombre del proveedor y las ID de eventos.
./rules/config/eventkey_alias.txt : este archivo tiene las asignaciones de alias de nombre cortos para campos y sus nombres de campo más largos originales.
Ejemplo:
InstanceID,Event.UserData.UMDFHostDeviceArrivalBegin.InstanceId
IntegrityLevel,Event.EventData.IntegrityLevel
IpAddress,Event.EventData.IpAddress
Si no se define un campo aquí, Hayabusa verificará automáticamente en Event.EventData para el campo.
./rules/config/exclude_rules.txt : este archivo tiene una lista de ID de reglas que se excluirán del uso. Por lo general, esto se debe a que una regla ha reemplazado a otra o la regla no puede usarse en primer lugar. Al igual que los firewalls e IDSE, cualquier herramienta basada en la firma requerirá un ajuste para que se ajuste a su entorno, por lo que es posible que deba excluir de forma permanente o temporal ciertas reglas. Puede agregar una ID de regla (Ejemplo: 4fe151c2-ecf9-4fae-95ae-b88ec9c2fca6 ) a ./rules/config/exclude_rules.txt para ignorar cualquier regla que no necesite o no se pueda usar.
./rules/config/noisy_rules.txt : este archivo una lista de ID de reglas que están deshabilitadas de forma predeterminada pero se pueden habilitar habilitando reglas ruidosas con la opción -n, --enable-noisy-rules . Estas reglas suelen ser ruidosas por naturaleza o debido a falsos positivos.
./rules/config/target_event_IDs.txt : solo las ID de evento especificadas en este archivo se escanearán si el filtro EID está habilitado. De manera predeterminada, Hayabusa escaneará todos los eventos, pero si desea mejorar el rendimiento, use la opción -E, --EID-filter . Esto generalmente resulta en una mejora de velocidad del 10 ~ 25%.
json-timeline El comando json-timeline creará una línea de tiempo forense de eventos en formato JSON o JSONL. La salida a JSONL será un tamaño de archivo más rápido y menor que JSON, por lo que es bueno si va a importar los resultados a otra herramienta como Elastic Stack. JSON es mejor si vas a analizar manualmente los resultados con un editor de texto. La salida de CSV es buena para importar plazos más pequeños (generalmente menos de 2 GB) en herramientas como LibreOffice o Timeline Explorer. JSON es mejor para un análisis más detallado de los datos (incluidos los grandes archivos de resultados) con herramientas como jq ya que los campos Details están separados para un análisis más fácil. (En la salida de CSV, todos los campos de registro de eventos están en una gran columna Details que realizan una clasificación de datos, etc. más difícil).
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 y archivos de configuración Las opciones y los archivos de configuración para json-timeline son las mismas que csv-timeline pero una opción adicional -L, --JSONL-output para la salida al formato JSONL.
level-tuning El comando level-tuning le permitirá ajustar los niveles de alerta para las reglas, ya sea elevando o disminuyendo el nivel de riesgo de acuerdo con su entorno.
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 Los autores de la regla de Hayabusa y Sigma determinarán el nivel de riesgo de la alerta al escribir sus reglas. Sin embargo, el nivel de riesgo real puede diferir según el medio ambiente. Puede ajustar el nivel de riesgo de las reglas agregándolas a ./rules/config/level_tuning.txt y ejecutando hayabusa.exe level-tuning que actualizará la línea level en el archivo de reglas. Tenga en cuenta que el archivo de regla se actualizará directamente.
Advertencia: en cualquier momento en que ejecute
update-rules, el nivel de alerta original sobrescribirá cualquier configuración que haya cambiado, por lo que deberá ejecutar el comandolevel-tuningdespués de cada vez que ejecuteupdate-rulessi desea cambiar los niveles.
./rules/config/level_tuning.txt Línea de muestra:
id,new_level
00000000-0000-0000-0000-000000000000,informational # sample level tuning line
En este caso, el nivel de riesgo de la regla con una id de 00000000-0000-0000-0000-000000000000 en el directorio de reglas tendrá su level reescrito a informational . Los posibles niveles para establecer son critical , high , medium , low e 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-profile Ejemplos de comandominimal : hayabusa.exe set-default-profile minimalsuper-verbose : hayabusa.exe set-default-profile super-verboseupdate-rules El comando update-rules sincronizará la carpeta rules con el repositorio de GitHub de las reglas Hayabusa, actualizando las reglas y los archivos de configuración.
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 Normalmente solo ejecutará esto: hayabusa.exe update-rules
Hayabusa tiene 5 perfiles de salida predefinidos para usar en config/profiles.yaml :
minimalstandard (predeterminado)verboseall-field-infoall-field-info-verbosesuper-verbosetimesketch-minimaltimesketch-verbose Puede personalizar fácilmente o agregar sus propios perfiles editando este archivo. También puede cambiar fácilmente el perfil predeterminado con set-default-profile --profile . Use el comando list-profiles para mostrar los perfiles disponibles y su información de campo.
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 En lugar de generar la información details mínimos, toda la información de campo en las secciones EventData y UserData se emitirá junto con sus nombres de campo originales.
%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-minimalSalida a un formato compatible con la importación a 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%
Los siguientes puntos de referencia se llevaron a cabo en un Lenovo P51 2018 (CPU Core 4 Core / 64GB RAM) 2018 con 3GB de datos EVTX y reglas 3891 habilitadas. (2023/06/01)
| Perfil | Tiempo de procesamiento | Salida de archivos de tamaño | Aumento de tamaño |
|---|---|---|---|
| mínimo | 8 minutos 50 segundos | 770 megas | -30% |
| Estándar (predeterminado) | 9 minutos 00 segundos | 1.1 GB | Ninguno |
| verboso | 9 minutos 10 segundos | 1,3GB | +20% |
| All-Field-Info | 9 minutos 3 segundos | 1,2GB | +10% |
| All-Field-Info-Verboso | 9 minutos 10 segundos | 1,3GB | +20% |
| súper verboso | 9 minutos 12 segundos | 1,5GB | +35% |
La siguiente información se puede emitir con perfiles de salida incorporados:
| Nombre de alias | Información de salida de Hayabusa |
|---|---|
| %Allfieldinfo% | Toda la información de campo. |
| %Canal% | El nombre del registro. |
| %Computadora% | El campo |
| %Detalles% | El campo de details en la regla de detección de YML, sin embargo, solo las reglas de Hayabusa tienen este campo. Este campo proporciona información adicional sobre la alerta o evento y puede extraer datos útiles de los campos en los registros de eventos. Por ejemplo, los nombres de usuario, la información de la línea de comandos, la información del proceso, etc. Cuando un marcador de posición apunta a un campo que no existe o hay una asignación de alias incorrecta, se generará como n/a (no disponible). Si no se especifica el campo details (es decir, las reglas Sigma), se emitirán los mensajes details predeterminados para extraer campos definidos en ./rules/config/default_details.txt . Puede agregar más mensajes details predeterminados agregando el Provider Name , EventID y el mensaje details que desea emitir en default_details.txt . Cuando no se define ningún campo details en una regla ni en default_details.txt , todos los campos se emitirán a la columna details . |
| %Extrafieldinfo% | Imprima la información de campo que no se obtuvo en %de detalles %. |
| %EventId% | El campo |
| %Evtxfile% | El nombre de archivo EVTX que causó la alerta o evento. |
| %Nivel% | El campo level en la regla de detección YML. ( informational , low , medium , high , critical ) |
| %Mitretactics% | Tácticas de Mitre ATT & CK (Ej: acceso inicial, movimiento lateral, etc.). |
| %MITRETAGS% | ID de grupo Mitre ATT & CK, ID de técnica e ID de software. |
| %OTROS OTRESTAGS% | Cualquier palabra clave en el campo tags en una regla de detección de YML que no se incluye en MitreTactics o MitreTags . |
| %Proveedor% | El atributo Name en |
| %RecordId% | El ID de registro de eventos desde |
| %Ruleautor% | El campo author en la regla de detección de YML. |
| %RulecreationDate% | El campo date en la regla de detección YML. |
| %File de regla% | El nombre de archivo de la regla de detección que generó la alerta o evento. |
| %RulemodifiedDate% | El campo modified en la regla de detección YML. |
| %Ruletitle% | El campo title en la regla de detección de YML. |
| %Estado% | El campo status en la regla de detección YML. |
| %TimeStamp% | El valor predeterminado es YYYY-MM-DD HH:mm:ss.sss +hh:mm format. --UTC . |
También puede agregar estos alias adicionales a su perfil de salida si los necesita:
| Nombre de alias | Información de salida de Hayabusa |
|---|---|
| %RenderedMessage% | El campo |
| %RuleId% | El campo id en la regla de detección YML. |
Nota: Estos no están incluidos en ningún perfil integrado, por lo que deberá editar manualmente el archivo config/default_profile.yaml y agregar las siguientes líneas:
Message: "%RenderedMessage%"
RuleID: "%RuleID%"
También puede definir alias clave de eventos para generar otros campos.
Para ahorrar espacio, utilizamos las siguientes abrevaciones al mostrar el level de alerta.
crit : criticalhigh : highmed : mediumlow : lowinfo : informational Para ahorrar espacio, utilizamos las siguientes abreviaturas al mostrar etiquetas de táctica Mitre ATT & CK. Puede editar libremente estas abreviaturas en el archivo de configuración ./config/mitre_tactics.txt .
Recon : ReconocimientoResDev : desarrollo de recursosInitAccess : acceso inicialExec : ejecuciónPersis : persistenciaPrivEsc : escalada de privilegiosEvas : evasión de defensaCredAccess : acceso de credencialesDisc : descubrimientoLatMov : movimiento lateralCollect : COLECCIÓNC2 : comando y controlExfil : exfiltraciónImpact : impacto Para ahorrar espacio, utilizamos las siguientes abreviaturas al mostrar el canal. Puede editar libremente estas abreviaturas en el archivo de configuración ./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 Las siguientes abreviaturas se utilizan en las reglas para que la salida sea lo más concisa posible:
Acct -> CuentaAddr -> DirecciónAuth -> AutenticaciónCli -> ClienteChan -> canalCmd -> comandoCnt -> contarComp -> computadoraConn -> Connection/ConnectedCreds -> credencialesCrit -> críticoDisconn -> desconexión/desconectadoDir -> DirectorioDrv -> ConductorDst -> DestinoEID -> ID de eventoErr -> ErrorExec -> EjecuciónFW -> FirewallGrp -> GrupoImg -> ImagenInjKrb -> KerberosLID -> ID de inicio de sesiónMed -> medioNet -> redObj -> objetoOp -> Operación/OperaciónProto -> ProtocoloPW -> ContraseñaReconn -> ReconexiónReq -> SolicitudRsp -> RespuestaSess -> SesiónSig -> FirmaSusp -> SospechosoSrc -> FuenteSvc -> ServicioSvr -> servidorTemp -> temporalTerm -> terminación/terminadoTkt -> boletoTgt -> objetivoUnkwn -> desconocidoUsr -> usuarioPerm -> PermentoPkg -> paquetePriv -> privilegioProc -> procesoPID -> ID de procesoPGUID -> Process Guid (ID global único)Ver -> versión La barra de progreso solo funcionará con múltiples archivos EVTX. Mostrará en tiempo real el número y el porcentaje de archivos EVTX que ha terminado de analizar.
Las alertas se emitirán en color en función del level de alerta. Puede cambiar los colores predeterminados en el archivo de configuración en ./config/level_color.txt en el formato de level,(RGB 6-digit ColorHex) . Si desea deshabilitar la salida de color, puede usar la opción --no-color .
Los eventos totales, el número de eventos con éxitos, métricas de reducción de datos, detecciones totales y únicas, fechas con la mayoría de las detecciones, las computadoras principales con detecciones y alertas superiores se muestran después de cada escaneo.
Si agrega la opción -T, --visualize-timeline , la función de línea de tiempo de frecuencia de eventos muestra una línea de tiempo de frecuencia de chispa de los eventos detectados. Nota: Debe haber más de 5 eventos. Además, los caracteres no se presentarán correctamente en el símbolo del sistema predeterminado o el indicador de PowerShell, por lo que utiliza un terminal como Windows Terminal, ITerm2, etc.
Las reglas de detección de Hayabusa están escritas en un formato YML similar a Sigma y se encuentran en la carpeta rules . Las reglas están alojadas en https://github.com/yamato-security/hayabusa-rules, así que envíe cualquier problema y extraiga las reglas allí en lugar del repositorio principal de Hayabusa.
Lea el readMe del repositorio de reglas Hayabusa para comprender el formato de regla y cómo crear reglas.
Todas las reglas del repositorio de reglas Hayabusa deben colocarse en la carpeta rules . Las reglas de nivel informational se consideran events , mientras que cualquier cosa con un level de low y superior se consideran alerts .
La estructura del directorio de reglas de Hayabusa se separa en 2 directorios:
builtin : registros que pueden generarse por la funcionalidad incorporada de Windows.sysmon : registros generados por Sysmon.Las reglas se separan aún más en directorios por tipo de registro (ejemplo: seguridad, sistema, etc.) y se nombran en el siguiente formato:
Consulte las reglas actuales para usar como plantilla para crear otras nuevas o para verificar la lógica de detección.
Hayabusa apoya las reglas de Sigma de forma nativa con una única excepción de manejar los campos logsource internamente. Para reducir los falsos positivos, las reglas de Sigma deben ejecutarse a través de nuestro convertidor explicado aquí. Esto agregará el Channel y EventID adecuados, y realizará la mapeo de campo para ciertas categorías como process_creation .
Casi todas las reglas de Hayabusa son compatibles con el formato Sigma, por lo que puede usarlas como las reglas de Sigma para convertirse a otros formatos SIEM. Las reglas de Hayabusa están diseñadas únicamente para el análisis de registros de eventos de Windows y tienen los siguientes beneficios:
details adicional para mostrar información adicional tomada solo de los campos útiles en el registro.|equalsfield y |endswithfield .Hasta donde sabemos, Hayabusa proporciona el mayor soporte nativo para las reglas de Sigma de cualquier herramienta de análisis de registro de eventos de código abierto de Windows.
Para detectar correctamente la actividad maliciosa en las máquinas de Windows, deberá mejorar la configuración de registro predeterminada. Hemos creado un proyecto separado para documentar qué configuración de registro debe habilitarse, así como los scripts para habilitar automáticamente la configuración adecuada en https://github.com/yamato-security/enableWindowsLogSettings.
También recomendamos los siguientes sitios para orientación:
Para crear la evidencia más forense y detectar con la mayor precisión, debe instalar Sysmon. Recomendamos los siguientes sitios y archivos de configuración:
Nos encantaría cualquier forma de contribución. Las solicitudes de extracción, la creación de reglas y los registros de muestra EVTX son las mejores, pero las solicitudes de funciones, notificándonos de errores, etc., también son muy bienvenidas.
Por lo menos, si le gusta nuestra herramienta, ¡danos una estrella en Github y muestre tu apoyo!
Envíe cualquier error que encuentre aquí. Este proyecto se mantiene activamente y estamos encantados de solucionar cualquier error reportado.
Si encuentra algún problema (falsos positivos, errores, etc.) con las reglas de Hayabusa, infórmalos a la página de problemas de GitHub de Hayabusa-Rules aquí.
Si encuentra algún problema (falsos positivos, errores, etc.) con las reglas de Sigma, infórmalos a la página de problemas de Sigmahq GitHub aquí.
Hayabusa se publica bajo AGPLV3 y todas las reglas se publicaron bajo la Licencia de Regla de Detección (DRL) 1.1.
Hayabusa utiliza datos de Geolite2 creados por MaxMind, disponibles en https://www.maxmind.com.
Puede recibir las últimas noticias sobre Hayabusa, actualizaciones de reglas, otras herramientas de seguridad de Yamato, etc ... siguiéndonos en Twitter en @Securityyamato.
