Investiguer sur un LLMNR poisoning et un SMB Relay avec Wireshark – Hack The Box Sherlocks : Noxious
Sommaire
I. Présentation
On se retrouve dans cet article pour une nouvelle solution de l'un des challenges d'investigation numérique/forensic nommés Sherlocks et mis à disposition par la plateforme Hack The Box. Dans cet article, nous allons détailler la démarche qui permet de résoudre le Sherlocks Noxious, de difficulté "débutant". Il s'agit d'investiguer sur les traces d'une cyberattaque ciblant un système d'exploitation Windows et un domaine AD via les protocoles LLMNR et SMB2.
Cet article sera notamment l'occasion de comprendre comment peut se dérouler concrètement une cyberattaque, et quels sont les modes opératoires des attaquants et des analystes en cybersécurité. Je vais ici vous détailler la marche à suivre en utilisant l'analyseur de paquet bien connu Wireshark, cela vous permettra de voir son utilisation dans un contexte réaliste.
Lien du challenge : Hack The Box - Sherlocks - Noxious
Cette solution est publiée en accord avec les règles d'HackThebox et ne sera diffusée que lorsque le Sherlocks en question sera indiqué comme "Retired".
| Technologies abordées | Réseau, LLMNR, SMB, NTLM |
| Outils utilisés | Wireshark |
Retrouvez tous nos articles Hack The Box via ce lien :
II. Découverte de l'archive et des journaux
Dans le cadre de l'investigation, un contexte et une archive sont mis à notre disposition :
Notre équipe informatique suspecte une cyberattaque à la suite d'une alerte concernant un trafic LLMNR anormal émise par notre IDS. L'adresse IP de la cible du trafic nous est fourni et nous devons en apprendre plus sur cette alerte.
Voici le contenu de l'archive à récupérer dans le cadre de l'analyse :
Nous commençons par ouvrir ce fichier ".pcap" (enregistrement réseau) à l'aide de Wireshark. La première chose à faire lorsque l'on a manifestement beaucoup de paquets interceptés est d'avoir une vue d'ensemble de la typologie des échanges (endpoints, protocoles, etc.) à l'aide des fonctions "Statistics" de Wireshark. Voici un exemple avec la liste et la répartition des protocoles dans la capture :
Premier élément, les paquets LLMNR de la capture ne représentent que 0,2% de l'ensemble du trafic capturé. Cela signifie certainement que, comme dans un cas réel, la majeure partie des paquets ne seront que du bruit à ignorer, et qu'il ne faudra pas pour autant passer à côté de ce qui est important dans le cadre de la cyberattaque.
III. Investigation numérique : le cas Noxious
A. Détecter une attaque LLMNR via le réseau
- Enoncé : Task 1 - Its suspected by the security team that there was a rogue device in Forela's internal network running responder tool to perform an LLMNR Poisoning attack. Please find the malicious IP Address of the machine.
Les premiers éléments de l'investigation nous orientent clairement vers une attaque utilisant le protocole LLMNR. Nous pouvons donc effectuer un filtre sur ce protocole dans Wireshark. Également, nous savons que les attaques sur le protocole LLMNR se caractérisent par l'émission de nombreuses réponses LLMNR par le poste de l'attaquant, qui va chercher à répondre à toutes les requêtes de son réseau local en se faisant passer pour tous les noms DNS demandés.
Si vous souhaitez en savoir plus sur les risques du protocoles LLMNR, les moyens de protections et de détection associés, je vous invite à consulter nos articles à ce sujet :
- IT-Connect - Active Directory : comment et pourquoi désactiver les protocoles LLMNR et NetBIOS ?
- IT-Connect - Comment détecter une attaque LLMNR poisoning sur votre réseau avec un HoneyPot
Le filtre Wireshark suivant permet de n'afficher que les paquets portant sur le protocole LLMNR et ayant un "dns.flags" à "0x80", signe d'une réponse LLMNR :
# Filtre sur les réponses LLMNR
(llmnr) && (dns.flags == 0x8000)Voici ce que j'obtiens en retour :
Nous obtenons 58 réponses LLMNR, dont 29 provenant du même hôte IPv4.
Une petite astuce sous Wireshark pour faciliter l'écriture des filtres est l'utilisation du clic droit sur l'élément à filtrer à partir d'un paquet que l'on juge intéressant, puis l'utilisation du "Apply as Filter". Nous pouvons ensuite choisir d'utiliser que ce filtre, d'en faire un filtre d'exclusion ou d'ajouter le filtre à ceux de notre requête actuelle :
Attardons-nous un peu sur les premiers éléments identifiés grâce à notre filtre, notamment la partie entourée en Orange. Dans un réseau d'entreprise, il n'est pas possible qu'un hôte ait deux noms DNS pour une même adresse IP. Hors si l'on regarde avec attention certaines des réponses LLMNR, on remarque que c'est ce que l'hôte "172.17.79.135" prétend. Il indique que son IP correspond à la fois à "DCC01", à "Forela-Wkstn001" et à "Forela-Wkstn002". C'est un indicateur fort qu'il tente de répondre à des requêtes LLMNR d'autres hôtes du réseau en souhaitant se faire passer pour tous les hôtes recherchés.
On peut donc être certain que l'hôte "172.17.79.135" est la source de l'attaque sur le protocole LLMNR
- Enoncé - Task 2 : What is the hostname of the rogue machine?
Le nom du système utilisé pour l'attaque LLMNR peut être retrouvé dans les échanges DHCP qu'il a effectués pour obtenir une adresse IP sur le réseau. En effet, le protocole DHCP permet au client d'annoncer son hostname dans les requêtes "DHCP Discover" et "DHCP Request" afin de faciliter la gestion et l'administration du réseau. J'applique donc un filtre sur le protocole DHCP dans Wireshark pour repérer ces échanges.
Cela nous permet de récupérer le nom d'hôte que l'attaquant n'a pas pensé à dissimuler : "kali".
La plupart des solutions et outils modernes de sécurité intègrent ou peuvent facilement utiliser des règles d'alerte basées sur les noms d'hôte. Au niveau du serveur DHCP ou de la surveillance du trafic réseau, l'apparition de noms comme "kali", "kalilinux" ou "commando" trahira rapidement la présence d'un attaquant peu prudent avec ce genre de règles en place.
- Enoncé - Task 3 - Now we need to confirm whether the attacker captured the user's hash and it is crackable!! What is the username whose hash was captured?
Lors de l'analyse des échanges sur le protocole LLMNR, nous avons vu apercevoir de nombreux paquets en IPv6. Il s'agit d'un élément à garder en tête pour le reste de l'analyse, car certains filtres relatifs à des attaques spécifiques peuvent différer entre IPv4 et IPv6. Notamment si on se base sur des règles de type Suricata qui cherchent une information à un offset bien précis, cela m'a value quelques minutes de doute durant l'exercice. Cela peut donc altérer notre compréhension de l'attaque.
Pour vérifier si le hash de l'utilisateur a bien été capturé puis réutilisé par l'attaquant, nous pouvons effectuer un filtre sur le protocole NTLMSSP (NT LAN Manager Security Support Provider), basé sur SMB2 et utilisé principalement pour authentifier les utilisateurs et les appareils dans des environnements Windows :
Cela nous permet de constater que la machine dont l'adresse IP termine par "c243" a tenté de rejouer le hash de l'utilisateur "FORELA\john.deacon" à de nombreuses reprises. Si l'on se fie aux adresses MAC, nous pouvons établir la correspondance suivante entre IPv4 et IPv6 :
- 00:0c:29:36:18:82 - fe80::2068:fe84:5fc8:efb7 - 172.17.79.135 (attaquant)
- 00:0c:29:85:78:cb - fe80::7994:1860:711:c243 - 172.17.79.136 (victime)
Si l'on effectue un filtre sur le protocole "smb2", les premiers échanges prouvent que le hash de l'utilisateur a bien été transmis à l'attaquant, puisque nous voyons un challenge request de l'attaquant vers la victime suivi d'un challenge response dans le sens inverse :
- Enoncé - Task 4 - In NTLM traffic we can see that the victim credentials were relayed multiple times to the attacker's machine. When were the hashes captured the First time?
Notre première partie d'analyse sur les échanges SMB2 permet de répondre à cette question, car les échanges SMB sont horodatés :
Ici, l'horodatage utilise le fuseau horaire " CEST (Central European Summer Time" qui est utilisé. Une rapide recherche sur Internet nous apprend qu'il y a un décalage de -2 heures avec l'UTC, référence généralement utilisée sur Hack The Box. L'heure exacte de la capture des identifiants est donc 2024-06-24 11:18:30.
- Enoncé - Task 5 - What was the typo made by the victim when navigating to the file share that caused his credentials to be leaked?
Comme nous l'avons vu dans notre article sur les risques du protocole LLMNR, un facteur assez fréquent qui entraine l'exploitation de l'attaquant est la saisie d'une typo sur des noms d'hôtes internes du domaine. Cela entraine l'émission d'une requête DNS, qui ne trouve pas de réponse, puis un basculement sur LLMNR ou NBNS. Dans notre contexte, nous pouvons nous intéresser aux requêtes LLMNR qui ont été effectuées par le poste de notre victime à l'aide du filtre Wireshark suivant :
# Requête Wireshark pour filter les requêtes LLMNR d'une IP précise
(llmnr && ip.src == 172.17.79.136) && (dns.flag == 0x0000)Voici ce que nous pourrons alors voir :
Nous pouvons deviner que le nom d'hôte "DCC01" était en fait "DC01" et que l'utilisateur a par erreur saisie un "C" en trop.
- Enoncé - Task 6 - To get the actual credentials of the victim user we need to stitch together multiple values from the ntlm negotiation packets. What is the NTLM server challenge value?
Il nous faut ici suivre avec attention le premier échange SMB2 qu'il y a entre la victime et l'attaquant à la suite du LLMNR poisoning. Le poste de la victime vient se connecter en SMB2 sur le poste de l'attaquant et celui-ci lui indique qu'il faut au préalable s'authentifier, ce qui entraine l'envoi d'un challenge NTLM. Challenge que le poste de la victime résout à l'aide de son mot de passe, puis il envoie la réponse à ce challenge et le poste de l'attaquant lui renvoi un "ACCESS DENIED" :
Lorsque l'on comprend comment fonctionnement ce mécanisme de challenge-response, il devient plus facile d'identifier le challenge envoyé par le serveur SMB de l'attaquant, qui est ici : "601019d191f054f1"
- Enoncé - Task 7 - Now doing something similar find the NTProofStr value.
Au cours d'un échange NTLMSSP, le champ "NTProofStr" est un élément qui représente une signature cryptographique (HMAC_MD5) générée par le client pour prouver qu’il détient le mot de passe correspondant à l'identifiant NTLM envoyé. Il est calculé lors de l'authentification NTLMv2. Nous pouvons donc rechercher dans l'échange analysé cet élément dans la réponse de la victime :
Le NTProofStr est "c0cc803a6d9fb5a9082253a04dbd4cd4".
- Enoncé - Task 8 - To test the password complexity, try recovering the password from the information found from packet capture. This is a crucial step as this way we can find whether the attacker was able to crack this and how quickly.
Pour la démonstration, j'ai utilisé l'outil PCredz afin d'extraire le hash NTLM de l'utilisateur depuis l'échange que nous venons de voir dans le fichier ".pcap" :
J'ai ensuite tenté de casser ce hash à l'aide de l'outil "johntheripper" et de son dictionnaire par défaut, ce qui a abouti assez rapidement :
Le mot de passe de l'utilisateur est : "NotMyPassword0k?"
Pour en savoir plus sur l'outil que j'ai utilisé, rendez-vous dans cet article qui lui est dédié :
Cela permet de rappeler que les preuves de compromission, les enregistrements réseau ou les logs sont aussi des données sensibles qu'il faut manipuler et stocker avec précaution.
- Enoncé - Task 9 - Just to get more context surrounding the incident, what is the actual file share that the victim was trying to navigate to?
Nous cherchons à présent à savoir quel partage l'utilisateur victime cherchait à joindre au moment de l'attaque. Nous pouvons découvrir cette information plus bas en suivant les échanges visibles dans le filtre "smb2" :
On peut noter que le poste de la victime échange ici avec le serveur "172.17.79.4", il s'agit probablement du vrai DC du système d'information.
"\\DC01\DC-Confidential"
IV. Conclusion
Cette analyse nous a permis de voir de plus près à quoi ressemble une attaque LLMNR poisoning ainsi qu'un SMB Relay, elle nous a également permis de faire un rappel sur le fonctionnement d'une authentification NTLMv2 basée sur le challenge response. Pour en savoir plus sur ces différents éléments, je vous oriente vers nos articles plus complets :
- IT-Connect - Active Directory : comment et pourquoi désactiver les protocoles LLMNR et NetBIOS ?
- IT-Connect - Comment détecter une attaque LLMNR poisoning sur votre réseau avec un HoneyPot
- IT-Connect - PCredz, récupérer des identifiants à partir d’une écoute réseau
Également, vous pouvez jeter un œil au TTP du MITRE relatif à la technique d'attaque que nous venons de voir :
Enfin, si vous voulez accéder à des cours et modules dédiés aux techniques offensives ou défensives et améliorer vos compétences en cybersécurité, je vous oriente vers Hack The Box Academy, utilisez ce lien d'inscription (je gagnerai quelques points 🙂 ) : Tester Hack the Box Academy
