En octobre 2023, Microsoft a réalisé une annonce charnière qui a marqué le début de la fin pour NTLM, y compris toutes ses versions. Cette décision, réitérée en juin 2024, souligne l'engagement de Microsoft à faire évoluer les développeurs vers des protocoles plus sécurisés, tels que Kerberos via le mécanisme de négociation. Le processus de dépréciation devant commencer début 2025 et s'achever d'ici 2027, le règne de longue date de NTLM touche à sa fin.
Malgré son importance historique, NTLM représente désormais un handicap considérable en matière de sécurité.. Ce blog explore les faiblesses critiques inhérentes à NTLM, les raisons de son utilisation prolongée et la transition impérative vers des systèmes plus sécurisés. protocoles d'authentification protocoles. Comprendre ces éléments est essentiel pour que les organisations puissent protéger leurs systèmes et leurs données dans un paysage numérique en évolution.
Annonce Microsoft
Microsoft annoncé en octobre 2023 son intention de déprécier toutes les versions de NTLM, y compris LANMAN, NTLMv1 et NTLMv2. Cette décision a été réaffirmée en juin 2024, soulignant que NTLM n'est plus en développement actif et exhortant les développeurs à passer à des protocoles plus sécurisés comme Kerberos via le mécanisme de négociation.
Le processus de dépréciation devrait commencer début 2025, avec des réductions progressives du soutien tout au long de l’année. D'ici mi-2026, NTLM ne sera plus disponible dans les nouvelles installations des systèmes d'exploitation de Microsoft (la possibilité de l'activer dans certains paramètres avancés n'est cependant pas vérifiée). La dépréciation totale, y compris la suppression du support existant, devrait être achevée d'ici la fin de 2027.
NTLM est un risque de sécurité
Aujourd'hui, NTLM présente des risques de sécurité importants en raison de méthodes cryptographiques obsolètes et de faiblesses bien documentées. De plus, NTLM ne dispose pas de fonctionnalités de sécurité modernes telles que authentification multi-facteurs (MFA) et validation de l’identité du serveur. En raison de ces faiblesses, les attaquants peuvent exploiter NTLM et obtenir un accès non autorisé à des ressources sensibles telles que des bases de données et des applications internes, ce qui en fait un handicap majeur.
Une ancienne version de NTLM utilisait un secret partagé (mot de passe) pour s'authentifier sur un canal non chiffré. Pour un nouvel utilisateur, il n’existe pas de protocole d’initialisation ; c'est aussi simple que « veuillez vous connecter à l'utilisateur X avec le mot de passe Y ».
Cela signifie que le protocole échange toutes les informations nécessaires pour qu'un attaquant puisse potentiellement déchiffrer le mot de passe avec une attaque par force brute au sein des messages eux-mêmes.
Pour améliorer les défauts de NTLM, le salage a été intégré au mécanisme défi-réponse de NTLMv2. En conséquence, NTLMv2 peut être considéré comme « partiellement salé » ou « non amélioré », améliorant la sécurité lors de l’authentification, mais ne traitant pas entièrement de la sécurité du stockage des hachages de mots de passe ou de la réutilisation des hachages, comme dans les attaques par relais. Dans l’ensemble, NTLMv2 n’offre pas de protection contre les attaques par relais en raison de sa capacité à réutiliser les mots de passe hachés.
La prévalence du NTLM : le dernier combat d'un héritage
Malgré ses nombreuses vulnérabilités connues, NTLM a tenu bon, tel un vieux guerrier qui refuse de prendre sa retraite. La persistance NTLM n’est pas aléatoire. À la fin des années 1990 et au début des années 2000, une vague d’applications héritées est née. Ces applications étaient souvent adaptées aux besoins uniques de leurs organisations. Cependant, au fil du temps, nombre de ces applications ont été abandonnées par leurs créateurs. Ils ont été laissés sans mises à jour ni support, mais ils sont restés essentiels pour d'innombrables entreprises.
NTLM, avec son mécanisme d'authentification simple mais robuste, est devenu la bouée de sauvetage de ces systèmes existants. Il offrait la compatibilité dont ils avaient besoin pour fonctionner dans un monde moderne qui avait depuis longtemps évolué vers des protocoles plus récents et plus sécurisés comme Kerberos.
Pour de nombreuses organisations, remplacer ces systèmes critiques était un véritable défi. La migration vers des protocoles d'authentification modernes n'était pas seulement un défi technique mais une entreprise coûteuse et complexe. Cela a nécessité une refonte approfondie de l’infrastructure et du code des applications. À mesure que le paysage de l’entreprise évoluait, son infrastructure informatique évoluait également.
De nouveaux systèmes ont été introduits, et avec eux est venue la nécessité de maintenir des relations de confiance dans un environnement multidomaine. NTLM, malgré son âge, s'est avéré être un pont fiable, assurant la continuité opérationnelle et la commodité administrative. Les mises à niveau progressives sont devenues la norme, et Le NTLM était souvent conservé comme solution de repli – un filet de sécurité lorsque de nouveaux protocoles trébuchaient.
Pourtant, les analystes en sécurité savaient que les faiblesses de NTLM en faisaient une cible privilégiée pour les attaquants. En effet, les attaques par hachage, les attaques par relais et les tentatives par force brute ne sont que trop familières dans NTLM. Ce recours à NTLM est une histoire de survie dans un monde numérique en évolution rapide, une danse délicate entre innovation et héritage.
Cependant, il convient de mentionner que NTLM n'est pas strictement un protocole d'authentification, mais plutôt un modèle conceptuel pour concevoir des mécanismes d'authentification.. Sa polyvalence lui permet de s'intégrer à divers protocoles complémentaires, tels que SMB ou CIFS pour le partage de fichiers et RPC pour l'accès RDP, ce qui en fait un modèle d'authentification robuste et adaptable.
Pourquoi NTLM règne toujours : compatibilité héritée, nécessités opérationnelles et considérations de sécurité
La mise à niveau ou la réécriture des systèmes existants entraîne des coûts et des complexités élevés, ce qui explique la persistance de NTLM. De plus, NTLM continue d'être utilisé malgré la disponibilité de protocoles d'authentification plus modernes en raison de la nature progressive des mises à niveau de l'infrastructure et de la dépendance à l'égard de systèmes non Windows et de tiers.
Voici une liste de certains des éléments clés :
Compatibilité et systèmes existants:
- Les systèmes et applications existants ont été conçus pour fonctionner avec NTLM.
- La réécriture ou la mise à niveau de ces systèmes peut être coûteuse et complexe.
- Certains systèmes et applications non Windows s'appuient toujours sur NTLM.
- Les organisations mettent souvent à niveau leur infrastructure informatique de manière progressive.
Contrôles de sécurité et assistance des fournisseurs:
- Certains fournisseurs tiers peuvent uniquement prendre en charge NTLM.
- Les organisations améliorent NTLM avec des contrôles de sécurité tels que l'authentification multifacteur et la surveillance.
- NTLM est utilisé dans des cas spécifiques tels que l'accès à distance.
- Le maintien de la continuité opérationnelle prime souvent sur l’adoption de nouvelles technologies.
Comprendre les défis de la synchronisation des mots de passe et les risques SaaS
Côté serveur, les hachages de mots de passe sont stockés en toute sécurité dans le fichier NTDS.dit sur chaque contrôleur de domaine (DC). Cependant, ces hachages sont sensibles aux attaques DCSync, une technique sophistiquée dans laquelle un logiciel malveillant se fait passer pour un DC légitime.
En exploitant cette technique, les attaquants peuvent inciter le DC à synchroniser sa base de données de hachages de mots de passe avec des logiciels malveillants tels que Mimikatz.
Cela permet à l'attaquant de récolter un ensemble complet de hachages d'informations d'identification du contrôleur de domaine, qui peuvent ensuite être utilisés pour le rachat de domaine.
La commande lsadump est utilisée pour extraire des informations sensibles telles que les mots de passe et les hachages des secrets de l'autorité de sécurité locale (LSA).
Ceci est particulièrement dangereux pour les environnements SaaS synchronisés avec des environnements sur site. Active Directory (AD) via des fournisseurs d'identité cloud (IdP) comme Entra ID. Les hachages volés peuvent être utilisés pour s'authentifier auprès des applications SaaS sans déchiffrer les mots de passe en tirant parti de l'intégration AD synchronisée. Cela autorise un accès non autorisé aux données et services commerciaux critiques dans le cloud.
Les attaquants peuvent se déplacer latéralement dans l'environnement cloud, compromettant des comptes supplémentaires et accédant à des informations sensibles. Si des informations d'identification administratives sont obtenues, elles peuvent déclencher la création d'une porte dérobée, modifier les paramètres de sécurité et maintenir un accès persistant. Cela met en évidence la nécessité d’une MFA, d’un suivi continu et du respect du principe de moindre privilège.
Exposition des vulnérabilités NTLM : accès initial, mouvement latéral et exposition aux menaces
Cette section examine les phases critiques de l'exposition, notamment la manière dont les attaquants exploitent souvent les faiblesses de NTLM lors des étapes initiales d'accès et post-exploitation, leur permettant de prendre pied, d'élever leurs privilèges et de se déplacer latéralement, amplifiant ainsi le potentiel de compromission généralisée du réseau.
Accès initial : Les attaquants obtiennent souvent un premier accès via des méthodes telles que le phishing ou l'exploitation de vulnérabilités logicielles. Une fois à l’intérieur, ils exploitent les vulnérabilités NTLM pour établir une présence sur le réseau.
Exposition post-exploitation : Après exploitation, les vulnérabilités NTLM permettent aux attaquants de maintenir et d’étendre leur accès. Cela pourrait impliquer une augmentation supplémentaire des privilèges et un déplacement latéral au sein du réseau, augmentant ainsi les dégâts.
Accès malveillant : mouvement latéral
Mouvement latéral: Avec NTLM, vous pouvez réutiliser ou rejouer le hachage sur d'autres machines plus privilégiées jusqu'à ce que vous obteniez la domination du domaine. Hors de la boîte (hacker), Kali Linux, intégré avec Metasploit exploits, peuvent être utilisés pour y parvenir.
Par exemple, dans le Cible de violation de données en 2013, les attaquants ont utilisé des informations d'identification volées pour se déplacer latéralement au sein du réseau, accédant ainsi à des systèmes sensibles et aux données des clients. Cette violation a exposé des millions de données de cartes de crédit et d'informations personnelles, soulignant les dangers des attaques par hachage. Les attaquants ont utilisé les hachages NTLM capturés pour s'authentifier et se déplacer entre les systèmes du réseau, évitant ainsi la détection et accédant à des ressources sensibles. Un autre exemple est le fameux Attaque WannaCry ransomware.
Les attaquants ont utilisé une vulnérabilité connue du protocole SMB pour propager le malware. Cela impliquait d'exploiter les faiblesses de l'authentification NTLM pour se déplacer latéralement sur les réseaux concernés. Cela leur a permis de propager rapidement le ransomware, provoquant des perturbations généralisées.
L'exposition aux menaces NTLM dévoilée
La section suivante examine l'exposition aux menaces posées par NTLM, en soulignant comment les attaquants peuvent exploiter les hachages stockés et transmis, conduisant ainsi à d'importantes failles de sécurité sur les réseaux.
Hachages NTLM stockés en mémoire
Les vulnérabilités de NTLM sont particulièrement évidentes dans la manière dont il gère et transmet les hachages, ce qui en fait une cible privilégiée pour les attaquants cherchant à compromettre la sécurité du réseau via l'extraction de mémoire, l'interception du réseau et les attaques par hachage.
Les hachages NTLM sont stockés dans la mémoire des machines authentifiées. Les attaquants peuvent utiliser des outils comme Mimikatz pour extraire ces hachages de la mémoire de la machine, leur permettant ainsi d'usurper l'identité des utilisateurs sans avoir besoin de leurs véritables mots de passe. Une fois que les attaquants ont extrait les hachages NTLM, ils peuvent effectuer une attaque par passe de hachage.
Cela implique d'utiliser le hachage pour s'authentifier auprès d'autres systèmes du réseau, leur accordant ainsi le même accès qu'à l'utilisateur d'origine. Cela peut conduire à une compromission à grande échelle du réseau si des comptes bénéficiant de privilèges plus élevés sont ciblés.
Hachages NTLM envoyés sur le réseau
L'authentification NTLM envoie des hachages sur le réseau, les rendant susceptibles d'être interceptés. En utilisant des outils de détection de réseau, les attaquants peuvent capturer ces hachages et effectuer des attaques de l'homme du milieu pour y accéder. Si les attaquants parviennent à intercepter ces hachages, ils peuvent les utiliser pour élever leurs privilèges en s'authentifiant sur des machines supplémentaires et en utilisant des outils tels que LSADUMP pour extraire d'autres informations d'identification.
NTLS a plusieurs authentifications par rapport à Kerberos
Authentification NTLM : Chaque fois qu'un utilisateur accède à une ressource différente, NTLM envoie les informations d'identification hachées sur le réseau. Cette transmission répétée de hachages offre davantage de possibilités aux attaquants de les intercepter et de les utiliser à mauvais escient.
Comme les hachages sont stockés sur chaque machine, ils sont, de par leur conception, dispersés dans tout le réseau.
Imaginez un utilisateur nommé Alice qui doit accéder à plusieurs ressources réseau telles qu'un serveur de fichiers, un serveur de messagerie et une imprimante. Pour chaque demande d'accès, le poste de travail d'Alice envoie ses informations d'identification hachées via le réseau au serveur respectif. Un attaquant utilisant un outil de détection de réseau peut intercepter ces hachages pendant la transmission. Avec suffisamment de hachages interceptés, l'attaquant peut effectuer une attaque par passe pour obtenir un accès non autorisé à d'autres systèmes en rejouant les hachages capturés.
Authentification Kerberos : Kerberos, en revanche, utilise un mécanisme d'authentification basé sur des tickets qui minimise les demandes d'authentification répétées et réduit considérablement le risque d'interception des informations d'identification. Dans Kerberos, l'utilisateur s'authentifie une fois auprès du centre de distribution de clés (KDC) et reçoit un ticket d'octroi de tickets (TGT). Ce TGT est ensuite utilisé pour demander des tickets de service pour accéder à différentes ressources sans renvoyer les informations d'identification de l'utilisateur sur le réseau.
Combattre les attaques NTLM : stratégies communes et mesures proactives
Le but de la section suivante est d'examiner les techniques liées à accès aux informations d'identification, en commençant par vider les hachages stockés en mémoire.
Lorsqu'un utilisateur se connecte ou s'authentifie auprès d'un service, ses informations d'identification sont hachées et ces hachages sont stockés dans la mémoire du système. Les attaquants utilisent fréquemment des outils tels que Mimikatz pour extraire les hachages NTLM de la mémoire d'une machine. Une fois obtenus, ces hachages peuvent être exploités dans des attaques pass-the-hash pour obtenir un accès non autorisé à d'autres systèmes du réseau.
Les attaquants commencent généralement par compromettre un système disposant de privilèges suffisants pour accéder à la mémoire LSASS (Local Security Authority Subsystem Service), où les hachages NTLM sont stockés. Exemple de hachages NTLM et SHA1 extraits à l'aide de Mimikatz.
À partir du trafic réseau : répondeur
Dans un réseau où l'authentification NTLM est utilisée, des outils tels que Responder constituent une menace importante car ils peuvent capturer les hachages NTLM du trafic réseau en usurpant les réponses des services réseau. Imaginez un scénario dans lequel un attaquant, Bob, infiltre le même segment de réseau qu'Alice, une administrateur réseau. Bob configure Responder sur son ordinateur portable pour écouter sur l'interface réseau et usurper les réponses aux requêtes NetBIOS Name Service (NBT-NS), LLMNR et mDNS.
Alors que le poste de travail d'Alice envoie des requêtes réseau pour résoudre les noms d'hôtes, Le répondeur intercepte ces demandes et prétend être le service réseau légitime. Lorsque la machine d'Alice s'authentifie auprès du service usurpé, elle envoie son hachage NTLM, que le répondeur capture. Par exemple, Responder peut afficher un hachage NTLMv2 intercepté tel que alice::CONTOSO:1122334455667788:9988776655443322:0101000000000000800000….
Armé de ce hachage, Bob peut effectuer une attaque par force brute hors ligne en utilisant des outils comme Hashcat pour déchiffrer le mot de passe d'Alice. Cependant, de manière plus efficace, il peut utiliser le hachage capturé directement dans une attaque de type « pass-the-hash » pour obtenir un accès non autorisé à d'autres systèmes du réseau en s'authentifiant sous le nom d'Alice.
Le but de la section suivante est d'examiner les techniques liées au mouvement latéral:
Exploitation du mouvement latéral hachages capturés
Passe-le-hachage: Les attaques PtH exploitent les faiblesses inhérentes à l'authentification NTLM. Les attaquants utilisent les hachages NTLM capturés pour s'authentifier auprès d'autres machines sans avoir besoin du mot de passe en texte brut.
Dans le scénario précédent, en exécutant une commande telle que pth-winexe -U 'CONTOSO\alice%1122334455667788:9988776655443322' //target-server cmd – à l'aide du kit d'outils PTH, Bob peut ouvrir une invite de commande sur un serveur cible en tant qu'Alice, en contournant le besoin du mot de passe en clair. Cela peut être fait à l'aide de divers outils prenant en charge l'authentification par hachage NTLM, tels que pth-winexe ou pth-smbclient.
Relais NTLM: Une attaque par relais NTLM consiste à intercepter une demande d'authentification NTLM d'un utilisateur et à la relayer vers un serveur cible pour obtenir un accès non autorisé. L'attaquant capture le hachage NTLM et l'utilise pour s'authentifier auprès d'un autre système en tant qu'utilisateur légitime, exploitant les relations de confiance au sein du réseau.
Il utilise un outil tel que ntlmrelayx pour relayer le hachage NTLM capturé vers un autre serveur du réseau qui fait confiance à l'authentification NTLM. Ce serveur, ignorant l'interception, traite l'authentification comme si elle provenait véritablement de l'utilisateur d'origine.
Utilisation d'un mot de passe déchiffré
Connexion directe -> Sur site: Les mots de passe NTLM déchiffrés permettent aux attaquants de contourner les mesures de sécurité et d'accéder directement aux systèmes sur site. Les attaquants peuvent extraire et déchiffrer les hachages NTLM des machines compromises à l'aide d'outils tels que Mimikatz.
Les mots de passe décryptés de cette manière peuvent être utilisés pour des connexions directes via le protocole de bureau à distance (RDP) ou le shell sécurisé (SSH), permettant un mouvement latéral à travers le réseau avec des informations d'identification légitimes, contournant ainsi efficacement l'authentification multifacteur - en supposant qu'elle ne soit activée que lors de la connexion initiale.
Connexion directe -> SaaS: Dans les environnements où les mots de passe NTLM sont synchronisés entre les systèmes sur site et les applications SaaS, les mots de passe déchiffrés constituent une menace importante. Les services cloud tels qu'Office 365, Salesforce et Google Workspace sont accessibles à l'aide de ces informations d'identification. Cela élargit le surface d'attaque au-delà du réseau d'entreprise pour inclure les ressources cloud, augmentant ainsi l'impact potentiel de la violation. Par exemple, le déchiffrement du mot de passe NTLM d'un administrateur à partir de l'environnement sur site permet aux attaquants d'accéder aux services cloud de l'organisation avec le même niveau de privilèges.
Cela souligne la nécessité de pratiques de chiffrement robustes, de contrôles d’accès stricts et d’une MFA sur tous les services pour se protéger contre la compromission des informations d’identification NTLM.
En raison de la nature unidirectionnelle des hachages NTLM, il n'est pas possible de déchiffrer directement les mots de passe en clair à partir des hachages NTLM. Il est possible d'exploiter ces hachages à l'aide de techniques comme les tables arc-en-ciel ou d'attaques par force brute à l'aide d'outils comme Hashcat.
De la capture de l'accès aux informations d'identification au mouvement latéral
Imaginez le scénario suivant : Bob, un attaquant expérimenté, décide d'exploiter la dépendance d'une entreprise à l'égard de NTLM pour l'authentification réseau. Il installe son ordinateur portable sur le même segment de réseau et configure Responder pour capturer les demandes d'authentification NTLM en écoutant sur l'interface réseau. Alors que des employés comme Alice tentent d'accéder aux ressources du réseau, Responder intercepte ces demandes et capture leurs hachages NTLM.
Avec ces hachages en main, Bob utilise ntlmrelayx pour les relayer vers un serveur cible de grande valeur à l'adresse IP 192.168.1.10. En exécutant ntlmrelayx.py -t smb://192.168.1.10, Bob transmet effectivement le hachage capturé d'Alice au serveur, qui accepte naïvement l'authentification et lui accorde l'accès comme s'il était Alice. Cela permet à Bob d'explorer les partages de fichiers du serveur et d'extraire potentiellement des informations sensibles, démontrant le risque grave posé par les attaques par relais NTLM dans un environnement réseau non protégé.
Gagner en visibilité sur l'utilisation de NTLM
Pour se protéger contre toutes les façons dont les attaquants peuvent exploiter NTLM, les organisations doivent d'abord gagner en visibilité sur où et comment NTLM est utilisé au sein de leurs réseaux. Cela implique d'identifier tous les systèmes et applications qui s'appuient sur NTLM pour l'authentification. Des audits réguliers du réseau et des outils de surveillance peuvent contribuer à obtenir cette visibilité.
Silverfort améliore la visibilité NTLM en intégrant sa plateforme pour surveiller et protéger toutes les authentifications au sein de l'environnement d'une organisation. Ce faisant, Silverfort fournit une visibilité en temps réel et une analyse des risques de l'authentification NTLM, permettant aux organisations de détecter et d'atténuer efficacement les menaces potentielles. SilverfortLe moteur d'analyse des risques basé sur l'IA surveille en permanence les tentatives d'accès, créant des lignes de base comportementales détaillées pour chaque utilisateur. Cela aide à identifier les activités anormales et les risques potentiels associés aux authentifications NTLM.
Réduire la dépendance à NTLM Des efforts doivent être faits pour réduire l'utilisation de NTLM au strict minimum. La transition vers des protocoles d'authentification plus sécurisés, tels que Kerberos ou des mécanismes d'authentification modernes basés sur le cloud, peut atténuer les risques liés au NTLM. Microsoft recommande d'utiliser le protocole Négocier, qui donne la priorité à Kerberos et revient à NTLM uniquement lorsque cela est nécessaire.
Améliorez la sécurité de votre organisation en obtenant une visibilité claire sur l'utilisation de NTLM tout en identifiant où NTLM est utilisé et prenez des mesures pour minimiser sa dépendance en passant à des protocoles d'authentification plus sécurisés.
NTLM est-il une surface d’attaque que vous souhaitez traiter ? Planifiez une rencontre avec un de nos experts ici.