Évasion de défense Azure : logs supprimés, Defender coupé

En bref. Dans Azure, les attaquants ne suppriment pas l'Activity Log : ils ne le peuvent pas, Azure ne permet à personne d'en modifier ou d'en supprimer les entrées. Ils coupent les tuyaux : microsoft.insights/diagnosticSettings/delete sur un Key Vault ou un compte de stockage (les logs de ressources s'arrêtent), la même opération au niveau de l'abonnement (l'export de l'Activity Log s'arrête), Microsoft.Security/pricings/write avec pricingTier: Free (un plan Defender est désactivé), Microsoft.Authorization/locks/delete, et des règles NSG ou de pare-feu de stockage ouvertes. Chacune de ces actions est elle-même enregistrée dans l'Activity Log, qu'Azure conserve 90 jours. Le trou qu'elles créent commence à l'horodatage de la suppression.

L'événement le plus parlant de nombreuses intrusions Azure n'est pas le vol, c'est le ménage. Un paramètre de diagnostic supprimé à 02:55 un dimanche par le même principal de service qui a lu douze secrets à 02:24, c'est à peu près ce qui se rapproche le plus d'un aveu dans des logs cloud.

Pourquoi l'Activity Log survit

Microsoft indique que les entrées de l'Activity Log sont générées par le système et qu'on ne peut ni les modifier ni les supprimer (journal d'activité dans Azure Monitor). Elles restent disponibles 90 jours, quelle que soit la configuration d'export. Ce qu'un attaquant peut faire :

Les blobs de logs existants dans un compte de stockage peuvent évidemment être supprimés par quelqu'un qui a des droits sur ce compte. Cela apparaît comme StorageDelete dans les propres logs du compte, si ces logs étaient activés et envoyés ailleurs. C'est pourquoi l'archive de logs doit vivre dans un abonnement séparé, avec son propre contrôle d'accès.

MITRE ATT&CK suit ces actions sous T1562.008 Disable or Modify Cloud Logs, T1562.001 Disable or Modify Tools et T1562.007 Disable or Modify Cloud Firewall.

Lire un événement diagnosticSettings/delete

Le resourceId vous dit ce qui s'est éteint :

• …/providers/Microsoft.KeyVault/vaults/<vault>/providers/microsoft.insights/diagnosticSettings/<name> : un Key Vault a cessé d'envoyer AuditEvent.
• …/providers/Microsoft.Storage/storageAccounts/<account>/…/diagnosticSettings/<name> : les logs de stockage se sont arrêtés.
• /subscriptions/<id>/providers/microsoft.insights/diagnosticSettings/<name> : pas de groupe de ressources dans le chemin, c'est le paramètre de l'abonnement, donc l'export de l'Activity Log.

Le nom du paramètre est souvent parlant (kv-audit-to-storage, export-activity-to-sentinel) et aide à retrouver où allaient les logs. Ensuite :

1. Notez l'horodatage exact. C'est la fin de votre visibilité sur le plan de données de cette ressource.
2. Regardez ce que le même appelant a fait dans l'heure précédente. Supprimer la journalisation est généralement la dernière étape, pas la première.
3. Si le paramètre a été recréé plus tard, vous avez un trou, pas une absence. Présentez-le comme tel.

Un diagnosticSettings/write peut aussi servir l'évasion : rediriger les logs vers un espace de travail contrôlé par l'attaquant ou retirer une catégorie dégrade silencieusement la collecte. Examinez le corps de la requête.

Les plans Defender for Cloud

Les plans Defender for Cloud se configurent par abonnement via l'API pricings. Repasser un plan au niveau Free apparaît comme Microsoft.Security/pricings/write avec "pricingTier": "Free" dans le corps de la requête. Le nom de la ressource indique le plan (VirtualMachines, StorageAccounts, KeyVaults, Arm…). Une décision de réduction des coûts produit le même événement : vérifiez auprès du responsable, puis comparez le moment avec les autres constats.

Les alertes Defender émises avant la désactivation du plan restent dans l'API des alertes ; exportez-les (guide d'export). L'analyseur Azure Forensics lit cet export et transforme chaque alerte en constat AZ-DEF-001, en reprenant la sévérité de l'alerte.

Ce que signale l'analyseur

Comme le verdict exige au moins deux constats hauts pour « Compromis », un AZ-DE-003 isolé issu d'une décision financière vous laisse à « Suspect », ce qui est la bonne réponse tant que personne n'a confirmé la raison.

Reconnaître le trou dans vos propres données

L'évasion se voit dans les données chargées, pas seulement dans les événements :

• Une source qui s'arrête net. Le bloc de couverture montre le premier et le dernier événement par source. Un log Key Vault qui se termine à 02:55 alors que l'Activity Log continue jusqu'à 03:30 correspond à une suppression à 02:55.
• Des blobs horaires qui s'arrêtent. Dans un export de stockage, les dossiers h= de cette ressource s'interrompent.
• Des doublons qui cessent. Si vous avez chargé à la fois l'export de stockage et un export az CLI récent, la copie CLI continue après la coupure de l'export : c'est la copie de 90 jours d'Azure qui fait son travail.

Dans l'exemple fictif, le paramètre de diagnostic du Key Vault est supprimé à 02:55:12 et l'export de l'abonnement à 02:55:40 ; l'Activity Log exporté vers le stockage s'arrête là, et seul l'export CLI montre la suppression de l'export lui-même.

Remédiation et durcissement

• Recréez les paramètres de diagnostic supprimés et l'export de l'Activity Log ; vérifiez que les données arrivent à nouveau.
• Réactivez les plans Defender ; examinez les alertes pendant et après le trou.
• Imposez la journalisation avec Azure Policy (deploy-if-not-exists pour les paramètres de diagnostic), afin que les paramètres manquants soient signalés comme non conformes et puissent être redéployés par une tâche de correction.
• Gardez l'archive de logs dans un abonnement séparé, avec des droits de suppression réservés à très peu d'identités ; envisagez un stockage immuable pour le conteneur d'archive.
• Rétablissez les verrous sur les ressources critiques et restreignez Microsoft.Authorization/locks/delete.

Articles liés

• Limites de la forensique des logs Azure : rétention, trous
• Logs d'audit Key Vault : qui a lu quel secret, et quand
• Abonnement Azure compromis ? Guide de réponse à incident