joeavanzato/trawlerPowerShell-Skript, das Incident Respondern hilft, potenzielle Persistenzmechanismen von Angreifern zu entdecken.
Trawler ist ein PowerShell-Skript, das Incident Respondern dabei helfen soll, potenzielle Anzeichen einer Kompromittierung auf Windows-Hosts zu entdecken. Der Fokus liegt dabei auf Persistenzmechanismen, einschließlich geplanter Aufgaben, Dienste, Registrierungsänderungen, Startobjekte, Binärdateiänderungen und mehr.
Derzeit kann Trawler die meisten Persistenstechniken erkennen, die von MITRE und Atomic Red Team speziell genannt werden, und es werden regelmäßig weitere Erkennungen hinzugefügt.
Laden Sie einfach trawler.ps1 herunter und führen Sie es in einer administrativen PowerShell/cmd-Eingabeaufforderung aus – alle Erkennungen werden in der Konsole angezeigt und auch in einer CSV-Datei (‚detections.csv‘) im aktuellen Arbeitsverzeichnis gespeichert. Die generierte CSV enthält Erkennungsname, Quelle, Risiko, Metadaten und die relevante MITRE-Technik.
Oder verwenden Sie diesen Einzeiler in einem administrativen PowerShell-Terminal:
iex ((New-Object System.Net.WebClient).DownloadString('https://raw.githubusercontent.com/joeavanzato/Trawler/main/trawler.ps1'))
Bestimmte Erkennungen verfügen über integrierte Zulassungslisten, um Rauschen durch Standard-Windows-Konfigurationen (10/2016/2019/2022) zu reduzieren – z. B. erwartete geplante Aufgaben, Dienste usw. Natürlich ist es immer möglich, dass Angreifer diese direkt übernehmen und sich mit großer Detailtreue als Standard-OS-Prozess tarnen – seien Sie bei der Analyse und Erkennung geschickter Gegner vorsichtig und verwenden Sie mehrere Analysemethoden.
Wenn Sie Beispiele oder Ideen für zusätzliche Erkennungen haben, reichen Sie bitte ein Issue oder einen PR mit den entsprechenden technischen Details/Verweisen ein – der Code ist derzeit noch etwas unordentlich und wird mit der Zeit bereinigt.
Wenn Sie außerdem offensichtliche Fehlalarme identifizieren, lassen Sie es mich bitte wissen, indem Sie ein Issue oder PR auf GitHub eröffnen! Die offensichtlichsten Kandidaten dafür sind nicht standardmäßige COMs, Dienste oder Aufgaben.
-scanoptions : Durch Tabulator blättern, um mögliche Erkennungen anzuzeigen, und eine Teilmenge mit kommagetrennten Begriffen auswählen (z. B. .\trawler.ps1 -scanoptions Services,Processes) oder überspringen, um alle Erkennungen durchzuführen
-quiet : Unterdrückt die Erkennungsausgabe in der Konsole
-snapshot : Pfad zu einer vorherigen Trawler-JSON-Ausgabe, die als Zulassungsliste verwendet werden soll.
-outpath : Definiert einen benutzerdefinierten Dateipfad zum Speichern der Erkennungsausgabe (Standard: "$PSScriptRoot\detections.csv")
-drivetarget : Definiert die Variable für ein eingehängtes Ziellaufwerk (z. B. .\trawler.ps1 -targetdrive "D:") – (Standard: lokales System)
-daysago : Definiert, wie viele ‚Tage zurück‘ wir für zeitbasierte Erkennungen berücksichtigen möchten (Standard: 45)
-hashmode : Definiert, welcher Hashing-Algorithmus für unterstützte Erkennungen verwendet werden soll – unterstützt sha1, md5 oder sha256 (Standard: sha1)
-evtx : Aktiviert die Erstellung einer Ereignisprotokollquelle und das Schreiben von Erkennungen in das Anwendungsereignisprotokoll unter Source=trawler mit EID=9001 (Standard: deaktiviert)
PersistenceSniper ist ein großartiges Tool – ich habe es in der Vergangenheit intensiv genutzt – aber es gibt einige wichtige Punkte, die diese Hilfsprogramme unterscheiden:
Insgesamt sind diese Tools extrem ähnlich, nähern sich dem Problem jedoch aus leicht unterschiedlichen Winkeln – PersistenceSniper liefert alle Informationen an den Analysten zurück, während Trawler versucht, die zurückgegebenen Ergebnisse auf solche zu beschränken, die wahrscheinlich potenzielle Persistenzmechanismen von Angreifern sind. Daher besteht bei Trawler die Möglichkeit von Fehlalarmen, wenn ein Angreifer ein auf der Zulassungsliste stehendes Element vollständig nachahmt.
Als Beispiel: PersistenceSniper gibt alle ‚nicht sicheren‘ Windows-Dienste zurück, während Trawler nur diejenigen zurückgibt, die einer bestimmten Erkennungsregel entsprechen usw.
Trawler unterstützt das Laden einer Zulassungsliste aus einem ‚Snapshot‘ – dazu sind zwei Schritte erforderlich.
Das war's – alle relevanten Erkennungen greifen dann auf die Snapshot-Datei als Zulassungsliste zu, um Rauschen zu reduzieren und potenzielle Änderungen am Basis-Image zu identifizieren.
(Die Zulassungsliste wird für die meisten Prüfungen implementiert, aber noch nicht für alle – die Implementierung ist noch aktiv.)
Während einer Untersuchung müssen Ermittler oft ein neues Laufwerk einhängen, das ein abgebildetes Windows-Gerät darstellt – Trawler unterstützt jetzt teilweise das Scannen dieser eingehängten Laufwerke durch die Verwendung des Parameters '-drivetarget'.
Zur Laufzeit setzt Trawler temporäre Skriptvariablen neu, um dateibasierte Artefakte zu überprüfen, und versucht auch, relevante Registrierungsstrukturen (HKLM\SOFTWARE, HKLM\SYSTEM, NTUSER.DATs, USRCLASS.DATs) unter HKLM/HKU mit dem Präfix 'ANALYSIS_' zu laden. Trawler versucht auch, diese temporär geladenen Strukturen nach Abschluss des Skripts wieder zu entladen.
Wenn Sie beispielsweise ein Image an einem Ort wie 'F:\Test' eingehängt haben, das das NTFS-Dateisystem enthält ('F:\Test\Windows', 'F:\Test\User' usw.), dann können Sie Trawler wie folgt aufrufen:
.\trawler.ps1 -drivetarget "F:\Test"
Bitte beachten Sie, dass die Zuordnung eines UNC-Pfads zu einem live entfernten Gerät NICHT funktioniert, da diese Dateien aufgrund von Systemsperren nicht zugänglich sind. Ich arbeite an einem Ansatz, der live entfernte Geräte behandelt, bleiben Sie dran.
Die meisten anderen Prüfungen funktionieren einwandfrei, da sie vollständig auf dem Lesen von Registrierungsstrukturen oder dateibasierten Artefakten basieren (oder entsprechend umgewandelt werden können, z. B. direktes Lesen von Task-XML anstelle der Verwendung integrierter Cmdlets).
Alle Einschränkungen bei Prüfungen während der Laufwerk-Neuausrichtung werden im GitHub-Wiki ausführlicher erläutert.
TODO
Bitte beachten Sie, dass einige dieser Techniken (natürlich) stärker erkannt werden als andere – zum Beispiel erkennen wir nicht alle möglichen Registrierungsänderungen, sondern überprüfen bestimmte Schlüssel auf offensichtliche Änderungen und verwenden die allgemeine MITRE-Technik „Modify Registry“, wenn keine andere Technik anwendbar ist. Bei anderen Elementen wie COM-Hijacking überprüfen wir alle Einträge im entsprechenden Registrierungsabschnitt, vergleichen sie mit ‚bekannt-guten‘ Mustern und heben unbekannte oder nicht übereinstimmende Werte hervor, was zu einer viel vollständigeren Erkennungsoberfläche für diese spezielle Technik führt.
Dieses Tool wäre ohne die erstaunliche InfoSec-Community nicht möglich – die wichtigsten Referenzen, die ich verwendet habe, sind unten aufgeführt.