__________ _____ . .
_____ \ ____ ____ __ __ ____ / _ \ ______ ______ ____ _ | | | .. | // _ \ / __| | _/ __ \ / /\ \ / // __// __ \ / | __ | |< | | | | ( <> ) // > | /\ / / | \ \ _ \ /| Y Y \ _\ \ |_ | || /_/_ /|/ _ > _| /____ >____ >___ >|| / /____/ | / // / / / / / / / /
___ ___ __
/ | \ __ __ / | ___________ / ~ \ | / \ __/ __ _ __
\ Y / | / | \ | \ /| | / _| /|/|| /| _ >|
/ / /

Rogue Assembly Hunter

Rogue Assembly Hunter ist ein Dienstprogramm zum Auffinden von „interessanten“ .NET CLR-Modulen in laufenden Prozessen.

• Autor: @bohops
• Lizenz: MIT
• Projekt: https://github.com/bohops/RogueAssemblyHunter

Hintergrund

.NET ist eine sehr leistungsfähige und vielseitige Entwicklungsplattform und Laufzeitumgebung zum Erstellen und Ausführen von verwalteten .NET-Anwendungen. In den letzten Jahren wurde .NET von Red Teams (und ähnlichen Gruppen) übernommen, um Handwerkszeug für offensive Operationen zu instrumentieren. Insbesondere der Wechsel von offensivem PowerShell zu .NET war (für viele) ein logischer Schritt, da PowerShell v5+ eine erhöhte Transparenz und opportunistische Sichtbarkeit bietet. Infolgedessen wurde offensive .NET-Tooling und -Handwerkszeug erfolgreich eingesetzt, um hostbasierte Sicherheitsfunktionen zu umgehen, Anwendungssteuerungen zu umgehen und bösartigen Code (ähnlich wie PowerShell) zu erstellen, zu inszenieren, zu liefern und auszuführen.

Aus präventiver Sicht unternimmt Microsoft mehr, um .NET-instrumentierte Bedrohungen zu bekämpfen und die gesamte .NET-Angriffsfläche zu minimieren. Beispielsweise hat Microsoft AMSI-Inspektionsfunktionen in .NET Framework 4.8 hinzugefügt, und WDAC-/WLDP-Mechanismen sind sehr effektiv. Aus Erkennungs-/Reaktionsperspektive ist eine weitere Sichtbarkeit und Einsicht in das .NET-Ökosystem stets vorteilhaft, um neue Wege zur Bekämpfung von .NET-spezifischen Bedrohungen zu entdecken.

Im Jahr 2017 veröffentlichte Joe Desimone (@dez_) einen fantastischen Artikel mit dem Titel Hunting For In-Memory .NET Attacks. Der Artikel, der auch heute noch relevant ist, beschreibt moderne .NET-Angriffsvektoren sowie On-Demand- und ereignisbasierte Erkennungstechniken. Begleitend zum Artikel veröffentlichte Joe ein Tool (Get-ClrReflection), um proaktiv In-Memory-.NET-CLR-Module zu erkennen (und abzurufen), denen ein ordnungsgemäßer Datenträgerverweis fehlt. Inspiriert von Joes Arbeit und unter Ausnutzung der Introspectionsfähigkeiten der CLRMD-Laufzeitdiagnosebibliothek (+ der anschließenden Datenzugriffsfähigkeiten von mscordacwks.dll) wurde Rogue Assembly Hunter erstellt, um:

• (Alle) laufenden .NET- („verwalteten“) Prozesse auf interessante CLR-Module zu überprüfen (z. B. Module, die eine „Assembly“ bilden)
• Einen einzelnen .NET- („verwalteten“) Prozess (nach PID) auf interessante CLR-Module zu überprüfen
• Auf neu erstellte Prozesse zu achten und zu versuchen, diese auf interessante CLR-Module zu überprüfen
• Mehrere „Jagd“-Fähigkeiten zu unterstützen, um in den Speicher geladene Module, den Signaturstatus von Modulen (falls von Datenträger geladen), Module, die aus interessanten Verzeichnissen geladen wurden, und Imposter-Module (z. B. gefälschte Dateiverweise) zu entdecken.
• Die CLR-Modul-Exportfunktionalität zu unterstützen (eine schnelle Portierung von Get-ClrReflection)
• Mehr interessante Tooling- und Handwerkszeug-Ideen zu inspirieren

Hauptanforderungen & Abhängigkeiten

• Ausführung in einem privilegierten Benutzer-/Prozesskontext
• .NET Framework 4.6.1+
• .NET CLRMD – Microsoft.Diagnostics.Runtime-Introspectionbibliothek (NuGet-Paket)
• ILMerge – Statischer Linker (NuGet-Paket)
• … und unterstützende NuGet-Pakete in Visual Studio.

Hinweise, Tipps & Einschränkungen

• Führen Sie das Tool als privilegierter Benutzer mit hoher/Systemintegrität aus.
• „Jagden“ sind experimentell und garantieren keine vollständigen/korrekten Ergebnisse. Seien Sie sich falsch positiver Ergebnisse (z. B. signierte Module) bewusst und validieren Sie entsprechend.
• RogueAssemblyHunter verwendet CLRMD, um eine Verbindung zu Live-Prozessen herzustellen, was zu interessanten Ergebnissen führen kann.
• Aufgrund der Scan-Natur von RogueAssemblyHunter besteht die Möglichkeit von Wettlaufsituationen und übersehenen Ergebnissen. Erwägen Sie, die Parameter --checks und --sleep zu verwenden, um dies zu verbessern (insbesondere im „watch“-Modus). In einigen Fällen kann es schwierig sein, eine bestimmte Assembly-Ladung aufgrund der Ausführungsgeschwindigkeit zu „erwischen“ (z. B. execute-assembly und Opferprozesse).
• Architektur („Bitanzahl“) und .NET-Versionen sind wichtig (z. B. 4+) für die Interaktion mit entfernten Prozessen mithilfe der .NET CLRMD-Bibliotheken.
  • Für maximale Inspektion/Abdeckung erstellen und führen Sie dieses Programm für x86- und x64-Anwendungsfälle aus.
  • Der Prozess-Sweep-Modus versucht, eine Verbindung zu allen laufenden Prozessen herzustellen, unabhängig von der „Bitanzahl“. Andernfalls schlägt er bei Architekturkonflikten entsprechend fehl.
• Getestet unter Windows 10 Pro 2H1H und Windows Server 2016 Standard 1607. Es kann mit dem entsprechenden .NET Framework auf anderen Versionen ausgeführt werden.
• Das Visual Studio-Projektquellprojekt mit NuGet-Paketen, PowerShell-Skript und Release-Binärdateien ist in diesem Projekt enthalten.
• Notice.md enthält Projekthaftungsausschlüsse und Lizenzinformationen.
• Ausführung auf eigene Gefahr (und nehmen Sie meinen schrecklichen Code nicht übel ;) )!

Verwendung

[*] Parameters:
    
    --mode=<.>   : Required | Select analysis mode. Options include sweep, process, and watch.

    --hunt=<.>   : Optional | Select the hunt scan type to find interesting CLR modules. Specify all (default), memory-only, unusual-dir,
                   sig-status, imposter-file, or list.

    --export=<.> : Optional, Experimental | Specify a file path to export loaded CLR modules for in-memory hunt scans and imposter-file hunt scans 
                   (e.g. --hunt=memory-only/imposter-file/all).

    --pid=<.>    : Optional | Specify a targeted process by PID. Must be used with --mode=process parameter/value.

    --checks=<.> : Optional | Specify a value for scan cycles. This may help reduce race condition misses during scans but could also repeat result output.
                   Default value is 1.

    --sleep=<.>  : Optional | Specify a value for sleep seconds. This may help reduce race condition misses during scans by delaying the check cycle.
                   Default value is 0 seconds.

    --debug      : Optional | Display exception information (e.g. process connect errors).

    --nobanner   : Optional | Suppress the display banner. Useful for executing with the PowerShell script or for use cases that leverage automation.

    --suppress   : Optional | Do not scan the RogueAssemblyHunter process during --mode=sweep or --mode=watch.