Analyse des flow logs NSG et VNet pour l'exfiltration
Analyse des flow logs NSG et VNet en réponse à incident : formats de tuples, octets et états de flux, exfiltration, minage, IP d'attaquant et angles morts.
En bref. Les flow logs sont des enregistrements de couche 4 de chaque flux traversant vos NSG (flow logs NSG) ou vos VNet (flow logs VNet), écrits dans un compte de stockage chaque minute sous forme de tuples : horodatage, source, destination, ports, protocole, direction, décision ou état, et, pour les NSG v2 et les flow logs VNet, paquets et octets dans chaque sens. En réponse à incident, ils répondent à trois questions : une VM compromise a-t-elle parlé à l'IP de l'attaquant, beaucoup de données sont-elles parties vers une même adresse, quelque chose atteint-il des pools de minage ou des ports d'administration. Les flow logs NSG seront retirés le 30 septembre 2027 ; les flow logs VNet les remplacent. Les flow logs ne voient pas les clients Internet qui téléchargent directement depuis un compte de stockage.
Les flow logs sont le log Azure le moins glamour, et souvent celui qui boucle le dossier. L'Activity Log dit « Run Command à 02:19 » ; le flow log dit « à 02:20, la VM a récupéré 46 Ko depuis l'IP de l'attaquant sur le port 80 ». C'est la différence entre soupçon et confirmation.
Deux formats, une même idée
| Flow logs NSG | Flow logs VNet | |
|---|---|---|
| Périmètre | Un groupe de sécurité réseau | Un réseau virtuel entier (sous-réseaux, cartes réseau) |
| Statut | Retrait le 2027-09-30 ; plus de création possible | Actuel |
| Conteneur de stockage | insights-logs-networksecuritygroupflowevent | insights-logs-flowlogflowevent |
| Catégorie d'enregistrement | NetworkSecurityGroupFlowEvent | FlowLogFlowEvent |
| Horodatage du tuple | Secondes Unix | Millisecondes Unix |
| Protocole | T / U | Numéro IANA (6 = TCP, 17 = UDP) |
| Décision | Champ séparé A / D | État de flux D pour refusé |
| Octets / paquets | Version 2 uniquement | Oui, plus l'état de chiffrement |
Les deux sont écrits à intervalles d'une minute (flow logs NSG, flow logs VNet). Un tuple NSG version 2 :
1542110379,10.5.16.4,203.0.113.117,59932,443,T,O,A,E,1,66,1,66
se lit : heure, IP source, IP destination, port source, port destination, TCP, sortant, autorisé, flux terminé, 1 paquet / 66 octets envoyés, 1 paquet / 66 octets reçus. Un tuple VNet :
1663146003606,10.0.0.6,192.0.2.180,23956,443,6,O,E,NX,3,767,2,1580
ajoute l'état de chiffrement (NX = non chiffré) et utilise des millisecondes et des numéros de protocole IANA.
Compter correctement les octets
Les états de flux sont B (début, sans compteurs), C (continuation, compteurs toutes les cinq minutes pour les flux longs) et E (fin, compteurs finaux) ; les flow logs VNet ajoutent D (refus). Microsoft précise que les compteurs C et E sont des cumuls depuis le tuple précédent du flux : le total d'une conversation est donc la somme de tous les tuples C et E, pas le dernier. Ignorer ce point conduit aussi bien à des doubles comptes qu'à des sous-estimations.
Deux autres pièges tirés de la documentation Microsoft :
- Pour les flow logs NSG, les flux touchant des règles entrantes TCP non par défaut sont traités sans état et leurs compteurs d'octets et de paquets ne sont pas enregistrés ; les flow logs VNet prennent en charge octets et paquets pour les flux sans état.
- Des VM sans IP publique peuvent quand même montrer des tuples entrants depuis des adresses Internet sur des ports SNAT ; la tentative est journalisée bien qu'Azure ne la délivre pas.
Ce qu'il faut chercher
| Motif | Pourquoi c'est important | Règle de l'analyseur |
|---|---|---|
| Tout flux entre une VM et une IP déjà vue dans d'autres constats (l'IP qui a lancé le Run Command, lu le coffre…) | Relie l'attaquant du plan de contrôle à l'activité sur la VM : deuxième charge, C2, exfiltration | AZ-NET-004, haut |
| Plus de 500 Mo sortis du réseau vers une même IP publique | Candidat à l'exfiltration (T1048) | AZ-NET-003, moyen |
| Sortant vers des ports typiques de pools de minage (3333, 4444, 5555, 7777, 14433, 14444, 45560, 45700) | Cryptominage (T1496) | AZ-NET-002, haut |
| Entrant autorisé depuis des IP publiques vers 22, 3389, 5985, 5986 | Ports d'administration exposés (T1133) | AZ-NET-001, moyen |
| Scans entrants refusés | Bruit de fond sur toute IP publique | — (contexte seulement) |
AZ-NET-004 est la plus précieuse, car elle n'a besoin d'aucun seuil : dès que l'analyseur dispose d'une IP d'attaquant issue de l'Activity Log, de Key Vault ou des logs Storage, chaque flux vers ou depuis cette IP est une preuve. La liste des ports de minage est une heuristique ; des services utilisant légitimement ces ports correspondront.
Comment l'analyseur gère le volume
Un sous-réseau actif écrit des millions de tuples par jour. L'analyseur Azure Forensics ne les conserve jamais un par un : il agrège par conversation (source, destination, port de destination, protocole, direction, décision) avec première et dernière apparition, nombre de tuples, et paquets et octets additionnés. L'onglet Entités affiche ensuite, pour chaque IP, les totaux envoyés et reçus : le moyen le plus rapide de trouver « la seule adresse qui a reçu 40 Go ».
Soyez tout de même sélectif à l'export : ne téléchargez que les heures de l'incident et les VNet ou NSG concernés. Le guide d'export donne les chemins.
Ce que les flow logs ne voient pas
- L'accès direct aux endpoints PaaS depuis l'extérieur. Un attaquant qui télécharge des blobs via Internet avec un SAS ne touche jamais votre VNet. Utilisez les logs Storage.
- Les charges utiles. Les flow logs ne contiennent que des métadonnées : pas d'URL, pas de nom de serveur TLS, pas de contenu.
- Le trafic au niveau du point de terminaison privé lui-même. Microsoft indique qu'il ne peut être capturé qu'à la VM source.
- Les services non pris en charge. Microsoft liste des services sans prise en charge des flow logs, dont App Service, Azure Functions, Logic Apps et Container Instances.
- Tout ce qui précède l'activation des flow logs, et tout ce que la rétention du compte de stockage a déjà supprimé.
Un exemple commenté
Dans l'exemple fictif du site, un Run Command démarre sur vm-app-01 à 02:19:40 UTC. Le flow log VNet montre la VM (10.10.1.4) ouvrant une connexion vers l'IP de l'attaquant sur le port 80 à 02:20:05 (812 octets envoyés, 46 338 reçus, la taille d'un petit script) puis sur le port 443 quatre secondes plus tard. Aucun de ces flux n'attirerait l'attention seul ; les deux deviennent des constats de sévérité haute parce que l'IP apparaît déjà dans l'événement Run Command. Le cas décortiqué montre la chaîne complète.
FAQ
Les flow logs NSG vont-ils disparaître ?
Oui. Microsoft indique que les flow logs NSG seront retirés le 30 septembre 2027 et qu'il n'est plus possible d'en créer de nouveaux. Les flow logs de réseau virtuel (VNet) les remplacent.
Les flow logs montrent-ils la quantité de données sortie d'une VM ?
Les flow logs NSG version 2 et les flow logs VNet contiennent paquets et octets dans chaque sens sur les tuples de continuation (C) et de fin (E). Les additionner par conversation donne le volume. Les flow logs NSG version 1 n'ont pas de compteurs d'octets.
Les flow logs montrent-ils les téléchargements depuis un compte de stockage par un attaquant externe ?
Non. Les flow logs enregistrent le trafic des interfaces réseau de vos réseaux virtuels. Un attaquant qui télécharge des blobs directement depuis l'endpoint de stockage via Internet ne traverse jamais votre VNet ; utilisez pour cela les logs de ressources Storage.