Forensic – EngineX : scan réseau et protocole industriel
Sommaire
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 :
- Cas n°1 : PhishingBoat - analyse d'un fichier Mbox et d'un fichier PDF malveillant
- Cas n°2 : FloatingCredentials - analyse d’une capture WireShark
- Cas n°3 : EngineX - détection d'un scan nmap et analyse réseau d'un protocole propriétaire industriel
- Cas n°4 : SteerOnSomewhere - analyse de PDF et EXE malveillants
- Cas n°5 - PearlArmor : analyse de journaux et d'une image disque
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 :
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 :
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 :
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 :
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 :
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
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 :
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 :
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 :
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 🙂 ) :
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 :
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... :
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.
