jymcheong/autottpAutomatisierte Taktiken, Techniken & Verfahren
Automatisierte Taktiken, Techniken & Verfahren. Das manuelle Wiederholen komplexer Abläufe für Regressionstests, Produktbewertungen, das Generieren von Daten für Forscher usw. kann mühsam sein. Ich habe mit der Idee gespielt, das Skripten von Empire (oder anderen Frameworks/Produkten/Toolkits, die APIs wie Metasploit (RPC), Cobalt-Strike usw. bereitstellen) mit einer IDE wie Visual Studio Code (oder einem Äquivalent) zu vereinfachen. Also begann ich, AutoTTP zu entwerfen. Dies ist noch stark in Arbeit. Getestet mit Empire 2.2.
Youtube – Überblick und ausgewählte Techniken im Detail
In meinem Fall sind die Taktiken gemäß meinem Angriffslebenszyklus-Modell organisiert. Es gibt andere Modelle wie Lockheed Martin's Kill-Chain(R), Mandiant Angriffslebenszyklus & Mitre's ATT&CK. Welches Modell auch immer es sein mag, eine "Taktik" gruppiert im Wesentlichen Techniken, z.B. Code-Ausführung/Payload-Ausführung kann auf viele Arten erreicht werden:
Ich verwende "Stage", um relevante "Taktiken" zu gruppieren. Wenn Sie in den Quellbaum schauen, spiegelt die Ordnerstruktur die Taktikspalte der Matrix wider. Die Matrix erwähnt auch entsprechende Kontrollen für jede offensive Taktik. Wie sind diese Stadien entstanden?
Das Venn-Diagramm in der Mitte des roten Kreises stammt vom Dartmouth College "Three Tenets for Secure Cyber-Physical System Design and Assessment". Es definiert die notwendigen und hinreichenden Bedingungen, oder einfach die Anforderungen jedes erfolgreichen physischen/logischen Angriffs. Ich habe den roten Ring (Stadien) um das Venn-Diagramm hinzugefügt, um typische offensive Abläufe zu veranschaulichen, die letztendlich zu Auswirkungen auf die Vertraulichkeit, Integrität von Informationen und Systemverfügbarkeit oder -sicherheit führen, wenn es sich um Cyber-Physical (denken Sie an Kritische Informationsinfrastruktur) handelt.
Ein Angreifer kann von Stufe 1 starten und direkt zu Stufe 4 gelangen, z.B. Standard-Admin-Anmeldedaten auf einer öffentlich zugänglichen Admin-Seite. Es muss nicht linear sein (Stufe 1->2->3->4). Nach der anfänglichen Infiltration könnte er/sie zuerst einige interne Informationssammlungen (Reconnaissance) durchgeführt haben, bevor er die Rechte auf der ersten Maschine ausweitet und dann einen entfernten Befehl an eine andere Zielmaschine im selben Netzwerk sendet. Für die nächste Opfermaschine handelt es sich um eine Stufe 2; erfolgreiche Payload-Lieferung und -Ausführung ermöglicht es dem Angreifer, die Kontrolle über eine weitere Maschine zu erlangen.
Die Datei links ist ein Verfahrensskript, die rechte ist ein Technikskript. Beachten Sie, dass das Verfahrensskript nicht mit zu vielen Empire-spezifischen Details überladen ist, viele Details sind im Technikskript gekapselt. Das Verfahrensskript sollte sich auf die Abfolge der Techniken unter Verwendung von Asset-Informationen wie Hostname/IP, welche E-Mail die Payload senden soll, welche Payload-Technik usw. konzentrieren.
Das Beispiel "Ist Benutzer Admin?" besteht tatsächlich aus mehreren Schritten, da es mindestens 3 Möglichkeiten gibt, wie in den Kommentaren des Skripts ausgeführt. Wir können natürlich benutzerdefinierte "Makros" in Empire, Metasploit usw. erstellen, aber das wird eng in ein bestimmtes Framework/Produkt integriert. Wir möchten die vorhandenen Tools nutzen und wiederverwendbare Techniken in Modulen organisieren, um sie auf prozeduraler Ebene (also der Automatisierung) kombinieren zu können.
Ich habe die gut strukturierten Module in Empire genutzt, um eine automatische Vervollständigungsklasse in Python zu erstellen. Anstatt den vollständigen Modulnamen (z. B. powershell/situational_awareness....) einzugeben, nutzen Sie einfach die Autovervollständigungsfunktionen der IDE.
Für jedes Modul gibt es Optionen (für die meisten, wenn nicht alle Frameworks). Die Sache mit Empire ist, dass es KEINE Konsole gibt, um die Moduloptionen einzusehen, sobald man es als REST/Headless ausführt (darauf werde ich später eingehen). In der Autovervollständigungs-Hilfsklasse hat jedes Modul eine options Unterklasse. Die erforderlichen Optionen sind wie oben gezeigt mit einem Präfix versehen, sodass wir diese Optionen zuerst mit Werten befüllen können, bevor wir ein Modul aufrufen.
Die Beschreibung jedes Moduls ist auch als Teil der Python-Klassendokumentation enthalten und wird beim Überfahren der Klasse angezeigt. Da es 276 Module gibt (Stand Empire 2.1), erfordert diese Hilfsklasse etwas Skripterstellung! Quelle: https://gist.github.com/jymcheong/22c2eede978c8eb694945e3347c20c6b
Mit IDEs wie Visual Studio Code (oder einem Äquivalent) kann man die Debug-Variablenüberwachung nutzen, das Skript schrittweise durchgehen oder sogar das Skript während des Debuggens/Schrittweises Durchgehens ändern, nachdem man die Struktur der Rückgabewerte kennt. Die REST-API-Dokumentation gibt es für Empire, aber manchmal kennen wir die Rückgabewerte nicht genau, bis wir das Modul ausführen. Aus diesem Grund führt es zum nächsten Thema.
So sehr wir auch alles in der IDE machen möchten, werden Sie eine Konsole benötigen. Der Autor von DeathStar wusste das bereits, als er dieses Skript entwickelte, das die Übernahme des Domain-Administrators mit Empire automatisiert. Ich habe seine Idee übernommen, aber seinen Threading-Ansatz für Empire 2.1 angepasst, da sein Ansatz für die umgestaltete Start-Restful-API-Funktion nicht funktioniert. Quelle: https://gist.github.com/jymcheong/6a7668ecf73c29dd1d234d1c76ef438c
Es ist NICHT nötig, das Empire-Skript zu hacken, da Empire 2.2 den Befehls-Schleifen-Handler im REST-Modus hat. Interagieren Sie jedoch NICHT mit dem Agenten, während Sie die API verwenden, um Agentenergebnisse zu erhalten.
Shout outz an @radioboyQ für seinen EmpireAPIWrapper, @allfro & @Mikaayenson für pymetasploit, & an @byt3bl33d3r, MTFBWU.
