Une application web située à l’adresse 10.0.10.20 reçoit une requête provenant de l’ordinateur portable de l’analyste (10.0.10.50), tandis qu’une rafale de trafic ultérieure, issue de 10.0.30.66, atteint les deux sous-réseaux internes. L’attaquant n’a pas besoin de se connecter pour générer des preuves. Chaque paquet enregistre la provenance du trafic, sa destination et le protocole utilisé pour le transporter. Pour le défenseur, l’enjeu consiste à déterminer comment une session capturée peut révéler à la fois un trafic web attendu et des tentatives de sondage suspectes, sans pour autant traiter la capture comme un simple flux d’octets illisible.
Notre environnement de laboratoire fixe comprend l’ordinateur portable de l’analyste et l’application web sur le réseau 10.0.10.0/24, un résolveur DNS à l’adresse 10.0.10.53 et une base de données à l’adresse 10.0.20.10. Un pare-feu et un routeur interconnectent ces réseaux via les adresses 10.0.10.1 et 10.0.20.1, tandis que la machine virtuelle de l’attaquant est isolée à l’adresse 10.0.30.66. La capture débute par du trafic DNS et web, puis inclut la machine virtuelle de l’attaquant contactant des adresses réparties sur les deux réseaux internes. Nous reviendrons sur ces adresses précises tout au long du cours, afin que tout filtre ou toute alerte ultérieurs puissent s’appuyer sur une référence connue.
Le schéma présente les équipements, les adresses et le trafic capturé :
Ce diagramme illustre l’importance du scan effectué ultérieurement. Une requête client adressée à l’application web a un objectif précis et attendu, tandis que des connexions répétées depuis 10.0.30.66 vers de nombreuses destinations peuvent signaler une phase de reconnaissance. Si les mesures préventives échouent et que le pare-feu laisse passer un trafic indésirable, la capture de paquets demeure une source de détection, car elle enregistre l’adresse source, l’adresse de destination, le protocole et les informations temporelles. La découverte de services réseau correspond à la technique T1046 du framework ATT&CK (version v20, octobre 2026) ; les défenseurs peuvent repérer ce modèle d’activité réseau via les journaux du pare-feu, les enregistrements de flux ou les captures de paquets.
La requête capturée devient compréhensible lorsqu’on l’examine sous l’angle de l’encapsulation, processus consistant à placer les données d’un protocole dans l’en-tête d’un autre protocole. Par exemple, la requête GET /login émise par le navigateur ne se limite pas à son simple texte. Le réseau doit également acheminer des informations telles que le port de destination, l’adresse IP de destination et la destination sur le réseau local.
Les modèles OSI et TCP/IP organisent ce même processus différemment. Le modèle OSI définit sept couches, alors que le modèle TCP/IP regroupe généralement le paquet en couches application, transport, internet et liaison. Aucun de ces modèles ne constitue un réseau distinct ; ils décrivent tous deux la trame Ethernet enregistrée par Wireshark.
Pour une requête allant de 10.0.10.50 vers 10.0.10.20, quelles informations permettent d’identifier la livraison locale, la livraison à l’hôte, le service destinataire et la page demandée ? La pile de protocoles du paquet présentée ci-dessous permet de visualiser ces différentes limites :
Cette pile présente la réponse en partant de l’extérieur vers l’intérieur. Ethernet utilise des adresses MAC pour acheminer la trame sur la liaison locale. IPv4 transporte les adresses 10.0.10.50 et 10.0.10.20, permettant aux routeurs de transférer le paquet entre les réseaux. TCP utilise les ports 51514 et 80 pour identifier les extrémités de la communication, tandis qu’HTTP transporte la requête GET /login en tant que données applicatives. Un analyste réseau peut ainsi poser une question différente à chaque couche, plutôt que de devoir examiner tous les champs simultanément.
Ordre des en-têtes Lisez les champs du paquet en suivant la progression de l’acheminement : liaison, hôte, puis service, avant d’interpréter la requête applicative.
Comme la trame englobe plusieurs couches, le volet de détails des paquets de Wireshark les développe sous forme d’entrées de protocole distinctes. Ethernet II affiche les champs MAC de couche 2, Internet Protocol Version 4 présente les adresses de couche 3, et Transmission Control Protocol expose les ports et les indicateurs de contrôle de couche 4. Une entrée Hypertext Transfer Protocol n’apparaît que lorsque Wireshark parvient à identifier des données HTTP visibles.
Toutes les trames ne contiennent pas nécessairement une requête HTTP. Avant la première requête GET /login, TCP établit la connexion via un paquet SYN provenant de 10.0.10.50 et une réponse SYN/ACK de 10.0.10.20. Ces paquets identifient bien les deux hôtes et les ports concernés, mais ils ne transportent aucune requête de page. La sortie de référence ci-dessous extrait les champs de ce même flux, sans prétendre correspondre à une exécution sur un système réel :