Los puntos ciegos del logging de autenticación en la nube

Un equipo de seguridad de TrustedSec acaba de revelar su tercer y cuarto métodos para saltarse el logging de inicio de sesión de Azure. Son cuatro técnicas independientes para autenticarse en los servicios cloud de Microsoft sin que la autenticación aparezca en los logs en los que los equipos de seguridad confían para detectar amenazas. El inicio de sesión ocurrió. Los logs no lo registraron. Quien monitorizara esos logs en busca de actividad sospechosa no vio nada.

Esto no es un problema teórico. Si un atacante roba credenciales y las usa para acceder a tu entorno de Azure, lo primero que hace tu equipo de seguridad es revisar los logs de inicio de sesión. Si esos logs están incompletos (si categorías enteras de autenticación no generan entradas), tu capacidad de detección tiene un agujero que no conocías. Y llevas tiempo tomando decisiones de seguridad basándote en la suposición de que los logs estaban completos.

Por qué los logs de autenticación tienen huecos

La suposición ingenua es que el logging de autenticación es sencillo: alguien se autentica, tú lo registras. En la práctica, la autenticación en la nube es un sistema enorme con decenas de protocolos, endpoints y tipos de token, y la cobertura de logging varía entre ellos.

Azure Active Directory (ahora Entra ID) gestiona la autenticación de Microsoft 365, los recursos de Azure, apps de terceros vía SAML/OIDC, aplicaciones locales heredadas a través de App Proxy, service principals, managed identities y mucho más. Cada una de estas rutas de autenticación tiene su propio backend, su propia canalización de logging y sus propios casos límite. Los logs de inicio de sesión los genera el servicio de autenticación, pero algunos flujos evitan ese servicio o usan rutas heredadas anteriores a la infraestructura de logging actual.

Huecos de los protocolos heredados

Microsoft mantiene compatibilidad hacia atrás con protocolos de autenticación de principios de los 2000, protocolos anteriores a su infraestructura de logging moderna. Algunas rutas de autenticación SMTP, IMAP y POP3 usan flujos 'Basic Auth' que se autentican en la capa de transporte de correo en lugar de hacerlo a través del endpoint de tokens estándar de Azure AD. Estas autenticaciones pueden no generar las mismas entradas de inicio de sesión que los flujos modernos OAuth/OIDC.

Microsoft lleva años retirando Basic Auth, pero en los entornos empresariales la retirada es lenta. Las organizaciones con clientes de correo antiguos, escáneres que envían documentos por email o aplicaciones de línea de negocio más viejas pueden seguir con Basic Auth habilitado. Cada ruta heredada es un posible hueco en el logging.

Autenticación con service principals

Los service principals (identidades no humanas que usan aplicaciones y automatizaciones) se autentican de forma distinta a los usuarios. Sus eventos de inicio de sesión aparecen en un flujo de logs separado (inicios de sesión de service principals frente a inicios de sesión interactivos y no interactivos). Los equipos de seguridad que solo monitorizan el log de inicios de sesión interactivos se pierden por completo la actividad de los service principals.

Esto importa porque los service principals comprometidos son un vector de ataque habitual. Un atacante que obtiene las credenciales o el certificado de un service principal puede autenticarse como esa aplicación y acceder a cualquier recurso para el que tenga permisos. Si el equipo de seguridad solo vigila los inicios de sesión de usuarios, nunca lo verá.

Reproducción y renovación de tokens

No todos los accesos implican una autenticación nueva. Los refresh tokens de OAuth permiten seguir accediendo sin volver a autenticarse. Si un atacante roba un refresh token válido (a través de un dispositivo comprometido, tráfico interceptado o malware), puede canjearlo por nuevos access tokens sin disparar las mismas entradas de inicio de sesión que generaría una autenticación con contraseña. El inicio de sesión inicial quedó registrado, pero las renovaciones posteriores pueden aparecer como inicios de sesión no interactivos, que muchas reglas de detección no monitorizan.

El problema de la ingeniería de detección

Los huecos en el logging de autenticación revelan un problema más amplio en la seguridad cloud: construimos sistemas de detección sobre logs que damos por completos y luego nos sorprendemos cuando los atacantes encuentran caminos que no generan logs.

La arquitectura de seguridad estándar para entornos cloud funciona así: los servicios cloud generan logs → los logs fluyen a un SIEM (sistema de gestión de información y eventos de seguridad) → las reglas de detección analizan los logs en busca de patrones sospechosos → las alertas disparan una investigación. Esto solo funciona si los logs capturan toda la actividad relevante. Si no lo hacen, tu SIEM es una forma muy cara de monitorizar una imagen incompleta.

Typical detection rule logic:
IF sign-in from unusual location
AND sign-in at unusual time
AND multiple failed attempts followed by success
THEN alert: possible credential compromise
What this misses:
- Authentication via legacy protocol → no sign-in log entry
- Stolen refresh token → appears as normal non-interactive sign-in
- Service principal abuse → in a different log stream entirely
- Authentication bypasses → sign-in doesn't appear at all
The rule is correct. The data it operates on is incomplete.

Lo que sí puedes hacer

No puedes arreglar los huecos de logging del proveedor cloud: eso le toca a Microsoft (o a AWS, o a Google). Pero sí puedes construir estrategias de detección que no dependan únicamente de que los logs de autenticación estén completos.

Monitorizar varias fuentes de logs

Los logs de autenticación son una señal. Los logs de actividad son otra. Aunque el inicio de sesión de un atacante no aparezca en los logs de autenticación, sus acciones posteriores (leer correos, acceder a archivos, consultar bases de datos, modificar configuraciones) generan sus propias entradas. Cruzar los logs de actividad con los de autenticación revela incoherencias: la actividad de una identidad sin un inicio de sesión reciente correspondiente es sospechosa, independientemente de por qué no se registró ese inicio de sesión.

-- Detection query: activity without recent authentication
-- (KQL-style for Azure Sentinel/Microsoft Sentinel)
let timeframe = 24h;
let activity_logs = AuditLogs
| where TimeGenerated > ago(timeframe)
| summarize Actions = count() by Identity, bin(TimeGenerated, 1h);
let signin_logs = SigninLogs
| where TimeGenerated > ago(timeframe)
| summarize LastSignIn = max(TimeGenerated) by UserPrincipalName;
activity_logs
| join kind=leftanti signin_logs
on $left.Identity == $right.UserPrincipalName
| where Actions > 5  // filter noise
// Results: identities with activity but no sign-in log entry
// These need investigation — either a logging gap or a bypass

Deshabilitar la autenticación heredada

Si no usas protocolos heredados (Basic Auth para SMTP, IMAP, POP3), deshabilítalos. Así eliminas categorías enteras de huecos de logging, porque las rutas de autenticación que evitan el logging moderno sencillamente no se pueden usar. Las políticas de acceso condicional de Azure pueden bloquear la autenticación heredada por usuario, por grupo o para todo el tenant.

Antes de deshabilitarla, audita el uso actual. Irónicamente, los logs de inicio de sesión de Azure sí muestran algunos intentos de autenticación heredada, y el workbook de Entra ID para autenticación heredada ayuda a identificar las aplicaciones que siguen usando protocolos antiguos. Arregla primero esas aplicaciones y luego bloquea la autenticación heredada.

Monitorizar la actividad de los tokens

Implementa Continuous Access Evaluation (CAE) si tu entorno lo soporta. CAE permite a Azure AD revocar tokens casi en tiempo real cuando cambian las condiciones (usuario deshabilitado, inicio de sesión de alto riesgo detectado, cambio de ubicación IP). Sin CAE, un access token robado es válido hasta que caduca (normalmente una hora), independientemente de lo que haga el equipo de seguridad.

Monitoriza también la duración de los tokens y los patrones de renovación. Un refresh token usado desde una IP nueva, un dispositivo nuevo o a horas inusuales debería marcarse: a menudo es la única señal de robo de tokens.

Prueba tu propio logging

Lo más impactante que puedes hacer es probar periódicamente si tu logging captura realmente lo que crees. Autentícate por cada método que soporte tu entorno (interactivo, no interactivo, service principal, protocolo heredado) y verifica que cada uno genera las entradas de log esperadas. Si no lo hace, habrás encontrado un hueco antes que un atacante.

Esto es una forma de testing en ingeniería de detección que pocas organizaciones hacen de forma sistemática. La mayoría de equipos escriben reglas de detección y dan por hecho que funcionan. Validar la calidad de los datos subyacentes (confirmar que los eventos de los que dependen tus reglas se están registrando realmente) es posiblemente más importante que las propias reglas.

La lección general

Los bypasses de inicio de sesión de Azure no son exclusivos de Microsoft. Todos los proveedores cloud tienen rutas de autenticación con logging incompleto. AWS CloudTrail tiene sus propios huecos conocidos: ciertas operaciones del plano de control en algunas regiones, ciertas asunciones de roles vinculados a servicios y patrones de encadenamiento de roles entre cuentas que pueden ocultar la identidad original. Los logs de auditoría de Google Cloud tienen casos límite similares.

La lección no es 'el logging de Azure está roto'. Es que todo logging es incompleto, y las arquitecturas de seguridad que asumen lo contrario van a fallar. La defensa en profundidad no consiste solo en tener varios controles de seguridad, sino en tener varias fuentes independientes de visibilidad. Si tu detección depende por completo de que una sola fuente de logs esté completa, tienes un punto único de fallo en tu postura de seguridad.

Diseña tu detección partiendo de la premisa de que cualquier fuente de logs individual puede estar incompleta o eludirse. Cruza logs de autenticación, de actividad, de red y telemetría de endpoints. Busca incoherencias entre fuentes: suelen apuntar exactamente a los huecos que explotan los atacantes. Y prueba tu logging con regularidad, porque el hueco que no conoces es el que se usará contra ti.