Problema

En entornos Microsoft Entra ID (antes Azure AD) que utilizan Password Hash Sync (PHS), los analistas de SOC a menudo necesitan determinar si una autenticación fallida fue causada por una contraseña incorrecta o por un paso de MFA que no se completó. Los registros de “Sign‑in logs” presentan una estructura de pasos (authenticationStep) donde cada paso indica el método usado, si tuvo éxito y un detalle.

El patrón que genera dudas es:

  • Un solo paso.
  • method vacío.
  • succeeded = false.
  • errorCode = 50074 (MFA required).

Al comparar con pruebas controladas, los intentos con contraseña correcta siempre generan dos pasos: el primero con method = Password y succeeded = true, y el segundo con MFA fallido. Cuando el registro muestra solo el paso vacío, no está claro si la contraseña fue rechazada o si el motor de autenticación omitió el paso de contraseña por alguna razón interna.

El reto es decidir, a partir de los logs, si el error 50074 solo aparece después de una validación de contraseña exitosa o si puede aparecer también cuando la contraseña es inválida.

Causa

1. Flujo de autenticación estándar con PHS

  1. Password verification – En la capa de Azure AD se compara el hash sincronizado con el hash recibido. Si coincide, se registra method = Password, succeeded = true, detail = "Correct password".
  2. MFA evaluation – Si la política requiere MFA, se crea un segundo paso. Cuando el usuario abandona la pantalla o la respuesta es negativa, el segundo paso queda con method vacío y errorCode = 50074.

2. Optimización de registro cuando la contraseña falla

Si la verificación de contraseña falla, Azure AD no avanza al paso de MFA. En versiones recientes del servicio, el motor omite el registro explícito del paso de contraseña y devuelve directamente un error de MFA (50074) con method vacío. Esto se hace para evitar revelar si la falla provino de la contraseña o de la política de MFA, alineándose con la práctica de “credential‑stuffing mitigation”.

3. Condiciones que provocan la ausencia del paso de contraseña

  • Política de “MFA required” con “block on password failure”: la política fuerza a bloquear antes de registrar la contraseña cuando la cuenta está bajo riesgo.
  • Sincronización parcial de hash: si el hash del usuario no está disponible en la nube (por ejemplo, replicación retrasada), Azure AD delega la evaluación a la capa de MFA y devuelve 50074 sin paso de contraseña.
  • Uso de “Conditional Access” que combina password y MFA en una única evaluación: en algunos escenarios de “combined authentication”, el registro se colapsa en un solo paso.

En la práctica, los tres casos aparecen con mayor frecuencia en entornos con alta seguridad y políticas de detección de anomalías.

Solución

1. Corroborar la presencia del paso de contraseña

Utiliza PowerShell o la API Graph para extraer los authenticationDetails de los últimos 24 h y filtra por errorCode = 50074. Si el campo authenticationStepDetails contiene un objeto con authenticationMethod = "Password" y succeeded = true, la contraseña fue válida. Si sólo aparece el paso vacío, la validez es incierta y se debe profundizar.

2. Añadir un “sign‑in event” de diagnóstico

Configura una política de Conditional Access que registre explícitamente el método de contraseña, incluso cuando la MFA falle. En Azure Portal:

  • Security > Conditional Access > Policies > New policy
  • Selecciona Grant > Require multi‑factor authentication y marca Enable security defaults logging.
  • En Session, activa Sign‑in frequency con un valor bajo (por ejemplo, 1 h). Esto fuerza a Azure AD a crear el registro de contraseña antes de evaluar MFA.

3. Verificar la sincronización de hashes

Ejecuta Get-ADSyncScheduler y revisa SyncCycleEnabled. Si la sincronización está deshabilitada o retrasada, los hashes pueden no estar disponibles y Azure AD caerá directamente en el paso de MFA. Reactiva la sincronización o fuerza una ejecución manual:

Start-ADSyncSyncCycle -PolicyType Delta

4. Revisar la política de “Block credential‑stuffing”

En Azure AD > Security > Authentication methods > Password protection, verifica que la opción Enforce password protection esté activada. Cuando está activa, Azure AD puede omitir el paso de contraseña en los logs para evitar dar pistas a atacantes.

5. Utilizar la API Graph para un análisis más granular

La consulta siguiente devuelve los detalles de cada paso:

GET https://graph.microsoft.com/v1.0/auditLogs/signIns?$filter=errorCode eq 50074&$select=id,userDisplayName,authenticationDetails

Con el resultado, inspecciona authenticationDetails → authenticationStepDetails. Si el array contiene un objeto con authenticationMethod = "Password" y succeeded = true, la contraseña pasó la validación.

Cuándo aplicar esta solución

  • Síntomas: logs con errorCode = 50074 y solo un paso vacío; necesidad de evidenciar si la contraseña fue correcta para auditorías o investigaciones de incidentes.
  • Entornos: Azure AD con Password Hash Sync, políticas de MFA obligatoria y Conditional Access.
  • No aplica: entornos que usan Pass‑Through Authentication (PTA) o federación con AD FS, ya que el flujo de registro es diferente y el error 50074 no se genera en los mismos términos.

Código

# Extraer los últimos 100 intentos con error 50074 y mostrar el método de cada paso
$uri = "https://graph.microsoft.com/v1.0/auditLogs/signIns?\$filter=errorCode eq 50074&\$top=100&\$select=id,userPrincipalName,authenticationDetails"
$signins = Invoke-RestMethod -Method Get -Uri $uri -Headers @{Authorization = "Bearer $($token)"}
foreach ($s in $signins.value) {
    $steps = $s.authenticationDetails.authenticationStepDetails
    $pwdStep = $steps | Where-Object { $_.authenticationMethod -eq "Password" }
    if ($pwdStep) {
        Write-Output "[$($s.id)] $($s.userPrincipalName) – Password OK, MFA failed"
    } else {
        Write-Output "[$($s.id)] $($s.userPrincipalName) – No password step, indeterminate"
    }
}

Verificación

  1. Ejecuta la política de diagnóstico descrita y genera un intento de inicio de sesión con contraseña correcta y MFA cancelado.
  2. Consulta los logs con la consulta Graph o PowerShell.
  3. Confirma que ahora aparecen dos pasos: Password (true) y MFA (false).
  4. Repite el proceso con una contraseña incorrecta; el registro debe mostrar solo el paso vacío con 50074.
  5. Si ambos casos siguen mostrando solo un paso, revisa la sincronización de hashes y la política de “Block credential‑stuffing”.

Notas adicionales

  • La ausencia del paso de contraseña no siempre implica que la contraseña sea incorrecta; puede ser síntoma de una política de seguridad que oculta la información.
  • En auditorías regulatorias, es recomendable habilitar la captura completa de authenticationDetails mediante Azure Monitor > Diagnostic settings, enviando los logs a Log Analytics para análisis histórico.
  • Los cambios en políticas de Conditional Access pueden tardar hasta 5 min en propagarse; espera ese tiempo antes de validar los resultados.
  • Si trabajas con entornos híbridos (PHS + PTA), combina la revisión de los logs de Azure AD con los eventos de seguridad del controlador de dominio (Event ID 4625) para obtener una visión completa.