Hayabusa-Bulk-Runner

Ein PowerShell-Wrapper, der Hayabusa über einen Ordner mit KAPE-Sammlungen laufen lässt, einen Durchlauf pro Host, und die Ergebnisse in einer einzigen hostübergreifenden Triage-Ansicht zusammenführt.

Hayabusa akzeptiert bereits ein ganzes Verzeichnis mit -d, und seine HTML-Zusammenfassung schlüsselt die Ergebnisse nach Computer auf. Ein Ordner mit KAPE-Sammlungen hinterlässt dennoch zwei Aufgaben, die von Hand erledigt werden müssen. Jede ZIP muss entpackt und jedes Disk-Image eingebunden werden, bevor Hayabusa es lesen kann, und ein Durchlauf über alle zusammen liefert eine kombinierte Ausgabe, ohne eigenen Bericht oder eigene Timeline für jeden Host. Genau das übernimmt dieses Tool. Richte es auf einen Ordner mit einem Eintrag pro Host, und du erhältst für jeden Host Hayabusas HTML-Alarmbericht, eine CSV-Timeline und ein Log, plus ein Dashboard, das zeigt, welche Hosts am schlimmsten betroffen sind und welche Regeln wo ausgelöst haben.

Vollständige Nutzungsreferenz: docs/USAGE.md

Screenshots

Das Dashboard nach einem Durchlauf über acht Hosts, mit der Severity-Untergrenze bei medium:

Die Konsole während desselben Durchlaufs:

Was es tut

• Führt Hayabusa einmal pro Host aus, sodass jeder Host seinen eigenen HTML-Bericht, seine eigene CSV-Timeline und sein eigenes Log erhält statt einer kombinierten Ausgabe.
• Entpackt jede KAPE-ZIP und bindet jedes Disk-Image für dich ein und baut danach alles wieder ab, sobald der Host fertig ist.
• Erstellt ein hostübergreifendes Dashboard: Summen nach Severity, die ausgelösten Regeln und die Hosts, die jede einzelne getroffen hat, und jeden Host nach Schweregrad sortiert, schlimmster zuerst.
• Liest den Hostnamen aus Hayabusas eigenem Computer-Feld, sodass lose Ausgabe, die KAPE nach einem Laufwerk benannt hat, trotzdem unter dem richtigen Host landet.
• Setzt einen Fall fort. Führe denselben Befehl erneut aus, und es überspringt die bereits abgeschlossenen Hosts und nimmt die übrigen auf.
• Behandelt die Beweismittel durchgehend als schreibgeschützt und belegt dies mit einem Vorher-Nachher-Hash jedes Images.
• Nimmt eine Engagement-Konfiguration entgegen, sodass jeder Host in einem Fall mit denselben Einstellungen läuft.

Status

Pre-Release. Es wurde unter Windows gegen echte Hayabusa 4.1.0- und KAPE-Images und -ZIPs ausgeführt, und die Testsuite läuft in CI unter Windows PowerShell 5.1, PowerShell 7 unter Windows und PowerShell 7 unter Linux. Zwei Verhaltensweisen benötigen noch die passenden Beweismittel zur Bestätigung, aufgeführt unter Not yet confirmed on Windows. Prüfe diese Liste, bevor du dich in einem Bericht auf eine davon verlässt.

Anforderungen

• Windows. Dieses Tool führt Hayabusa aus und bindet Disk-Images nur unter Windows ein. Das Rollup kann überall neu erstellt werden, wo PowerShell läuft.
• Windows PowerShell 5.1 oder PowerShell 7.
• Hayabusa 4.1.0 mit seinen Regeln. Führe hayabusa.exe update-rules einmal zu Beginn des Engagements aus und lass die Regeln bis zum Abschluss unangetastet, damit jeder Host gegen denselben Satz geprüft wird.
• Eine erhöhte Sitzung, wenn eine Sammlung ein Disk-Image ist, einschließlich eines Disk-Images innerhalb einer ZIP.

Bezug

Klone das Repository oder lade es als ZIP von GitHub herunter und entpacke es:

git clone https://github.com/rorywag/Hayabusa-Bulk-Runner.git

Behalte den lib-Ordner neben den beiden Skripten, da sie alles daraus laden. Windows markiert Dateien aus einer heruntergeladenen ZIP als aus dem Internet stammend. Die unten gezeigte Execution Policy im Process-Scope erlaubt sie bereits, sodass nichts entsperrt werden muss.

Schnellstart

.\Invoke-BulkHayabusa.ps1 -InputRoot D:\Cases\Case01\KAPE -OutputRoot D:\Cases\Case01\Output -HayabusaPath D:\Tools\hayabusa\hayabusa.exe

Es gibt während des Laufs eine Zeile pro Host aus, dann eine kurze Zusammenfassung und wo nachzusehen ist:

[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.

In einem frischen PowerShell-Fenster kann das Skript durch die Execution Policy blockiert werden. Dies erlaubt es nur für dieses Fenster und ändert nichts auf dem Rechner:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

.\Invoke-BulkHayabusa.ps1 -Help oder -h gibt eine kurze Nutzungszusammenfassung aus. Die vollständige Parameterliste, ausgearbeitete Beispiele, das Eingabe- und Ausgabemodell und die Engagement-Konfiguration findest du in docs/USAGE.md.

Integrität der Beweismittel

Die Beweismittel werden ausschließlich gelesen.

• Disk-Images werden niemals direkt eingebunden. KAPE-Images sind beim Erstellen dirty, sodass ein schreibgeschütztes Einbinden überhaupt kein Volume anzeigt. Stattdessen bindet das Tool eine Differencing-Disk unter OutputRoot\_diff ein, mit dem Beweis-Image als übergeordnetes Element. Windows spielt das Journal in das Kind ab, und das übergeordnete Element wird nur gelesen, geprüft an KAPE-Ausgabe mit demselben Hash des übergeordneten Elements vorher und nachher.
• Ein bereits angehängtes Image wird abgelehnt, nicht wiederverwendet oder ausgehängt, da dieser Durchlauf es nicht angehängt hat.
• ZIPs werden in eine Arbeitskopie unter OutputRoot\_work entpackt. Die ZIP selbst wird nur gelesen.
• Nach jedem Host läuft der Abbau in fester Reihenfolge ab, egal was passiert ist: den Ordner-Mountpoint entfernen, falls einer verwendet wurde, das Kind aushängen, den leeren Mount-Ordner entfernen, das Kind löschen, das Extrakt löschen. Es wird niemals rekursiv durch einen Ordner gelöscht, der noch ein Mountpoint sein könnte. Das Tool löscht nur innerhalb seiner eigenen _work-, _mnt- und _diff-Ordner, plus den vorherigen Bericht und die Timeline eines Hosts, unmittelbar bevor dieser Host erneut ausgeführt wird. Wenn ein Aushängen fehlschlägt, bleibt alles danach an Ort und Stelle, und die Fehlermeldung sagt, was noch vorhanden ist.
• OutputRoot wird abgelehnt, wenn sein Pfad innerhalb von InputRoot liegt, damit die Ausgabe nicht neben den Beweismitteln landet.
• Nichts aus den Beweismitteln wird jemals ausgeführt. Werte daraus, wie Regeltitel und Computernamen, werden überall, wo sie ausgegeben werden, kodiert.

Dokumentation

docs/USAGE.md behandelt den Rest: