Cet article explique comment le passage de Microsoft de l'ancien Azure Diagnostics Agent à l'Azure Monitor Agent modifie en profondeur la manière dont la journalisation des machines virtuelles est gérée, et souligne comment cette refonte peut créer des angles morts en matière de détection si les équipes de sécurité ne mettent pas à jour leur approche de surveillance.
À la suite de ce changement, une seule opération API, même peu visible, peut perturber discrètement la journalisation sur plusieurs systèmes, augmentant ainsi le risque que des événements de sécurité soient ignorés ou mal attribués.
Nous vous expliquons ce qui a changé et comment vous adapter.
Nous avons signalé ce problème à Microsoft, qui l'a reconnu et est en train de mettre en œuvre des modifications visant à améliorer la visibilité, notamment l'ajout de journaux au niveau des machines virtuelles pour la suppression des associations DCR. Ces modifications devraient être déployées d'ici le 21 avril. Nous mettrons à jour cet article dès que nous disposerons de plus amples informations.
Passage des extensions VM à la journalisation basée sur DCR
Le 31 mars 2026, Microsoft a retiré l'ancien agent Azure Diagnostics (WAD/LAD) et l'a remplacé par l'agent Azure Monitor (AMA), faisant ainsi passer la journalisation des machines virtuelles des extensions au niveau des machines virtuelles à des règles de collecte de données (DCR) centralisées et à des associations de DCR.
Cette modification transfère la gestion de la journalisation vers le plan de contrôle, ce qui modifie en profondeur la manière dont les modifications et les incidents liés à la journalisation apparaissent dans les journaux d'activité Azure.
Conséquences sur l'informatique et les opérations de sécurité
Auparavant, les modifications apportées à la journalisation étaient liées à l'activité des extensions de VM. Un signal courant indiquant des modifications liées à la journalisation était :
Microsoft.Compute/virtualMachines/extensions/write
Avec AMA, la journalisation est gérée par les DCR, ce qui signifie qu'elle peut être modifiée ou supprimée via des opérations du plan de contrôle telles que :
Microsoft.Insights/dataCollectionRuleAssociations/writeMicrosoft.Insights/dataCollectionRuleAssociations/supprimerMicrosoft.Insights/règlesDeCollecteDeDonnées/écritureMicrosoft.Insights/règlesDeCollecteDeDonnées/supprimer
Lors des tests, la suppression d'un DCR ou de son association met immédiatement fin à la journalisation. Cependant, le signal d'extension de la machine virtuelle attendu est retardé de 2 à 2,5 heures et attribué à une identité gérée par Microsoft plutôt qu'à un acteur pouvant faire l'objet de mesures.
Cela entraîne deux risques: un retard dans la détection et une perte d'attribution, ce qui remet en cause les hypothèses sur lesquelles reposent les systèmes de détection existants.
Comment cela se passe-t-il dans la pratique ?
Nous avons testé ce comportement à l'aide de machines virtuelles Azure sur lesquelles AMA était installé, en créant un DCR associé à plusieurs machines virtuelles. Des différences notables ont été observées entre le comportement du portail et celui de l'API :
- Le portail Azure empêche la suppression d'un DCR comportant des associations actives.
- L'API permet de supprimer un DCR et toutes ses associations en un seul appel (
supprimerLesAssociations=true).
Du point de vue de la sylviculture :
- La journalisation s'arrête immédiatement sur toutes les machines virtuelles concernées.
- Un seul
Microsoft.Insights/règlesDeCollecteDeDonnées/supprimeron a constaté un événement. - Aucun événement de suppression d'association individuelle n'est consigné.
Cela signifie qu'un seul appel d'API permet de désactiver la journalisation sur plusieurs machines virtuelles tout en générant un volume minimal de données de télémétrie.
Lacunes dans la détection
Ces comportements entraînent des lacunes dans la détection :
- Les actions du portail et de l'API génèrent des données de télémétrie différentes.
- Un simple appel API permet de désactiver la journalisation avec un minimum d'impact.
- Les signaux d'extension VM sont retardés et ne peuvent être attribués, ce qui en fait des indicateurs moins fiables.
Par conséquent, les détections qui s'appuient uniquement sur l'activité des extensions risquent de passer complètement à côté d'une perturbation de la journalisation ou de l'interpréter de manière erronée.
Les éléments à surveiller à l'avenir
Au minimum, les responsables de la sécurité devraient étendre leur couverture aux domaines suivants :
Microsoft.Insights/dataCollectionRuleAssociations/supprimer(perturbation de la journalisation au niveau des ressources)Microsoft.Insights/règlesDeCollecteDeDonnées/supprimer(impact sur plusieurs ressources à la suite d'une seule action)Microsoft.Insights/règlesDeCollecteDeDonnées/écriture(altération de la configuration)
La nécessité d'une couverture résiliente
Cette évolution souligne la nécessité de disposer de systèmes de détection qui restent efficaces malgré les changements intervenus dans le paysage des menaces et la surface d'attaque.
Chez Vectra AI, nous avons mis à jour la couverture de détection afin de donner la priorité aux événements liés au DCR et à ses associations par rapport à l'activité d'extension des machines virtuelles avant que cette modification n'entre en vigueur, garantissant ainsi une visibilité sur les perturbations de la journalisation et une attribution exploitable des activités de contournement des défenses associées.
En surveillant en permanence tant les comportements des pirates que plateforme , nous adaptons notre protection de manière proactive afin de garantir à nos clients une protection à jour, solide et fiable, même lorsque les mécanismes de télémétrie et de contrôle sous-jacents évoluent.
Communication et suivi de Microsoft
Microsoft a annoncé ce changement dans un avis sur l'état du service concernant l'abandon de l'agent Azure Diagnostics et la migration vers AMA avant le 31 mars 2026.
Microsoft a annoncé ce changement dans un avis sur l'état du service, dans le cadre de la migration vers AMA avant la date limite de retrait fixée au 31 mars 2026. Nous avons ouvert un ticket auprès de Microsoft concernant le comportement observé et les implications en matière de sécurité constatées lors des tests. Ce ticket a été accepté par Microsoft et fait actuellement l'objet d'une enquête ; des mises à jour sont attendues le 21 avril. Nous mettrons à jour cet article à mesure que les recommandations évolueront.
En résumé
Il ne s'agit pas simplement d'une migration d'agents. Cela modifie le lieu où la journalisation est gérée et la manière dont les incidents se produisent. Les équipes qui s'appuient sur Azure Activity Logs pour détecter les tentatives de manipulation doivent mettre à jour leur couverture sans délai afin de s'assurer qu'aucun comportement visant à contourner les mesures de défense ne passe inaperçu.