zypherion-technologies/nemesisMonitor de procesos .NET que engancha CLR en la capa nativa, vuelca ensamblados reflectivos desde la memoria y comprueba la integridad de AMSI/ETW frente a los binarios en disco.
mañana se publica una actualización, cambiando la licencia y también algunas nuevas funciones contra los ladrones de datos.
Herramienta de Windows que creé porque me cansé de ver bifurcaciones de jlaive en muestras de malware sin nada público para realmente desarmarlas en tiempo de ejecución.
En resumen, es un monitor de procesos .NET que engancha el CLR en la capa nativa, rastrea las cargas de ensamblados reflectivos y automáticamente vuelca PE directamente desde la memoria. También verifica la integridad de AMSI y ETW contra los binarios originales en disco mientras detecta técnicas de evasión como el parcheo de cadenas de clr.dll y el uso directo de LoadFromBuffer.
¿dónde encontrar muestras? recomiendo revisar https://tria.ge (no es un anuncio) y puedes descargar cualquier muestra que quieras y filtrar según una familia
Podrías preguntarte, ¿por qué el nombre Nêmesis? Porque representa el propósito exacto de la herramienta. Un nêmesis es algo que representa un desafío constante o la caída de un oponente, y esa es la idea detrás de este proyecto.
En la mitología griega, Némesis era el espíritu de la retribución divina, la que repartía el pago a cualquiera que se volviera demasiado arrogante o pensara que era intocable. Un poco obvio para el malware que se jacta de ser "FUD", si me preguntas.
Soy analista de malware. Si haces este trabajo (pasatiempo para mí) el tiempo suficiente, empiezas a ver las mismas cadenas de cargadores una y otra vez, especialmente desde que jlaive (también llamado crybat) explotó y cada script kiddie lo bifurcó.
El patrón es estúpidamente simple pero terriblemente molesto de tratar:
something.bat → obfuscated powershell → csharp stub → your actual payload
Haces doble clic en un .bat que parece una ensalada de palabras. cmd inicia powershell con un muro de basura. powershell descifra/descomprime un stub .NET (aes, gzip, base64). Ese stub parcha AMSI + ETW, carga reflectivamente el exe/dll real en memoria, y listo, nada amigable llega al disco en una forma útil.
Eso me molestaba. Realmente no hay una buena herramienta pública destinada a combatir esta cadena específica: enganchar donde el payload .NET se materializa, volcarlo antes de que el proceso se consuma a sí mismo, capturar los parches de AMSI/ETW que estos stubs siempre hacen. Así que construí Nêmesis.
No es una bala de plata. No va a reemplazar tu sandbox. Pero te da algo real para ejecutar contra un .bat sospechoso en una máquina de prueba y realmente extraer artefactos.
launcher (Launcher.exe)
Nemesis.dll antes de que se ejecute el hilo principalnemesis dll (Nemesis.dll)
nLoadImagenLoadFileAssemblyNative::LoadFromBuffer (pattern resolved off nLoadImage)%TEMP%\Nemesis_dumpsamsi.dll / ntdll.dll con las copias en disco (captura el parche clásico ret en AmsiScanBuffer / EtwEventWrite).rdata de clr cuando clr está cargado (algunas evasiones parchan esas en su lugar; hay un gran artículo de vxug al respecto llamado 2024-11-21 - New AMSI Bypss Technique Modifying CLRDLL in Memory.pdf )%TEMP%\Nemesis.log también tiene ENABLE_VIRTUAL_TERMINAL_PROCESSING para evitar problemas con la consola siendo, digamos, extraña :Dbásicamente: deja que la cadena del bat se ejecute, captura el payload donde el crypter realmente lo carga, y registra los trucos de evasión en el camino.
necesitas Visual Studio 2022+ con escritorio C++ + MASM (x64).
abre Nemesis.slnx, elige Release | x64, compila la solución.
este es el caso de uso real: apúntalo a un bat sospechoso y mira lo que sale:
cd x64\Release
.\Launcher.exe "C:\path\to\suspicious.bat"
los argumentos adicionales después de -- se pasan al objetivo:
.\Launcher.exe myapp.exe -- --some-flag
ruta personalizada de dll:
.\Launcher.exe --dll C:\path\Nemesis.dll myapp.exe
artefactos:
%TEMP%\Nemesis.log%TEMP%\Nemesis_dumpses:
no es:
LNK1104? algo todavía tiene nemesis.dll cargado; mata el objetivo y recompilapwsh.exe vcpkg durante la compilación es inofensivo, ignóralosi quieres entender contra lo que estás luchando:
al usar Nêmesis aceptas esto. se proporciona tal cual sin garantía — asumes todo el riesgo.
eres el único responsable del uso legal y autorizado (máquinas virtuales de laboratorio, sistemas propios, permiso explícito). en la máxima medida permitida por la ley, los autores y zypherion.tech renuncian a toda responsabilidad por cualquier daño, pérdida o reclamo legal que surja del uso o mal uso. consulta LICENSE para los términos completos.
uso no comercial / personal / investigación / pasatiempo → PolyForm Noncommercial 1.0.0
uso comercial (venderlo, producto pago, saas, trabajo para clientes, etc.) → necesitas una licencia separada. polyform noncommercial no cubre eso.
contáctame si quieres una licencia comercial:
[[email protected] / @wd6g(discord) / telegram: @ZypherionTechnologies]
nota rápida: tengo que investigar compilemethod y arreglarlo; por ahora no es realmente necesario ya que los crypters normalmente no lo usan en absoluto... ya que tienen que usar
asm.load(...)también me recuerda que tengo que verificar rdata str ya que no lo he probado correctamente, lamentablemente... no hagas un PR con código tonto, por favor; no se pueden enganchar backends n(Native) como nLoadImage normalmente, tienes que preservar los registros y es solo meh, por eso usamos asm.