Connect the dots #7: « Elévation de privilèges »

Le but principal de toute cette activité de beaconing que nous avons vue lors de la post-exploitation, consiste a obtenir l'accès à un compte à privilèges, à savoir un compte d'administration de l'annuaire (Active Directory dans la plupart des cas). Cette action, appelée "élévation des privilèges", permet de passer des droits d'utilisateur sur une machine lambda au contrôle total d'un système d'informations, en créant un moyen d'accéder en permanence à distance à toutes les machines, y compris celles qui ne sont pas contaminées !

Comment se passe cette élévation de privilèges ?

Il s'agit notamment de trouver les mauvaises configurations de l'AD ou bien des mots de passe faibles de certains admins existants, et de les utiliser à leur insu. Pour cela il est important de comprendre comment fonctionne l'authentification à un système d'informations de nos jours: On utilise le protocole "Kerberos", c'est un nom qui provient de la mythologie grecque, d'un chien "Cerbère" à plusieurs têtes qui gardait l'entrée des enfers, empêchant les morts de s'en évader ou aux vivants d'y entrer… Hercule lors de ses "12 travaux" est celui qui les a vaincus. Dans notre cas, il s'agit du système de protection des accès au "royaume" (realm) du contrôleur de domaine (DC- Domain Controller) de notre système d'informations…

(c) Manga Zombie – Emeraude1977

Kerberos fonctionne avec un système de "tickets" créés par un chiffrement symétrique en utilisant le hash unique de chaque utilisateur. Un hash (condensat en français, mais tout le monde dit "hash") est un chiffrement, en principe irréversible mathématiquement, qui génère une chaine de caractères unique en partant d'une autre chaine. Par exemple, en très simplifié, "lenetwizz" calculé sur le poste client en RC4 (un système de hash très répandu) donne ad f3 2f fa 98 92 fe 75 2b, avec un mot de passe "AAA" que vient de saisir l'utilisateur.  Le contrôleur de domaine va faire le même calcul de son côté et, si les deux résultats de calcul du hash coïncident, alors un ticket émis par le service TGS (Ticket Granting Service) va être remis à la station cliente pour l'autoriser à accéder à ce à quoi l'utilisateur à droit. Les deux intérêts de ce système, par rapport à simplement transmettre le mot de passe sur le réseau jusqu'à un serveur, est primo que l'interception du mot de passe en clair n'est pas possible (le fameux Man in the Middle) et deuxio qu'à chaque session on va changer de ticket en réémettant un nouveau ticket, ce qui va éviter les attaques par "rejeu" en s'appuyant sur l'heure précise incluse dans le ticket (timestamp). C'est pour cela d'ailleurs que les serveurs de temps sont fondamentaux à protéger, pour éviter que les attaquants ne modifient l'heure pour "revenir dans le passé" et rejouent un ticket qui sera alors valable pour déverrouiller la session de l'utilisateur. Les attaquants vont donc activer les beacons pour récupérer des tickets kerberos et retrouver le mot de passe. Tout est une question de temps: plus le mot de passe est faible, plus ça sera facile. Le "kerberoasting" consiste à récupérer des tickets kerberos puis à les craquer. On commence par faire un dump (une récupération massive) des identifiants et des hash associés avec un outil comme Mimikatz. Ce "travail" peut se faire à distance une fois le fichier "hash" évadé vers le C2. 

Lors de la phase de post-exploitation les attaquants listent ainsi tous les SPN (Service Principal Names) des contrôleurs de domaine qui contiennent les "couples" TERMSRV/DC. TERMSRV est un service qui est actif sur un contrôleur de domaine. Ils font ensuite une requête kerberos normale et récupèrent un ticket. Enfin, ils cassent les hash avec un outil approprié. Notez bien que plus le mot de passe est faible, plus c'est facile à craquer. Je reproduis ici un tableau du SCSP Community pour prendre conscience du problème:

Si vous avez des mots de passe de 8 caractères, avec juste des lettres et des chiffres sans aucun caractère spécial, on parle d'un délai d'une heure avant de se faire craquer ! 9 heures dans le cas où vous avez un caractère spécial dans le mot de passe… Or cela fait des jours, voire des semaines que l'accès initial a eu lieu et que les attaquants ont eu tout loisir de lancer leur décryptage. 

La conséquence immédiate est de devoir remonter la taille et la complexité des mots de passe de tous vos personnels informatiques et des tous les comptes à privilèges. 12 caractères, avec au moins un caractère autre que des chiffres et des lettres parait suffisant pour le moment. 

On doit tenir compte aussi de l'algorithme de chiffrement lui-même: Jusqu'à Windows Server 2012 on utilisait RC4. Mais avec les versions en AES des serveurs récents de Microsoft c'est beaucoup plus difficile à casser. RC4 utilise 40 bits alors que AES 128 bits, 192 bits ou 256 bits. De plus RC4 a été cassé officiellement en 1995 par Adam Back, Eric Young et David Byers, alors que AES non (en tous les cas pas de manière publique).

Il faut également empêcher les attaquants d'utiliser une faille du système Active Directory pour réussir à récupérer les hash des utilisateurs. Il faut donc auditer d'urgence la sécurité de l'AD et colmater toutes les brèches. Des outils existent pour cela comme PingCastle ou Alsid. La deuxième action immédiate est donc de mettre à niveau les serveurs hébergeant les contrôleurs de domaine vers des versions récentes de Windows Server. Mais il faut aussi que de "vieux" ordinateurs puissent s'y connecter ce qui ne sera pas possible avec notamment Windows XP… Il faut donc également mettre à niveau toutes vos machines clientes en Windows10 ou bien passer en "mode terminal" par la virtualisation du système. Nous en parlerons dans le dernier article de la série sur le "Zero Trust". En attendant, on va donc rester avec le RC4 et l'AES, en cohabitation…

Ce n'est pas tout, il faut également traquer et empêcher l'installation de keyloggers, c'est à dire des outils qui vont récupérer les frappes clavier notamment lorsque l'utilisateur se connecte à sa session, car sinon, quelles que soient la longueur et la complexité du mot de passe, c'est "game over"…

Détection et blocage du kerberoasting

Comme le kerberoasting utilise simplement le protocole kerberos, ce n'est pas une activité anormale que l'on peut extraire parmi les activités d'accès légitime des utilisateurs. Aussi, il faut analyser les logs en temps réel (si possible avec une IA/ML) pour repérer les utilisateurs/postes qui ont une activité anormalement importante. Ensuite il faut voir si c'est légitime ou pas, par exemple un automate qui fait des virements, mais qui échoue sans cesse pour cause de changement du mot de passe du compte.

Le deuxième point à repérer est le protocole lui-même. La plupart des attaquants (à part les équipes du niveau d'un Etat) vont aller au plus simple et utiliser RC4 beaucoup plus facile à craquer que AES. L'activité vue dans les logs sera donc RC4 alors que la plupart de vos machines (à part Windows XP et Windows 2003 Server) vont se connecter avec AES. 

La troisième tactique consiste à créer un faux compte admin (un pot de miel) qui n'est pas utilisé. S'il commence à émettre des demandes de tickets c'est que quelque chose d'externe tente un kerberoasting…

Tout ceci demande à outiller en temps réel les logs des contrôleurs de domaine et notamment son activité d'authentification par kerberos. Il est également clair que la réduction au strict minimum de la liste des administrateurs du domaine et le renforcement de leurs mots de passe est une action évidente.

A ce stade; les attaquants ont donc réussi à faire un dump des hash de tous les mots de passe des utilisateurs et ont craqué les plus faibles avec un outil approprié. Mais ce n'est pas fini !

Golden ticket.

(c) Warner Bros 

Au lieu de se contenter d'avoir le mot de passe d'au moins un admin du domaine, ils vont se créer un "passe" permanent qui fonctionnera, même si on s'aperçoit de l'attaque et que l'on change les mots de passe. Comme dans le film "Charlie et la Chocolaterie" ce "ticket doré" va permettre aux attaquants d'accéder à la totalité des composants du système d'informations sans avoir besoin de s'authentifier à nouveau. C'est le fameux outil Mimikatz qui, une fois installé, permet cette attaque. Le chercheur Français en cybersécurité Benjamin Delpy a mis au point et dévoilé cet outil et, cela pourrait faire facilement un bon scenario de film…

https://www.wired.com/story/how-mimikatz-became-go-to-hacker-tool/

Une fois l'utilisateur authentifié, un PAC (Privilege Attribute Certificate) permet d'associer des droits correspondants à l'utilisateur. C'est comme un badge qui ouvre certaines portes et pas d'autres, en fonction de comment il a été programmé. On appelle un "silver ticket" le fait de fabriquer un ticket valide pour accéder à une ressource qui normalement aurait été délivrée par le service TGS (ticket granting service) que nous avons vu plus haut. C'est possible si on a récupéré préalablement la clef de session unique de ce compte de service. Tout ceci se passe par une requête à KRB_TGS (kerberos ticket granting service) et sa réponse. En résumé: 1- L'attaquant vole un hash du compte de service. 2- Il fabrique un PAC valide avec. 3-Il s'authentifie auprès du service visé. 

Par rapport au "silver ticket", le "golden ticket" est une amélioration sous forme de "passe" universel qui s'obtient en piratant le compte spécial "KRBTGT": L'attaquant va fabriquer un ticket avec comme information que l'utilisateur fait partie du groupe "Administrateurs du domaine". Et voilà…

Le golden ticket va permettre aux attaquants d'accéder à n'importe quelle ressource de manière autorisée et sans se faire repérer. Ce qui est terrible est que même si vous changez le mot de passe du compte KRBTGT, le golden ticket reste valable, car tous les tickets kerberos déjà émis resteront valides, en étant "rafraichis" juste avant leur expiration (en général toutes les 10 heures)… 

Comment contrer l'attaque Golden Ticket ? 

1- Trouvez et empêchez à tout prix l'exécution des outils comme Mimikatz. Pour cela, il faut installer sur chaque poste de travail et serveur, un EDR antiviral de manière à ce qu'ils soient le premier élément de défense. (Consultez mon article "Connect the dots #4, sur l'accès initial).

2- Protégez vos contrôleurs de domaine comme les "Bijoux de la Couronne". Mettez en place un outil d'audit, de supervision et de protection de l'AD. Corrigez toutes les failles de l'AD le plus vite possible. Limitez les accès à cet AD par très peu de comptes admin et à travers un "bastion d'administration" qui va journaliser et enregistrer tous les accès. 

3- Journalisez tous les changements de privilèges au niveau de l'AD. Analysez tous les changements et demandez des clarifications aux admins dans le cas où vous avez un doute. Faites vous aider par une IA/ML.