Forensic – EngineX : scan réseau et protocole industriel

I. Présentation

Nous continuons notre suite d'articles sur le CTF du FIC 2021 proposé par l'école EPITA afin de découvrir certains outils et méthodes de forensic (investigation numérique). Dans cet article, nous allons nous pencher sur l'analyse de traces réseau contenant un protocole propriétaire permettant de gérer des automates industriels.

Nous allons à nouveau utiliser logiciel Wireshark et quelques-unes de ses fonctionnalités.

Cette enquête est découpée en 5 articles, voici la liste des articles :

II. Contexte : Panic on board - EngineX

Le contexte de l'incident sur lequel nous intervenons est le suivant : Un bateau de croisière de la compagnie maritime ArMor a subi une panne et se retrouve bloqué en pleine mer.

Dans la phase précédente, nous avons identifié dans différentes traces réseau le fait que l'attaquant ait mis la main sur les éléments d'authentification VPN d'un utilisateur légitime. Le contexte de cette troisième étape de l'analyse est le suivant : 

Bienvenue à bord à vous et à votre équipe ! Pour déterminer la cause de l’arrêt soudain des moteurs, vous disposez à présent d’une capture réseau réalisée sur le SeaCastle. À vous de trouver les actions louches sur le réseau interne du fleuron de la flotte d’ArMor !

Ici, une trace réseau nous est fournie :

  • SeaCastle_suspect.pcap

 Nous devons répondre aux questions suivantes afin de compléter cette troisième étape de l'analyse :

N'oublions pas de vérifier l'intégrité de la trace récupérée (le hash BLAKE2 est fourni avec le fichier sur le site du challenge) :

$ b2sum SeaCastle_suspect.pcap
ce16940ae28744b6eb2179c2cfc6974581234403407602b3835bf4c7496e967e78f602208d907900100250946a052490d2385636553dd8d680317ba8d8e2447c SeaCastle_suspect.pcap

Vous trouverez le challenge en question et les fichiers utilisés dans cet article ici : Panic On Board - EngineX

III. Détecter un scan réseau dans un PCAP

Notre premier objectif est ici de détecter un scan réseau et de retrouver l'adresse IP du poste émetteur de ce scan. Pour cela, il faut comprendre ce qu'est un scan réseau.

Un scan réseau est une action menée afin de découvrir les hôtes actifs d'un réseau et les services qu'ils hébergent, il peut aller jusqu'à chercher à identifier ses services (technologies, versions, faiblesses de configuration). L'outil le plus utilisé pour la réalisation d'un scan réseau est le fameux nmap, bien que de nombreux autres existent aujourd'hui (masscan, ping, nessus, etc.). Dans les cas les plus classiques, une adresse IP va donc chercher à savoir si d'autres adresses IP sur le même réseau local sont actives, par l'intermédiaire d'un simple ping ou l'envoi d'un paquet sur les services les plus communs (TCP/22, TCP/445, TCP/80 par exemple).

Lorsqu'une adresse IP est détectée comme valide par l'outil de scan, celui-ci va ensuite chercher à énumérer tous les services hébergés par cette adresse IP.

Maintenant que nous avons une meilleure vue sur ce qu'est un scan réseau, il est temps de "traduire" cela en comportement réseau pouvant être présent dans notre capture. Nous allons dans un premier temps tenter d'identifier qui a le plus "parlé" au sein de cette capture réseau.

Notre capture réseau contient plus de 196 000 paquets, l'analyse de ces derniers à la main via un scrolling furieux n'est donc pas une option. Comme dans l'article précédent, nous allons utiliser la fonction Endpoints de Wireshark :

Utilisation de la fonction endpoints de Wireshark
Utilisation de la fonction Endpoints de Wireshark

L'adresse IP 192.168.101.31 sort un peu du lot, et elle est première toutes catégories confondues (nombre de paquets émis/reçus, volumétrie des échanges, etc). Il s'agit d'un indice intéressant, mais trop faible pour affirmer avec certitude que c'est cette adresse IP qui est la source d'un scan réseau. L'accès à la fonction Statistiques - IPv4 Statistics - Source and Destination nous confirme ce constat, l'adresse 192.168.101.31 est concernée par 94% (la majorité) des échanges contenus dans cette capture réseau : 

Accès à la fonction Statistics IPv4 - All Addresses de Wireshark
Accès à la fonction Statistics IPv4 - All Addresses de Wireshark

Une autre option nous permet de détecter clairement qu'un scan réseau a eu lieu sans avoir à parcourir manuellement les paquets : Statistiques - IPv4 Statistics - Destinations and ports :

Utilisation de la fonction Statitics - Destinations and Ports
Utilisation de la fonction Statistics - Destinations and Ports

Ici, nous voyons que sur plusieurs adresses IP du même sous-réseau, des échanges très brefs (1 ou 2 paquets) ont été réalisés systématiquement sur les mêmes ports, ce qui est exactement le comportement qu'adoptent les outils de scan réseau pour tester la présence d'un service sur un ensemble d'adresses IP. Terminons cette section avec la fonction Statistiques - Conversations, qui va nous permettre de visualiser l'ensemble des échanges émis par adresse source, destination et port :

Utilisation de la fonction Conversations de Wireshark
Utilisation de la fonction Conversations de Wireshark

En se rendant sur l'onglet TCP puis en regardant les colonnes Address A (IP source) et Port B (port destination), on se rend compte que l'adresse IP 192.168.101.19 a communiqué avec un grand nombre d'hôtes, systématiquement sur les mêmes ports. Nous pouvons donc affirmer que l'adresse IP source du scan réseau est donc celle-ci et non 192.168.101.31, qui est l'adresse IP la plus bavarde, mais qui n'a échangé qu'avec 5 hôtes différents :

Utilisation de la fonction Statistiques - Conversations avec l'application d'un filtre par IP
Utilisation de la fonction Statistiques - Conversations avec l'application d'un filtre par IP

Dans la capture ci-dessus, le fait de cocher la case Limiter au Filtre d'Affichage permet d'avoir une vue des conversations concernant uniquement l'adresse IP choisie.

Sans avoir parcouru aucun paquet et uniquement via les fonctions statistiques de Wireshark, nous pouvons donc affirmer qu'un scan réseau a eu lieu et identifier l'adresse IP source de ce scan réseau : 192.168.101.19.

Dans le framework MITRE ATT&CK, la technique du scan réseau est référencé T1046 Network Service Scanning.

Il est ici intéressant de retenir, en plus des différentes fonctions de statistique très utiles de Wireshark, le fait qu'un scan réseau n'est pas forcément l'échange le plus verbeux sur une trace réseau. L'échange d'un fichier de 100 Mo réalisé en même temps que la capture du scan réseau suffira à semer le trouble si l'on analyse uniquement la volumétrie des échanges.

IV. Analyse d'échanges SIEMENS S7

La prochaine étape de l'investigation consiste à étudier ce qu'a fait l'attaquant à la suite de ce scan réseau. Pour cela, nous utiliserons la même trace réseau. Nous devons chercher dans un premier temps le protocole utilisé pour effectuer l'attaque. À nouveau, la fonction Conversations va nous aider à cibler nos recherches, au-delà du scan réseau émis par l'adresse IP 192.168.101.19, il se passe clairement quelque chose à destination des ports TCP/102 des systèmes présents sur le réseau :

Nous pouvons donc appliquer un filtre dans Wireshark sur les paquets qui ont pour source ou destination ce port, et qui concernent l'adresse IP 192.168.101.19.

ip.src==192.168.101.19 && tcp.port==102
Filtre sur le port relatif aux communications S7COMM (Port TCP/102)
Filtre sur le port relatif aux communications S7COMM (Port TCP/102)

Nous nous retrouvons alors avec 374 paquets, ce qui devient plus gérable pour une analyse manuelle :). Nous voyons notamment apparaitre le protocole S7COMM

Le protocole S7COMM est, d'après cette source, utilisé pour le contrôle à distance d'automates de la famille S7-300/400 de la marque Siemens. Dans le monde industriel, un automate peut également être appelé PLC (programmable logic controllers). Il s'agit donc dans notre contexte de systèmes pouvant recevoir des ordres par le réseau TCP/IP et qui ont également une action physique dans la vie réelle, principe même des systèmes industriels (gestion d'un bras mécanique, d'une porte automatique, etc.).

Mais comment Wireshark détermine-t-il un protocole ?

Wireshark utilise des dissecteurs pour déterminer et "décoder" correctement le contenu d'un paquet. Il s'agit simplement de parsers de protocoles qui permettent d'identifier son contenu et de l'afficher correctement dans l'interface graphique, les paquets des couches 2, 3 et 4 intègrent directement une indication sur le protocole de niveau supérieur qu'ils contiennent :

Indication des protocles de niveaux supérieur pour les couches 2, 3 et 4
Indication des protocoles de niveaux supérieurs pour les couches 2, 3 et 4

Pour déterminer quel protocole est utilisé au-delà de la couche 4 (TCP/UDP) : cela se complique un peu et sachez que Wireshark peut ici faire des erreurs, car il essaye de deviner le protocole utilisé à partir de plusieurs critères comme des champs caractéristiques, le numéro de port source ou destination, etc... (Source : 11.4. Control Protocol dissection).

Une fois qu'un protocole a été identifié par Wireshark, celui-ci utilise le dissecteur associé qui va "traduire" le format hexadécimal que vous voyez en bas de votre fenêtre en sections lisibles. Si l'on s'intéresse aux paquets qui utilisent le protocole S7COMM, nous pouvons voir que Wireshark a déjà ordonné le contenu du paquet dans différentes sections en utilisant d'ailleurs un dissecteur documenté sur son site officiel :

Dissection du protocole S7COMM par Wireshark
Dissection du protocole S7COMM par Wireshark

Lorsque Wireshark trouve une valeur hexadécimale à cet endroit précis d'un paquet identifié comme utilisant le protocole S7COMM, il sait que cette valeur sert à déterminer la fonction (l'ordre) envoyée par le paquet, c'est le dissecteur qui permet de faire cette "catégorisation/rangement" des valeurs hexadécimales.

Vous pouvez d'ailleurs ajouter votre propre dissecteur dans Wireshark dans le cas où vous tombez sur un protocole non encore pris en charge ou spécifique à votre contexte. On remarque notamment la partie Function qui contient l'instruction 0x29, soit PCL Stop. Cela nous permet de répondre aux questions suivantes :

Si l'on souhaite effectuer un filtre très précis sur tous les paquets du protocole S7COMM qui contiennent cette instruction, nous pouvons tenter de manuellement trouver les bons champs à indiquer dans le filtre, ou simplement faire un Clic droit -> Appliquer comme Filtre -> Sélectionné sur le champ Function d'un paquet contenant l'instruction PLC Stop :

Application d'un filtre depuis le chmap du protocole s7COMM disséqué
Application d'un filtre depuis le champ du protocole s7COMM disséqué

Wireshark appliquera alors automatiquement le filtre suivant : 

s7comm.param.func == 0x29

Nous aurons alors la liste des paquets contenant cette instruction et nous pourrons avoir une liste toute jolie des adresses IP ciblées avec la fonction Endpoints que vous connaissez bien à présent (n'oubliez pas de cocher la case Limiter au Filtre d'Affichage 🙂 ) :

Affichage de la liste des adresse IP concernées par le filtre appliqué
Affichage de la liste des adresses IP concernées par le filtre appliqué

En excluant l'adresse IP de l'attaquant, nous pouvons donc répondre à notre dernière question :

L'attaquant vise donc ici clairement l'arrêt des automates présents sur le réseau, dans le framework MITRE, qui possède un déclinaison spécifique au monde industriel, il s'agit de la T0826 Loss of Availability.

Nous avons vu dans cette section que les dissecteurs intégrés à Wireshark nous permettent de comprendre un protocole industriel que ne nous ne connaissions pas du tout avant, la dissection des paquets (format hexadécimal vers un format plus ordonné et textuel) et l'une des forces de Wireshark. Les dissecteurs actifs peuvent être visualisés dans la fonction Analyser -> Protocoles activés de Wireshark :

Liste des dissecteurs activés sur Wireshark
Liste des dissecteurs activés sur Wireshark

Il faut cependant garder en tête que Wireshark peut se tromper dans la détermination d'un protocole pour un paquet, il est alors possible d'indiquer à Wireshark quel dissecteur utiliser pour quel port dans la section Analyser -> Décoder comme...

Indication d'une liaison entre un port et un dissecteur dans Wireshark
Indication d'une liaison entre un port et un dissecteur dans Wireshark

Dans cet exemple, j'indique à Wireshark de décoder les paquets sur les ports TCP/4000 comme de l'HTTP

J'espère que cet article vous aura intéressé et qu'au-delà du scénario de forensic proposé par le challenge du FIC, vous aurez appris quelques astuces sur le fonctionnement et l'utilisation de Wireshark :). Le prochain article portera sur l'analyse plus approfondie d'un PDF embarquant un exécutable malveillant.

Partagez cet article Partager sur Twitter Partager sur Facebook Partager sur Linkedin Partager sur Google+ Envoyer par mail

Mickael Dorigny

Co-fondateur d'IT-Connect.fr. Auditeur/Pentester chez Orange Cyberdéfense.

mickael has 518 posts and counting.See all posts by mickael

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.