Pass-the-hash et attaques de rejeu : quand le mot de passe n'est même plus nécessaire

Et si un attaquant n'avait même pas besoin de connaître un mot de passe pour s'authentifier à sa place ? C'est le principe troublant du pass-the-hash, une technique qui illustre pourquoi la protection des identifiants va bien au-delà de la simple robustesse du mot de passe choisi par l'utilisateur.

Le principe, en une phrase

Dans certains systèmes d'authentification, en particulier dans des environnements Windows d'entreprise, la preuve d'identité envoyée sur le réseau n'est pas directement le mot de passe, mais une valeur dérivée de celui-ci (apparentée au hachage que vous avez étudié). Si un attaquant parvient à récupérer cette valeur dérivée — par exemple en mémoire sur une machine déjà compromise — il peut, dans certaines conditions, l'utiliser directement pour s'authentifier ailleurs, sans jamais avoir besoin de connaître ni de casser le mot de passe d'origine. C'est ce qu'on appelle le « pass-the-hash » (littéralement, « faire passer le hachage » à la place du mot de passe).

Pourquoi cette technique est si redoutée

Elle bouleverse une intuition naturelle : on pense souvent que protéger un mot de passe suffit à protéger un compte. Le pass-the-hash montre que ce qui circule réellement sur le réseau pour s'authentifier peut, dans certains protocoles plus anciens ou mal configurés, être réutilisé directement. Cela rejoint un principe vu au chapitre précédent sur le pivoting : un attaquant qui obtient un premier accès (par exemple sur un poste de travail) peut y trouver de quoi s'authentifier ailleurs dans le réseau, sans jamais « deviner » quoi que ce soit.

Le lien avec le mouvement latéral

Imaginez un réseau d'entreprise fictif où le même compte administrateur local est utilisé, avec le même mot de passe, sur de nombreux postes de travail (une pratique malheureusement fréquente, pour simplifier la gestion). Si un attaquant compromet un seul de ces postes et y retrouve la valeur d'authentification de ce compte, il peut potentiellement l'utiliser pour s'authentifier sur tous les autres postes qui partagent ce même compte. Une seule machine compromise peut ainsi ouvrir l'accès à un grand nombre d'autres machines : c'est une des causes les plus fréquentes de propagation rapide d'un incident de sécurité à l'échelle d'un réseau entier.

Les attaques de rejeu, une famille plus large

Le pass-the-hash appartient à une famille plus générale : les attaques de rejeu, qui consistent à intercepter ou récupérer une preuve d'authentification valide, puis à la réutiliser telle quelle (ou presque) pour se faire passer pour l'utilisateur légitime, sans avoir besoin de connaître le secret initial. D'autres exemples de ce principe général :

• Le vol de cookie de session, vu dans le cours précédent sur le pentest web : un cookie volé permet de réutiliser une session déjà authentifiée ;
• Le pass-the-ticket, une variante propre à certains protocoles d'authentification d'entreprise, qui réutilise un jeton d'accès déjà émis plutôt qu'un hachage ;
• La réutilisation d'un jeton d'API volé ou mal protégé.

Le point commun : dans tous ces cas, la protection repose moins sur la force du mot de passe de l'utilisateur que sur la façon dont le système génère, transmet et révoque les preuves d'authentification.

Pourquoi ces protocoles plus anciens restent-ils dangereux ?

Certains protocoles d'authentification plus anciens ont été conçus avant que ce type d'attaque soit bien compris, et conservent, pour des raisons de compatibilité avec de vieux systèmes, des mécanismes qui rendent ce rejeu possible. Les protocoles plus récents intègrent des protections supplémentaires : des valeurs changeantes à chaque tentative (qui empêchent de rejouer exactement la même preuve une seconde fois), une durée de vie limitée, et des liens cryptographiques plus stricts entre la session et la machine. C'est pourquoi une recommandation très fréquente dans les audits d'infrastructures Windows est de désactiver les protocoles d'authentification obsolètes au profit des plus récents, dès que la compatibilité avec d'anciens systèmes le permet.

Les défenses concrètes, au-delà du mot de passe

• Éviter les comptes et mots de passe partagés entre de nombreuses machines : chaque poste devrait avoir des identifiants d'administration locaux uniques, générés et gérés automatiquement plutôt que fixés manuellement une fois pour toutes ;
• Limiter les comptes à privilèges élevés à ce qui est strictement nécessaire, et éviter qu'un compte administrateur de domaine se connecte sur de simples postes de travail où sa trace pourrait être récupérée ;
• Segmenter l'administration : utiliser des postes dédiés et sécurisés pour les tâches sensibles, séparés des usages courants ;
• Désactiver les protocoles d'authentification obsolètes quand la compatibilité le permet ;
• Surveiller les authentifications inhabituelles : un même compte qui s'authentifie soudainement sur un grand nombre de machines en peu de temps est un signal fort ;
• Limiter la durée de vie des sessions et jetons, et savoir les révoquer rapidement en cas de doute.

Ces recommandations rejoignent directement le principe du moindre privilège, déjà rencontré dans le premier cours du parcours, et la notion de segmentation vue dans la leçon sur le pivoting : ce ne sont jamais des sujets isolés, mais des facettes d'une même discipline de défense en profondeur.

Le point de vue du testeur : documenter sans démontrer dangereusement

Dans un audit, constater qu'un même compte administrateur local est réutilisé sur plusieurs machines est souvent suffisant pour signaler le risque, sans nécessiter de démonstration technique complète du rejeu, qui pourrait être risquée pour la stabilité du réseau client. Un rapport peut légitimement indiquer : « le compte administrateur local X utilise le même mot de passe sur un nombre significatif de postes observés (échantillon vérifié avec l'accord du client), ce qui exposerait l'ensemble de ces machines à une compromission rapide si l'une d'elles était compromise » — une formulation qui démontre la compréhension du risque sans détailler de procédure d'attaque.

À vous de jouer : évaluer un scénario fictif

Un client fictif vous explique que, pour simplifier la gestion de son parc de 200 postes, son équipe informatique a configuré le même compte administrateur local, avec le même mot de passe, sur l'ensemble des machines. Rédigez, dans votre carnet, (1) une explication en deux phrases du risque, compréhensible par une personne non technique, (2) une estimation qualitative de la gravité selon les critères du chapitre 3 (exposition, criticité, facilité d'exploitation, intérêt pour la progression), et (3) deux recommandations concrètes et réalistes pour corriger la situation sans tout reconstruire d'un coup.

Nous avons vu comment attaquer, et comprendre, les identifiants. La dernière leçon de ce chapitre change de perspective : comment, côté défense, gérer ces identifiants pour limiter structurellement ces risques ?