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 :

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 : 

Accès au menu statistiques - conversations de Wireshark
Accès au menu statistiques - conversations de Wireshark

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 :

Identification de l'adresse IP potentielle du poste d'écoute
Identification de l'adresse IP potentielle du poste d'écoute

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 :

Affichage du pourcentage de paquet affichés à la suite de l'application du filtre.
Affichage du pourcentage de paquets affichés à la suite de l'application du 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 : 

Accès àa la fonction Endpoints de Wireshark
Accès à la fonction Endpoints 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 :

Visualisation des endpoints IPv4 dans Wireshark
Visualisation des endpoints IPv4 dans Wireshark

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 :

Liste des échanges par port TCP via la focntion Endpoint
Liste des échanges par port TCP via la fonction Endpoint

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 :

Application du filtre sur les résultats de la fonction Endpoints
Application du filtre sur les résultats de la fonction Endpoints

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 :

Sélection de l'option "Suivre" sur un paquet
Sélection de l'option "Suivre" sur un paquet

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 :

Suivi d'échanges TCP sur un protocole en clair
Suivi d'échanges TCP sur un protocole en clair

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 :

Description de la technique T1059.003 dans le framework MITRE ATT&CK
Description de la technique T1059.003 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 :

Affichage des identifiants VPN par l'attaquant
Affichage des identifiants VPN par l'attaquant

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.

Description de la technique T1552.001 dans le framework MITRE ATT&CK
Description de la technique T1552.001 dans le 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 :

Affichage des commandes saisies et de leurs résultats
Affichage des commandes saisies et de leurs résultats

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.

Description de la technique T1078 dans le framework MITRE ATT&CK
Description de la technique T1078 dans le framework MITRE ATT&CK

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.

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 en sécurité des systèmes d'information chez Amossys

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

4 thoughts on “Forensic – FloatingCredentials : analyse d’une capture WireShark

  • Bonjour Mickael,

    Merci pour cette série d’articles très intéressants.

    Je voulais te demander pourquoi tu ne donnais pas le lien vers le ctf pour pouvoir accéder aux fichiers pcap ?

    Je voulais te demander également comment tu faisais pour retrouver, facilement la technique d’attaque dans MITRE ATT&CK ?

    Un dernier point, je pense que tu peux simplifier le filtre de recherche pour l’ip dans wireshark comme ça : « ip.addr==192.168.0.12 ».

    Je te remercie,
    Bonne journée,
    Olivier

    Répondre
  • Bonjour Olivier,
    Merci pour ton commentaire. Effectivement je pourrais donner le lien du challenge à chaque fois, je vais modifier les articles publiés et futurs pour intégrer ce lien.

    Pour la recherche MITRE ATT&CK, je n’ai pas vraiment de technique à te proposer. je me sert du champ de recherche présent sur le site du MITRE ATT&CK et de quelques mots clés relatifs à une attaque ou une situation pour trouver les techniques qui peuvent matcher au mieux. Mon expérience d’auditeur/pentester me sert beaucoup ici puisque j’ai déjà une bonne idée du type de technique/outils qui peuvent être décrits dans le MITRE ATT&CK et la tactique (pour reprendre les termes du framework) où elle peut se situer. Utiliser le framework au quotidien aide, à force, à s’y repérer et à le maitriser.

    Répondre
  • Merci pour vos articles passionnants.
    Dans la « vraie vie » avez-vous déjà rencontré des sociétés qui fournissent à ses auditeurs les traces réseaux d’évènements passés ? Cela me parait un peu de la SF 😉

    Répondre
  • Bonjour,
    Merci ton commentaire :). Effectivement ça parait assez lourd d’enregistrer tous les paquets qui passent au travers un routeur, switch ou interface réseau, et ce constamment. Je n’ai jamais croisé un tel cas, mais le forensic n’est pas mon métier, donc je ne sais pas tout :).

    Je pense que des enregistrements réseau partiels peuvent être produits et utilisés suite à une suspicion ou détection préalable, on souhaite surveiller un poste ou réseau en particulier. Ou via l’utilisation d’une plateforme d’analyse de malware, qui produit aussi ce type d’enregistrement réseau.

    Répondre

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

 

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