Nimpostor: Entwicklung eines Nim Agent für Mythic C2

Mythic funktioniert mit Hilfe von Docker-Containern. Die Datei Payload_Type/mypayload/Dockerfile wird verwendet, um den Docker-Container zu definieren, den der Payload Builder verwenden wird. Es sind bereits Docker-Basis-Images verfügbar, die Abhängigkeiten für die Erstellung verschiedener Arten von Payloads enthalten, aber es kann auch ein benutzerdefinierter Container definiert werden, was in diesem Fall erforderlich war, um alle Abhängigkeiten für Nim zu installieren. Dieser Docker-Container wird für die Erstellung des Payloads verwendet; andere Funktionen wie die C2-Kommunikation werden in Profil-Containern behandelt.

Die Datei Payload_Type/mypayload/mythic/agent_functions/builder.pyenthält Metadaten über den Payload zusammen mit der Implementierung für die Erstellung jedes Payloads. Die Mythic-Dokumentation für diese Datei enthält eine sehr ausführliche Anleitung, was in dieser Datei enthalten sein muss, um Ihren Agenten in Mythic zu definieren und wie man Build-Parameter in die Payload kompiliert.

Man kann sich die Entwicklung von Payload Typen so vorstellen, dass sie "Payload"-Code und "Mythic" Code enthalten. Der Payloadcode ist der Code für den Agenten selbst und befindet sich im Verzeichnis Payload_Type/mypayload/agent_code/. Hier findet die eigentliche Entwicklung des Agenten und seiner Funktionen statt. Der andere Teil des Agenten ist der Mythic Code, der sich im Verzeichnis Payload_Type/mypayload/mythic/agent_functions/befindet. Hier werden verschiedene Befehle für den Agenten definiert. Die Befehle und ihre Parameter werden zusammen mit allen anderen Vorabaufgaben definiert, bevor sie an den Agenten gesendet werden.

HTTP ist ein sehr verbreiteter C2-Kommunikationstransport und einer der am einfachsten zu implementierenden. Mythic enthält bereits ein HTTP-C2-Profil, das mit einem Agenten für C2-Kommunikation verwendet werden kann. Es handelt sich um ein relativ einfaches Profil, das HTTP GET/POST-Anfragen und base64-kodierte JSON-Daten verwendet. Das anfängliche Einchecken eines Agenten besteht aus einer HTTP-Anfrage mit mehreren Datenfeldern, die der Mythic-Server verwendet, um den Agenten bzw. das System, auf dem der Agent läuft, zu identifizieren.

Jeder Agent hat eine eindeutige PayloadUUID, die zur Kompilierungszeit generiert wird. Eine HTTP POST-Anfrage mit dieser im Body der Anfrage registriert einen ersten Check-In mit Mythic auf der Callbacks-Seite. Die Verschlüsselung kann in die Nutzdaten der Anfrage aufgenommen werden, indem das in der Dokumentation angegebene Format eingehalten wird.

Von hier aus sendet ein Agent in regelmäßigen Abständen Anfragen an den Mythic-Server, um Aufgaben über das “tasking“ zu erhalten und die Ergebnisse der abgeschlossenen Aufgaben zurückzusenden.

Das ist alles, was für die Erstellung eines einfachen Mythic-Payloads benötigt wird. Die Erstellung fortgeschrittener Befehle kann in der Mythic-Dokumentation nachgelesen werden. Das Beispiel geht nicht in die Tiefe über all die anderen Funktionen, die in Mythic enthalten sind. Eine gute Quelle für Möglichkeiten sind die bereits existierenden Agenten. Mythic unterstützt auch eine Struktur für Peer-to-Peer-Kommunikation zwischen Agenten. Ein Agent kann direkt mit anderen Agenten kommunizieren, um Aufgaben weiterzugeben. Die Agenten Apollo und Poseidon unterstützen die P2P-Funktionalität über SMB und/oder TCP.

Warum Nim?

Einer der größten Vorteile von Nim ist, dass es eine kompilierte, statisch typisierte Sprache mit einer Syntax ist, die sich wie eine Skriptsprache anfühlt. Ein Großteil der Syntax entspricht genau der von Python oder ist ihr sehr ähnlich. Dies war ein großer Vorteil, da viele kleine Werkzeuge, die für den internen Gebrauch entwickelt wurden, auf Python basieren.

Da es sich bei Nim außerdem um eine vorzeitig kompilierte Sprache handelt, ist sie für die Entwicklung von C2-Implantaten oder anderen Tools zur Post-Exploitation wahrscheinlich eine sinnvollere Wahl als Python. Es ist zwar möglich, Python-Code mit Tools wie PyInstaller oder Py2Exe zu einer ausführbaren Datei zu kompilieren, aber diese Tools scheinen Probleme mit Antivirenprogrammen zu haben, und ihre Verwendung bedeutet einen weiteren Schritt im Entwicklungsprozess.

Hier ist ein kurzer Überblick über einige andere Funktionen, die Nim vielversprechend machen:

• Cross-Kompilierungsunterstützung mit mingw-64. Sprachen wie Go, die in einem anderen persönlichen Forschungsprojekt analysiert wurden, zeigen, wie hilfreich eine nahtlose Cross-Kompilierung für die Entwicklung offensiver Tools ist. Die Möglichkeit, Agenten sowohl für Windows- als auch für Linux-Clients zu kompilieren, bringt mehr Flexibilität.
• Die von Nim erzeugten Binaries sind im Vergleich zu den von Go erzeugten Binaries recht klein, was für den initialen Einsatz des Agenten entscheidend ist.
• Nim bietet Unterstützung für den Aufruf von Backend-Code wie der Windows-API unter Verwendung seines “Foreign Function Interface”. Dies scheint eine besonders vielversprechende Funktion für alle zu sein, die an der Entwicklung von Post-Exploitation-Tools für Windows in Nim interessiert sind.
• Die Dokumentation ist sehr detailliert und es gibt eine Menge Tutorials für den Einstieg.

Nimpostor Funktionen

Um ein Gefühl dafür zu bekommen, welche Funktionen essentiell sind, wurden andere Agenten aus dem MythicAgents github analysiert. Vor allem die Agenten Apollo, Medusa und Poseidon sind sehr fortschrittlich und haben eine große Übersicht an Funktionen. Darüber hinaus gaben die Codeschnipsel aus dem OffensiveNim-Repository weitere

Derzeit ist der Proof-of-Concept Payload sehr einfach und hat keine erweiterten Funktionen implementiert. Er konzentriert sich auf einfache Dateisystemaufgaben wie cd, ls, download, upload und die erweiterte Funktion execute_assembly, die die Ausführung von .NET-Dateien direkt im Speicher ermöglicht.

Fazit

Das Hauptziel dieser Untersuchung war es, die Sprache Nim kennenzulernen und herauszufinden, ob sie für die interne Toolentwicklung geeignet ist. Dies kann zu 100 % bestätigt werden und die in "Warum Nim?" genannten Themen machen es zum neuen Favoriten für die interne Werkzeugentwicklung für Red-Teaming-Projekte.

Obwohl sich der Agent derzeit sozusagen im Betastadium befindet, wird er auf jeden Fall weiterentwickelt, so dass er in zukünftigen Red Team Projekten eingesetzt werden kann.

Die nächsten Schritte sind ein bof_loader, um Beacon Object Files direkt im Speicher ausführen zu können, ein Socks Proxy und die p2p Funktionalität für die Kommunikation zwischen Agenten über SMB oder TCP.

Wer einen Blick auf den Code werfen und den Agenten selbst testen möchte, kann dies auf der SEC Consult Github-Seite tun.

Dieser Blogpost wurde von Lukas Donaubauer geschrieben und im Auftrag des SEC Consult Vulnerability Lab veröffentlicht.