Los registros de actividad completos y puntuales son herramientas poderosas que permiten la supervisión de la seguridad y la respuesta a incidentes en la cloud. Sin embargo, al estudiar los registros de Azure, nuestros investigadores observaron muchas deficiencias que complican la comprensión de las acciones de los usuarios e incluso pueden dejar escapar a un atacante. En este post, discutiremos estos problemas y su impacto en el trabajo del equipo azul.
Por qué estudiamos Azure Monitor Logs
Antes de hablar de los detalles específicos de cada proveedor, debemos señalar que los registros tienen un significado diferente en los entornos cloud y en los locales.
Los administradores tienen algunas opciones en las instalaciones locales: Pueden intervenir en el tráfico de red para supervisar la actividad o recopilar registros en el borde de la red y en máquinas individuales. Las soluciones de registro y supervisión (hardware y software) son sustituibles, y si un producto de un proveedor concreto no funciona bien, puede instalarse otro.
En la cloud, no tienes esas opciones: el proveedor controla totalmente los registros disponibles. Si son de alta calidad, ¡genial! Pero si hay problemas, estás a merced de la voluntad del proveedor para solucionarlos. Puedes planteárselos al proveedor y esperar que los solucione o intentar evitarlos, en la medida de lo posible.
Al supervisar la actividad en el entorno de cloud , hay varias expectativas:
- Ningún cambio imprevisto en la estructura o el contenido del registro
- Registro puntual de los acontecimientos
- Registros completos y precisos (sin valores que falten o estén rotos)
- Documentación completa de los eventos registrados
- Una forma sencilla de correlacionar eventos y sesiones de usuario entre distintos registros
- Un conjunto de indicadores de amenazas para utilizar en el análisis de incidentes
Al analizar la actividad, los siguientes datos deben estar disponibles de forma consistente en todas las fuentes de registro y para todos los tipos de eventos:
- Nombres y detalles de las operaciones
- Identidad del usuario e información de la sesión
- IPs
- Geolocalización
- Información sobre el dispositivo
- Indicadores de amenaza y reputación
Esencialmente, usted quiere ser capaz de decir quién hizo qué y cuándo (y qué más hicieron). Por desgracia, estas expectativas no siempre se cumplen en los registros de Azure.
Cómo supervisamos los eventos en Azure
Azure cuenta con un conjunto maduro de productos de análisis y supervisión de eventos:
Microsoft Sentinel es un producto SIEM nativo que ingiere registros de varias fuentes. Cuenta con un conjunto de detecciones integradas y nos permite definir otras personalizadas.
Azure Log Analytics es una plataforma de análisis de registros ideal para investigaciones ad hoc de eventos sospechosos.
Ambos son compatibles con Kusto, un potente lenguaje de consulta y análisis de registros. Además, puedes utilizar soluciones de terceros para supervisar e interpretar los registros.
La infraestructura de registro de Azure es enorme y tiene docenas, si no cientos, de fuentes de registro. Sería imposible hablar de todas ellas, así que vamos a centrarnos en los registros generados por Azure AD (ahora Entra ID), la solución IAM de Azure, y Microsoft 365, un paquete de oficina SaaS cloud .
Cubierta de registros Entra ID:
- Inicios de sesión - varios registros que cubren la actividad de inicio de sesión de usuarios interactivos y no interactivos, principales de servicio e identidades gestionadas.
- Auditorías: un registro de las operaciones significativas del directorio
- Aprovisionamiento: datos sobre el aprovisionamiento de usuarios por servicios de terceros.
Estos registros son accesibles a través de Graph API y actualmente existen una versión base (1.0) y una Beta, que tienen esquemas diferentes.
Los registros de actividad de Microsoft 365 se consumen a través de la API de actividad de administración, que proporciona varios registros para distintos tipos de eventos:
- Audit.AzureActiveDirectory - eventos del servicio Entra ID (similar a lo que está disponible a través de Graph API), como asignaciones y cambios de directorio
- Auditoría.Exchange - Eventos Exchange
- Auditoría.SharePoint - Actividad de SharePoint
- Auditoría.General - la mayoría de las acciones que no encajan en ninguno de los otros registros.
- DLP.All - Eventos de Prevención de Pérdida de Datos
Problemas conocidos de Azure Monitor Log
Ahora que hemos explorado la importancia de Azure Log Monitoring, vamos a profundizar en algunos problemas que hemos encontrado en estos registros. Conocerlos puede ayudarte a construir mejores consultas de análisis y perder menos tiempo preguntándote por qué las cosas se comportan como lo hacen.
Entre los retos específicos que deberían estar en el radar de todo analista y arquitecto de seguridad se incluyen:
- Esquema de fluidos
- Flujo de registros
- Retrasos en los eventos
- Eventos pendientes
- Impuesto de matriculación
- Eventos que nunca se registran
- Documentación deficiente
- Cambios sin previo aviso
- Incoherencias de identificación
- Incoherencias IP
- Incoherencias de geolocalización
- Incoherencias en la información sobre dispositivos
- Valores rotos
Veamos cada una de ellas con más detalle.
Esquema de fluidos
El esquema de algunos registros (por ejemplo, el de la API de gestión de actividades) es "fluido". Esto significa que un parámetro único en una nueva operación se añadirá al registro como una nueva columna.
Esto dificulta su gestión, incluso para Log Analytics. (Hemos observado que muestra errores sobre un "límite máximo de 500 columnas alcanzado"). Si buscas consumir eventos en un SIEM externo, puede que tengas que ser selectivo sobre qué columnas consumir, y es imposible predecir las nuevas que Azure añade.
Un método mejor habría sido un esquema estático en todos los registros, con campos de estructura (por ejemplo, en JSON) añadidos para manejar la variabilidad.
Flujo de registros
Ocasionalmente se producen cortes de registro en Azure. De hecho, hemos visto varios en los últimos años. Aunque una de ellas duró varias semanas y se descubrió accidentalmente, Microsoft suele avisar bien a los clientes en estas situaciones.
El problema es que, durante una interrupción del servicio, es posible que no veas ninguna actividad en el entorno. Si además te pierdes el anuncio de la interrupción, nada te indicará que hay un problema. Es esencial estar al tanto de la salud del servicio en Azure y posiblemente invertir en alguna solución de monitorización que rastree el flujo de registros.
Las interrupciones también pueden ser deliberadas. La configuración del registro se controla dentro de la banda, y un compromiso de la cuenta de un administrador puede llevar al atacante a desactivar el registro a gran escala (por ejemplo, a través de Set-AdminAuditLogConfig) o de una manera más detallada y sigilosa (por ejemplo, a través de Set-Mailbox -AuditEnabled).
Supervisar el flujo de registros y los cambios de configuración es esencial para mitigar estos problemas. Sólo unos pocos usuarios autorizados deben poder cambiar la configuración de los registros. Sería preferible que Azure añadiera más controles a la configuración de los registros debido a las importantes consecuencias adversas derivadas de la desactivación accidental o deliberada de los registros.
Retrasos en los eventos
Microsoft publica los tiempos previstos para la disponibilidad de sus eventos de registro. Se afirma que el tiempo de ingestión de Graph API es inferior a 3 minutos. En nuestra experiencia, los eventos de esas fuentes pueden tardar hasta 30 minutos en aparecer.
La disponibilidad típica anunciada para los eventos de Management ActivityAPI oscila entre 60 y 90 minutos. En realidad, los retrasos que hemos observado son más significativos. A continuación se muestran algunas cifras máximas que hemos capturado recientemente: algunas veces superan con creces las 24 horas (la columna max_delay contiene el tiempo máximo observado entre la creación del evento y su disponibilidad en el registro):
Este tipo de retrasos son insostenibles. Algunos atacantes se mueven con extrema rapidez. Si tenemos en cuenta el tiempo necesario para el procesamiento por parte de las herramientas de detección, la ingestión por parte del SIEM externo y la reacción del personal del SOC, queda claro que, en muchos casos, el equipo azul llegará tarde, casi por diseño.
Cuanto más automaticen los atacantes sus herramientas, peor será la situación. Azure debe dar prioridad a la rápida disponibilidad de los registros. De lo contrario, los defensores sólo podrán reaccionar ante los incidentes, no detenerlos. Los retrasos en los eventos son aún más difíciles de tratar cuando los registros se reenvían a un SIEM externo. Las llamadas a la API de registro toman intervalos de tiempo como parámetros, por lo que tendría que aceptar la pérdida de registros o consultar intervalos de tiempo solapados y eliminar registros duplicados para no perderse eventos tardíos.
Eventos pendientes
Algunos tipos de eventos pueden encontrarse en más de un registro. Por ejemplo, los registros de inicio de sesión están disponibles tanto en Graph API como en Management Activity API. Compare los registros del mismo evento en ambas fuentes, y se revelarán diferencias ocasionales.
Consideremos los siguientes ejemplos extraídos de una reciente investigación de incidentes. Aunque todos corresponden a las mismas acciones por parte de un atacante, los registros no coinciden exactamente:
Graph API (beta -en Azure Portal):
API de gráficos (v1.0):
AuditAzureActiveDirectoryen la API de actividad de gestión:
Este tipo de incoherencia es difícil de reproducir y explicar, pero hay que tenerla en cuenta a la hora de analizar los registros. Los registros pueden perderse, y puede ser necesario el análisis de múltiples registros para construir una imagen más completa de lo ocurrido.
Impuesto de matriculación
Muchos tipos de eventos de registro y detalles sólo están disponibles con los niveles de pago más altos (por ejemplo, E5 y P2). Algunos ejemplos son los eventos MailItemsAccessed, los detalles de riesgo en el registro de inicios de sesión y otros. Esto supone un dilema para muchos clientes, ya que les obliga a elegir entre reducir costes o mejorar la visibilidad de las actividades de su entorno.
No es una buena elección a la que obligar y, en nuestra opinión, las funciones básicas de seguridad (como los registros) deberían estar disponibles para todos los clientes cloud . Como dijo recientemente el senador estadounidense Ron Wyden:"Cobrar a la gente por funciones premium necesarias para no ser hackeado es como vender un coche y luego cobrar un extra por los cinturones de seguridad y los airbags."
Esta falta de visibilidad ha causado dificultades en muchos incidentes de clientes Vectra AI AI que hemos tenido que investigar. Una reciente violación pública por parte de APT Storm-0558, a la que tuvo que hacer frente la propia Microsoft, ha sacado a la luz este problema. Como resultado de ese incidente, Microsoft acordó con CISA ampliar el acceso al registro a todos los clientes este otoño.
Esperemos que las cosas mejoren pronto. Mientras tanto, debe asegurarse de que el registro al que tiene acceso a través de su licencia es adecuado para las necesidades de IR de su organización. Si no es así, es hora de actualizarla. Cuando los datos esenciales no están disponibles, algunos de ellos (por ejemplo, la reputación IP y la información de geolocalización) podrían adquirirse de fuentes de terceros.
Algunos eventos que nunca se registran
Azure es un "paraíso del reconocimiento", con eventos de tipo "get" que corresponden a la lectura de configuración y datos que, salvo raras excepciones, no se registran. A partir de octubre de 2023, se introdujo un nuevo registro que registra las llamadas a la API Graph y sí cubre algunas de las operaciones de reconocimiento. Sin embargo, la enumeración a través de otras API sigue siendo invisible para los defensores.
Esto significa que cuando un atacante consigue acceder al entorno de cloud , puede enumerar la mayor parte de la información -usuarios, servicios, configuración- sin ser visto por los defensores. En nuestras pruebas, la mayoría de las herramientas de enumeración M365/AAD de código abierto no dejaron ningún rastro en los registros.
No está claro por qué se tomó la decisión de no registrar estos eventos, aunque puede ser para ahorrar espacio. Desafortunadamente, no existe ninguna opción para habilitar este registro, incluso si el cliente quiere ver este tipo de eventos. Lo que significa que estarás a oscuras hasta que los atacantes empiecen a hacer cambios en tu entorno.
Documentación deficiente
Mientras que las API de Azure están razonablemente bien documentadas, falta documentación sobre los eventos de registro. Para muchos eventos, lo único documentado es el nombre de la operación, pero los campos individuales y su significado son a menudo un misterio. Tienes que buscar en blogs y foros de discusión para tratar de interpretar lo que está sucediendo.
Además de que el propósito de un campo no está claro, los valores de los datos individuales a veces tampoco están bien documentados. Hemos visto tipos de autenticación específicos, códigos de estado, subtipos de operación y otros datos sin descripción. Incluso un esfuerzo de investigación exhaustivo no aportó claridad para algunos de esos valores.
Como no entendemos algunos campos y valores, no podemos supervisarlos e interpretarlos durante la investigación y respuesta a incidentes.
Cambios sin previo aviso
A medida que la funcionalidad de cloud evoluciona (como ocurre con frecuencia), aparecen nuevos tipos de eventos sin previo aviso en los registros. Por ejemplo, se ha añadido un nuevo código de error para los fallos de inicio de sesión sin contraseña que hemos documentado recientemente. El equipo de investigación de seguridad de Vectra AI tuvo que dedicar tiempo a investigarlo antes de que pudiéramos entender qué lo provocaba y, hasta entonces, nuestras consultas de supervisión no lo detectaron.
Lo más preocupante es que los eventos existentes también pueden desaparecer o cambiar de formato. Algunos ejemplos recientes son:
- Evento MailboxLogin que estábamos rastreando y que desapareció silenciosamente de los registros de Exchange.
- Errores de inicio de sesión por nombres de usuario inexistentes que rastreábamos para detectar las primeras fases de la actividad de reconocimiento y que ya no se escribían en los registros de inicio de sesión.
Cuando tienes consultas de monitorización y análisis que buscan eventos específicos, estos cambios harán que dejen de funcionar sin previo aviso. Este es el peor tipo de fallo: cuando ni siquiera se sabe que hay un problema. Es posible que tenga que invertir en lógica para supervisar la integridad de los registros y vigilar de cerca los cambios en el contenido y la documentación de los registros. Por desgracia, la mayoría de los defensores están demasiado ocupados para dedicar tiempo a eso.
Incoherencias de identificación
Los identificadores de usuario no siempre son "estables". Dependiendo del contexto y del tipo de operación, el mismo usuario puede aparecer en los registros bajo diferentes "nombres principales de usuario" (UPN). Por ejemplo, su usuario podría estar registrado como:
- john.smith@company.com
- John.Smith@company.com (observe la diferencia entre mayúsculas y minúsculas)
- AN045789@company.com
M365 Exchange echa un órdago al añadir nombres heredados como los siguientes (además de otros):
"NAMPR07A006.PROD.OUTLOOK.COM/Microsoft ExchangeHosted Organizations/ company.onmicrosoft.com/0cf179f8-0fa4-478f-a4cc-b2ea0b18155e" en nombre de "NAMPR07A006.PROD.OUTLOOK.COM/Microsoft ExchangeHosted Organizations/ company.onmicrosoft.com/JohnSmith".
En los casos de variabilidad de nombres, relacionar diferentes eventos con el mismo usuario se hace difícil. Aunque correlacionar los eventos por el UPN puede ser el primer impulso, hacerlo por el ID interno único puede ser una estrategia más sólida (pero aún no infalible).
Las dificultades continúan:
- Diferentes nombres en diferentes registros pueden tener nombres de campo superpuestos con diferentes significados. Por ejemplo, user_id significará un GUID de usuario en un registro y un UPN en otro.
- Los ID de usuario pueden tener valores que representen nombres y apellidos de usuario, nombres de aplicación, GUID de aplicación y otros nombres e ID únicos inusuales.
- Los ID de usuario pueden estar vacíos o contener nombres inútiles como "No disponible", "Desconocido", "Sin UPN":
Como defensor, tienes que estar preparado para ver esta información (poco útil) en los campos de identidad del usuario y construir la funcionalidad de consulta en consecuencia.
Incoherencias IP
Una dirección IP válida es una expectativa básica para cada registro de log. Aunque las direcciones IPv4 e IPv6 válidas están disponibles en las entradas de registro la mayoría de las veces, a veces vemos IPs que son difíciles de entender y utilizar en el análisis:
- IPs con números de puerto (tanto v4 como v6)
- IP vacías
- IPs locales y privadas:127.0.0.1, 192.168.*, 10.*
- Todas las IPs a cero: 0.0.0.0
- Máscaras IP en lugar de IPs:255.255.255.255
- IPs que corresponden a la infraestructura de Azure, no al usuario que realiza la operación
Las IP no pueden correlacionarse con los registros de entrada de algunas de las operaciones, lo que complica el análisis de incidentes. Los indicadores de riesgo y reputación de IP pueden estar disponibles ocasionalmente, pero están sujetos al "impuesto de registro".
Como defensor, debes esperar estos casos especiales cuando escribas consultas de caza y alertas y acomodarlos en tu lógica.
Incoherencias de geolocalización
Actualmente, Microsoft sólo proporciona geolocalización para los registros de inicio de sesión. Esto habría sido útil para otras fuentes de registro, ya que no siempre se puede conectar la actividad a registros de inicio de sesión específicos.
Esta función no es perfecta. En ocasiones, hay problemas:
- La misma IP resuelve múltiples ubicaciones (muy probablemente relacionadas con dispositivos móviles).
- Los registros se geolocalizan incorrectamente de forma masiva.
- Falta información geográfica:
La geolocalización también se engaña fácilmente con TOR, VPN, proxies e IP de proveedores cloud , y debe tomarse con cautela.
Incoherencias en la información sobre dispositivos
Los detalles del dispositivo son complejos de determinar para Microsoft (a menos que se trate de un dispositivo registrado). La información sobre la plataforma y el navegador se obtiene normalmente del agente de usuario (UA).
Por desgracia, aquí también hay incoherencias:
- Algunos registros analizan la UA y la proporcionan por partes, mientras que otros proporcionan la cadena de UA completa (que usted tiene que interpretar)
- La información sobre el dispositivo no está disponible en todos los registros
- Los valores analizados no siempre son coherentes (por ejemplo, "Windows" frente a "Windows 10").
Los atacantes pueden falsificar fácilmente el Agente de Usuario, pero sigue siendo valioso para las investigaciones, ya que no todos son lo suficientemente disciplinados como para cambiarlo discretamente.
Valores rotos
Algunos campos de registro tienen estructuras complejas (por ejemplo, JSON), y las consultas de caza y supervisión necesitan analizarlos para hacer referencia a subcampos específicos.
Ocasionalmente, estos valores se cortan debido a límites de tamaño, resultando en estructuras rotas. Por ejemplo, considere el siguiente valor registrado para la operación Set-ConditionalAccessPolicy. Una parte se corta y se sustituye por tres puntos ("..."), lo que confundirá al analizador JSON:
Las consultas de control que se encuentren con estos registros fallarán, lo que provocará puntos ciegos.
En estos casos, confiar en que los valores se analicen correctamente puede no ser la mejor estrategia, y las búsquedas por subcadenas pueden funcionar mejor.
¿Qué hace falta para mejorar la calidad de los troncos?
No somos los únicos que criticamos la calidad de los registros de Azure ( CrowdStrike y EricWoodruff ya plantearon problemas similares), y sólo podemos especular sobre el motivo de que existan tantos.
En el desarrollo de software, los registros suelen quedar relegados a un segundo plano frente a otras funciones. Cuando el equipo de desarrollo tiene que lanzar la funcionalidad principal del producto, puede sacrificar las funciones de servicio secundario.
En ecosistemas de productos enormes como Azure, se reúnen múltiples productos independientes (y, a veces, heredados). Hacer que todos ellos proporcionen una buena señal en una arquitectura de registro común puede ser difícil y esta funcionalidad no está exactamente "orientada al cliente", por lo que las quejas al respecto pueden quedar desatendidas.
Sea cual sea la razón, la ausencia de alternativas en un entorno cloud hace que los problemas de registro sean mucho más graves de lo que habrían sido en una configuración tradicional en las instalaciones. Aparte de ser conscientes de las deficiencias de los registros e intentar solucionar algunas de ellas, los defensores no tienen otras opciones. Microsoft es el propietario de esta funcionalidad, y depende de ellos mejorarla.
Creemos que el equipo de Azure puede (y debe) realizar una serie de cambios no intrusivos:
- Todos los eventos, campos y valores enum deben estar completamente documentados para eliminar las conjeturas del análisis de registros.
- La estructura y el contenido de los registros deben tratarse como una API: cualquier cambio que pueda romper la funcionalidad de consulta de los registros debe introducirse de forma controlada, y hay que dar tiempo a los clientes para que se adapten a los cambios.
- Todas las altas y (sobre todo) bajas de operaciones registradas deben anunciarse claramente.
- Los registros deben entregarse con mucha más puntualidad que hoy -en segundos en lugar de minutos u horas- y los eventos no deben retrasarse ni llegar fuera de plazo.
- Todos los valores registrados deben ser útiles, correctos y no ambiguos.
- Los registros deben contener información rica que sea útil para la respuesta a incidentes (por ejemplo, reputación IP).
Idealmente, la refactorización de la arquitectura de registro para que sea más ágil (similar a lo que está disponible en AWS y Okta) sería beneficioso.
Conclusiones para el equipo rojo
Hasta ahora sólo hemos hablado de las dificultades que estos problemas plantean a su equipo. Pero es importante recordar que cualquier pérdida del defensor es ganancia del atacante. Los black hats, APTs y red-teamers competentes pueden aprovecharse de las peculiaridades del registro de Azure para ocultar sus acciones y complicar los esfuerzos del equipo azul.
Estas son algunas de las técnicas que podrían emplear los atacantes:
- Recurrir a operaciones inusuales menos documentadas o comprendidas
- Ejecutar acciones que inyectan valores rotos o no documentados en los registros para complicar el análisis.
- Conectarse desde ubicaciones cuya información de IP o geolocalización se registra incorrectamente.
- Cronometrar las operaciones para aprovechar los retrasos en la ingesta o complicar el descubrimiento de eventos relacionados.
Por supuesto, se necesitaría más investigación para convertir cualquier deficiencia de registro en una técnica de evasión robusta.
Su trabajo como defensor es duro. Tratar de detectar y remediar los ataques rápidamente es una gran tarea, y se vuelve aún más laborioso cuando tienes que registrar mentalmente los problemas y trabajar en torno a ellos.
La promesa de una mayor seguridad en cloud no es una quimera, y una de las formas de ayudar a conseguirla es ofrecer un registro de alta calidad. Aunque los proveedores tienen el poder de hacer que esto suceda, pueden carecer de incentivos para convertirlo en un objetivo prioritario. Ahí es donde entramos nosotros. Cuanto más exponga la comunidad de investigadores de seguridad y más presión ejerzamos, más cerca estaremos de mejorar la calidad de los registros.
¿Quieres unirte a la conversación? Habla directamente con el equipo de investigación de seguridad de Vectra AI sobre esta entrada del blog y otros temas en Reddit.