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

Rogue Assembly Hunter

Rogue Assembly Hunter est un utilitaire pour découvrir des modules .NET CLR « intéressants » dans les processus en cours d’exécution.

• Auteur : @bohops
• Licence : MIT
• Projet : https://github.com/bohops/RogueAssemblyHunter

Contexte

.NET est une plateforme de développement et un framework d’exécution très puissants et capables pour construire et exécuter des applications gérées .NET. Au cours des dernières années, .NET a été adopté par les Red Teams (et assimilés) pour instrumenter des techniques afin de soutenir des opérations offensives. En particulier, le passage de PowerShell offensif à .NET a été un saut logique (pour beaucoup) en raison de la visibilité accrue et de l’opportunité offerte par PowerShell v5+. Ainsi, les outils et techniques offensifs .NET ont été utilisés avec succès pour contourner les capacités défensives basées sur l’hôte, contourner le contrôle des applications et construire/stager/livrer/exécuter du code malveillant (similaire à PowerShell).

D’un point de vue préventif, Microsoft fait davantage pour lutter contre les menaces instrumentées par .NET et minimiser la surface d’attaque globale de .NET. Par exemple, Microsoft a ajouté des capacités d’inspection AMSI dans .NET Framework 4.8, et les mécanismes WDAC/WLDP sont assez efficaces. D’un point de vue détection/réponse, une visibilité et une introspection supplémentaires dans l’écosystème .NET sont toujours avantageuses pour découvrir de nouvelles façons de combattre les menaces ciblant .NET.

En 2017, Joe Desimone (@dez_) a écrit un article fantastique intitulé Hunting For In-Memory .NET Attacks. Toujours d’actualité, l’article décrit les vecteurs d’attaque .NET modernes ainsi que les techniques de détection à la demande et basées sur les événements. Accompagnant l’article, Joe a publié un outil (Get-ClrReflection) pour détecter (et récupérer) de manière proactive les modules CLR .NET en mémoire qui n’ont pas de référence disque appropriée. Inspiré par le travail de Joe et profitant des capacités d’introspection de la bibliothèque de diagnostics d’exécution CLRMD (ainsi que des capacités d’accès aux données ultérieures de mscordacwks.dll), Rogue Assembly Hunter a été créé pour :

• Inspecter (tous) les processus .NET (« gérés ») en cours d’exécution à la recherche de modules CLR intéressants (par exemple les modules qui forment un « assembly »)
• Inspecter un seul processus .NET (« géré ») (par PID) à la recherche de modules CLR intéressants
• Surveiller les nouveaux processus créés et tenter d’inspecter les modules CLR intéressants
• Prendre en charge plusieurs capacités de « chasse » pour découvrir les modules chargés en mémoire, l’état de signature des modules (si chargés depuis le disque), les modules chargés depuis des répertoires intéressants et les modules imposteurs (par exemple les fausses références de fichier)
• Prendre en charge la fonctionnalité d’exportation de modules CLR (un port rapide de Get-ClrReflection)
• Inspirer davantage d’outils et de techniques intéressants

Principales exigences et dépendances

• Exécution sous un contexte utilisateur/processus privilégié
• .NET Framework 4.6.1+
• .NET CLRMD - Bibliothèque d’introspection Microsoft.Diagnostics.Runtime (paquet NuGet)
• ILMerge - Éditeur de liens statique (paquet NuGet)
• ...et les paquets NuGet associés dans Visual Studio.

Remarques, conseils et mises en garde

• Exécutez en tant qu’utilisateur privilégié avec une intégrité haute/système.
• Les « chasses » sont expérimentales et ne garantissent pas des résultats complets/corrects. Méfiez-vous des faux positifs (par exemple les modules signés) et validez en conséquence.
• RogueAssemblyHunter utilise CLRMD pour se connecter aux processus en direct, ce qui peut introduire des résultats intéressants.
• En raison de la nature de balayage de RogueAssemblyHunter, des conditions de concurrence et des résultats manqués sont possibles. Envisagez de régler les commutateurs --checks et --sleep pour vous aider (surtout en mode « watch »). Dans certains cas, il peut être difficile de « capturer » un chargement d’assembly particulier en raison de la vitesse d’exécution (comme execute-assembly et les processus sacrifiés).
• L’architecture (32/64 bits) et les versions de .NET (par ex. 4+) sont importantes pour interagir avec les processus distants avec les bibliothèques .NET CLRMD.
  • Pour une inspection/ couverture maximale, compilez et exécutez ce programme pour les cas d’utilisation x86 et x64.
  • Le mode de balayage des processus tentera de se connecter à tous les processus en cours d’exécution indépendamment du « bitness ». Il échouera autrement en cas d’incompatibilité d’architecture.
• Testé sur Windows 10 Pro 2H1H et Windows Server 2016 Standard 1607. Peut fonctionner sur d’autres versions avec le .NET Framework approprié.
• Le projet Visual Studio avec les paquets NuGet, le script PowerShell et les binaires de la version sont inclus dans ce projet.
• Notice.md contient les clauses de non-responsabilité et les informations de licence.
• À utiliser à vos risques et périls (et ne faites pas attention à mon code horrible ;) ) !

Utilisation

[*] Paramètres :
    
    --mode=<.>   : Requis | Sélectionnez le mode d’analyse. Options : sweep, process et watch.

    --hunt=<.>   : Facultatif | Sélectionnez le type de chasse pour trouver des modules CLR intéressants. Spécifiez all (par défaut), memory-only, unusual-dir,
                   sig-status, imposter-file ou list.

    --export=<.> : Facultatif, expérimental | Spécifiez un chemin de fichier pour exporter les modules CLR chargés pour les chasses en mémoire et les chasses de fichiers imposteurs
                   (ex. --hunt=memory-only/imposter-file/all).

    --pid=<.>    : Facultatif | Spécifiez un processus ciblé par PID. Doit être utilisé avec le paramètre/valeur --mode=process.

    --checks=<.> : Facultatif | Spécifiez une valeur pour les cycles d’analyse. Cela peut aider à réduire les oublis dus aux conditions de concurrence, mais peut aussi répéter la sortie des résultats.
                   Valeur par défaut : 1.