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

Rogue Assembly Hunter

Rogue Assembly Hunter es una utilidad para descubrir módulos '.NET CLR' 'interesantes' en procesos en ejecución.

• Autor: @bohops
• Licencia: MIT
• Proyecto: https://github.com/bohops/RogueAssemblyHunter

Antecedentes

.NET es una plataforma de desarrollo y un marco de tiempo de ejecución muy potente y capaz para construir y ejecutar aplicaciones administradas de .NET. En los últimos años, .NET ha sido adoptado por Red Teams (y afines) para instrumentar tácticas que apoyan operaciones ofensivas. En particular, el cambio de PowerShell ofensivo a .NET fue un salto lógico (para muchos) debido al aumento de la óptica y la visibilidad oportunista presentes en PowerShell v5+. Como tal, las herramientas y tácticas ofensivas de .NET se han utilizado con éxito para evadir capacidades defensivas basadas en el host, eludir el control de aplicaciones y construir/preparar/entregar/ejecutar código malicioso (similar a PowerShell).

Desde una perspectiva de prevención, Microsoft está haciendo más para combatir las amenazas instrumentadas con .NET y minimizar la superficie de ataque general de .NET. Por ejemplo, Microsoft ha añadido capacidades de inspección AMSI en .NET Framework 4.8, y los mecanismos WDAC/WLDP son bastante efectivos. Desde una perspectiva de detección/respuesta, una mayor visibilidad e introspección en el ecosistema .NET siempre es ventajosa para descubrir nuevas formas de combatir las amenazas centradas en .NET.

En 2017, Joe Desimone (@dez_) escribió un fantástico artículo llamado Hunting For In-Memory .NET Attacks. Aún relevante hoy, el artículo describe vectores de ataque modernos de .NET, así como técnicas de detección bajo demanda y basadas en eventos. Acompañando al artículo, Joe lanzó una herramienta (Get-ClrReflection) para detectar (y recuperar) de forma proactiva módulos CLR de .NET en memoria que carecen de una referencia de disco adecuada. Inspirado por el trabajo de Joe y aprovechando las capacidades de introspección de la biblioteca de diagnóstico en tiempo de ejecución CLRMD (+ las capacidades de acceso a datos posteriores de mscordacwks.dll), se creó Rogue Assembly Hunter para:

• Inspeccionar todos los procesos .NET ('administrados') en ejecución en busca de módulos CLR interesantes (por ejemplo, módulo(s) que forman un 'ensamblado')
• Inspeccionar un solo proceso .NET ('administrado') (por PID) en busca de módulos CLR interesantes
• Vigilar procesos recién creados e intentar inspeccionarlos en busca de módulos CLR interesantes
• Soportar varias capacidades de 'cacería' para descubrir módulos cargados en memoria, estado de firma de los módulos (si se cargaron desde disco), módulos cargados desde directorios interesantes y módulos impostores (por ejemplo, referencias de archivos falsas).
• Soportar funcionalidad de exportación de módulos CLR (un puerto rápido de Get-ClrReflection)
• Inspirar herramientas y tácticas más interesantes.

Requisitos y Dependencias Principales

• Ejecutarse bajo un contexto de usuario/proceso privilegiado
• .NET Framework 4.6.1+
• .NET CLRMD - Biblioteca de introspección Microsoft.Diagnostics.Runtime (Paquete NuGet)
• ILMerge - Enlazador estático (Paquete NuGet)
• ...y paquetes NuGet de soporte en Visual Studio.

Notas, Consejos y Advertencias

• Ejecutar como un usuario privilegiado con integridad alta/sistema.
• 'Cacerías' son experimentales y no se garantiza que proporcionen resultados completos/correctos. Tenga cuidado con los falsos positivos (por ejemplo, módulos firmados) y valide en consecuencia.
• RogueAssemblyHunter usa CLRMD para conectarse a procesos en vivo, lo que podría introducir resultados interesantes.
• Debido a la naturaleza de escaneo de RogueAssemblyHunter, existe la posibilidad de condiciones de carrera y resultados perdidos. Considere ajustar con los interruptores --checks y --sleep para ayudar (especialmente en modo 'watch'). En algunos casos, puede ser difícil 'atrapar' una carga de ensamblado particular debido a la velocidad de ejecución (como execute-assembly y procesos sacrificiales).
• La arquitectura ('bitness') y las versiones de .NET importan (por ejemplo, 4+) para interactuar con procesos remotos con las bibliotecas CLRMD de .NET.
  • Para máxima inspección/cobertura, compile y ejecute este programa para casos de uso x86 y x64.
  • El modo de barrido de procesos intentará conectarse a todos los procesos en ejecución independientemente del 'bitness'. De lo contrario, fallará en consecuencia por desajustes de arquitectura.
• Probado en Windows 10 Pro 2H1H y Windows Server 2016 Standard 1607. Puede ejecutarse en otras versiones con el .NET Framework relevante.
• El código fuente del proyecto de Visual Studio con paquetes NuGet, script de PowerShell y binarios de lanzamiento están incluidos en este proyecto.
• Notice.md incluye avisos del proyecto e información de licencia.
• ¡Úselo bajo su propio riesgo (y no le importe mi horrible código ;) )!

Uso

[*] 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.