En este blog se explica cómo el cambio de Microsoft del antiguo Azure Diagnostics Agent al Azure Monitor Agent modifica radicalmente la forma en que se controla el registro de máquinas virtuales, y se destaca cómo este rediseño puede generar puntos ciegos en la detección si los equipos de seguridad no actualizan su enfoque de supervisión.
A raíz de este cambio, una sola acción de la API, que pasa desapercibida, puede alterar silenciosamente el registro de eventos en varios sistemas, lo que aumenta el riesgo de que se pasen por alto o se atribuyan erróneamente los incidentes de seguridad.
Te explicamos qué ha cambiado y cómo adaptarte.
Hemos informado de este comportamiento a Microsoft, que lo ha reconocido y está implementando cambios para mejorar la visibilidad, incluyendo registros adicionales a nivel de máquina virtual para la eliminación de asociaciones DCR. Se espera que estos cambios se implementen antes del 21 de abril. Actualizaremos esta publicación a medida que dispongamos de más detalles.
Pasar de las extensiones de máquina virtual al registro basado en DCR
El 31 de marzo de 2026, Microsoft retiró el antiguo agente de diagnóstico de Azure (WAD/LAD) y lo sustituyó por el agente de Azure Monitor (AMA), pasando el registro de máquinas virtuales de las extensiones a nivel de máquina virtual a reglas de recopilación de datos (DCR) centralizadas y asociaciones de DCR.
Este cambio traslada el control del registro de eventos al plano de control, lo que modifica de forma sustancial la forma en que se muestran los cambios y las interrupciones en los registros de actividad de Azure.
Repercusiones en las TI y las operaciones de seguridad
Anteriormente, los cambios en el registro estaban vinculados a la actividad de las extensiones de VM. Una señal habitual de los cambios relacionados con el registro era:
Microsoft.Compute/máquinas-virtuales/extensiones/escribir
En AMA, el registro se controla mediante los DCR, lo que significa que se puede modificar o eliminar mediante operaciones del plano de control, tales como:
Microsoft.Insights/dataCollectionRuleAssociations/writeMicrosoft.Insights/dataCollectionRuleAssociations/deleteMicrosoft.Insights/reglasDeRecopilaciónDeDatos/escrituraMicrosoft.Insights/reglasDeRecopilaciónDeDatos/eliminar
En las pruebas, al eliminar un DCR o su asociación, el registro se detiene de inmediato. Sin embargo, la señal de extensión de la máquina virtual esperada se retrasa entre 2 y 2,5 horas y se atribuye a una identidad gestionada por Microsoft, en lugar de a un actor sobre el que se pueden tomar medidas.
Esto plantea dos riesgos: la detección tardía y la pérdida de atribución, lo que invalida las hipótesis en las detecciones existentes.
¿Qué ocurre en la práctica?
Probamos este comportamiento utilizando máquinas virtuales de Azure con AMA instalado y creando un DCR asociado a varias máquinas virtuales. Se observaron diferencias clave entre el comportamiento del portal y el de la API:
- El Portal de Azure impide eliminar un DCR que tenga asociaciones activas.
- La API permite eliminar un DCR y todas sus asociaciones en una sola llamada (
deleteAssociations=true).
Desde el punto de vista de la tala:
- El registro se detiene inmediatamente en todas las máquinas virtuales afectadas.
- Solo uno
Microsoft.Insights/reglasDeRecopilaciónDeDatos/eliminarse observó el fenómeno. - No se registran eventos de eliminación de asociaciones individuales.
Esto significa que con una sola llamada a la API se puede desactivar el registro en varias máquinas virtuales, generando al mismo tiempo una cantidad mínima de datos de telemetría.
Lagunas en la detección
Estos comportamientos dan lugar a lagunas en la detección:
- Las acciones del portal y de la API generan datos de telemetría diferentes.
- Con una sola llamada a la API se puede desactivar el registro de eventos con una visibilidad mínima.
- Las señales de la extensión VM sufren retrasos y no es posible determinar su origen, lo que las convierte en indicadores menos fiables.
Por lo tanto, las detecciones que se basan únicamente en la actividad de las extensiones pueden pasar por alto por completo o malinterpretar una interrupción en el registro.
Qué hay que vigilar de aquí en adelante
Como mínimo, los defensores deberían ampliar la cobertura para:
Microsoft.Insights/dataCollectionRuleAssociations/delete(interrupción del registro a nivel de recursos)Microsoft.Insights/reglasDeRecopilaciónDeDatos/eliminar(impacto en múltiples recursos a través de una sola acción)Microsoft.Insights/reglasDeRecopilaciónDeDatos/escritura(manipulación de la configuración)
La necesidad de una cobertura resiliente
Este cambio pone de relieve la necesidad de contar con sistemas de detección que sigan siendo eficaces a pesar de los cambios en el panorama de amenazas y en la superficie de ataque.
En Vectra AI, actualizamos la cobertura de detección para dar prioridad a los eventos de DCR y de asociación de DCR frente a la actividad de extensión de máquinas virtuales antes de que este cambio entrara en vigor, garantizando así la visibilidad de las interrupciones en el registro y una atribución útil de las actividades relacionadas con la evasión de las defensas.
Al supervisar continuamente tanto el comportamiento de los atacantes como los cambios en las plataformas que estos utilizan, adaptamos de forma proactiva nuestra cobertura para garantizar que los clientes dispongan de una protección actualizada, sólida y fiable, incluso cuando cambian los mecanismos de telemetría y control subyacentes.
Comunicación y seguimiento de Microsoft
Microsoft comunicó este cambio a través de un aviso sobre el estado del servicio relacionado con la retirada del agente de diagnóstico de Azure y la migración a AMA antes del 31 de marzo de 2026.
Microsoft anunció este cambio a través de un aviso sobre el estado del servicio, como parte de la migración a AMA antes de la fecha límite de retirada del 31 de marzo de 2026. Hemos abierto un ticket con Microsoft en relación con el comportamiento observado y las implicaciones de seguridad detectadas durante las pruebas. Microsoft lo ha aceptado y lo está investigando; se esperan novedades para el 21 de abril. Actualizaremos esta publicación a medida que haya novedades.
En resumen
No se trata simplemente de una migración de agentes. Cambia dónde se controla el registro y cómo se producen las interrupciones. Los equipos que utilizan los registros de actividad de Azure para detectar manipulaciones deben actualizar la cobertura sin demora para asegurarse de que no se pasan por alto los comportamientos destinados a eludir las defensas.