Vulnérables, nos SI sont également fragiles: l’exemple de Kerberoasting
/Analyse de l’attaque Kerberoast
par Claire Loffler Security Engineer chez Vectra AI
Il faut en avoir conscience: face aux cyberattaques qui se multiplient, les systèmes d’information sont à la fois vulnérables et fragiles. Vulnérables dans la mesure où ils sont confrontés à des agressions extérieures récurrentes; fragiles également – et c’est moins connu – dans la mesure où tous les systèmes d’information (SI) sont eux-mêmes porteurs de points névralgiques qui peuvent les affaiblir en profondeur et que l’on ne peut changer.
Fragilité du système: l’exemple de Kerberoasting
Actuellement, de plus en plus de SI sont ontologiquement concernés par les fragilités. Dans ce cas, la dimension faillible émane de certaines parties de leur propre structure. Le cas de Kerberoasting est à ce sujet éloquent, et peut nous servir d’exemple.
Kerberoast est le nom d’une attaque relativement identifiée. Celle-ci permet de récupérer de nouveaux comptes au sein de l’Active Directory afin d’accéder à des services (web, bases de données, fichiers…). L’immense majorité des entreprises sont concernées, 99% d’entre elles ayant un annuaire entreprise Active Directory.
De quelle manière cette attaque opère-t-elle ? L’attaque Kerberoast vise le protocole Kerberos, du nom de ce chien polycéphale – le cerbère – issu de la mythologie grecque. Sur le plan informatique, Kerberos a été créé par le MIT (Massachusetts Institute of Technology) en 1988, avant de devenir depuis Windows 2000 le protocole d’identification par défaut.
La manière dont cette attaque se déploie est technique et exploite le fait que, avec Kerberos, tout utilisateur du domaine authentifié peut demander un ticket d’accès à un service, même s’il n’a pas le droit de s’y connecter. Ces tickets sont chiffrés en utilisant le hash NTLM du mot de passe du compte de service.
RC4: un algorithme faible
Ainsi, avec un compte d’utilisateur de domaine compromis, l’attaquant peut demander un ticket de service au contrôleur de domaine. Ce dernier répond avec un ticket de service chiffré avec la clé secrète du compte de service SPN. C’est ici que le bât peut potentiellement blesser: l’attaquant peut « spammer » un serveur Kerberos de demandes de TGS, extraire ces tickets de la mémoire et ensuite essayer de cracker offline les mots de passe, en cherchant à « casser » un algorithme appelé RC4, faible, sans avoir besoin de générer de requêtes / paquets auprès du service cible.
En cas de réussite, l’attaquant a alors en sa possession des identifiants du compte de service et peut accéder sans restriction à tous système et ressources auxquels le compte compromis a accès. Dès lors, l'attaque peut continuer à se déployer avec un accès élargi au SI.
Les attaques de type Kerberoasting exploitent une fragilité de l’architecture Kerberos. Celle-ci permet à un attaquant – avec l’accès à un compte user de domaine (que ce soit avec son mot de passe ou ticket TGT) – de demander des tickets de connexion à un service, quel qu’il soit, même si l’utilisateur n’est pas autorisé à accéder à ce service. C’est le ticket de service donné par le contrôleur de domaine à tout client authentifié qui le demande, qui est chiffré avec le hash du mot de passe du compte de service, et que les attaquants vont chercher à cracker offline.
En cas de succès, l’attaquant pourra augmenter très rapidement ses privilèges et effectuer des mouvements latéraux au sein du système d’information de l’entreprise.
Difficiles à détecter, avec une partie de l’attaque offline pour les phases de bruteforce, ces mouvements permettent au cyberattaquant de progresser jusqu’à prendre le contrôle du SI.
Des attaques subites dont on peut se prémunir
Afin de se prémunir, plusieurs actions sont possibles. Il convient en premier d’intervenir sur les comptes utilisateurs privilégiés, car ceux-ci constituent une cible prioritaire pour les attaquants. Dans la mesure du possible, il est préférable de ne pas disposer de tels comptes pouvant exécuter des services, si les droits privilégiés ne sont pas nécessaires. Par ailleurs, si le compte n’a pas vocation à être utilisé en dehors de l’Active Directory, il est préférable d’utiliser les MSA (Managed Service Accounts), qui permettent de garantir que le mot de passe du compte soit robuste et changé régulièrement et automatiquement. Et si le compte est utilisé en dehors de l’Active Directory, il convient de mettre en place un mot de passe de plus de 32 caractères. Enfin, le compte utilisateur doit être configuré pour supporter l’algorithme AES, moins vulnérable que le RC4.
On le voit bien avec le Kerberoasting, tout en étant vulnérables nos systèmes d’information sont également fragiles. La fragilité illustrée par Kerberos, loin d’être une vulnérabilité, est en réalité une simple fonctionnalité que l’on ne peut en aucun cas extraire du SI, de la même manière qu’on ôterait un agent pathogène. Parmi les moyens de se prémunir, appliquer de bonnes pratiques de sécurité (au regard des algorithmes de chiffrement des tickets, de la gestion des comptes de service...) ou encore disposer d’outils de détection de menaces internes aux réseaux est primordial. Repérer les mouvements latéraux, établir le narratif d’une attaque en vue ou l’utilisation suspecte d’un compte : la véritable solution passe nécessairement par là.
