Analyse des VPC Flow Logs : exfiltration et minage
Lire les VPC Flow Logs en investigation : champs clés, volume sortant par destination, ports de pools de minage, ce qu'ils n'enregistrent pas et les pièges.
En bref. Les flow logs sont des métadonnées réseau : qui a parlé à qui, sur quel port, combien d'octets, flux accepté ou rejeté, par interface réseau, agrégés sur une à dix minutes. En investigation, trois questions sont rentables : combien d'octets sont sortis d'une adresse privée vers chaque destination publique (exfiltration), quelles instances maintiennent des connexions de longue durée vers des ports typiques de pools (minage) et quelles adresses externes ont atteint SSH/RDP avec succès (accès). Ils ne contiennent ni le contenu des paquets, ni les requêtes DNS vers le résolveur Amazon, ni le trafic vers les métadonnées d'instance, et les téléchargements S3 effectués depuis Internet ne traversent jamais votre VPC.
CloudTrail vous dit ce qui a été configuré. Les VPC Flow Logs vous disent ce que les ressources ont ensuite fait sur le réseau. Lorsqu'un attaquant prend pied sur une instance (via une clé volée, une application vulnérable ou une nouvelle instance qu'il a lancée), les flow logs sont souvent la seule trace de la destination des données.
L'enregistrement par défaut
Le format par défaut est la version 2 (documentation AWS) :
version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status
2 111122223333 eni-0f9e8d7c6b5a40000 10.20.1.11 192.0.2.150 40000 3333 6 42 8123 1789379520 1789379579 ACCEPT OK
| Champ | Signification en investigation |
|---|---|
interface-id | L'ENI : faites le lien avec une instance via DescribeNetworkInterfaces ou les réponses RunInstances dans CloudTrail |
srcaddr / dstaddr | Pour le trafic sortant, srcaddr est l'adresse privée de l'interface |
dstport, protocol | 6 = TCP, 17 = UDP |
bytes, packets | Par enregistrement, uniquement pour cette fenêtre d'agrégation |
start, end | Secondes Unix |
action | ACCEPT ou REJECT (groupe de sécurité / NACL) |
log-status | OK, NODATA (aucun trafic), SKIPDATA (enregistrements ignorés) |
Les formats personnalisés peuvent ajouter vpc-id, instance-id, tcp-flags, pkt-srcaddr / pkt-dstaddr (les adresses d'origine derrière un NAT ou des IP secondaires), flow-direction et traffic-path. Lorsque vous récupérez des fichiers depuis S3, la première ligne nomme les champs : conservez-la, car l'ordre des colonnes dépend du format choisi à la création du flow log.
Question 1 : des données sont-elles sorties ?
Filtrez les enregistrements ACCEPT dont la source est privée (RFC 1918) et la destination publique, puis additionnez bytes par couple (source, destination) sur toute la fenêtre de l'incident. L'exfiltration est une question de volume, et ce volume est réparti sur de nombreux enregistrements, puisque chacun couvre au plus dix minutes (une minute ou moins sur les instances Nitro).
Ce qu'il faut rechercher :
- une destination publique unique recevant des gigaoctets depuis une instance qui, d'ordinaire, ne parle qu'à une base de données et à un load balancer ;
- des transferts à des heures inhabituelles, ou qui démarrent quelques minutes après une session SSH de l'attaquant ;
- des destinations chez des hébergeurs plutôt que chez vos partenaires connus.
Vérifiez ensuite ce qui pourrait l'expliquer autrement : sauvegardes vers un service externe, mises à jour logicielles, récupération depuis l'origine par un CDN. La technique correspondante est MITRE ATT&CK T1048 Exfiltration Over Alternative Protocol ; le protocole est invisible dans les flow logs, seuls le volume et les ports le sont.
Question 2 : quelque chose mine-t-il ?
Le trafic de minage est l'inverse de l'exfiltration : faible, régulier, sans fin. Les signes :
- chaque instance lancée pendant l'incident maintient une connexion
ACCEPTvers les mêmes une ou deux adresses publiques ; - des ports de destination utilisés par les pools de minage (3333, 4444, 5555, 7777, 14444 et similaires) ;
- des volumes d'octets similaires minute après minute, dans les deux sens.
Il existe des pools qui écoutent sur le port 443 : le port seul n'est donc pas une preuve ; la régularité et la chronologie par rapport aux événements RunInstances, si. Voir la réponse à incident en cas de minage de cryptomonnaie.
Question 3 : qui est entré ?
Des ACCEPT entrants sur les ports 22 ou 3389 depuis des adresses publiques vers une instance vous indiquent quels hôtes externes ont atteint un port donnant accès à un shell. Une avalanche de REJECT révèle un scan ; un unique ACCEPT depuis une adresse qui apparaît ensuite dans CloudTrail comme source d'appels d'API relie les deux sources entre elles.
Relier les interfaces aux instances
Les flow logs nomment des interfaces réseau, pas des instances. Pour rattacher un flux au récit tiré de CloudTrail :
- Prenez l'
interface-iddes enregistrements suspects. - Recherchez-la avec
aws ec2 describe-network-interfaces --network-interface-ids eni-…, qui renvoie l'instance attachée et ses adresses privées, si l'instance existe encore. - Si elle a été supprimée, cherchez dans CloudTrail la réponse
RunInstancescontenant cet identifiant d'interface ou cette adresse privée ; la réponse listenetworkInterfaceSetpour chaque instance lancée. - À partir de l'instance, pivotez vers le principal qui l'a lancée et vers son profil d'instance.
Ajoutez instance-id aux formats personnalisés lorsque vous créez de nouveaux flow logs : cela vous épargnera cette étape lors du prochain incident.
Ce que les flow logs ne vous montreront jamais
D'après la liste des limitations des flow logs publiée par AWS, les éléments suivants ne sont pas journalisés :
- le trafic vers le serveur DNS Amazon (donc aucune trace d'exfiltration DNS via le résolveur du VPC : utilisez les journaux de requêtes Route 53 Resolver) ;
- le trafic vers 169.254.169.254 (métadonnées d'instance : un vol d'identifiants via IMDS ne laisse aucun flux) ;
- Amazon Time Sync, DHCP, l'activation de licences Windows, ARP, le trafic vers l'adresse réservée du routeur VPC par défaut ;
- le trafic mis en miroir, côté source.
Par ailleurs, les flow logs ne s'appliquent qu'à partir de leur création, ne peuvent pas être modifiés (un nouveau format exige un nouveau flow log), peuvent ignorer des enregistrements sous forte charge (SKIPDATA) et ne voient pas les téléchargements S3 ou autres appels d'API AWS effectués depuis Internet : ceux-ci n'entrent jamais dans votre VPC. Pour S3, utilisez les événements de données ou les journaux d'accès au serveur.
Les pièges dans les données
- Deux enregistrements par conversation. Un par sens et par interface ; ne comptez pas les octets deux fois en additionnant les deux.
- Passerelles NAT. Derrière une passerelle NAT, les flux de l'instance apparaissent sur l'interface du NAT ; utilisez
pkt-srcaddr/pkt-dstaddrsi le format les contient. - Fenêtres temporelles.
start/enddélimitent la fenêtre d'agrégation, pas la session TCP. - VPC par défaut des régions inutilisées. Les attaquants y lancent leurs instances précisément parce que personne n'y a activé de flow logs. L'absence de journaux n'est pas l'absence de trafic.
Dans l'analyseur
AWS Forensics lit les flow logs au format par défaut comme au format personnalisé (en tenant compte de la ligne d'en-tête et des champs pkt-*addr, et en ignorant NODATA/SKIPDATA) et signale plus de 1 Gio accepté depuis une adresse privée vers un même hôte sur Internet ainsi que les connexions sortantes acceptées vers des ports connus de pools de minage, avec les interfaces et les destinations en paramètres. Les preuves issues des flow logs apparaissent sur la même chronologie que CloudTrail, si bien que la connexion SSH, l'appel RunInstances et la première connexion au pool s'alignent. Pour savoir comment les collecter, consultez le guide d'export.