InlineExecute-Assembly

InlineExecute-Assembly ist ein Proof-of-Concept Beacon Object File (BOF), das es Sicherheitsexperten ermöglicht, .NET-Assemblys prozessintern auszuführen – als Alternative zum traditionellen Fork-and-Run-Modul execute-assembly von Cobalt Strike. InlineExecute-Assembly führt jede Assembly mit dem Einstiegspunkt Main(string[] args) oder Main() aus. Dadurch sollten die meisten veröffentlichten Tools ohne vorherige Anpassung laufen.

Das BOF ermittelt automatisch, welche Common Language Runtime (CLR) (v2.0.50727 oder v4.0.30319) für Ihre Assembly in den Prozess geladen werden muss, bevor es zur Ausführung kommt. In den meisten Fällen sollte es sich bei Problemen ordentlich beenden. Das BOF unterstützt außerdem mehrere Flags, mit denen der Operator verschiedene Verhaltensweisen vor der .NET-Ausführung festlegen kann: Deaktivieren von AMSI durch In-Memory-Patching, Deaktivieren und Wiederherstellen von ETW durch In-Memory-Patching, Anpassung des zu erstellenden CLR-AppDomain-Namens, Festlegen, ob die Konsolenausgabe Ihrer Assembly über eine Named Pipe oder ein Mailslot umgeleitet werden soll, sowie Umschalten des Standard-Einstiegspunkts von Main(string[] args) auf Main(). Weitere Details zur Nutzung, zu Anwendungsfällen und möglichen Erkennungen finden Sie unten sowie auf https://securityintelligence.com/posts/net-execution-inlineexecute-assembly/.

Der Vorteil der Ausführung unserer .NET-Assemblys im selben Prozess wie unser Beacon-Implantat ist schließlich, dass wir das Standardverhalten des execute-assembly-Moduls von Cobalt Strike vermeiden, das einen neuen Prozess erstellt, um die CLR/.NET-Assembly zu laden/injizieren. Dennoch bestehen andere opsec-bedingte Überlegungen – zum Beispiel: Lädt der Prozess, in dem wir ausführen, normalerweise die CLR? Hat die ausgeführte .NET-Assembly bekannte Signaturen? Der Nachteil ist daher, dass bei einer Erkennung und Beseitigung (z. B. durch AMSI) auch Ihr Beacon beseitigt wird.

Quellenangaben

Dieses Tool wäre nicht ohne die großartige Forschung, Tools und Code möglich gewesen, die bereits von Mitgliedern der Sicherheitsgemeinschaft veröffentlicht wurden. Vielen Dank dafür. Falls jemand unten vergessen wurde, lassen Sie es mich bitte wissen, und ich werde ihn ergänzen.

• HostingCLR – hier – CLR/Ausführungslogik der Assembly
• Dotnet-Loader-Shellcode – (von @modexpblog) – hier – Rundum großartige Forschung, u. a. zu COM-Schnittstellen für die Ausführung von .NET in C – Wirklich MVP
• Donut – (von @TheRealWover und @modexpblog) – hier – COM-Schnittstellen-Header
• Memory Patching AMSI Bypass – (von @_RastaMouse) – hier – Forschung zum AMSI-Memory-Patching
• Metasploit-Execute-Assembly – (von @b4rtik) – hier – Modifiziertes AMSI-Patching und verwendete Funktion zum Ermitteln der .NET-Version
• ExecuteAssembly – (von @med0x2e) – hier – Modifiziertes Aggressor-Skript
• Hiding Your .NET ETW – (von @xpn) – hier – Hervorragende ETW-Forschung
• ETW BOF – (von @ajpc500) – hier – Modifiziertes ETW-Patching
• ExecuteAssembly_Mailslot – (von @N4k3dTurtl3) – hier – Modifizierte Verwendung von Mailslots zur Konsolenumleitung
• @freefirex2 – Hat freundlicherweise einige gute Einblicke in die inneren Abläufe von BOFs und Fallstricke geteilt.

Erste Schritte

1. Kopieren Sie den Ordner inlineExecute-Assembly mit seinem gesamten Inhalt auf ein System, mit dem Sie über die Cobalt-Strike-GUI-Anwendung verbinden möchten.
2. Laden Sie das Aggressor-Skript inlineExecute-Assembly.cna.
3. Führen Sie inlineExecute-Assembly --dotnetassembly /pfad/zu/assembly.exe für die grundlegendste Ausführung aus (siehe Anwendungsfälle unten für spezifische Flag-Beispiele).

Eigene Version erstellen

Führen Sie den folgenden Befehl im Verzeichnis src über die x64 Native Tools-Eingabeaufforderung für VS 2019 aus:

cl.exe /c inlineExecute-Assembly.c /GS- /FoinlineExecute-Assemblyx64.o

Führen Sie den folgenden Befehl im Verzeichnis src über die x86 Native Tools-Eingabeaufforderung für VS 2019 aus:

cl.exe /c inlineExecute-Assembly.c /GS- /FoinlineExecute-Assemblyx86.o

Flags

--dotnetassembly        Directory path to your assembly **required**
--assemblyargs          Assembly arguments to pass
--appdomain             Change default name of AppDomain sent (default value is totesLegit and is set via the included aggressor script) *Domain always unloaded*
--amsi                  Attempts to disable AMSI via in memory patching (If successful AMSI will be disabled for the entire life of process)
--etw                   Attempts to disable ETW via in memory patching (If successful ETW will be disabled for the entire life of process unless reverted)
--revertetw             Attempts to disable ETW via in memory patching and then repatches it back to original state
--pipe                  Change default name of named pipe (default value is totesLegit and is set via the included aggressor script)
--mailslot              Switches to using mailslots to redirect console output. Changes default name of mailslot (If left blank, default value is totesLegit and is set via the included aggressor script)
--main                  Changes entry point to Main() (default value is Main(string[] args))

Anwendungsfall

.NET-Assembly ausführen

Syntax

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe

Anwendungsfall

.NET-Assembly mit Argumenten ausführen

Syntax

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker

Anwendungsfall

.NET-Assembly mit Argumenten ausführen und AMSI deaktivieren

Syntax

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker --amsi

Anwendungsfall

.NET-Assembly mit Argumenten ausführen und ETW deaktivieren

Syntax

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker --etw

Anwendungsfall

.NET-Assembly mit Argumenten ausführen und Ausgabe über Mailslots anstelle der standardmäßigen Named Pipe umleiten

Syntax

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --mailslot

Anwendungsfall

.NET-Assembly mit Argumenten ausführen und den im Aggressor-Skript festgelegten Standard-Named-Pipe-Namen ändern

Syntax

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --pipe forRealLegit

Anwendungsfall

.NET-Assembly ausführen und die im Aggressor-Skript festgelegte Standard-AppDomain ändern

Syntax

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --appdomain forRealLegit

Anwendungsfall

.NET-Assembly mit dem Einstiegspunkt Main() anstelle des Standard-Einstiegspunkts Main(string[] args) ausführen

Syntax

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/simpleMain.exe --main

Anwendungsfall

Volles Programm

Syntax

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker --amsi --etw --appdomain forRealLegit --mailslot forRealLegit

Einschränkungen

1. Obwohl ich versucht habe, das Tool so stabil wie möglich zu gestalten, gibt es keine Garantie, dass nie etwas abstürzt oder Beacons sterben. Wir haben nicht den Luxus von Fork-and-Run, bei dem unser Beacon überlebt, wenn etwas schiefgeht. Das ist der Nachteil von BOFs. Ich kann nicht genug betonen, wie wichtig es ist, Ihre Assemblys vorher zu testen, um sicherzustellen, dass sie mit dem Tool ordnungsgemäß funktionieren.
2. Da das BOF prozessintern ausgeführt wird und während der Laufzeit das Beacon übernimmt, sollte dies vor der Verwendung für langlaufende Assemblys bedacht werden. Wenn Sie etwas ausführen, das lange braucht, um Ergebnisse zu liefern, wird Ihr Beacon nicht aktiv sein, um weitere Befehle entgegenzunehmen, bis die Ergebnisse zurückkommen und die Assembly fertig ist. Dies folgt auch nicht der Sleep-Einstellung. Wenn z. B. Ihr Sleep auf 10 Minuten eingestellt ist und Sie das BOF ausführen, erhalten Sie die Ergebnisse, sobald das BOF fertig ist.
3. Sofern nicht Änderungen an Tools vorgenommen werden, die PE-Dateien im Speicher laden (z. B. SafetyKatz), werden diese höchstwahrscheinlich Ihr Beacon zum Absturz bringen. Viele dieser Tools funktionieren mit execute-assembly gut, da sie ihre Konsolenausgabe aus dem Opferprozess senden können, bevor sie sich beenden. Wenn sie über unser In-Process-BOF beendet werden, töten sie unseren Prozess und damit unser Beacon. Diese können modifiziert werden, um zu funktionieren, aber ich empfehle, solche Assemblys über execute-assembly auszuführen, da andere nicht OPSEC-freundliche Dinge in Ihren Prozess geladen werden könnten, die nicht entfernt werden.
4. Wenn Ihre Assembly Environment.Exit verwendet, muss dies entfernt werden, da es den Prozess und das Beacon beendet.
5. Named Pipes und Mailslots müssen eindeutig sein. Wenn Sie keine Daten zurückerhalten und Ihr Beacon noch lebt, liegt das Problem höchstwahrscheinlich darin, dass Sie einen anderen Named-Pipe- oder Mailslot-Namen wählen müssen.

Erkennung

Einige Erkennungs- und Abwehrstrategien, die verwendet werden könnten:

1. Verwendet PAGE_EXECUTE_READWRITE beim Durchführen von AMSI- und ETW-Memory-Patching. Dies wurde absichtlich so gemacht und sollte ein Warnsignal sein, da nur sehr wenige Programme Speicherbereiche mit dem Schutz PAGE_EXECUTE_READWRITE haben.
2. Der Standardname der erstellten Named Pipe ist totesLegit. Dies wurde absichtlich so gemacht, und Signaturerkennungen könnten verwendet werden, um dies zu markieren.
3. Der Standardname des erstellten Mailslots ist totesLegit. Dies wurde absichtlich so gemacht, und Signaturerkennungen könnten verwendet werden, um dies zu markieren.
4. Der Standardname der geladenen AppDomain ist totesLegit. Dies wurde absichtlich so gemacht, und Signaturerkennungen könnten verwendet werden, um dies zu markieren.
5. Gute Tipps zur Erkennung bösartiger .NET-Nutzung (von @bohops) hier, (von F-Secure) hier und hier.
6. Achten auf das Laden der .NET CLR in verdächtige Prozesse, z. B. nicht verwaltete Prozesse, die niemals die CLR laden sollten.
7. Ereignisverfolgung hier.
8. Achten auf andere bekannte Cobalt-Strike-Beacon-IOCs oder C2-Egress-/Kommunikations-IOCs.