In diesem Blogbeitrag wird erläutert, wie Microsofts Umstellung vom bisherigen Azure Diagnostics Agent auf den Azure Monitor Agent die Steuerung der Protokollierung von VMs grundlegend verändert, und es wird aufgezeigt, wie diese Neugestaltung zu Erkennungslücken führen kann, wenn Sicherheitsteams ihren Überwachungsansatz nicht anpassen.
Infolge dieser Änderung kann eine einzige, kaum wahrnehmbare API-Aktion die Protokollierung über mehrere Systeme hinweg unbemerkt stören, wodurch das Risiko steigt, dass Sicherheitsereignisse übersehen oder falsch zugeordnet werden.
Wir erklären, was sich geändert hat und wie man sich darauf einstellen kann.
Wir haben dieses Verhalten an Microsoft gemeldet, das das Problem bestätigt hat und derzeit Änderungen zur Verbesserung der Transparenz umsetzt, darunter zusätzliche Protokollierung auf VM-Ebene für die Aufhebung von DCR-Zuordnungen. Diese Änderungen werden voraussichtlich bis zum 21. April eingeführt. Wir werden diesen Beitrag aktualisieren, sobald weitere Details vorliegen.
Umstellung von VM-Erweiterungen auf DCR-basierte Protokollierung
Am 31. März 2026 hat Microsoft den veralteten Azure Diagnostics Agent (WAD/LAD) außer Betrieb genommen und durch den Azure Monitor Agent (AMA) ersetzt, wodurch die Protokollierung von VMs von Erweiterungen auf VM-Ebene auf zentralisierte Datenerfassungsregeln (DCRs) und DCR-Zuordnungen umgestellt wurde.
Durch diese Änderung wird die Steuerung der Protokollierung in die Steuerungsebene verlagert, wodurch sich die Darstellung von Änderungen und Störungen in den Azure-Aktivitätsprotokollen grundlegend ändert.
Auswirkungen auf IT und SecOps
Bisher waren Protokollierungsänderungen an die Aktivitäten der VM-Erweiterung gekoppelt. Ein häufiges Signal für Änderungen im Zusammenhang mit der Protokollierung war:
Microsoft.Compute/virtualMachines/extensions/write
Bei AMA wird die Protokollierung über DCRs gesteuert, was bedeutet, dass sie durch Vorgänge auf der Steuerungsebene geändert oder entfernt werden kann, wie zum Beispiel:
Microsoft.Insights/dataCollectionRuleAssociations/writeMicrosoft.Insights/dataCollectionRuleAssociations/deleteMicrosoft.Insights/dataCollectionRules/writeMicrosoft.Insights/dataCollectionRules/delete
In Tests wird die Protokollierung sofort beendet, wenn ein DCR oder dessen Zuordnung entfernt wird. Das erwartete VM-Erweiterungssignal tritt jedoch mit einer Verzögerung von 2 bis 2,5 Stunden auf und wird einer von Microsoft verwalteten Identität zugeordnet, anstatt einem aktionsfähigen Akteur.
Dies birgt zwei Risiken: eine verzögerte Erkennung und den Verlust der Zuordnung, wodurch Annahmen bestehender Erkennungsmechanismen hinfällig werden.
Wie sieht das in der Praxis aus?
Wir haben dieses Verhalten anhand von Azure-VMs getestet, auf denen AMA installiert war, und dabei ein DCR erstellt, das mit mehreren VMs verknüpft war. Dabei wurden wesentliche Unterschiede zwischen dem Verhalten im Portal und dem über die API festgestellt:
- Das Azure-Portal verhindert das Löschen eines DCR mit aktiven Zuordnungen.
- Die API ermöglicht es, einen DCR und alle zugehörigen Verknüpfungen in einem einzigen Aufruf zu löschen (
deleteAssociations=true).
Aus Sicht der Protokollierung:
- Die Protokollierung wird auf allen betroffenen VMs sofort beendet.
- Nur ein einziger
Microsoft.Insights/dataCollectionRules/deleteEs wurde ein Ereignis beobachtet. - Es werden keine einzelnen Löschvorgänge von Assoziationen protokolliert.
Das bedeutet, dass mit einem einzigen API-Aufruf die Protokollierung auf mehreren VMs deaktiviert werden kann, wobei nur minimale Telemetriedaten generiert werden.
Entstandene Erkennungslücken
Diese Verhaltensweisen führen zu Erkennungslücken:
- Portal- und API-Aktionen erzeugen unterschiedliche Telemetriedaten.
- Ein einziger API-Aufruf kann die Protokollierung mit minimaler Sichtbarkeit deaktivieren.
- Signale der VM-Erweiterung sind verzögert und lassen sich nicht eindeutig zuordnen, was sie zu weniger zuverlässigen Indikatoren macht.
Infolgedessen können Erkennungen, die sich ausschließlich auf die Aktivität von Erweiterungen stützen, Störungen der Protokollierung vollständig übersehen oder falsch interpretieren.
Was ist künftig zu beobachten?
Die Verteidiger sollten ihre Deckung zumindest auf folgende Bereiche ausweiten:
Microsoft.Insights/dataCollectionRuleAssociations/delete(Störung der Protokollierung auf Ressourcenebene)Microsoft.Insights/dataCollectionRules/delete(Auswirkungen auf mehrere Ressourcen durch eine einzige Maßnahme)Microsoft.Insights/dataCollectionRules/write(Manipulation der Konfiguration)
Die Notwendigkeit einer widerstandsfähigen Berichterstattung
Diese Entwicklung unterstreicht die Notwendigkeit von Erkennungsmechanismen, die trotz Veränderungen in der Bedrohungslandschaft und der Angriffsfläche weiterhin wirksam bleiben.
Bei Vectra AI haben wir die Erfassungsreichweite angepasst, um DCR- und DCR-Assoziationsereignisse gegenüber VM-Erweiterungsaktivitäten zu priorisieren, noch bevor diese Änderung in Kraft trat. Damit haben wir die Transparenz bei Protokollierungsstörungen und die umsetzbare Zuordnung damit verbundener Aktivitäten zur Umgehung von Abwehrmaßnahmen sichergestellt.
Durch die kontinuierliche Überwachung sowohl des Verhaltens von Angreifern als auch von Änderungen an den Plattformen passen wir unseren Schutz proaktiv an und stellen so sicher, dass unsere Kunden stets über einen aktuellen, robusten und zuverlässigen Schutz verfügen – selbst wenn sich die zugrunde liegenden Telemetrie- und Kontrollmechanismen ändern.
Kommunikation und Nachverfolgung durch Microsoft
Microsoft hat diese Änderung in einer Service-Health-Mitteilung bekannt gegeben, die sich auf die Einstellung des Azure Diagnostics Agent und die Migration zu AMA bis zum 31. März 2026 bezieht.
Microsoft hat diese Änderung im Rahmen der AMA-Migration im Vorfeld der Auslauffrist am 31. März 2026 in einer Service Health-Mitteilung angekündigt. Wir haben bei Microsoft ein Ticket bezüglich des beobachteten Verhaltens und der bei Tests festgestellten Sicherheitsauswirkungen eröffnet. Dieses wurde von Microsoft angenommen und wird derzeit untersucht; Updates werden für den 21. April erwartet. Wir werden diesen Beitrag aktualisieren, sobald sich die Leitlinien weiterentwickeln.
Fazit
Es handelt sich hierbei nicht nur um eine Agent-Migration. Es ändert sich, wo die Protokollierung gesteuert wird und wie Störungen auftreten. Teams, die sich bei der Erkennung von Manipulationen auf Azure Activity Logs verlassen, sollten ihre Erfassungsreichweite umgehend anpassen, um sicherzustellen, dass Verhaltensweisen zur Umgehung von Sicherheitsmaßnahmen nicht übersehen werden.