Hayabusa
v2.18.0 ?
Hayabusa é um gerador rápido de linha do tempo forense de log de eventos do Windows e uma ferramenta de caça a ameaças criada pelo grupo Yamato Security no Japão. Hayabusa significa “falcão peregrino” em japonês e foi escolhido porque os falcões peregrinos são os animais mais rápidos do mundo, ótimos na caça e altamente treináveis. Ele é escrito em Rust e suporta multithreading para ser o mais rápido possível. Fornecemos uma ferramenta para converter regras Sigma para o formato de regras Hayabusa. As regras de detecção Hayabusa compatíveis com Sigma são escritas em YML para serem tão facilmente personalizáveis e extensíveis quanto possível. A Hayabusa pode ser executada em sistemas únicos para análise ao vivo, coletando logs de um ou vários sistemas para análise offline ou executando o artefato Hayabusa com Velociraptor para caça a ameaças e resposta a incidentes em toda a empresa. A saída será consolidada em uma única linha do tempo CSV para fácil análise no LibreOffice, Timeline Explorer, Elastic Stack, Timesketch, etc...
evtx .-T )-H )-M Multiline)computer-metricscomputer-metricscomputer-metricseid-metricseid-metricseid-metricseid-metricslogon-summarylogon-summarylogon-summarypivot-keywords-listpivot-keywords-listpivot-keywords-listsearchsearchsearchcsv-timelinecsv-timelinecsv-timelinejson-timelinejson-timeline e arquivos de configuraçãolevel-tuninglevel-tuninglevel-tuninglist-profilesset-default-profileset-default-profileupdate-rulesupdate-rulesminimal de perfilstandardverboseall-field-infoall-field-info-verbosesuper-verbosetimesketch-minimaltimesketch-verboseAtualmente, a Hayabusa tem mais de 4.000 regras Sigma e mais de 170 regras de detecção integradas da Hayabusa, com mais regras sendo adicionadas regularmente. Ele pode ser usado para caça proativa de ameaças em toda a empresa, bem como DFIR (Digital Forensics and Incident Response) gratuitamente com o artefato Hayabusa do Velociraptor. Ao combinar essas duas ferramentas de código aberto, você pode essencialmente reproduzir retroativamente um SIEM quando não houver configuração de SIEM no ambiente. Você pode aprender como fazer isso assistindo ao passo a passo do Velociraptor de Eric Capuano aqui.
A análise do log de eventos do Windows tem sido tradicionalmente um processo muito longo e tedioso porque os logs de eventos do Windows estão 1) em um formato de dados difícil de analisar e 2) a maioria dos dados é ruído e não é útil para investigações. O objetivo da Hayabusa é extrair apenas dados úteis e apresentá-los em um formato conciso e fácil de ler, que possa ser usado não apenas por analistas treinados profissionalmente, mas por qualquer administrador de sistema Windows. A Hayabusa espera permitir que os analistas realizem 80% do seu trabalho em 20% do tempo, em comparação com a análise tradicional do log de eventos do Windows.
-T ) 
-H ) 
-M Multiline) 
Você pode aprender como analisar cronogramas CSV no Excel e no Timeline Explorer aqui.
Você pode aprender como importar arquivos CSV para o Elastic Stack aqui.
Você pode aprender como importar arquivos CSV para o Timesketch aqui.
Você pode aprender como analisar resultados formatados em JSON com jq aqui.
|equalsfield e |endswithfield .0xc0000234 -> ACCOUNT LOCKED )Baixe a versão estável mais recente do Hayabusa com binários compilados ou compile o código-fonte na página de lançamentos.
Fornecemos binários para as seguintes arquiteturas:
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 alguma razão, o binário Linux ARM MUSL não funciona corretamente, por isso não fornecemos esse binário. Está fora do nosso controle, por isso planejamos fornecê-lo no futuro, quando for consertado.
A partir da v2.18.0, fornecemos pacotes especiais do Windows que usam regras codificadas em XOR fornecidas em um único arquivo, bem como todos os arquivos de configuração combinados em um único arquivo (hospedado no repositório de regras codificadas em hayabusa). Basta baixar os pacotes zip com live-response no nome. Os arquivos zip incluem apenas três arquivos: o binário Hayabusa, o arquivo de regras codificado em XOR e o arquivo de configuração. O objetivo desses pacotes de resposta ao vivo é ao executar Hayabusa em endpoints de clientes. Queremos ter certeza de que scanners antivírus como o Windows Defender não forneçam falsos positivos em arquivos de regras .yml . Além disso, queremos minimizar a quantidade de arquivos gravados no sistema para que artefatos forenses como o USN Journal não sejam substituídos.
Você pode git clone o repositório com o seguinte comando e compilar o binário do código-fonte:
Atenção: O branch principal do repositório é para fins de desenvolvimento então você poderá acessar novos recursos ainda não lançados oficialmente, porém, pode haver bugs então considere-o instável.
git clone https://github.com/Yamato-Security/hayabusa.git --recursiveNota: Se você esquecer de usar a opção --recursive, a pasta
rules, que é gerenciada como um submódulo git, não será clonada.
Você pode sincronizar a pasta de rules e obter as regras mais recentes da Hayabusa com git pull --recurse-submodules ou usar o seguinte comando:
hayabusa.exe update-rules Se a atualização falhar, pode ser necessário renomear a pasta rules e tentar novamente.
Cuidado: Ao atualizar, as regras e os arquivos de configuração na pasta
rulessão substituídos pelas regras e arquivos de configuração mais recentes no repositório hayabusa-rules. Quaisquer alterações feitas nos arquivos existentes serão substituídas, por isso recomendamos que você faça backups de todos os arquivos editados antes de atualizar. Se você estiver realizando ajuste de nível comlevel-tuning, reajuste seus arquivos de regras após cada atualização. Se você adicionar novas regras dentro da pastarules, elas não serão substituídas ou excluídas durante a atualização.
Se você tiver o Rust instalado, poderá compilar a partir do código-fonte com o seguinte comando:
Nota: Para compilar, você geralmente precisa da versão mais recente do Rust.
cargo build --releaseVocê pode baixar a versão instável mais recente no branch principal ou a versão estável mais recente na página de lançamentos.
Certifique-se de atualizar periodicamente o Rust com:
rustup update stable O binário compilado será gerado na pasta ./target/release .
Você pode atualizar para as caixas Rust mais recentes antes de compilar:
cargo updateInforme-nos se algo quebrar após a atualização.
Você pode criar binários de 32 bits em sistemas Windows de 64 bits com o seguinte:
rustup install stable-i686-pc-windows-msvc
rustup target add i686-pc-windows-msvc
rustup run stable-i686-pc-windows-msvc cargo build --releaseAviso: Certifique-se de executar
rustup install stable-i686-pc-windows-msvcsempre que houver uma nova versão estável do Rust, poisrustup update stablenão atualizará o compilador para compilação cruzada e você poderá receber erros de compilação.
Se receber erros de compilação sobre o openssl, você precisará instalar o Homebrew e depois instalar os seguintes pacotes:
brew install pkg-config
brew install opensslSe receber erros de compilação sobre o openssl, você precisará instalar o seguinte pacote.
Distribuições baseadas em Ubuntu:
sudo apt install libssl-devDistribuições baseadas no Fedora:
sudo yum install openssl-develEm um sistema operacional Linux, primeiro instale o destino.
rustup install stable-x86_64-unknown-linux-musl
rustup target add x86_64-unknown-linux-muslCompilar com:
cargo build --release --target=x86_64-unknown-linux-muslAviso: Certifique-se de executar
rustup install stable-x86_64-unknown-linux-muslsempre que houver uma nova versão estável do Rust, poisrustup update stablenão atualizará o compilador para compilação cruzada e você poderá receber erros de compilação.
O binário MUSL será criado no diretório ./target/x86_64-unknown-linux-musl/release/ . Os binários MUSL são cerca de 15% mais lentos que os binários GNU, no entanto, são mais portáveis em diferentes versões e distribuições do Linux.
Você pode receber um alerta de produtos antivírus ou EDR ao tentar executar o hayabusa ou mesmo apenas ao baixar as regras .yml , pois haverá palavras-chave como mimikatz e comandos suspeitos do PowerShell na assinatura de detecção. Esses são falsos positivos, portanto, será necessário configurar exclusões em seus produtos de segurança para permitir a execução do hayabusa. Se você está preocupado com malware ou ataques à cadeia de suprimentos, verifique o código-fonte da hayabusa e compile os binários você mesmo.
Você pode enfrentar um tempo de execução lento, especialmente na primeira execução após uma reinicialização, devido à proteção em tempo real do Windows Defender. Você pode evitar isso desativando temporariamente a proteção em tempo real ou adicionando uma exclusão ao diretório de tempo de execução hayabusa. (Leve em consideração os riscos de segurança antes de fazer isso.)
Em um prompt de comando/PowerShell ou terminal do Windows, basta executar o binário apropriado do Windows de 32 ou 64 bits.
Ao usar o prompt de comando ou PowerShell integrado no Windows, você pode receber um erro informando que a Hayabusa não conseguiu carregar nenhum arquivo .evtx se houver espaço no caminho do arquivo ou diretório. Para carregar os arquivos .evtx corretamente, faça o seguinte:
Primeiro você precisa tornar o binário executável.
chmod +x ./hayabusaEm seguida, execute-o no diretório raiz da Hayabusa:
./hayabusaNo Terminal ou iTerm2, primeiro você precisa tornar o binário executável.
chmod +x ./hayabusaEm seguida, tente executá-lo a partir do diretório raiz da Hayabusa:
./hayabusaNa versão mais recente do macOS, você pode receber o seguinte erro de segurança ao tentar executá-lo:
Clique em “Cancelar” e em Preferências do Sistema, abra “Segurança e Privacidade” e na guia Geral, clique em “Permitir assim mesmo”.
Depois disso, tente executá-lo novamente.
./hayabusaO seguinte aviso aparecerá, então clique em "Abrir".
Agora você deve ser capaz de executar o hayabusa.
computer-metrics : imprime o número de eventos com base nos nomes dos computadores.eid-metrics : Imprime o número e a porcentagem de eventos com base no ID do evento.logon-summary : imprime um resumo dos eventos de logon.pivot-keywords-list : Imprima uma lista de palavras-chave suspeitas para usar.search : pesquise todos os eventos por palavras-chave ou expressões regulares csv-timeline : Salve a linha do tempo no formato CSV.json-timeline : Salve a linha do tempo no formato JSON/JSONL.level-tuning : ajuste personalizado do level dos alertas.list-profiles : lista os perfis de saída disponíveis.set-default-profile : Altere o perfil padrão.update-rules : Sincronize as regras com as regras mais recentes no repositório GitHub hayabusa-rules. help : imprime esta mensagem ou a ajuda do(s) subcomando(s) fornecido(s)list-contributors : Imprime a lista de contribuidorescomputer-metrics Você pode utilizar o comando computer-metrics para verificar quantos eventos existem de acordo com cada computador definido no campo Computer para separar eventos pelo computador original. Às vezes, o Windows 11 usa nomes Computer completamente diferentes ao salvar nos logs de eventos. Além disso, o Windows 10 às vezes registra o nome Computer em letras minúsculas. Este comando não usa nenhuma regra de detecção, portanto analisará todos os eventos. Este é um bom comando para executar para ver rapidamente quais computadores têm mais logs. Com essas informações, você pode usar as opções --include-computer ou --exclude-computer ao criar suas linhas do tempo para tornar a geração da linha do tempo mais eficiente, criando várias linhas do tempo de acordo com o computador ou excluindo eventos de determinados computadores.
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 Você pode usar o comando eid-metrics para imprimir o número total e a porcentagem de IDs 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 O canal, os IDs dos eventos e os títulos dos eventos são definidos em rules/config/channel_eid_info.txt .
Exemplo:
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 Você pode usar o comando logon-summary para gerar um resumo das informações de logon (nomes de usuário de logon e contagem de logons bem-sucedidos e com falha). Você pode exibir as informações de logon de um arquivo evtx com -f ou de vários arquivos evtx com a opção -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 Você pode usar o comando pivot-keywords-list para criar uma lista de palavras-chave pivot exclusivas para identificar rapidamente usuários, nomes de host, processos, etc. anormais... bem como correlacionar eventos.
Importante: por padrão, hayabusa retornará resultados de todos os eventos (informativos e superiores), por isso é altamente recomendável combinar o comando pivot-keywords-list com a opção -m, --min-level . Por exemplo, comece criando apenas palavras-chave de alertas critical com -m critical e depois continue com -m high , -m medium , etc... Provavelmente haverá palavras-chave comuns em seus resultados que corresponderão a muitos eventos normais, portanto, depois de verificar manualmente os resultados e criar uma lista de palavras-chave exclusivas em um único arquivo, você pode criar um cronograma reduzido de atividades suspeitas com um 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 Você pode personalizar quais palavras-chave deseja pesquisar editando ./rules/config/pivot_keywords.txt . Esta página é a configuração padrão.
O formato é KeywordName.FieldName . Por exemplo, ao criar a lista de Users , hayabusa listará todos os valores nos campos SubjectUserName , TargetUserName e User .
search O comando search permitirá que você pesquise por palavra-chave em todos os eventos. (Não apenas resultados de detecção da Hayabusa.) Isto é útil para determinar se há alguma evidência em eventos que não são detectados pela 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 pela palavra-chave mimikatz : hayabusa.exe search -d ../hayabusa-sample-evtx -k "mimikatz"
Nota: A palavra-chave corresponderá se
mimikatzfor encontrado em qualquer lugar dos dados. Não é uma correspondência exata.
../hayabusa-sample-evtx as palavras-chave mimikatz ou kali : hayabusa.exe search -d ../hayabusa-sample-evtx -k "mimikatz" -k "kali"
../hayabusa-sample-evtx a palavra-chave mimikatz e ignore maiúsculas e minúsculas: hayabusa.exe search -d ../hayabusa-sample-evtx -k "mimikatz" -i
../hayabusa-sample-evtx por endereços IP usando expressões regulares: hayabusa.exe search -d ../hayabusa-sample-evtx -r "(?:[0-9]{1,3}.){3}[0-9]{1,3}"
../hayabusa-sample-evtx e mostre todos os eventos onde o campo WorkstationName é kali : hayabusa.exe search -d ../hayabusa-sample-evtx -r ".*" -F WorkstationName:"kali"
Nota:
.*é a expressão regular correspondente a cada evento.
search ./rules/config/channel_abbreviations.txt : Mapeamentos de nomes de canais e suas abreviações.
Os comandos csv-timeline e json-timeline agora têm um assistente de verificação habilitado por padrão. O objetivo é ajudar os usuários a escolher facilmente quais regras de detecção desejam ativar de acordo com suas necessidades e preferências. Os conjuntos de regras de detecção a serem carregados são baseados nas listas oficiais do projeto Sigma. Os detalhes são explicados nesta postagem do blog. Você pode facilmente desligar o assistente e usar o Hayabusa da maneira tradicional adicionando a opção -w, --no-wizard .
O conjunto de regras core permite regras com status de test ou stable e nível high ou critical . Estas são regras de alta qualidade, de alta confiança e relevância e não devem produzir muitos falsos positivos. O status da regra é test ou stable , o que significa que nenhum falso positivo foi relatado por mais de 6 meses. As regras corresponderão às técnicas do invasor, atividades suspeitas genéricas ou comportamento malicioso. É o mesmo que usar as opções --exclude-status deprecated,unsupported,experimental --min-level high .
O conjunto de regras core+ permite regras com status de test ou stable e nível medium ou superior. as regras medium geralmente precisam de ajustes adicionais, pois determinados aplicativos, comportamento legítimo do usuário ou scripts de uma organização podem ser correspondidos. É o mesmo que usar as opções --exclude-status deprecated,unsupported,experimental --min-level medium .
O conjunto de regras core++ permite regras com status experimental , test ou stable e nível medium ou superior. Essas regras são inovadoras. Eles são validados em relação aos arquivos evtx de linha de base disponíveis no projeto SigmaHQ e revisados por vários engenheiros de detecção. Fora isso, eles praticamente não foram testados no início. Use-os se quiser detectar ameaças o mais cedo possível, ao custo de gerenciar um limite mais alto de falsos positivos. É o mesmo que usar as opções --exclude-status deprecated,unsupported --min-level medium .
O conjunto de regras Emerging Threats (ET) permite regras que possuem uma tag detection.emerging_threats . Estas regras visam ameaças específicas e são especialmente úteis para ameaças atuais onde ainda não há muita informação disponível. Estas regras não devem ter muitos falsos positivos, mas diminuirão de relevância com o tempo. Quando essas regras não estão habilitadas, é o mesmo que usar a opção --exclude-tag detection.emerging_threats . Ao executar Hayabusa tradicionalmente sem o assistente, estas regras serão incluídas por padrão.
O conjunto de regras Threat Hunting (TH) permite regras que possuem uma tag detection.threat_hunting . Essas regras podem detectar atividades maliciosas desconhecidas, mas normalmente terão mais falsos positivos. Quando essas regras não estão habilitadas, é o mesmo que usar a opção --exclude-tag detection.threat_hunting . Ao executar Hayabusa tradicionalmente sem o assistente, estas regras serão incluídas por padrão.
A partir do Hayabusa v2.16.0, habilitamos um filtro baseado em canal ao carregar arquivos .evtx e regras .yml . O objetivo é tornar a digitalização o mais eficiente possível, carregando apenas o necessário. Embora seja possível haver vários provedores em um único log de eventos, não é comum ter vários canais dentro de um único arquivo evtx. (A única vez que vimos isso foi quando alguém mesclou artificialmente dois arquivos evtx diferentes para o projeto sample-evtx.) Podemos usar isso a nosso favor, primeiro verificando o campo Channel no primeiro registro de cada arquivo .evtx especificado. a ser digitalizado. Também verificamos quais regras .yml usam quais canais especificados no campo Channel da regra. Com essas duas listas, carregamos apenas regras que utilizam canais que estão realmente presentes nos arquivos .evtx .
Assim, por exemplo, se um usuário quiser verificar Security.evtx , apenas regras que especifiquem Channel: Security serão usadas. Não adianta carregar outras regras de detecção, por exemplo regras que apenas procuram eventos no log Application , etc... Observe que os campos de canal (Ex: Channel: Security ) não são explicitamente definidos dentro das regras originais do Sigma. Para regras Sigma, os campos de IDs de canal e evento são definidos implicitamente com campos service e category em logsource . (Ex: service: security ) Ao fazer a curadoria de regras Sigma no repositório hayabusa-rules, desabstraímos o campo logsource e definimos explicitamente os campos de canal e ID de evento. Explicamos como e por que fazemos isso em detalhes aqui.
Atualmente, existem apenas duas regras de detecção que não possuem Channel definido e que se destinam a verificar todos os arquivos .evtx são as seguintes:
Se quiser usar essas duas regras e verificar todas as regras em relação aos arquivos .evtx carregados, você precisará adicionar a opção -A, --enable-all-rules nos comandos csv-timeline e json-timeline . Em nossos benchmarks, a filtragem de regras geralmente oferece uma melhoria de velocidade de 20% a 10x, dependendo de quais arquivos estão sendo verificados e, claro, usa menos memória.
A filtragem de canal também é usada ao carregar arquivos .evtx . Por exemplo, se você especificar uma regra que procure eventos com um canal Security , não fará sentido carregar arquivos .evtx que não sejam do log Security . Em nossos benchmarks, isso proporciona um benefício de velocidade de cerca de 10% com verificações normais e até 60%+ de aumento de desempenho ao verificar com uma única regra. Se você tiver certeza de que vários canais estão sendo usados dentro de um único arquivo .evtx , por exemplo, alguém usou uma ferramenta para mesclar vários arquivos .evtx , desative essa filtragem com -a, --scan-all-evtx-files opção nos comandos csv-timeline e json-timeline .
Observação: a filtragem de canal funciona apenas com arquivos
.evtxe você receberá um erro se tentar carregar logs de eventos de um arquivo JSON com-J, --json-inpute também especificar-Aou-a.
csv-timeline O comando csv-timeline criará uma linha do tempo forense de eventos em 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 padrão: 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: Ativar o filtro EID irá acelerar a análise em cerca de 10-15% nos nossos testes, mas existe a possibilidade de faltar 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 ) e regras ruidosas (aquelas cujo ID de regra está listado em .rulesconfignoisy_rules.txt ):Nota: Recentemente, as regras obsoletas agora estão localizadas em um diretório separado no repositório sigma, portanto não são mais incluídas por padrão no Hayabusa. Portanto, você provavelmente não precisará ativar regras 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
Regras de carregamento:
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
Erros durante a verificação:
[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 . Você pode adicionar informações GeoIP (organização ASN, cidade e país) aos campos SrcIP (IP de origem) e campos TgtIP (IP de destino) com os dados de geolocalização GeoLite2 gratuitos.
Passos:
.mmdb da página de download e salve-os em um diretório. Os nomes dos arquivos devem ser chamados GeoLite2-ASN.mmdb , GeoLite2-City.mmdb e GeoLite2-Country.mmdb .csv-timeline ou json-timeline , adicione a opção -G seguida do diretório com os bancos de dados MaxMind. Quando csv-timeline é usada, as 6 colunas a seguir serão geradas adicionalmente: SrcASN , SrcCity , SrcCountry , TgtASN , TgtCity , TgtCountry .
Quando json-timeline é usado, os mesmos campos SrcASN , SrcCity , SrcCountry , TgtASN , TgtCity , TgtCountry serão adicionados ao objeto Details , mas apenas se contiverem informações.
Quando SrcIP ou TgtIP for localhost ( 127.0.0.1 , ::1 , etc...), SrcASN ou TgtASN será gerado como Local .
Quando SrcIP ou TgtIP for um endereço IP privado ( 10.0.0.0/8 , fe80::/10 , etc...), SrcASN ou TgtASN será gerado como Private .
Os nomes dos campos que contêm endereços IP de origem e destino que são pesquisados nos bancos de dados GeoIP são definidos em rules/config/geoip_field_mapping.yaml . Você pode adicionar a esta lista, se necessário. Há também uma seção de filtro neste arquivo que determina quais eventos extrair informações de endereço IP.
Os bancos de dados Geoip MaxMind são atualizados a cada 2 semanas. Você pode instalar a ferramenta MaxMind geoipupdate aqui para atualizar automaticamente esses bancos de dados.
Etapas no macOS:
brew install geoipupdate/usr/local/etc/GeoIP.conf : coloque seu AccountID e LicenseKey que você crie após o login no site MaxMind. Certifique-se de que a linha EditionIDs diz EditionIDs GeoLite2-ASN GeoLite2-City GeoLite2-Country .geoipupdate .-G /usr/local/var/GeoIP quando você deseja adicionar informações geoip.Etapas no Windows:
geoipupdate_4.10.0_windows_amd64.zip ) na página Releases.ProgramDataMaxMind/GeoIPUpdateGeoIP.conf : coloque seu AccountID e LicenseKey você crie após o login no site MaxMind. Certifique-se de que a linha EditionIDs diz EditionIDs GeoLite2-ASN GeoLite2-City GeoLite2-Country .geoipupdate . csv-timeline ./rules/config/channel_abbreviations.txt : mapeamentos de nomes de canais e suas abreviações.
./rules/config/default_details.txt : O arquivo de configuração para que informações de campo padrão ( %Details% do campo) devem ser emitidas se não houver details: a linha for especificada em uma regra. Isso é baseado no nome do provedor e IDs de eventos.
./rules/config/eventkey_alias.txt : Este arquivo possui os mapeamentos de aliases de nome curto para campos e seus nomes de campo mais longos originais.
Exemplo:
InstanceID,Event.UserData.UMDFHostDeviceArrivalBegin.InstanceId
IntegrityLevel,Event.EventData.IntegrityLevel
IpAddress,Event.EventData.IpAddress
Se um campo não estiver definido aqui, o Hayabusa verificará automaticamente em Event.EventData para o campo.
./rules/config/exclude_rules.txt : Este arquivo possui uma lista de IDs de regra que serão excluídos do uso. Geralmente, isso ocorre porque uma regra substituiu outra ou a regra não pode ser usada em primeiro lugar. Como firewalls e IDSEs, qualquer ferramenta baseada em assinatura exigirá alguma ajuste para ajustar seu ambiente, para que você precise excluir permanente ou temporariamente certas regras. Você pode adicionar um ID de regra (Exemplo: 4fe151c2-ecf9-4fae-95ae-b88ec9c2fca6 ) para ./rules/config/exclude_rules.txt para ignorar qualquer regra que você não precisa ou não pode ser usada.
./rules/config/noisy_rules.txt : Este arquivo é uma lista de IDs de regra que são desativados por padrão, mas que podem ser ativados ativando regras barulhentas com a opção -n, --enable-noisy-rules . Essas regras geralmente são barulhentas por natureza ou devido a falsos positivos.
./rules/config/target_event_IDs.txt : Somente os IDs do evento especificados neste arquivo serão digitalizados se o filtro EID estiver ativado. Por padrão, o Hayabusa digitalizará todos os eventos, mas se você quiser melhorar o desempenho, use a opção -E, --EID-filter . Isso geralmente resulta em uma melhoria de velocidade de 10 ~ 25%.
json-timeline O comando json-timeline criará uma linha do tempo forense dos eventos no formato JSON ou JSONL. A saída para o JSONL será mais rápida e menor do que o JSON, por isso é bom se você quiser importar os resultados para outra ferramenta como a pilha elástica. O JSON é melhor se você quiser analisar manualmente os resultados com um editor de texto. A saída CSV é boa para importar prazos menores (geralmente menos de 2 GB) em ferramentas como LibreOffice ou Timeline Explorer. O JSON é melhor para uma análise mais detalhada dos dados (incluindo grandes arquivos de resultados) com ferramentas como o jq pois os campos Details são separados para facilitar a análise. (Na saída CSV, todos os campos de log de eventos estão em uma grande coluna Details , fazendo classificação de dados, etc ... mais 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 As opções e arquivos de configuração para json-timeline são os mesmos que csv-timeline , mas uma opção extra -L, --JSONL-output para saída para o formato JSONL.
level-tuning O comando level-tuning permitirá que você ajuste os níveis de alerta das regras, aumentando ou diminuindo o nível de risco de acordo com o seu ambiente.
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 Os autores de hayabusa e regra de Sigma determinarão o nível de risco do alerta ao escrever suas regras. No entanto, o nível de risco real pode diferir de acordo com o meio ambiente. Você pode ajustar o nível de risco das regras, adicionando-as a ./rules/config/level_tuning.txt e executando hayabusa.exe level-tuning , que atualizará a linha level no arquivo de regra. Observe que o arquivo de regra será atualizado diretamente.
AVISO: Sempre que você executa
update-rules, o nível de alerta original substituirá todas as configurações que você alterou, para que você precise executar o comandolevel-tuningapós toda vez que você executarupdate-rulesse quiser alterar os níveis.
./rules/config/level_tuning.txt linha de amostra:
id,new_level
00000000-0000-0000-0000-000000000000,informational # sample level tuning line
Nesse caso, o nível de risco da regra com um id de 00000000-0000-0000-0000-000000000000 no diretório de regras terá seu level reescrito para informational . Os níveis possíveis a serem definidos são 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-profileminimal : hayabusa.exe set-default-profile minimalsuper-verbose : hayabusa.exe set-default-profile super-verboseupdate-rules O comando update-rules sincronizará a pasta rules com o repositório do GitHub das regras de Hayabusa, atualizando as regras e os arquivos de configuração.
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 Você normalmente apenas executará isso: hayabusa.exe update-rules
Hayabusa possui 5 perfis de saída predefinidos a serem usados em config/profiles.yaml :
minimalstandard (padrão)verboseall-field-infoall-field-info-verbosesuper-verbosetimesketch-minimaltimesketch-verbose Você pode facilmente personalizar ou adicionar seus próprios perfis editando este arquivo. Você também pode alterar facilmente o perfil padrão com set-default-profile --profile . Use o comando list-profiles para mostrar os perfis disponíveis e suas informações de campo.
minimal do perfil %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 Em vez de produzir as informações mínimas details , todas as informações de campo nas seções EventData e UserData serão emitidas junto com seus nomes de campo originais.
%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-minimalSaída para um formato compatível com a importação para o 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%
Os seguintes benchmarks foram realizados em um Lenovo P51 2018 (CPU do Xeon 4 Core / 64 GB de RAM) com 3 GB de dados EVTX e regras 3891 ativadas. (2023/06/01)
| Perfil | Tempo de processamento | Saída de arquivo | Aumento do tamanho do arquivo |
|---|---|---|---|
| mínimo | 8 minutos e 50 segundos | 770 MB | -30% |
| padrão (padrão) | 9 minutos 00 segundos | 1,1GB | Nenhum |
| detalhado | 9 minutos 10 segundos | 1,3 GB | +20% |
| All-Field-Info | 9 minutos 3 segundos | 1,2 GB | +10% |
| All-Field-Info-Verbose | 9 minutos 10 segundos | 1,3 GB | +20% |
| super-verbose | 9 minutos 12 segundos | 1,5 GB | +35% |
As informações a seguir podem ser emitidas com perfis de saída internos:
| Nome do alias | Informações de saída Hayabusa |
|---|---|
| %Allfieldinfo% | Todas as informações de campo. |
| %Canal% | O nome do log. |
| %Computador% | O campo |
| %Detalhes% | O campo de details na regra de detecção da YML, no entanto, apenas as regras de Hayabusa têm esse campo. Este campo fornece informações extras sobre o alerta ou evento e pode extrair dados úteis dos campos nos logs de eventos. Por exemplo, nomes de usuário, informações da linha de comando, informações de processo, etc ... Quando um espaço reservado aponta para um campo que não existe ou existe um mapeamento incorreto de alias, ele será produzido como n/a (não disponível). Se o campo details não for especificado (isto é, regras de Sigma), as mensagens padrão details as mensagens para extrair campos definidos em ./rules/config/default_details.txt serão emitidos. Você pode adicionar mais mensagens de details padrão adicionando o Provider Name , a mensagem EventID e details que deseja produzir em default_details.txt . Quando nenhum campo details é definido em uma regra nem em default_details.txt , todos os campos serão emitidos para a coluna details . |
| %ExtrafieldInfo% | Imprima as informações de campo que não foram emitidas em %detalhes %. |
| %EventId% | O campo |
| %Evtxfile% | O nome do EVTX que causou o alerta ou evento. |
| %Nível% | O campo level na regra de detecção de YML. ( informational , low , medium , high , critical ) |
| %Mitretactics% | MITER ATT & CK TATICS (EX: Acesso inicial, movimento lateral, etc ...). |
| %Mitretags% | MITER ATT & CK GRUPO ID, ID da técnica e ID de software. |
| %De outros tags% | Qualquer palavra -chave no campo tags em uma regra de detecção de YML que não está incluída no MitreTactics ou MitreTags . |
| %Provedor% | O atributo Name em |
| %Recordid% | O ID do registro do evento do |
| %RegulAuthor% | O campo author na regra de detecção da YML. |
| %RegulCreationDate% | O campo date na regra de detecção de YML. |
| %De regras | O nome do arquivo da regra de detecção que gerou o alerta ou evento. |
| %Renemodifieddate% | O campo modified na regra de detecção de YML. |
| %Governetitle% | O campo title na regra de detecção de YML. |
| %Status% | O campo status na regra de detecção de YML. |
| %Timestamp% | O padrão é YYYY-MM-DD HH:mm:ss.sss +hh:mm formato. --UTC . |
Você também pode adicionar estes aliases extras ao seu perfil de saída, se precisar deles:
| Nome do alias | Informações de saída Hayabusa |
|---|---|
| %Renderedmessage% | O campo |
| %Regra% | O campo id na regra de detecção de YML. |
NOTA: Eles não estão incluídos em perfis embutidos, portanto, você precisará editar manualmente o arquivo config/default_profile.yaml e adicionar as seguintes linhas:
Message: "%RenderedMessage%"
RuleID: "%RuleID%"
Você também pode definir aliases de chave de evento para produzir outros campos.
Para economizar espaço, usamos as seguintes abrevações ao exibir o level de alerta.
crit : criticalhigh : highmed : mediumlow : lowinfo : informational Para economizar espaço, usamos as seguintes abreviações ao exibir tags táticas ATT e CK de miter. Você pode editar livremente essas abreviações no arquivo de configuração ./config/mitre_tactics.txt .
Recon : reconhecimentoResDev : Desenvolvimento de RecursosInitAccess : acesso inicialExec : ExecuçãoPersis : PersistênciaPrivEsc : escalada de privilégiosEvas : evasão de defesaCredAccess : acesso de credenciaisDisc : descobertaLatMov : movimento lateralCollect : ColeçãoC2 : comando e controleExfil : ExfiltraçãoImpact : Impacto Para economizar espaço, usamos as seguintes abreviações ao exibir canal. Você pode editar livremente essas abreviações no ./rules/config/channel_abbreviations.txt arquivo de configuração.
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 As seguintes abreviações são usadas nas regras para tornar a saída o mais concisa possível:
Acct -> ContaAddr -> endereçoAuth -> AutenticaçãoCli -> ClienteChan -> canalCmd -> comandoCnt -> contagemComp -> computadorConn -> conexão/conectadoCreds -> CredenciaisCrit -> críticoDisconn -> desconexão/desconectadoDir -> diretórioDrv -> driverDst -> DestinoEID -> ID do eventoErr -> erroExecFW -> FirewallGrp -> GrupoImg -> imagemInj -> injeçãoKrb -> KerberosLID -> id de logonMed -> MédioNet -> redeObj -> objetoOp -> Operacional/OperaçãoProto -> ProtocoloPW -> SenhaReconn -> ReconexãoReq -> solicitaçãoRsp -> RespostaSess -> SessãoSig -> assinaturaSusp -> suspeitoSrc -> fonteSvc -> ServiçoSvr -> servidorTemp -> temporárioTerm -> terminação/encerradoTkt -> TicketTgt -> TargetUnkwn -> DesconhecidoUsr -> UsuárioPerm -> PermamentPkg -> pacotePriv -> privilégioProc -> ProcessoPID -> ID do processoPGUID -> Process GUID (ID exclusivo global)Ver -> versão A barra de progresso funcionará apenas com vários arquivos EVTX. Ele será exibido em tempo real o número e a porcentagem dos arquivos EVTX que terminou de analisar.
Os alertas serão emitidos em cores com base no level de alerta. Você pode alterar as cores padrão no arquivo de configuração em ./config/level_color.txt no formato de level,(RGB 6-digit ColorHex) . Se você deseja desativar a saída de cores, pode usar --no-color da opção.
Eventos totais, o número de eventos com hits, métricas de redução de dados, detecções totais e exclusivas, datas com mais detecções, computadores principais com detecções e alertas superiores são exibidos após cada varredura.
Se você adicionar a opção -T, --visualize-timeline , o recurso da linha do tempo da frequência de eventos exibe uma linha do tempo de frequência Sparkline dos eventos detectados. Nota: É preciso haver mais de 5 eventos. Além disso, os personagens não renderizarão corretamente no prompt de comando padrão ou no prompt de PowerShell; portanto, use um terminal como o Windows Terminal, Iterm2, etc ...
As regras de detecção de Hayabusa são escritas em um formato YML do tipo Sigma e estão localizadas na pasta rules . As regras estão hospedadas em https://github.com/yamato-security/hayabusa-rules, então envie quaisquer problemas e retire solicitações de regras lá em vez do repositório principal de Hayabusa.
Leia o repositório Hayabusa-Rules Readme para entender sobre o formato de regra e como criar regras.
Todas as regras do repositório Hayabusa-Rules devem ser colocadas na pasta rules . As regras de nível informational são consideradas events , enquanto qualquer coisa com um level de low e mais alto são considerados alerts .
A estrutura do diretório de regras de Hayabusa é separada em 2 diretórios:
builtin : logs que podem ser gerados pela funcionalidade embutida do Windows.sysmon : logs gerados pelo Sysmon.As regras são ainda mais separadas nos diretórios por tipo de log (exemplo: segurança, sistema, etc ...) e são nomeados no seguinte formato:
Confira as regras atuais a serem usadas como modelo para criar novas ou para verificar a lógica de detecção.
Hayabusa apóia a Sigma governa de maneira nativamente uma única exceção de lidar com os campos logsource internamente. Para reduzir os falsos positivos, as regras da Sigma devem ser executadas através do nosso conversor explicado aqui. Isso adicionará o Channel e EventID adequado e executará o mapeamento de campo para determinadas categorias como process_creation .
Quase todas as regras de Hayabusa são compatíveis com o formato Sigma, para que você possa usá -las como as regras da Sigma para converter em outros formatos do SIEM. As regras de Hayabusa são projetadas exclusivamente para análise de log de eventos do Windows e têm os seguintes benefícios:
details extras para exibir informações adicionais tiradas apenas dos campos úteis no log.|equalsfield e |endswithfield .Até onde sabemos, o Hayabusa fornece o maior suporte nativo para a Sigma exclui qualquer ferramenta de análise de log de eventos de código aberto do Windows.
Para detectar adequadamente atividades maliciosas nas máquinas do Windows, você precisará melhorar as configurações de log padrão. Criamos um projeto separado para documentar quais configurações de log precisam ser ativadas, bem como scripts para ativar automaticamente as configurações adequadas em https://github.com/yamato-security/enablewindowslogsettings.
Também recomendamos os seguintes sites para orientação:
Para criar a maior evidência forense e detectar com a maior precisão, você precisa instalar o Sysmon. Recomendamos os seguintes sites e arquivos de configuração:
Adoraríamos qualquer forma de contribuição. Solicitações de puxar, criação de regras e amostra de logs EVTX são os melhores, mas solicitações de recursos, notificando -nos de bugs, etc ... também são muito bem -vindos.
No mínimo, se você gosta da nossa ferramenta, dê -nos uma estrela no Github e mostre seu apoio!
Por favor, envie todos os bugs que encontrar aqui. Atualmente, este projeto é mantido ativamente e estamos felizes em corrigir quaisquer bugs relatados.
Se você encontrar algum problema (falsos positivos, bugs, etc ...) com as regras de Hayabusa, denuncie-as à página Hayabusa-Rules Github.
Se você encontrar algum problema (falsos positivos, bugs, etc ...) com as regras da Sigma, informe -as à página de problemas do Sigmahq Github a montante aqui.
O Hayabusa é liberado no AGPLV3 e todas as regras são divulgadas sob a Licença de Regra de Detecção (DRL) 1.1.
Hayabusa usa dados geolite2 criados pelo MaxMind, disponível em https://www.maxmind.com.
Você pode receber as últimas notícias sobre Hayabusa, atualizações de regras, outras ferramentas de segurança Yamato, etc ... nos seguindo no Twitter em @Securityyamato.
