El password spraying y el credential stuffing se manifiestan como un montón de inicios de sesión fallidos, pero la forma de ese montón es distinta, y también lo es la solución. Si su única alerta es "cinco fallos en una cuenta", se le escaparán ambos.
Tres ataques, tres patrones
La Credential Stuffing Prevention Cheat Sheet de OWASP los diferencia así:
| Ataque | Qué hace el atacante |
|---|---|
| Fuerza bruta | Prueba muchas contraseñas de un diccionario contra una sola cuenta |
| Credential stuffing | Prueba pares de usuario y contraseña obtenidos de la brecha de otro sitio |
| Password spraying | Prueba una única contraseña débil contra un gran número de cuentas distintas |
OWASP señala que, en muchos casos, las defensas son las mismas y que también sirven contra la fuerza bruta.
Qué buscar en los logs
La estrategia de detección de MITRE para el password spraying consiste en buscar un gran volumen de fallos de autenticación con una misma contraseña, o un conjunto reducido de ellas, en muchas cuentas de usuario dentro de una ventana de tiempo. En el caso del credential stuffing, son múltiples fallos con pares usuario/contraseña distintos desde una misma dirección IP o sesión en un intervalo corto.
Los atacantes se adaptan a las contramedidas más evidentes:
- Spraying ralentizado. MITRE describe herramientas de APT28 que realizaban aproximadamente cuatro intentos por hora y por cuenta objetivo durante días o semanas. La actividad de Quad7 usaba un único intento de inicio de sesión en un periodo de 24 horas, con lo que eludía los umbrales de detección de fuerza bruta. Los contadores por cuenta no detectarán esto.
- Spraying distribuido. MITRE también indica que APT28 utilizó un clúster de Kubernetes para realizar sprays distribuidos a gran escala. Un recuento solo por IP de origen no lo detectará, porque ninguna dirección falla con frecuencia. Cuente también las cuentas distintas que fallan por ventana de tiempo en todos los orígenes, y desglose esos mismos datos por ASN y user agent.
- Protocolos más discretos. Los atacantes pueden recurrir a intentos por LDAP y Kerberos, que es menos probable que generen eventos de alta visibilidad como el "logon failure" de Windows con ID de evento 4625, que se dispara habitualmente con conexiones SMB fallidas. Recopile los fallos de LDAP y Kerberos además del 4625.
Los atacantes suelen ir a por servicios de administración en puertos habituales: SSH (22/TCP), RDP (3389/TCP), SMB (445/TCP), LDAP (389/TCP), Kerberos (88/TCP) e interfaces de administración web en los puertos 80 y 443. También atacan el SSO, las aplicaciones en la nube con autenticación federada y el correo expuesto a internet, como Office 365 y OWA.
Microsoft 365: use bien el smart lockout
El smart lockout de Microsoft Entra está siempre activo. Por defecto bloquea una cuenta tras 10 intentos fallidos en los tenants de Azure Public, o tres en los tenants de Azure US Government. El primer bloqueo dura un minuto y se alarga con los fallos posteriores. Microsoft no revela el ritmo de incremento.
- Registra los hashes de las tres últimas contraseñas incorrectas, de modo que repetir la misma contraseña errónea no incrementa el contador. Así se evita que el mismo error de tecleo de un usuario lo deje bloqueado. Sirve de poco contra un spray, en el que cada cuenta ve la contraseña una sola vez.
- Las ubicaciones conocidas y las desconocidas tienen contadores de bloqueo independientes, por lo que un atacante desde una ubicación nueva puede quedar bloqueado mientras el usuario legítimo sigue trabajando con normalidad.
- Los valores personalizados requieren Microsoft Entra ID P1 o superior. Inicie sesión en el Microsoft Entra admin center como mínimo con el rol Authentication Policy Administrator y vaya a Entra ID > Authentication methods > Password protection. Allí se establecen el Lockout threshold y el Lockout duration en segundos (por defecto, 60).
- Entra también bloquea por defecto algunos inicios de sesión según señales de tráfico IP y de comportamiento, y devuelve
AADSTS50053 - IdsLocked, con independencia de que la contraseña fuera válida. Considere objetivo de un ataque a las cuentas que muestren este código, pero no lo interprete como prueba de que la contraseña fuera correcta o incorrecta.
El smart lockout no garantiza que un usuario legítimo nunca llegue a quedar bloqueado. MITRE añade la otra cara de la moneda: una política demasiado estricta puede provocar una denegación de servicio, con todas las cuentas del ataque bloqueadas.
Entornos híbridos
Con pass-through authentication, el umbral de Entra debe ser inferior al umbral de AD DS local, y el umbral de AD DS debería ser al menos dos o tres veces superior. La duración del bloqueo en Entra debe ser mayor que la de AD DS. El ejemplo de Microsoft es un umbral de 10 frente a 20, y 120 segundos frente a 60. La duración en Entra se fija en segundos y en AD DS en minutos, así que compruebe las unidades.
El seguimiento de hashes no está disponible con pass-through authentication. Para consultar los valores de su AD DS, abra Group Policy Management, edite la directiva que contiene su configuración de bloqueo y navegue hasta Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Account Lockout Policy.
Su propia página de login y los servicios expuestos
El bloqueo es un control por cuenta. En nuestra opinión, un ataque de stuffing que pruebe cada cuenta una o dos veces a menudo nunca alcanzará el umbral, así que no lo trate como su defensa principal. MITRE advierte de que el stuffing puede causar numerosos fallos y bloqueos, pero eso depende de su política. Sus mitigaciones para ambas técnicas añaden:
- Autenticación multifactor (MFA), activada en los servicios expuestos a internet siempre que sea posible.
- Políticas de acceso condicional que bloqueen los inicios de sesión desde dispositivos no conformes o desde fuera de los rangos de IP definidos de la organización.
- Bloqueo de peticiones de riesgo, como las procedentes de servicios de anonimización o proxies.
- Políticas de contraseñas basadas en las directrices del NIST.
- En el caso del stuffing, restablecer de forma proactiva las cuentas que se sepa que aparecen en credenciales filtradas, bien de inmediato, bien tras detectar intentos de fuerza bruta.
Si se trata de una aplicación propia, la Authentication Cheat Sheet de OWASP incluye apartados sobre protección frente a ataques automatizados, CAPTCHA, y registro y monitorización.
Por dónde empezar
- Haga un inventario de todos los logins accesibles desde internet: Microsoft 365 u OWA, VPN, RDP, SSH, SSO y sus propios formularios web. Cierre todo puerto de administración que no necesite estar abierto.
- Revise el umbral y la duración del smart lockout en Entra ID > Authentication methods > Password protection. Con pass-through authentication, compárelos con su política de bloqueo de AD DS aplicando las reglas anteriores.
- Cree dos consultas sobre sus logs de inicio de sesión. La primera cuenta las cuentas distintas con inicios de sesión fallidos por IP de origen y hora. La segunda ignora el origen: cuenta las cuentas distintas que fallan por ventana de tiempo en conjunto y después desglosa por ASN y user agent. Configure alertas para ambas y mantenga
AADSTS50053como una vista aparte. - Active la MFA en todos los servicios expuestos a internet y, después, añada reglas de acceso condicional para dispositivos no gestionados y servicios de anonimización.
- Compare las cuentas de su plantilla con brechas conocidas, por ejemplo con nuestro comprobador de contraseñas filtradas, y restablezca las que coincidan. Si no dispone de personal para vigilar los logs a diario, la monitorización gestionada cubre esa carencia.
