Hydra:

fuerza bruta de servicios de red paso a paso

Herramientas de Kali Linux | unfantasmaenelsistema.com

En el artículo sobre Hashcat vimos el descifrado de contraseñas offline: alguien tiene una lista de hashes y prueba millones de candidatos por segundo en su propia máquina, sin que el sistema atacado se entere. Hydra hace lo contrario: fuerza bruta online, probando usuario y contraseña directamente contra un servicio en marcha —SSH, un panel web, un servidor de correo— una petición cada vez, por la red.

Ese cambio de escenario lo cambia casi todo. Online eres lento, ruidoso y dependes de que el servicio te deje seguir intentándolo. Por eso Hydra es tan útil para entender el ataque como para diseñar la defensa: casi todas las contramedidas que un administrador puede aplicar —bloqueo de cuenta, fail2ban, límites de tasa, MFA, alertas en el SIEM— están pensadas precisamente para que una herramienta como esta no llegue a ninguna parte. Este artículo mira las dos caras.

Qué aprenderás en este artículo

La diferencia real entre fuerza bruta online y offline, y por qué importa · Qué servicios ataca Hydra y cómo es su sintaxis básica · Cómo se construyen y eligen las listas de usuarios y contraseñas · Por qué el paralelismo (-t) y el throttling determinan si te detectan · Cómo se detecta y se frena este ataque: la parte que de verdad importa

Uso legal y responsable

Lanzar fuerza bruta contra un servicio que no es tuyo y sin autorización expresa y por escrito es un delito de acceso ilícito a sistemas informáticos (en España, arts. 197 bis y 264 del Código Penal), aunque no llegues a adivinar ninguna credencial · Todos los ejemplos de este artículo apuntan a 192.168.56.x, el rango del laboratorio aislado que usamos en la serie: máquinas virtuales propias, sin salida a internet · Contra servicios reales —incluso «para probar»— el intento ya genera responsabilidad; además, un bloqueo masivo de cuentas es una denegación de servicio en sí misma

1. Online frente a offline: dos ataques distintos

Un ataque offline trabaja sobre material ya robado —normalmente hashes de una base de datos filtrada— en el equipo del atacante. No hay límite de velocidad más allá del hardware, no hay nadie vigilando, y la única defensa posible es que la contraseña sea fuerte y el hash se guardara con un KDF lento. Es lo que cubre Hashcat.

Un ataque online como el de Hydra prueba credenciales contra el servicio vivo. Cada intento es una conexión de red completa: negociación, autenticación, respuesta. Eso impone tres límites que el atacante no controla y el defensor sí.

	Offline (Hashcat)	Online (Hydra)
Qué necesita el atacante	Los hashes ya extraídos	Solo conectividad con el servicio
Velocidad	Miles de millones/s en GPU	De unas pocas a decenas por segundo
¿Deja rastro en la víctima?	Ninguno	Un registro por cada intento
Defensa principal	KDF lento + contraseña larga	Bloqueo, rate limiting, MFA, monitorización
¿La frena el servidor?	No puede	Sí, y con facilidad

La lectura para el defensor es cómoda: la fuerza bruta online es de los ataques más fáciles de detectar y cortar que existen. Si tiene éxito, casi siempre es por una contraseña por defecto o trivial y por la ausencia total de controles, no por la potencia del atacante.

2. Qué es Hydra y qué ataca

Hydra (o thc-hydra) es un paralelizador de intentos de login que sabe «hablar» decenas de protocolos de autenticación. Viene preinstalado en Kali. Su trabajo es simple: dada una lista de usuarios, una lista de contraseñas y un objetivo, prueba combinaciones en paralelo y avisa de las que el servicio acepta.

Acceso remoto: ssh, telnet, rdp, vnc
Web: http-get / http-post-form (formularios de login), http-head, y variantes con TLS
Correo: ftp, smtp, pop3, imap
Bases de datos: mysql, postgres, mssql, redis
Directorio y otros: ldap, smb, snmp

El módulo de formulario web (http-post-form) es el más usado y el más delicado de configurar: hay que indicarle la ruta, los nombres de los campos, y una cadena que aparezca en la respuesta solo cuando el login falla, para que Hydra distinga acierto de error.

3. Sintaxis básica

La forma general combina credenciales (usuario y contraseña, cada uno como valor único -l/-p o como lista -L/-P), opciones de control, el objetivo y el módulo.

# Estructura general
hydra -L usuarios.txt -P passwords.txt <objetivo> <servicio> [opciones]
 
# SSH contra una VM del laboratorio, usuario conocido, lista de contrasenas
hydra -l pruebas -P passwords.txt ssh://192.168.56.101 -t 4
 
# FTP con lista de usuarios y de contrasenas, parar al primer acierto por host
hydra -L usuarios.txt -P passwords.txt ftp://192.168.56.102 -f
 
# Formulario web POST (DVWA u otra app vulnerable del lab)
hydra -l admin -P passwords.txt 192.168.56.103 http-post-form \
  "/login.php:user=^USER^&pass=^PASS^:F=Login failed" -t 4

Opción	Para qué sirve
-l / -L	Un usuario / una lista de usuarios
-p / -P	Una contraseña / una lista de contraseñas
-t N	Número de intentos en paralelo (por defecto 16)
-f	Detenerse en cuanto encuentra una credencial válida
-w N	Tiempo de espera por respuesta, en segundos
-V / -vV	Mostrar cada intento (usuario:contraseña) por pantalla
-o fichero	Guardar los aciertos en un archivo
-s puerto	Puerto no estándar del servicio

El módulo http-post-form, campo a campo

Se separa en tres partes con ‘:’ — ruta, cuerpo con ^USER^ y ^PASS^ como marcadores, y condición · F=texto indica una cadena presente cuando el login FALLA; S=texto una presente cuando ACIERTA · Elegir mal esa cadena es el error más común: Hydra da miles de falsos positivos o ninguno · Aplicaciones modernas con token CSRF, cookies de sesión o rate limiting rompen este módulo, que es justamente el punto: son defensas que funcionan

4. Listas de usuarios y contraseñas

Un ataque de diccionario vale lo que valen sus listas. La potencia bruta apenas importa cuando solo puedes hacer unos pocos intentos por segundo: lo que decide es el orden en que pruebas.

4.1 Usuarios

Nombres genéricos: admin, administrator, root, user, test, guest, service
Convenciones de la organización: inicial+apellido, nombre.apellido, deducibles del formato del correo
Cuentas por defecto de cada producto (routers, cámaras, paneles): documentadas y públicas
SecLists (seclists/Usernames) reúne las listas de referencia que ya vienen en Kali

4.2 Contraseñas

Contraseñas por defecto del fabricante — la primera causa real de éxito de estos ataques
Listas cortas y priorizadas (los top 100-1000 de filtraciones) antes que rockyou.txt entero: online no da tiempo a más
Variaciones estacionales y locales: nombre de la empresa, ciudad, año en curso, ‘Primavera2026’
Reglas de complejidad mal entendidas por los usuarios: ‘Empresa2026!’, ‘Password1’

De dónde NO sacar listas

Descargar «wordlists» de foros al azar es una vía habitual de introducir malware en tu propia máquina · Usa las que trae Kali (/usr/share/wordlists, SecLists) o repositorios reconocidos y verificables

5. Paralelismo, ruido y por qué online es lento

La opción -t fija cuántos intentos van en paralelo. Subirla acelera… hasta que el servicio se satura, empieza a rechazar conexiones, o directamente te bloquea. Y cada intento, en paralelo o no, queda escrito en algún registro.

SSH: valores altos de -t provocan errores de «too many authentication failures» y desconexiones; 4 suele ser el máximo práctico
Servicios web: un pico de POST a /login desde una sola IP es un patrón trivial de detectar
Bloqueo de cuenta: si el objetivo bloquea tras N fallos, un ataque de contraseñas contra un usuario deja esa cuenta inutilizada — molestia para el usuario y alarma para el SOC
Password spraying: la técnica que intenta esquivar el bloqueo probando una contraseña común contra muchos usuarios, despacio; sigue siendo visible si se monitoriza la tasa global de fallos

Conclusión operativa: la fuerza bruta online «a saco» es de aficionado. Es lenta, se corta sola y se ve desde lejos. Su valor real hoy es didáctico y de verificación puntual en auditorías con permiso (¿siguen las credenciales por defecto?, ¿hay bloqueo de cuenta?).

6. El otro lado: detección y mitigación

Esta es la sección que justifica el artículo. Frente a la fuerza bruta online, el defensor tiene ventaja estructural: controla el servicio, ve todos los intentos y puede cortar por varios sitios a la vez.

6.1 Prevención

Control	Qué consigue
MFA / segundo factor	Adivinar la contraseña ya no basta para entrar: anula el ataque
Bloqueo temporal de cuenta	Corta la fuerza bruta contra un usuario tras N fallos
Rate limiting por IP y por cuenta	Frena el volumen sin bloquear al usuario legítimo del todo
Eliminar credenciales por defecto	Cierra la causa nº 1 de éxito real
Contraseñas largas + comprobación contra listas filtradas	Saca la contraseña del diccionario del atacante
Exponer solo lo necesario (VPN, allowlist, cambiar de puerto)	Reduce la superficie; el cambio de puerto es solo ruido, no defensa
CAPTCHA / prueba de trabajo tras varios fallos	Rompe la automatización de formularios web

6.2 Detección

Umbral de fallos de autenticación: muchos ‘failed login’ desde una IP en poco tiempo, o contra muchas cuentas — se mapea a MITRE ATT&CK T1110 (Brute Force)
Linux: líneas ‘Failed password’ y ‘Invalid user’ en /var/log/auth.log; Windows: Event ID 4625 (fallo) y picos anómalos de 4624/4740 (éxito / bloqueo)
fail2ban: lee esos registros y banea la IP en el firewall automáticamente tras X fallos; es la respuesta estándar en servidores Linux expuestos
Web: ratio de respuestas 401/403, o de 200 a /login con cuerpo de error, por IP y por minuto
Señal de éxito tras muchos fallos: un login correcto justo después de una ráfaga de fallos es más sospechoso que la ráfaga misma — hay que alertar sobre esa secuencia
User-Agent y cadencia: Hydra y similares tienen huellas de temporización muy regulares y cabeceras por defecto poco habituales

# Contar intentos fallidos de SSH por IP (revision rapida en un servidor propio)
grep 'Failed password' /var/log/auth.log | \
  awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head
 
# Estado de fail2ban para el jail de SSH
sudo fail2ban-client status sshd

Checklist para un servicio expuesto a internet

MFA obligatorio para todo acceso administrativo · Bloqueo de cuenta y/o rate limiting configurados y probados · fail2ban (o equivalente del WAF/proxy) activo sobre los registros de autenticación · Cero credenciales por defecto; inventario de cuentas de servicio revisado · Alertas en el SIEM por umbral de 4625 / ‘Failed password’ y por ‘éxito tras ráfaga de fallos’ · Acceso de gestión detrás de VPN o allowlist siempre que sea posible

7. Practicar en el laboratorio

La forma correcta de ver esto funcionar —por los dos lados— es montarlo en máquinas propias sin salida a internet.

Objetivos: Metasploitable 2, DVWA, o una VM Linux limpia a la que tú pongas un usuario con contraseña débil, todos en la red 192.168.56.x
Lanza Hydra con una lista corta que sepas que contiene la contraseña, y observa el intento en -vV
En paralelo, mira crecer /var/log/auth.log en la víctima: esa es la telemetría que vería un defensor
Activa fail2ban en la VM objetivo y repite: comprueba cómo el ataque se corta solo y tu IP queda baneada
Añade un segundo factor (por ejemplo con un PAM de TOTP) y comprueba que, aun acertando la contraseña, el acceso no se concede

Recordatorio final

Metasploitable y DVWA son deliberadamente vulnerables: nunca los expongas a una red con salida · Cualquier objetivo que no hayas creado tú necesita autorización escrita previa; sin ella, el intento ya es delito y un bloqueo masivo de cuentas es además una denegación de servicio

Conclusión

Hydra es una herramienta sencilla que enseña una lección doble. Por el lado ofensivo, deja claro que la fuerza bruta online es lenta, ruidosa y fácil de cortar: cuando funciona es por credenciales por defecto o triviales y por la ausencia de controles básicos, casi nunca por mérito del atacante.

Por el lado defensivo, es un banco de pruebas perfecto: MFA, bloqueo de cuenta, rate limiting, fail2ban y una alerta de SIEM bien puesta convierten este ataque en un registro más y una IP baneada. Si administras un servicio expuesto, trata la sección 6 como tu lista de tareas.

Referencias

github.com/vanhauser-thc/thc-hydra — Repositorio oficial y lista de módulos soportados · github.com/danielmiessler/SecLists — Listas de usuarios y contraseñas de referencia · OWASP Authentication Cheat Sheet — Bloqueo de cuenta, rate limiting y buenas prácticas · MITRE ATT&CK T1110 — Brute Force: sub-técnicas y detecciones · Nuestro artículo sobre Hashcat, para el enfoque offline y los KDF lentos

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)

Hydra: fuerza bruta de servicios de red paso a paso