
Executar o Hayabusa em massa em uma pasta de coleções KAPE, uma execução por host, com relatórios por host e um painel de triagem entre hosts
Um wrapper PowerShell que executa o Hayabusa em uma pasta de coleções KAPE, uma execução por host, e consolida os resultados em uma única visão de triagem entre hosts.
O Hayabusa já aceita um diretório inteiro com -d, e seu resumo HTML detalha os resultados por computador. Uma pasta de coleções KAPE ainda deixa dois trabalhos para fazer manualmente. Cada ZIP precisa ser extraído e cada imagem de disco montada antes que o Hayabusa possa lê-la, e uma execução sobre todas elas gera uma saída combinada, sem relatório ou linha do tempo própria para cada host. Esta ferramenta faz essa parte. Aponte-a para uma pasta com uma entrada por host e você obtém, para cada host, o relatório de alertas HTML do Hayabusa, uma linha do tempo CSV e um log, além de um painel mostrando quais hosts estão piores e quais regras dispararam onde.
Referência completa de uso: docs/USAGE.md
O painel após uma execução sobre oito hosts, com o piso de severidade em médio:

O console durante a mesma execução:

Computer do Hayabusa, para que saídas soltas que o KAPE nomeou com base em uma unidade ainda caiam sob o host correto.Pré-lançamento. Foi executado contra imagens e ZIPs reais do Hayabusa 4.1.0 e KAPE no Windows, e a suíte de testes roda em CI no Windows PowerShell 5.1, PowerShell 7 no Windows e PowerShell 7 no Linux. Dois comportamentos ainda precisam da evidência correta para serem confirmados, listados em Ainda não confirmado no Windows. Verifique essa lista antes de confiar em um deles em um relatório.
hayabusa.exe update-rules uma vez no início do engajamento e deixe as regras em paz até que ele termine, para que cada host seja verificado contra o mesmo conjunto.Clone o repositório, ou baixe-o como ZIP do GitHub e extraia-o:
git clone https://github.com/rorywag/Hayabusa-Bulk-Runner.git
Mantenha a pasta lib ao lado dos dois scripts, já que eles carregam tudo a partir dela. O Windows marca arquivos de um ZIP baixado como vindos da internet. A política de execução de escopo de Processo mostrada abaixo já os permite, então não há nada para desbloquear.
.\Invoke-BulkHayabusa.ps1 -InputRoot D:\Cases\Case01\KAPE -OutputRoot D:\Cases\Case01\Output -HayabusaPath D:\Tools\hayabusa\hayabusa.exe
Ele imprime uma linha por host conforme avança, depois um breve resumo e onde procurar:
[1/4] DC01 ... Completed, 12 detections
[2/4] FS02 ... Completed, 6 detections
WARNING: [3/4] WS03 ... Failed: Hayabusa exited with code 2. See D:\Cases\Case01\Output\WS03\WS03_hayabusa.log. No CSV was written.
[4/4] WS04 ... skipped, already Completed
Done: 3 processed, 2 completed, 0 completed with errors, 1 failed, 1 skipped.
Output is in D:\Cases\Case01\Output. Open triage_dashboard.html there to start triage.
Em uma janela nova do PowerShell, o script pode ser bloqueado pela política de execução. Isto o permite apenas para essa janela, e não altera nada na máquina:
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
.\Invoke-BulkHayabusa.ps1 -Help, ou -h, imprime um breve resumo de uso. Para a lista completa de parâmetros, exemplos práticos, o modelo de entrada e saída e a configuração de engajamento, veja docs/USAGE.md.
A evidência é apenas lida.
OutputRoot\_diff com a imagem de evidência como seu pai. O Windows reproduz o journal no filho e o pai é apenas lido, verificado na saída do KAPE com o hash do pai igual antes e depois.OutputRoot\_work. O ZIP em si é apenas lido._work, _mnt e _diff, além do relatório e da linha do tempo anteriores de um host pouco antes de esse host ser reexecutado. Se uma desmontagem falhar, tudo depois dela é deixado no lugar e o erro diz o que ainda está lá.docs/USAGE.md cobre o resto:
Veja SECURITY.md para saber como relatar uma vulnerabilidade de forma privada.
MIT. Veja LICENSE.