pwn1sher/frostbyteCombina la inyección de AppDomain Manager con la incrustación de shellcode en binarios firmados para evadir la detección de EDR/AV en payloads de equipos rojos.
En los últimos días he estado experimentando con la técnica de inyección del administrador de AppDomain y tuve un éxito decente con ella en mis compromisos anteriores de Red Team contra ciertos EDR. Aunque esto es realmente bueno para el vector de acceso inicial, quería lanzar un POC que ayude a ocultar tu shellcode en otro lugar. ¡No más archivos DLL con shellcode incrustado!
Aunque es una excelente técnica cuando se usa de forma independiente, pero cuando se combina con una técnica de entrega como enviar un C# ClickOnce dentro de un archivo ISO/ZIP/VHD/VHDX. El problema real es que 1 de cada 10 veces el DLL para el appdomain era detectado por las heurísticas de IA/ML del AV/EDR. Esto se debe a que el archivo DLL debe colocarse en el disco antes de inicializar el appdomain. Ignorando las cargas de DLL remotas por ahora (rutas UNC en .config), el DLL para el appdomain contendría el shellcode y sentí firmemente que esa es la razón de una probable detección estática, porque el resto del código, que son llamadas WINAPI, se puede resolver dinámicamente y estar bastante bien ofuscado.
Quería mejorar esta técnica en términos de minimizar lo que el DLL contendría inicialmente. Empecé colocando shellcode cifrado en un archivo separado en el disco junto con el DLL inyector, pero luego me topé con este increíble blog de Checkpoint sobre la Campaña de Zloader
Versión TLDR: Podemos incrustar datos arbitrarios en algunos campos dentro del PE de una manera que no rompa la firma del archivo. Así, nuestros datos se incrustarán y el exe seguirá estando firmado digitalmente.
Más información sobre esto - https://www.blackhat.com/docs/us-16/materials/us-16-Nipravsky-Certificate-Bypass-Hiding-And-Executing-Malware-From-A-Digitally-Signed-Executable-wp.pdf
Entonces la idea es incrustar un stub de shellcode cifrado en un ejecutable firmado conocido y aún así lograr mantenerlo firmado como lo hizo el malware Zloader. Al hacerlo, el DLL del Administrador de AppDomain ya no contendrá el shellcode en sí mismo, sino que solo tendrá la lógica para analizar el shellcode del binario PE que lo carga para descifrarlo y ejecutarlo como un hilo separado. Hacer esto podría disminuir la tasa de detección estática para el DLL mientras tu shellcode está bien colocado dentro de un binario firmado.
Estaba intentando lograr esto manipulando manualmente las muestras de ZLoader que obtuve de VirusTotal, pero luego descubrí un proyecto que ya había implementado todas estas técnicas bastante bien - Sigflip. En este POC aproveché el código de carga de Sigflip para construir el DLL de AppDomain y el inyector SigFlip para incrustar el shellcode cifrado en nuestro exe de C#.
Grandes fragmentos de shellcode como el shellcode Stageless de Cobalt Strike ya no residirán en un DLL sin firmar en el disco, independientemente de las técnicas de ofuscación/codificación utilizadas. El DLL es más limpio, más pequeño y más sigiloso con código mínimo, reduciendo así las posibilidades de detección.
SigFlip.exe -i "Z:\ZLoader\CasPol.exe" "Z:\ZLoader\x64-stageless.bin" "Z:\ZLoader\update.exe" "S3cretK3y"update.exe que será un PE firmado digitalmente con shellcode cifrado incrustado.csc /target:library /out:test.dll test.csEste POC es solo una idea que tenía en mente para combinar dos técnicas de evasión de defensa totalmente diferentes que me ayudarían a mí y a otros Red Teamers a construir mejores payloads de ejecución inicial para sus operaciones. Este proyecto utiliza la Inyección del Administrador de AppDomain como ejemplo, pero esta idea es aplicable a otras técnicas de inyección también, como - DLL SideLoading, DLL Hijacking, etc.
Todos los créditos a med0x2e, este POC está construido basado en su proyecto SigFlip