Los equipos de seguridad necesitan extraer significado real de cada intento de inicio de sesión registrado en Microsoft Entra ID. Cuando un ataque de password spraying deja cientos o miles de entradas con los códigos 53004 (fuera de horario permitido) y 53003/53000 (bloqueado por Acceso Condicional), la primera duda es siempre la misma: ¿esos bloqueos indican que la contraseña era correcta o los atacantes siguen tanteando claves al azar?
Introducción
En este artículo despejamos esa incertidumbre profundizando en:
- Cómo funciona el flujo de autenticación interna de Entra ID y en qué etapa se generan los distintos códigos de error.
- Métodos prácticos para deducir si la contraseña superó la autenticación primaria.
- Estrategias recomendadas para contener y reducir el volumen de intentos de spray.
- Pasos de investigación y escalado cuando las trazas no bastan.
Panorama rápido de preguntas y respuestas
Pregunta: ¿Los mensajes “fuera de horario” (53004) o “bloqueado por Acceso Condicional” (53003/53000) aparecen aunque la contraseña sea incorrecta?
Respuesta corta: No en la mayoría de los casos. Esos dos códigos se generan después de una autenticación primaria correcta. La excepción es cuando la directiva de Acceso Condicional incluye la acción “requerir MFA”; si la contraseña está mal, el proceso se detiene antes y verás 50126 o 50132.
Cómo se procesa un inicio de sesión en Entra ID
1. Autenticación primaria (Password Validation)
Se verifica la combinación usuario–contraseña. Si la contraseña no coincide con el hash almacenado, el servicio responde con “Invalid username or password” (50126). El flujo termina aquí.
2. Evaluación de directivas de Acceso Condicional
Solo ocurre si la contraseña fue válida o si el método primario elegido (por ejemplo, certificado) superó el filtro. En este punto, Entra ID comprueba:
- Estado del dispositivo (compliance, join, riesgo).
- Ubicación (incluidas VPN, rangos seguros o prohibidos).
- Horario configurado en Logon Hours ya sea on‑prem (si hay sync) o en la nube.
- Requisitos de MFA, autenticadores FIDO2, presencia de identidad protegida, etc.
Si alguna regla bloquea la sesión se devuelven códigos 53004 (Logon Hours), 53003 o 53000 (Acceso Condicional).
3. MFA y paso posterior (si aplica)
Solo si todo lo anterior se cumple: Entra ID lanza el reto MFA. Fallos en esta etapa generan códigos como 50074 (MFA Failed) o 50076 (MFA Required). La cadena de control ya garantizó que la contraseña era correcta.
Interpretación práctica de los códigos de error
| Código ( Mensaje ) | Momento en el flujo | Lo que sugiere sobre la contraseña |
|---|---|---|
| 50126 / 50132 Invalid username or password | Autenticación primaria | Contraseña (o usuario) incorrecta. No se evalúan directivas ni MFA. |
| 53004 El usuario intentó iniciar sesión fuera del horario permitido | Después de la autenticación primaria | Contraseña correcta. Logon Hours impide continuar. |
| 53003 Se ha bloqueado el acceso debido a directivas de Acceso Condicional | Después de la autenticación primaria, antes del reto MFA | Contraseña correcta en la mayoría de los casos. Una directiva (ubicación, riesgo, dispositivo, etc.) deniega la sesión. |
| 53000 Access has been blocked by Conditional Access | Igual que 53003 | Mismo significado funcional que 53003. |
Cómo decidir si la contraseña ya está comprometida
La visualización repetida de 53004 o 53003 para el mismo UPN, desde IPs nuevas o con agentes de usuario sospechosos, es un fuerte indicador de que los atacantes ya poseen la contraseña y chocan contra barreras lógicas.
- Correlaciona con señales de riesgo: Identity Protection clasifica al usuario en riesgo High si detecta un uso anómalo de credenciales válidas.
- Revisa la columna “MFA Required” en el portal de Sign‑in Logs: si “Sí” y aún así el inicio de sesión no llega a 50074/50076, la directiva de bloqueo se disparó antes.
- Observa el intervalo entre eventos: los sprayers envían la misma contraseña a muchos usuarios en segundos. Un patrón 53004 para varios UPN distintos casi simultáneos sugiere spray con un diccionario que ha coincidido.
Buenas prácticas para mitigar el password spraying
Optimizar el diseño de Acceso Condicional
- Alínea reglas basadas en horario o ubicación solo a grupos que realmente las necesiten.
- Evita condicionar el inicio de sesión de cuentas privilegiadas exclusivamente por ubicación; confía más en MFA fuerte y device compliance.
Activar capacidades de protección nativas
- Smart Lockout: diferencia entre intentos legítimos y ataques distribuido‑lentos. Bloquea al atacante y permite al usuario.
- Password Protection: prohíbe contraseñas comunes y variantes con fecha, estación o teclado.
- Habilitar “Stop legacy authentication”: SMTP, POP, IMAP y otros protocolos obsoletos no soportan MFA y son el vector preferido de spray.
Supervisión continua
- Exporta Sign‑in Logs a Sentinel o a un SIEM externo via Diagnostic Settings; así podrás crear consultas KQL que agrupen por código, IP y agente de usuario.
- Configura alertas por umbral: más de n eventos 53004 para un UPN en menos de 15 minutos → señal de compromiso.
- Habilita la Risky Sign‑in policy en Identity Protection para forzar restablecimiento de contraseña ante coincidencias de riesgo.
Procedimiento de investigación en el portal
- Navega a Azure Portal → Entra ID → Sign‑in Logs.
- Filtra por Result code = 53004 (o 53003/53000) y por el UPN sospechoso.
- Haz clic en el evento, luego en la pestaña Conditional Access: verás la política responsable y el paso exacto.
- En la pestaña Location revisa la IP. Usa la opción “Map” para descubrir patrones regionales.
- Vuelve a filtrar por esa IP y comprueba si aparece en cuentas distintas. Spray multi‑usuario que golpea la misma IP es típico de botnets.
- En la pestaña Risk verifica si Identity Protection asignó Risky User = Yes.
- Si la contraseña parece comprometida, impón Reset Password inmediato y obliga al usuario a registrar métodos MFA seguros (FIDO2 o Microsoft Authenticator con notificación y código).
Escenarios de ejemplo
Ataque fuera de horario
Un actor conoce la contraseña de un empleado que solo trabaja de 8:00 a 16:00. Envía la solicitud a las 2:13; se registra 53004. Aunque se bloquea, el atacante ya validó las credenciales. La solución es ampliar Logon Hours y exigir MFA con “Sign‑in frequency = 24 h”. Así, incluso a las 9:00 se pedirá un segundo factor.
Ataque con contraseña incorrecta y directiva MFA
La organización aplica “require MFA” para todo el grupo “Office Apps”. Un bot prueba P@ssw0rd2022 contra 500 usuarios. Cada intento produce 50126. Al no haber clave correcta, el proceso no toca Acceso Condicional ni genera 53003.
Cuándo escalar a Microsoft Q&A
Si, tras revisar trazas, no puedes explicar por qué ciertos inicios de sesión alcanzan 53003 desde ubicaciones internas válidas, prepara esta información antes de publicar en el foro:
- Capturas o exportaciones CSV de los eventos afectados.
- Detalle de las directivas (incluir policy ID y orden).
- Topología de red (VPN, proxies, ZTNA) si el problema es de ubicación.
- Número aproximado de cuentas, frecuencia y hora de los incidentes.
Usa la etiqueta “Microsoft Entra ID” para que un ingeniero especializado responda con la arquitectura exacta del flujo que aplica a tu entorno.
Preguntas rápidas y respuestas resumidas
- ¿Basta con bloquear por país?
No. Los atacantes usan proxies residenciales dentro del mismo país del objetivo. Combina país con MFA y device compliance. - ¿Es seguro permitir correo IMAP a los usuarios?
No. IMAP básico omite MFA; deshabilítalo o exige OAuth2 moderno. - ¿Debo instalar agentes de seguridad extra?
Solo si necesitas visibilidad más granular. Entra ID ya registra lo esencial; lo importante es exportarlo a tu SIEM. - ¿Smart Lockout afecta a usuarios legítimos?
Rara vez; se basa en reputación de IP y patrones de uso. Ajusta el umbral si recibes quejas.
Conclusión
Entender en qué fase exacta del flujo de autenticación ocurre cada código de error es la clave para decidir si un intento de inicio de sesión es ruido o evidencia de credenciales filtradas. Los códigos 53004 y 53003/53000 revelan casi siempre que la contraseña ha sido aceptada; tu política la bloquea después. Eso te da la oportunidad de:
- Rotar la contraseña antes de que el actor encuentre un punto de entrada sin restricciones.
- Fortalecer Acceso Condicional para que el atacante choque con MFA o dispositivo registrado, aunque la clave sea correcta.
- Enriquecer tus alertas con contexto (IP, agente, riesgo) y elevar los casos realmente críticos.
Aplica las prácticas descritas, monitoriza los códigos apropiados y, cuando las trazas no alcancen, recurre al canal especializado de Microsoft para cerrar el círculo.