Forensic – FloatingCredentials : analyse d’une capture WireShark

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 afin de déterminer les actions menées par un attaquant.

Nous allons notamment utiliser le logiciel Wireshark et explorer quelques-unes de ses nombreuses fonctionnalités, notamment celles permettant de comprendre et d'analyser une trace réseau comprenant un grand nombre de paquets et d'échanges différents.

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 - FloatingCredentials

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.

Nous avons, dans le premier article de cette série, identifié que l'attaquant a envoyé un mail de phishing contenant une pièce jointe malveillante. Le contexte de cette seconde étape de l'analyse est le suivant :

M.Deloin affirme avoir cliqué sur la pièce jointe malveillante dès sa lecture, soit le lundi 03/08 à 9h00. Aussi, selon Armor, la seule connexion à leur VPN depuis le poste de Christian Deloin pendant le mois d’août a eu lieu le 05/08 à 13h. Récoltez des preuves permettant d’affirmer que l’attaquant s’est servi de la machine de M.Deloin pour se connecter au VPN d’Armor.

Comme dans toute analyse forensic, les éléments de contexte sont importants à prendre en compte et permettent d'orienter nos recherches. Ici, deux traces réseau nous sont fournies :

• deloin_03_08_09_00.pcapng : date d'ouverture de la pièce jointe malveillante par l'utilisateur ;
• deloin_05_08_13_00.pcapng : date d'une connexion VPN établie depuis le poste de Mr Deloin.

Ces deux traces réseau correspondent aux éléments de contexte indiqué.  Nous devons fournir les éléments suivants pour compléter cette deuxième étape de l'analyse :

• IP de l'attaquant;
• Identifiants du VPN;
• IP du VPN;
• Commande complète utilisée pour se connecter chez Armor.

N'oublions pas de vérifier l'intégrité des éléments récupérés (le hash BLAKE2 est fourni avec les fichiers sur le site du challenge) :

$ b2sum deloin_03_08_09_00.pcapng 
72891fe777ccc13f29ab0b4a62ddaa644d68ab7a82ee52b3e29025de971504257c04578f27c3a9cd2aee3145fa35c21df7f59e8df898b64ed17e11d264f0163c deloin_03_08_09_00.pcapng

$ b2sum deloin_05_08_13_00.pcapng 
f1af4b121e62f9137f571b00023501530bf8c6f12aa797d858a39d5afe9dd7d15bad86092f5152175ff8fbd7c3b6d711e7071313d5a456ac89caf5b69d24fcb3 deloin_05_08_13_00.pcapng

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

III. Analyse d'une trace réseau avec WireShark

Les traces réseau reçues contiennent un grand nombre de paquets, l'analyse manuelle des paquets un à un n'est donc pas une méthodologie viable dans notre cas. Heureusement, Wireshark propose de nombreuses fonctionnalités de filtre, de tri, de statistique et de catégorisation des échanges qui vont nous être utiles.

A. Identifier l'adresse IP du poste d'écoute

Commençons par l'analyse du fichier deloin_03_08_09_00.pcapng qui contient plus de 90 000 paquets.  Pour rappel, la pièce jointe malveillante analysée dans la première étape était un PDF exécutant des commandes système dès son ouverture (voir cet article Forensic – PhishingBoat : analyse de fichiers Mbox et PDF). On peut donc penser que cette activité a laissé une trace réseau.

Afin d'avoir une bonne compréhension des échanges, il nous faut déterminer l'adresse IP du poste ayant été utilisé pour l'enregistrement des traces réseau, nous pourrons ainsi plus facilement mettre un sens sur les paquets analysés.

Dans Wireshark, il n'existe pas de moyen fiable à 100% de déterminer cette information : mettre une interface en mode promiscious et réaliser l'écoute réseau depuis un actif réseau en mode mirroring font partie des cas de figure qu'il nous sera difficile de caractériser.

Nous pouvons simplement tenter de déduire cette information à partir de différentes sources. L'utilisation de la fonction Conversations dans le menu Statistiques est une source possible : 

Dans Wireshark, une conversation réseau est un trafic entre deux points de terminaison spécifiques qui peuvent être caractérisés par adresses Ethernet (MAC), IPv4, IPv6, UDP ou TCP. Ce que l'on remarque rapidement dans les onglets IPv4 et TCP, c'est que l'adresse 192.168.0.12 est la plus présente en adresse source et destination :

C'est un indicateur intéressant, car si la capture réseau a été faite sur le poste lui-même, la grande majorité des paquets aura pour adresse source ou destination celle du poste en question, hormis les paquets multicast et broacast (et les paquets non IP).

Nous pouvons à présent utiliser les filtres Wireshark pour faire un filtre sur l'adresse IP 192.168.0.12 : 

ip.src==192.168.0.12 || ip.dst ==192.168.0.12

Nous utilisons ici l'opérateur || qui permet d'indiquer un OU : soit l'adresse IP source est 192.168.0.12 , soit l'adresse IP destination est 192.168.0.12. Information intéressante, lorsque nous utilisons un filtre sur Wireshark, celui-ci nous indique (discrètement) le pourcentage de paquets affichés à la suite de l'application de ce filtre :

Nous savons donc que 99,9% des paquets ont pour adresse source ou destination l'adresse IP ciblée par le filtre, un autre indicateur qui confirme notre choix. Enfin, nous pouvons utiliser la fonction Endpoint du menu Statistiques de Wireshark : 

Cette fonctionnalité va lister de manière unitaire les points de terminaison présents dans la capture réseau, l'équivalent d'un sort -u pour les Linuxiens. À nouveau, différents onglets sont proposés : Ethernet, IPv4, IPv6, TCP et UDP. En se rendant sur IPv4, on remarque à nouveau que les valeurs des colonnes Tx packets (Transmitter) et Rx Packets(Receiver) pour la ligne de l'adresse 192.168.0.12 sont les plus élevées, ce qui va dans le même sens que nos constats précédents :

Nous venons de voir dans cette section comment utiliser certaines fonctionnalités de Wireshark pour identifier une adresse IP pouvant correspondre à celle du poste sur laquelle a été réalisée la capture réseau. Ces fonctions peuvent également servir à identifier des exceptions et des comportements qui sortent de l'ordinaire.

B. Identifier un trafic anormal

Pour rappeler notre mission principale, nous devons identifier un trafic anormal au sein de cette capture ainsi que l'adresse IP de l'attaquant. Nous allons ici lister les différents ports TCP présents dans la capture réseau à l'aide de la fonction Endpoints, plus précisément dans l'onglet TCP :

Pour l'instant, rien de très parlant. Nous voyons des échanges sur les ports HTTP et HTTPS classiques. Nous cherchons dans un premier temps des comportements anormaux concernant l'adresse IP 192.168.0.12. Nous pouvons utiliser un filtre pour inclure ou exclure certains paquets, par exemple :

 (ip.dst == 192.168.0.12 || ip.src==192.168.0.12) && (!tcp.port==80 && !tcp.port == 443)

Ainsi, nous excluons les paquets qui ne concernent pas l'adresse 192.168.0.12 et qui sont des échanges sur les ports 80 ou 443. Nous pouvons ensuite retourner dans la fonction Endpoint. Une petite astuce ici consiste à appliquer le filtre Wireshark sur les données présentées par cette fonction :

Voilà qui est un peu plus clair. Nous nous retrouvons avec une liste plus réduite de cas "anormaux" et pouvons maintenant investiguer sur ces cas un à un. Notamment en utilisant un filtre comme celui-ci pour le port 1723 (première ligne sur l'image ci-dessus) :  

(ip.dst == 192.168.0.12 || ip.src==192.168.0.12) && tcp.port==1723

C. Suivre une connexion TCP

Pour chaque filtre appliqué, nous nous retrouvons à nouveau avec une dizaine ou une centaine de paquets à analyser, nous pouvons ici utiliser la fonction Suivre de Wireshark en faisant un clic droit sur l'un des paquets :

Ici, rien de très parlant, mais cette fonction peut être très utile pour certains protocoles puisqu'elle permet de visualiser, dans une seule fenêtre, les échanges entre le serveur (en bleu) et le client (en rouge), c'est notamment le cas pour les protocoles non chiffrés. Faisons la même opération pour le port TCP/5000 :

Voilà qui est plus intéressant, cela ressemble fortement à un shell PowerShell distant, typiquement le type d'outils et de méthodes utilisés dans le cadre d'un accès distant par un attaquant. Nous pouvons donc obtenir, grâce à ce filtre, l'adresse IP de notre attaquant : 93.29.253.182.

Nous pouvons donc affirmer ici que l'attaquant a utilisé la technique T1059.003 Command and Scripting Interpreter: Windows Command Shell référencée dans le framework MITRE ATT&CK :

Un peu plus bas dans cette même conversation, nous remarquons que l'attaquant était à la recherche d'identifiants VPN, qu'il a fini par trouver :

Nous sommes donc en mesure de dire, grâce à ces éléments, que l'attaquant a bien mis la main sur ces identifiants. Cela nous amène à notre deuxième capture réseau, qui concerne une connexion VPN établie avec le compte de Mr Deloin peu après cette première capture réseau.

Le vol d'éléments d'identification sur un système compromis est décrit dans la technique T1552.001 Unsecured Credentials: Credentials In Files du framework MITRE ATT&CK.

Nous ouvrons donc la capture réseau deloin_05_08_13_00.pcapng et appliquons dans un premier temps le même filtre que précédemment :

(ip.dst == 192.168.0.12 || ip.src==192.168.0.12) && tcp.port==5000

À nouveau en faisant un suivi de connexion TCP sur ces échanges, nous obtenons une vue en clair des commandes exécutées par l'attaquant et des réponses obtenues :

Ce qui nous permet de répondre aux deux dernières questions :

• IP du VPN : 90.70.74.155
• Commande complète utilisée pour se connecter chez Armor : Invoke-Expression "rasdial.exe RH-ARMOR christian.deloin Chr123delo!"

L'attaquant a donc utilisé les identifiants volés afin d'obtenir un accès VPN valide au SI ciblé, cette technique T1078 Valid Accounts est également décrite dans le framework MITRE ATT&CK. Cette action peut être vue comme un moyen d'accès initial ou de persistance.

Les choses auraient bien sûr été plus complexes si l'attaquant avait utilisé un protocole chiffré ainsi qu'un échange sur un port commun (80 ou 443). Gardons à l'esprit qu'il s'agit d'un exercice et non d'un cas 100% réel :). Cela nous a cependant permis de nous familiariser avec différentes fonctionnalités de Wireshark et d'avoir un aperçu de l'état d'esprit qu'il faut avoir en matière d'investigation. Nous avons également vu dans cet article que nous sommes en capacité d'associer une technique du framework MITRE ATT&CK à chaque action de l'attaquant. Cela nous permettra par la suite de tenter d'en savoir plus sur ses intentions, sur les recommandations et moyens de détection à mettre en place à la suite de cette attaque, et très éventuellement de tenter d'assigner cette attaque à une entité connue (APT).

Le prochain article de cette série portera sur une analyse réseau également, nous étudierons quelques fonctions de filtre supplémentaires ainsi que l'analyse d'un protocole industriel.

Mickael Dorigny Co-founder

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

See Full Bio