Defense Evasion in Azure: gelöschte Logs, Defender aus

Kurz gesagt. Angreifer löschen in Azure nicht das Activity Log – sie können es nicht; Azure erlaubt niemandem, Einträge zu ändern oder zu löschen. Stattdessen kappen sie die Leitungen: microsoft.insights/diagnosticSettings/delete auf einem Key Vault oder Speicherkonto (Ressourcenlogs stoppen), dieselbe Operation auf Abonnementebene (der Activity-Log-Export stoppt), Microsoft.Security/pricings/write mit pricingTier: Free (ein Defender-Plan wird abgeschaltet), Microsoft.Authorization/locks/delete sowie geöffnete NSG- oder Speicher-Firewall-Regeln. Jede dieser Aktionen wird selbst im Activity Log erfasst, das Azure 90 Tage aufbewahrt. Die entstehende Lücke beginnt mit dem Zeitstempel der Löschung.

Das aufschlussreichste Ereignis vieler Azure-Einbrüche ist nicht der Diebstahl, sondern das Aufräumen. Eine Diagnoseeinstellung, die an einem Sonntag um 02:55 von demselben Dienstprinzipal gelöscht wird, der um 02:24 zwölf Secrets gelesen hat, kommt einem Geständnis in Cloud-Logs so nahe wie nur möglich.

Warum das Activity Log überlebt

Laut Microsoft werden Activity-Log-Einträge vom System erzeugt und lassen sich weder ändern noch löschen (Aktivitätsprotokoll in Azure Monitor). Sie bleiben unabhängig von jeder Exportkonfiguration 90 Tage verfügbar. Was ein Angreifer tun kann:

Vorhandene Log-Blobs in einem Speicherkonto kann natürlich löschen, wer Rechte auf dieses Konto hat. Das erscheint als StorageDelete in den eigenen Logs des Kontos – sofern diese aktiviert waren und woanders hingingen. Deshalb sollte das Log-Archiv in einem separaten Abonnement mit eigener Zugriffssteuerung liegen.

MITRE ATT&CK führt diese Aktionen als T1562.008 Disable or Modify Cloud Logs, T1562.001 Disable or Modify Tools und T1562.007 Disable or Modify Cloud Firewall.

Ein diagnosticSettings/delete-Ereignis lesen

Die resourceId verrät, was dunkel geworden ist:

• …/providers/Microsoft.KeyVault/vaults/<vault>/providers/microsoft.insights/diagnosticSettings/<name> – ein Key Vault sendet kein AuditEvent mehr.
• …/providers/Microsoft.Storage/storageAccounts/<account>/…/diagnosticSettings/<name> – Storage-Logs sind gestoppt.
• /subscriptions/<id>/providers/microsoft.insights/diagnosticSettings/<name> – keine Ressourcengruppe im Pfad: Das ist die Einstellung des Abonnements, also der Activity-Log-Export.

Der Name der Einstellung ist oft sprechend (kv-audit-to-storage, export-activity-to-sentinel) und hilft herauszufinden, wohin die Logs gingen. Danach:

1. Notieren Sie den genauen Zeitstempel. Er markiert das Ende Ihrer Sicht auf die Datenebene dieser Ressource.
2. Sehen Sie sich an, was derselbe Aufrufer in der Stunde davor getan hat. Das Löschen der Protokollierung ist meist der letzte Schritt, nicht der erste.
3. Wurde die Einstellung später neu angelegt, haben Sie eine Lücke, kein Fehlen. Beschreiben Sie es genau so.

Auch ein diagnosticSettings/write kann der Verschleierung dienen: Logs in einen vom Angreifer kontrollierten Arbeitsbereich umzuleiten oder eine Kategorie zu entfernen, verschlechtert die Erfassung unbemerkt. Prüfen Sie den Anforderungstext.

Defender for Cloud-Pläne

Defender for Cloud-Pläne werden pro Abonnement über die pricings-API konfiguriert. Wird ein Plan auf den Free-Tarif zurückgesetzt, erscheint Microsoft.Security/pricings/write mit "pricingTier": "Free" im Anforderungstext. Der Ressourcenname nennt den Plan (VirtualMachines, StorageAccounts, KeyVaults, Arm …). Eine Sparentscheidung erzeugt dasselbe Ereignis; klären Sie das also mit dem Verantwortlichen und vergleichen Sie dann den Zeitpunkt mit den übrigen Befunden.

Defender-Warnungen, die vor der Deaktivierung des Plans ausgelöst wurden, sind weiterhin über die Warnungs-API abrufbar; exportieren Sie sie (Exportleitfaden). Der Azure Forensics Analyzer liest diesen Export und macht aus jeder Warnung einen Befund AZ-DEF-001 mit übernommenem Schweregrad.

Was der Analyzer meldet

Da das Urteil „Kompromittiert“ mindestens zwei hohe Befunde erfordert, bleibt ein einzelnes AZ-DE-003 aus einer Finanzentscheidung bei „Verdächtig“ – die richtige Antwort, bis jemand den Grund bestätigt.

Die Lücke in den eigenen Daten erkennen

Verschleierung zeigt sich in den geladenen Daten, nicht nur in den Ereignissen:

• Eine Quelle, die abrupt endet. Der Abdeckungsblock zeigt das erste und letzte Ereignis je Quelle. Ein Key Vault-Log, das um 02:55 endet, während das Activity Log bis 03:30 weiterläuft, passt zu einer Löschung um 02:55.
• Stündliche Blobs, die aufhören. In einem Speicherexport enden die h=-Ordner dieser Ressource einfach.
• Duplikate, die aufhören. Haben Sie sowohl den Speicherexport als auch einen aktuellen az CLI-Export geladen, läuft die CLI-Kopie nach dem Kappen des Exports weiter: Das ist Azures 90-Tage-Kopie bei der Arbeit.

Im fiktiven Beispiel wird die Diagnoseeinstellung des Key Vault um 02:55:12 gelöscht und der Export des Abonnements um 02:55:40; das in den Speicher exportierte Activity Log endet dort, und nur der CLI-Export zeigt die Löschung des Exports selbst.

Behebung und Härtung

• Legen Sie gelöschte Diagnoseeinstellungen und den Activity-Log-Export neu an; prüfen Sie, dass wieder Daten ankommen.
• Aktivieren Sie die Defender-Pläne wieder; prüfen Sie Warnungen während und nach der Lücke.
• Erzwingen Sie die Protokollierung mit Azure Policy (deploy-if-not-exists für Diagnoseeinstellungen), sodass fehlende Einstellungen als nicht konform markiert und per Wartungstask neu bereitgestellt werden können.
• Halten Sie das Log-Archiv in einem separaten Abonnement, mit Löschrechten für sehr wenige Identitäten; erwägen Sie unveränderlichen Speicher für den Archivcontainer.
• Stellen Sie Sperren auf kritischen Ressourcen wieder her und beschränken Sie Microsoft.Authorization/locks/delete.

Verwandte Artikel

• Grenzen der Azure-Logforensik: Aufbewahrung und Lücken
• Key Vault-Audit-Logs: Wer hat welches Secret gelesen?
• Azure-Abonnement kompromittiert? Leitfaden zur Reaktion