Rastrear los intentos maliciosos de inicio de sesión no es fácil
Recientemente, investigamos un comportamiento sospechoso en un entorno en el que se había configurado la autenticación sin contraseña de Azure. El motivo de la investigación fue que varios usuarios recibieron mensajes inesperados de la aplicación Authenticator. Afortunadamente, ninguno de los usuarios cayó en la trampa ni dejó entrar al atacante.
Este tipo de evento, conocido como MFA Fatigue, es rutinario y esperado en organizaciones grandes y pequeñas. Los atacantes aprovecharán esta técnica de ingeniería social para engañar a los usuarios para que acepten las solicitudes de autenticación push, lo que ha tenido éxito en ataques recientes, incluyendo Uber).
El escenario resultó ser especialmente difícil de investigar debido a los registros de logs asociados a los avisos fallidos sin contraseña.
Las limitaciones en la capacidad de registro complican las investigaciones
El seguimiento de los intentos de inicio de sesión malintencionados es crucial para proteger los entornos de cloud y sólo es posible mediante la supervisión de los registros de cloud disponibles . Aunque Microsoft y otros proveedores de cloud publican esquemas de registro y ofrecen acuerdos de nivel de servicio (SLA) para la entrega de registros, todavía hay varios problemas que afectan a los registros de cloud :
- Los tipos de eventos de registro no suelen estar bien documentados, y a veces ni siquiera lo están.
- Algunos de los valores e ID registrados son internos del proveedor de cloud y su significado no está claro.
- Se añaden nuevos tipos de registros, se retiran otros y se modifican los formatos sin previo aviso a los consumidores.
Todo esto complica la supervisión y la respuesta ante incidentes, y deja a los consumidores de cloud inseguros sobre la integridad de los registros y jugando a ponerse al día con los cambios no anunciados, por lo que resulta difícil investigar las solicitudes fallidas sin contraseña a partir de los datos registrados.
Cómo descubrir y mitigar los fallos de inicio de sesión sin contraseña en Azure
Autenticación sin contraseña
Para aquellos que no estén familiarizados, la autenticación sin contraseña es una opción sólida para mitigar el riesgo de que los usuarios creen contraseñas inseguras. Hay varias formas de habilitar la autenticación sin contraseña en Azure. En el entorno investigado, se utilizó la aplicación Microsoft Authenticator.
Para inscribirse en la autenticación sin contraseña, los usuarios finales deben seguir estos pasos de configuración detallados. Una vez que el usuario se haya inscrito en este método, podrá introducir su nombre de usuario en la solicitud de inicio de sesión de Azure y, a continuación, seleccionar la opción "Usar una aplicación en su lugar":
A continuación, el usuario recibe un número que debe introducir en la aplicación móvil para completar el proceso:
Si el número coincide, el usuario queda autenticado. Además de ser razonablemente seguro, este método ya no requiere que los usuarios se ocupen de crear y recordar buenas contraseñas, lo que mejora notablemente la usabilidad.
Investigación
En el pasado hemos monitorizado diferentes formas de configurar MFA en Azure, incluyendo el uso de inicio de sesión sin contraseña con Microsoft Authenticator como segundo factor (es decir, cuando el usuario sería preguntado en la aplicación después de introducir la contraseña correcta). Microsoft Authenticator como segundo factor observamos uno de los dos errores siguientes en los registros si se abandonan los avisos de Authenticator, o el código es incorrecto:
- 50074 Se requiere autenticación fuerte.
- 500121 Error de autenticación durante la solicitud de autenticación fuerte.
Como resultado, nuestras consultas de detección y caza se configuraron para buscar estos códigos de error.
Sin embargo, cuando la aplicación Microsoft Authenticator se configura como un único factor, como en el caso de la autenticación sin contraseña, se produce el siguiente error cuando se abandona la solicitud
- {"errorCode":1003033,"failureReason":"The remote NGC session was denied."}
Este código de error era novedoso, algo que nunca habíamos visto antes y la búsqueda en Internet no aporta prácticamente ninguna información sobre su origen. El mensaje de error también era críptico, sin ninguna explicación sobre qué es "NGC". Tras algunas búsquedas, establecimos que corresponde al GUID D6886603-9D2F-4EB2-B667-1971041FA96B, que está documentado como "PIN Credential Provider".
Al examinar el registro, observamos otras incoherencias (véase la captura de pantalla siguiente):
- La ubicación y los detalles del dispositivo (en rojo) no se rellenan.
- Falta información sobre la aplicación y los recursos (en azul).
- La información del usuario (en morado) es limitada. UserPrincipalName y UserDisplayName no se rellenan con sus valores esperados (dirección de correo electrónico y nombre completo del usuario). En su lugar, el valor UserId está en los tres campos.
El código de error inusual y los datos que faltan en los registros hacen que sea difícil alertar sobre tales eventos e investigarlos adecuadamente.
Mitigación
Dada la dificultad que tuvimos para investigar este incidente, quisimos compartir los detalles que recopilamos con la comunidad de seguridad para que los profesionales de la seguridad pudieran ajustar sus consultas de caza para detectar esta condición. En Vectra ya hemos actualizado nuestros productos para cubrir este escenario.
La consulta de caza podría ser tan simple como el siguiente fragmento de Kusto que encontrará todos los intentos fallidos de inicio de sesión sin contraseña en los últimos 30 días:
SigninLogs | where TimeGenerated > ago(30d) | where ResultType == 1003033
Algunos otros códigos de error relacionados con NGC también pueden ser de interés:
Para llevar:
- A medida que introduzca nuevas formas de autenticación en su entorno, evalúe los registros resultantes de las interacciones con estos nuevos mecanismos. Busque nuevos códigos de error y tipos de registro que deban tenerse en cuenta para la supervisión y las alertas.
- Las organizaciones que controlan los fallos de inicio de sesión sin contraseña deberían considerar añadir el código 1003033 a sus consultas de búsqueda. Tenga en cuenta que la información disponible con este registro es limitada: no podrá utilizar UserPrincipalName ni otra información que normalmente está disponible en los registros de inicio de sesión.
- Un llamamiento a los proveedores de cloud (incluido Microsoft): por favor, empiecen a tratar los registros como una característica de seguridad crucial de la que dependen muchos actores. Por favor, documenten minuciosamente los registros, completen la información que falta en ellos y anuncien cualquier cambio que realicen. Esto ayudará a sus clientes y a los proveedores de seguridad en su lucha por mantener la seguridad de todos.
El autor desea agradecer a Peter Schaub y Rey Valero su ayuda en la investigación de este incidente.