Une nouvelle variante du botnet "TheMoon" a été repéré dans 88 pays différents sur des milliers de routeurs, notamment de la marque ASUS, et des appareils IoT. Faisons le point sur cette menace.
Les chercheurs en sécurité de Black Lotus Labs ont surveillé de près la dernière campagne de TheMoon, qui s'est déroulée en mars 2024, et les chiffres sont élevés : en 72 heures, ce botnet est parvenu à compromettre 6 000 routeurs ASUS. Plus globalement, voici ce que précise le rapport au sujet de l'activité de TheMoon : "Alors que Lumen a déjà documenté cette famille de logiciels malveillants, notre dernier suivi a montré que TheMoon semble permettre la croissance de Faceless à un rythme de près de 7 000 nouveaux utilisateurs par semaine."
En effet, les appareils compromis par le botnet TheMoon sont ensuite exploités par le service proxy "Faceless" auquel il est lié. Ce service s'appuie sur les appareils infectés pour les utiliser comme proxy afin de masquer le trafic généré par les cybercriminels. Ainsi, ceci permet aux cybercriminels, notamment ceux des groupes IcedID et SolarMarker, de masquer leurs activités malveillantes.
TheMoon n'est pas une nouvelle menace puisqu'il a été repéré pour la première fois en 2014. À cette époque, il ciblait particulièrement les équipements LinkSys. Lors de la première semaine de mars, il y a eu une importante vague d'attaques à destination des routeurs ASUS.
Les routeurs ASUS, une cible privilégiée
Les chercheurs de Black Lotus Labs ne précisent pas comment les routeurs ASUS ont pu être compromis, mais il s'agirait de modèles qui ne sont plus pris en charge par le fabricant. Il est fort probable que des failles de sécurité connues et non corrigées soient exploitées par le botnet, ou que la technique du brute force soit utilisée : ces routeurs sont susceptibles d'être mal configurés et le compte admin par défaut pourrait fonctionner dans certains cas...
Lorsqu'un appareil est compromis, le logiciel malveillant part à la recherche d'un shell avec lequel il est compatible : "/bin/bash," "/bin/ash," ou "/bin/sh". Si c'est le cas, le chargeur télécharge, déchiffre et exécute un payload nommé ".nttpd" sur l'appareil. Ensuite, des règles de filtrage sont créées via iptables pour bloquer les flux entrants sur les ports 8080 et 80 en TCP, sauf pour des plages d'adresses IP spécifiques. Ceci permet aux attaquants d'être les seuls à pouvoir exploiter cet appareil à distance, notamment via le service de proxy. Enfin, TheMoon établit une connexion aux serveurs C2 pilotés par les attaquants et il est en attente de recevoir des instructions.
Si vous constatez des problèmes de stabilité, de performances ou des paramètres qui ont changé sur votre routeur ou un appareil IoT, il se pourrait que vous soyez victime de ce botnet, notamment si vous utilisez un routeur ASUS.
Grâce à l'entrée en vigueur du Digital Markets Act, Opera affiche une énorme croissance de 402% sur iPhone, en France ! Il s'agit d'une alternative à Safari qui semble séduire les utilisateurs de smartphones Apple.
Le 6 mars 2024, le Digital Markets Act (DMA) est entré en vigueur et les géants de la tech ont dû s'y préparer : que ce soit Google, Amazon, Microsoft ou encore Apple. D'ailleurs, sur les smartphones sous Android et iOS, Google et Apple doivent permettre à l'utilisateur de choisir facilement un navigateur tiers. Autrement dit, si nous prenons le cas de l'iPhone, Apple ne doit pas imposer Safari. Sur Android, il s'agit d'avoir le choix d'utiliser autre chose que Google Chrome. L'objectif étant d'offrir aux utilisateurs une certaine liberté, et surtout, de pouvoir faire ses choix de façon simple.
Bien que de nombreux utilisateurs d'iPhone aient pris la décision de poursuivre l'aventure avec Safari, d'autres, quant à eux, ont choisi d'utiliser un autre navigateur. En effet, il y a du choix : Brave, Mozilla Firefox, ou encore Opera. Au total, il y a une petite dizaine d'alternatives proposées.
Au mois de mars, le grand gagnant, c'est Opera : il affiche une croissance de 402% sur iOS, rien qu'en France. Chez nos voisins européens, il y a également une belle évolution pour Opera : +143% en Espagne, +68% en Pologne et +56% en Allemagne. Sur Android, Opera a également progressé : "Opera pour Android a également connu une croissance significative, en particulier en France, où le nombre de nouveaux utilisateurs a augmenté de 54 % le jour où le Ballot Screen a commencé à être introduit.", peut-on lire dans l'article de presse d'Opera.
De façon globale, sur desktop et mobile, Opera reste moins utilisé que certains navigateurs comme Google Chrome, Microsoft Edge et Safari, c'est un sérieux coup de pouce pour ce navigateur qui se démarque par certaines fonctionnalités intéressantes pour la confidentialité en ligne.
D'ailleurs, dans son article de presse, Opera en profite pour rappeler certaines de ces fonctionnalités disponibles sur mobiles : "Opera pour Android et Opera pour iOS sont des navigateurs puissants qui offrent une expérience rapide, sécurisée et centrée sur l'utilisateur. Tous deux proposent des fonctions de confidentialité avancées, telles qu'un VPN gratuit et sans connexion, ainsi qu'un bloqueur de publicités, un bloqueur de traqueurs et un bloqueur de fenêtres pop-up et de cookies intégrés."
Par ailleurs, certains utilisateurs ont pris la décision de s'orienter vers d'autres navigateurs. Du côté de Brave, le nombre d'installations quotidiennes est passé de 8 000 à 11 000 à partir du 9 mars 2024.
Vous utilisez Microsoft Edge sur Windows Server et il se ferme au bout de quelques secondes ? Sachez que vous n'êtes pas le seul et que ce problème serait lié à la version 123 du navigateur Edge. Faisons le point sur ce problème.
La Build 123.0.2420.53 de Microsoft Edge semble donner du fil à retordre aux administrateurs systèmes qui exploitent ce navigateur sur Windows Server. En effet, cette version ne semble pas fonctionner correctement : une page blanche s'ouvre au démarrage, puis quelques secondes plus tard, le navigateur se ferme tout seul. Ceci peut s'avérer très problématique sur certains serveurs, notamment les hôtes de sessions Bureau à distance (RDS) où les utilisateurs se connectent directement !
Ce problème fait suite à l'installation de la version 123.0.2420.53 sur Windows Server. Une version disponible depuis quelques jours sur Windows et Windows Server puisqu'elle a introduit le canal Stable de Microsoft Edge le 23 mars 2024.
Comment résoudre ce problème ?
Actuellement, la solution consiste à revenir en arrière, c'est-à-dire sur une version antérieure de Microsoft Edge. D'ailleurs, sur le forum de Microsoft une ligne de commande a été fournie par un utilisateur pour expliquer comment revenir en arrière à partir du package MSI d'une précédente version d'Edge grâce à l'utilisation du paramètre "ALLOWDOWNGRADE=1" :
msiexec /I Microsoft Edge_122.0.2365.106_Machine_X64_msi_en-US.msi ALLOWDOWNGRADE=1
Vous pouvez télécharger la version de Microsoft Edge de votre choix à partir de cette page. Sur la page du forum Microsoft, l'agent qui a répondu confirme que d'autres utilisateurs ont rencontré ce problème ! D'ailleurs, ces dernières heures, Microsoft a retiré cette mise à jour de son catalogue et elle n'est plus distribuée via WSUS: preuve qu'il y a un réel problème avec celle ! En attendant, si elle est déjà passée sur vos serveurs, vous risquez de rencontrer ce problème !
Et vous, rencontrez-vous ce bug sur Windows Server ?
PS : merci à Fabien Guérout de chez Délibérata (un ancien collègue !) de m'avoir signalé ce dysfonctionnement et confirmé que le downgrade vers une version antérieure permettait de corriger ce problème !
Tycoon 2FA, c'est le nom d'une plateforme de Phishing-as-a-Service (Phaas) utilisée par les cybercriminels pour cibler les utilisateurs de Gmail (Google) et de Microsoft 365, tout en outrepassant l'authentification à deux facteurs. Voici ce qu'il faut savoir sur ce kit redoutable !
En octobre 2023, les analyses de Sekoia ont fait la découverte de Tycoon 2FA pour la première fois. Néanmoins, les pirates du groupe Saad Tycoon en font la promotion sur un canal Telegram privé depuis août 2023.
Comme le soulignent les équipes de Sekoia dans un nouveau rapport, ce kit de phishing prêt à l'emploi est en pleine évolution et une nouvelle version a été publiée en 2024 : plus efficace et plus furtive, notamment l'ajout de capacités de détection et de blocage des bots. Actuellement, Tycoon 2FA exploite 1 100 domaines et a été utilisé pour mettre au point des milliers d'attaques de phishing.
Afin de pouvoir contourner l'authentification multifacteur et voler les informations d'identification des utilisateurs, Tycoon 2FA doit intercepter les données de la victime et les transmettre au service légitime. Pour atteindre cet objectif, la plateforme Tycoon 2FA intègre un reverse proxyqui va se positionner entre l'ordinateur de la victime et le service sur lequel elle va se connecter.
Un processus bien rôdé, en 7 étapes
Ainsi, actuellement en mars 2024, une attaque Tycoon 2FA se déroule en 7 étapes distinctes :
Étape 0 : les attaquants diffusent des liens malveillants par l'intermédiaire d'une campagne de phishing (e-mails malveillants) ou des QR codes piégés, dans le but d'amener la victime vers la page falsifiée.
Étape 1 : lorsqu'un utilisateur clique sur l'URL contenue dans l'e-mail, ou qu'il scanne le QR code, il est redirigé vers une page intégrant un défi Turnstile de Cloudflare afin de filtrer le trafic indésirable.
Étape 2 : cette étape n'est pas visible pour l'utilisateur, car elle exécute un code JavaScript en arrière-plan et redirige ensuite l'utilisateur vers une autre page en fonction de la présence d'une adresse électronique.
Étape 3 : cette étape est également invisible pour l'utilisateur qui sera redirigé automatiquement vers une autre page contrôlée par les cybercriminels.
Étape 4 : l'utilisateur se retrouve face à une fausse page de connexion Microsoft qui est utilisée par les attaquants pour voler les informations d'identification. WebSockets est utilisé pour l'exfiltration des données.
Étape 5 : c'est à ce moment-là que, si nécessaire, Tycoon 2FA va utiliser du code JavaScript pour proposer un défi 2FA à l'utilisateur, en relayant et en prenant en charge plusieurs méthodes (Notification sur Microsoft Authenticator, code à usage unique via une application, SMS ou par appel téléphonique). Il interceptera les informations de validation émises par l'utilisateur pour compléter le challenge MFA.
Étape 6 : fin du processus, l'utilisateur est redirigé vers une page déterminée par les cybercriminels. Le site de Microsoft, dans certains cas.
Au sujet de l'étape n°5, Sekoia précise : "À l'aide de serveurs proxy commerciaux, les pages d'hameçonnage Tycoon 2FA transmettent les données de l'utilisateur, notamment l'adresse électronique, le mot de passe et le code 2FA, à l'API d'authentification légitime de Microsoft. La réponse au trafic de l'API Microsoft renvoie les pages et les informations appropriées à l'utilisateur." - Ce qui montre l'efficacité de Tycoon 2FA et prouve que c'est un kit prêt à l'emploi très évolué.
Source : Sekoia
Les affiliés de Tycoon 2FA ont accès à un véritable tableau de bord d'administration au sein duquel ils peuvent visualiser les identifiants collectés avec l'identifiant, le mot de passe, l'état du MFA, ainsi que la possibilité d'obtenir des cookies d'authentification prêts à l'emploi.
Un ensemble de domaines malveillants est associé à l'utilisation du kit Tycoon 2FA. Vous pouvez retrouver la liste sur le GitHub de Sekoia, sur cette page.
Tycoon 2FA, une plateforme massivement utilisée par les pirates
Sekoia a pu analyser le portefeuille de cryptomonnaie utilisé par le groupe de cybercriminels à l'origine du kit Tycoon 2FA. Depuis août 2023, il y a eu 700 transactions entrantes d'une valeur moyenne de 366 dollars, soit plus de 256 000 dollars. Les analystes indiquent également que 530 transactions ont dépassé 120 dollars, ce qui correspond au tarif pour accéder à la plateforme PhaaS pendant 10 jours.
"En supposant que le portefeuille est principalement utilisé pour les opérations PhaaS de Tycoon 2FA depuis août 2023, le montant total des transactions suggère que plusieurs centaines de kits Tycoon 2FA ont été vendus 'as a service' sur une période de six mois.", peut-on lire.
Dans cet article, nous allons comprendre, exploiter et corriger une vulnérabilité fréquente sur les environnements Active Directory : ASREPRoast.
Ce nom ne vous dit peut-être rien, mais il s'agit d'un défaut de configuration fréquent dans l'Active Directory. L'attaque ASREPRoast permet à un attaquant situé sur un réseau d'entreprise possédant un domaine de compromettre rapidement un compte utilisateur, et ainsi de passer d'un mode opératoire boite noire (attaque sans identifiants valides, juste une connexion au réseau) à un mode boite grise (attaque depuis un compte valide sur le domaine). Le passage d'un mode boite noire à boite grise change en général la donne de façon très importante lors d'une cyberattaque, car l'accès authentifié au domaine permet d'en extraire beaucoup d'informations.
L'objectif de cet article est de vous expliquer en détail cette vulnérabilité. Nous allons notamment voir comment elle peut être introduite sur un Active Directory, comment un attaquant peut l'exploiter et comment un défenseur peut l'identifier et la corriger.
C'est parti !
II. Qu'est-ce que l'attaque ASREPRoast ?
A. Dans les grandes lignes
Commençons par essayer de comprendre le nom de l'attaque. "ASREP" fait référence au message "KRB-AS-REP" du service Kerberos lors d'une authentification (réponse à un message KRB-AS-REQ, une requête d'authentification Kerberos). "Roast" renvoi simplement au mot "rôtir" ou "cuisiner" car l'on devra ensuite travailler un peu sur la donnée obtenue pour pouvoir l'utiliser.
Au sein d'un domaine, l'authentification Kerberos est assurée par le composant Key Distribution Center (KDC) des contrôleurs de domaine. Lorsqu'un utilisateur souhaite accéder à un service ou à une ressource réseau, il doit d'abord obtenir un Ticket Granting Ticket (TGT) auprès du KDC. Pour cela, l'utilisateur envoie une requête de type "KRB-AS-REQ" (Kerberos Authentication Service Request) au KDC, elle contient notamment des informations d'identification de l'utilisateur et une clé liée à son mot de passe.
Le KDC vérifie alors les informations d'identification fournies par l'utilisateur. Si celles-ci sont correctes et que l'utilisateur existe dans le domaine, le KDC lui délivre un TGT. Ce TGT est ensuite utilisé par l'utilisateur pour obtenir des tickets de session (TGS) lui permettant d'accéder aux différents services réseau sans avoir à fournir à nouveau ses informations d'identification. Ce processus s'appelle pre-authentification.
Schéma d'une authentification Kerberos et de l'émission d'un TGT.
Cependant, il existe une configuration spécifique représentée par un attribut sur les comptes utilisateurs appelé "Do not require Kerberos preauthentication". Cet attribut autorise l'envoi d'un TGT pour un compte sans que le demandeur ait prouvé son identité au préalable.
Schéma de l'émission d'un TGT pour un utilisteur ayant l'attribut "Do not require Kerberos preauthentication".
En conséquence, n'importe qui sur le réseau peut obtenir un TGT représentant ce compte utilisateur et tenter d'usurper son identité. Il est important de noter que le TGT obtenu ne peut être utilisé que si la personne qui le détient connaît le mot de passe du compte associé. Cependant, en cas d'utilisation d'un mot de passe faible, le contenu du TGT peut être utilisé pour retrouver le mot de passe du compte utilisateur.
Le TGT ne contient pas directement le mot de passe de l'utilisateur. Mais, il contient des informations chiffrées grâce au secret de l'utilisateur, qui sont utilisés pour prouver l'identité de l'utilisateur lorsqu'il demande des tickets de session ultérieurs. Ainsi, des "traces" du mot de passe s'y trouve, ce qui permet de tenter de casser le TGT pour retrouver le mot de passe en clair.
Regardons à présent dans le détail ce qu'il se passe lors d'une authentification via Kerberos. Pour cela, j'ai effectué une capture réseau des échanges dans différents cas de figures.
AS-REQ pour un login inexistant
Lorsqu'un utilisateur souhaite s'authentifier auprès du service Kerberos, le client envoi dans un premier temps un message de demande d'authentification ("KRB-AS-REQ"), voici à quoi il ressemble sur une capture réseau (cliquez sur l'image pour zoomer) :
"AS-REQ" suivi d'une erreur "ERR_C_PRINCIPAL_UNKNOWN".
Dans le cas d'une demande d'authentification avec un login incorrect, c'est-à-dire qui n'existe pas dans l'Active Directory, le service Kerberos renvoi un message de type "KRB-ERROR : C-PRINCIPAL-UNKNOWN" en réponse à l'AS-RE" du client. Le message est clair : l'utilisateur "MMARTIN1" n'existe pas dans l'Active Directory.
AS-REQ pour un login existant avec pré-authentification
Si le login est correct, le service renvoi une réponse de type "KRB-ERROR : PREAUTH REQUIRED". Cette réponse du service Kerberos indique que pour obtenir un TGT pour cet utilisateur, il faut au préalable s'authentifier, ce qui est plutôt une bonne nouvelle d'un point de vue sécurité. Rappelons que les TGT sont des tickets qui permettent de demander des TGS (Ticket Granting Service) pour accéder à un service au nom de l'utilisateur présenté dans le ticket. Il est donc préférable de prouver son identité (s'authentifier) au préalable.
À noter que cette différence de comportement dans la réponse du service ("PRINCIPAL_UNKNOWN "ou "PREAUTH REQUIRED") permet une énumération des utilisateurs basée sur un dictionnaire. Sans même connaitre le mot de passe associé à un compte, on peut savoir s'il existe dans l'annuaire, car le service Kerberos nous indiquera clairement cette information dans sa réponse.
Voici à quoi rassemble une réponse "PREAUTH_REQUIRED". Suite à cette réponse, notre client s'authentifie envoyant un message "AS-REQ", encore ? (cliquez sur l'image pour zoomer) :
Réponse "ERR_PREAUTH_REQUIRED" indiquant que le compte utilisateur existe dans l'annuaire.
Ce second message "AS-REQ" contient cependant un nouvel item, il s'agit d'une donnée chiffrée à l'aide d'une clé liée au mot de passe utilisateur. Si le service Kerberos parvient à déchiffrer ce message avec le mot de passe de l'utilisateur (qu'il possède de son côté grâce à l'annuaire et sa base NTDS.DIT) alors, il aura la preuve qu'il s'agit du bon mot de passe, et donc du vrai utilisateur. Tout cela sans que le mot de passe ait transité en clair sur le réseau. Pour plus de détails, sachez que la donnée chiffrée est un timestamp : c'est-à-dire la date et l'heure actuelle dans un format précis (notez le "pA-ENC-TIMESTAMP" dans la seconde AS-REQ).
Enfin, si les identifiants sont corrects, le service envoi un message de réponse "AS-REP" contenant notamment un TGT, qui permet de demander ensuite des TGS (cliquez sur l'image pour zoomer) :
Transmission d'un TGT par le service Keberos suite à une authentification réussie.
Voilà à quoi ressemble une authentification "classique" via Kerberos en vue d'obtenir un TGT.
AS-REQ pour un login existant sans pré-authentification
Cependant, Microsoft a ajouté un attribut aux objets utilisateur qui permet d'autoriser le service Kerberos à fournir un TGT à quiconque le demande, sans authentification : l'attribut "Do not require Kerberos preauthentication". Dans ce cas, un attaquant peut demander un TGT pour un tel compte sans avoir besoin de fournir de preuve d'identité valide. Voilà alors ce qu'il se passe (cliquez sur l'image pour zoomer) :
Obtention d'un TGT sans authentification préalable pour un utilisateur ayant l'attribut "No preauthentication required".
Une "AS-REQ", demandant un TGT pour l'utilisateur "RDUBOIS", puis une "AS-REP" du KDC délivrant TGT, le tout sans preuve d'identité (authentification). N'importe qui peut donc usurper l'identité de l'utilisateur "RDUBOIS" en demandant un TGT à son nom, puis des TGS pour échanger avec les services du domaine.
Pour être plus précis, rappelons que le TGT obtenu dans les messages "AS-REP" est chiffré et ne peut être utilisé sans connaître le mot de passe du compte utilisateur. Cependant, étant donné qu'il est chiffré avec un dérivé du mot de passe utilisateur, l'attaquant pourra tenter de casser ce mot de passe en Offline (localement, sans interactions supplémentaires avec le KDC ou le domaine), pour retrouver le mot de passe de l'utilisateur.
En résumé, quand cet attribut est présent sur un compte utilisateur, n'importe qui peut obtenir une donnée (le TGT) qui utilise un dérivé du mot de passe du compte utilisateur, et donc tenter de retrouver le mot de passe en clair. Même en étant confiant sur l'algorithme de chiffrement et la robustesse du mot de passe utilisé, reconnaissons qu'il est plutôt périlleux de fournir ce genre d'informations à un simple visiteur non authentifié sur notre système d'information.
J'espère que cette vue en détail des échanges Kerberos vous aura permis de mieux comprendre le fonctionnement de l'attaque ASREPRoast.
C. Pourquoi cet attribut ?
Certaines applications ne prennent pas en charge la pré-authentification Kerberos, il est ainsi courant de trouver des utilisateurs avec la pré-authentification Kerberos désactivée, permettant ainsi aux attaquants de demander des TGT pour ces utilisateurs. C'est la raison principale de l'existence de ce paramètre d'après la documentation Microsoft. La pré-authentification Kerberos peut également être désactivée pour d'autres raisons liées à des besoins spécifiques de sécurité ou de compatibilité avec d'autres systèmes.
Dans la réalité, il n'est pas rare de trouver de tels comptes, notamment sur des systèmes d'information qui ont un certain historique...
III. Configuration d'un Lab vulnérable
Attention, dans ce chapitre, nous allons configurer de manière volontaire un Lab vulnérable pour vous exposer le but et le fonctionnement de l'attaque.
NE PAS REPRODUIRE SUR UN ENVIRONNEMENT DE PRODUCTION.
Dans mon Lab de démonstration, j'ouvre la console "Utilisateurs et ordinateurs Active Directory", puis je sélectionne un de mes utilisateurs, ici l'utilisateur "RDUBOIS". Il faut ensuite faire un clic droit "Propriétés" sur cet objet et se rendre dans "Compte" :
Configuration de l'attribut "Do not require Kerberos preauthentication" sur un compte utilisateur.
Dans les "Options de compte", il faut trouver et cocher "La pré-authentification Kerberos n'est pas nécessaire" comme sur l'image ci-dessus.
Si vous vous souvenez des explications précédentes, l'attaque ASREPROAST est d'autant plus dangereuse si le mot de passe utilisé est faible, pour avoir un cas d'école, nous allons paramétrer le mot de passe de l'utilisateur "RDUBOIS" à "#1p@ssword" (ce n'est pas un mot de passe faible ? Vous allez voir que si ). Il faut à nouveau faire un clic droit sur l'objet puis "Réinitialiser le mot de passe" :
Paramétrage d'un mot de passe faible sur le compte utilisateur.
Vous l'aurez compris, pour effectuer une attaque ASREPRoast, il faut un login utilisateur à tester, voire plusieurs. Dans un premier temps, l'attaquant doit donc se constituer une liste de login (dictionnaire) qu'il soumettra ensuite au service Kerberos.
Dans le cas où l'attaquant n'est pas authentifié sur le domaine (boite noire) :
Si l'attaquant n'a pas de compte sur l'Active Directory, il peut utiliser différentes méthodes pour récupérer des logins valides. L'OSINT (Open Source Intelligence) est une méthode assez commune puisqu'avec quelques requêtes Google ou recherches Linkedin, on peut assez facilement retrouver une liste de personnes travaillant dans une entreprise. La recherche dans des fuites de données, basée sur le nom de l'entreprise ou l'adresse mail, est aussi fréquente.
Depuis l'intérieur du réseau (toujours sans compte valide sur le domaine), il existe un grand nombre de techniques également. Les imprimantes sont mon moyen favori, souvent mal protégées avec des interfaces d'administration exposées et verbeuses, elles stockent des carnets d'adresses qui exposent souvent des logins utilisateur. Les applications web internes, services SNMP, SMB et RPC mal configurés (authentification anonyme) ou même l'interception réseau sont également très efficaces.
Également, il est possible pour l'attaquant d'utiliser des dictionnaires pré-conçus utilisant des couples prénom-noms communs, voir des noms de comptes techniques comme "svc-ldap", "backup", "formation", "accueil", etc. Les dictionnaires que j'utilise souvent sont publics et fonctionnent en général très bien, bien qu'utilisant majoritairement des noms anglophones : https://github.com/insidetrust/statistically-likely-usernames.
Avec toutes ces méthodes, il est souvent très facile de se constituer une liste bien fournie de logins utilisateur potentiels. Il faut enfin savoir les formater grâce à la nomenclature actuelle de l'Active Directory ciblé : est-ce "marc.martin", marc_martin, "m.martin", "mmartin" ? etc.
Dans le cas où l'attaquant est authentifié sur le domaine (boite grise) :
Si l'attaquant possède déjà un compte sur le domaine, rien de plus facile. Une simple requête LDAP permettra de récupérer la totalité des logins utilisateur de l'annuaire, il aura alors une liste exhaustive des comptes à cibler, augmentant ses chances d'en trouver un avec l'attribut "Do not require Kerberos preauthentication".
Depuis Linux, une requête "ldapsearch" fera l'affaire :
J'utilise ici la commande "ldapsearch" pour récupérer les attributs "sAMAccountName" des utilisateurs du domaine, puis la commande "grep" pour isoler les lignes qui m'intéressent et enfin "cut" pour isoler uniquement le login de l'utilisateur. Si vous peinez à comprendre cette commande, n'hésitez pas à la décomposer dans votre environnement et à exécuter les commandes une à une. Le tout est enregistré dans le fichier "/tmp/userlist". Voici un exemple du résultat attendu :
Extraction des utilisateurs de l'Active Directory avec un compte valide sur le domaine via "ldapsearch".
Je me retrouve donc avec une liste de 1000 logins utilisateur valides dans le fichier "/tmp/userlist".
L'outil BloodHound va également récupérer la liste des utilisateurs pour les stocker dans un fichier JSON, qui pourra facilement être parcouru pour en extraire les logins. Je vous oriente sur mon cours sur BloodHound si vous souhaitez en savoir plus : Identifiez les faiblesses de votre Active Directory avec Bloodhound
Une fois cette liste, hypothétique, partielle ou complète à disposition, l'attaquant va pouvoir interroger sur le service Kerberos du domaine afin de voir si :
L'utilisateur existe dans l'annuaire;
Il dispose de l'attribut "Do not require Kerberos preauthentication".
B. Exploiter ASREPRoast depuis Linux
Depuis Linux, une multitude d'outils offensifs existent pour effectuer cette attaque. Je vais ici vous présenter les outils les plus classiques : "impacket" et "netexec".
Impacket est une bibliothèque Python utilisée pour interagir avec des protocoles de réseau tels que SMB, LDAP et Kerberos. Elle offre des outils pour la manipulation de paquets réseau, la création de serveurs et de clients pour ces protocoles, ainsi que des fonctionnalités avancées pour l'analyse et l'exploitation de vulnérabilités. Impacket est très largement utilisé pour les opérations offensives et de nombreux outils utilisent cette librairie.
En plus d'être une librairie très puissante, les créateurs d'Impacket fournissent des scripts qui l'utilisent afin d'automatiser certaines opérations et attaques, comme ASREPRoast. Je ne peux pas détailler ici la procédure d'installation de "Impacket" et de ses "examples scripts", je vous renvoie pour cela à la documentation officielle : Github - Impacket.
ASREPRoast en boite noire
Nous allons notamment utiliser le script "impacket-GetNPUsers" ("NP" pour "NoPreauth"). Dans le cas où nous sommes en boite noire, nous avons au préalable construit notre dictionnaire à partir de différentes sources. Nous pouvons utiliser ce dictionnaire pour réaliser une attaque ASREPRoast. Ici,"192.168.56.102" est l'adresse IP de mon contrôleur de domaine, qui héberge le service Kerberos (KDC)) :
Si l'on dispose d'un accès authentifié au domaine, encore mieux, "impacket-GetNPUsers" peut automatiser à la fois la récupération des utilisateurs dans la base LDAP, et l'envoi d'un "AS-REQ" en leur nom pour voir s'ils sont vulnérables à l'ASREPRoast :
Même principe pour "netexec", il suffira de spécifier l'utilisateur ("-u") et son mot de passe de ("-p") pour s'authentifier auprès du service LDAP afin de récupérer la liste des utilisateurs :
Voici le résultat attendu pour "impacket-GetNPUsers" et "netexec" :
Utilisation de "impacket-gtNPUsers" et "netexec" pour la réalisation d'une attaque ASREPRoast authentifiée.
On voit donc que plusieurs logins sont tentés sur le service Kerberos et que, pour certains, un hash au format "$krb5asrep$23$" est obtenu. Il s'agit d'une donnée extraite du TGT obtenu pour chaque utilisateur vulnérable, spécialement formaté pour être interprété par des outils de cassage de mot de passe.
Maintenant que nous avons ces hashs, nous pouvons tenter de les casser, par exemple, à l'aide de "JohnTheRipper" ou "hashcat" et de listes de mots de passe communs comme le dictionnaire de mot de passe "rockyou.txt" :
hashcat -m 18200 -a 0 ASREProastables.txt rockyou.txt
john --wordlist=rockyou.txt ASREProastables.txt
Ce cassage s'effectue totalement en local, sans interactions avec l'Active Directory ou le service Kerberos. Ainsi, aucune détection n'est possible. Également, l'utilisateur a ici tout son temps et la rapidité de l'opération dépendra de la robustesse du mot de passe et des ressources de calcul qu'il a à disposition. Si des mots de passe faibles ont été utilisés par les comptes utilisateurs vulnérables, ils seront retrouvés par ces outils :
Cassage du hash "krb5asrep" extrait du TGT de l'utilisateur obtenu via ASREPRoast.
Si les mots de passe sont très robustes, alors il faudra déployer des moyens considérables pour les casser. Ici, le mot de passe semble plutôt correct avec 3 alphabets et une longueur de 10 caractères, mais il se trouve dans le dictionnaire public et très connu "rockyou.txt". Nous venons de retrouver le mot de passe d'un utilisateur de l'Active Directory par l'intermédiaire d'un TGT signé grâce à un dérivé de son mot de passe par le service Kerberos.
C. Exploiter ASREPRoast depuis Windows
Sous Windows, l'outil le plus classique pour effectuer cette attaque est "Rubeus.exe", écrit en C#. Le plus simple est de l'exécuter sur une machine intégrée au domaine ou via un "runas.exe" :
Utilisation de "Rubeus.exe" pour la réalisation d'une attaque ASREPRoast.
Comme pour les outils Linux, le fichier "hashes.asreproast" contiendra les hashs contenus dans les TGT récupérés et pourra être passé à "hashcat" ou "JohnTheRipper" pour cassage.
V. Point de vue du défenseur
A. Lister les comptes utilisateurs avec preauth-notreq
Nous allons maintenant adopter le point de vue du défenseur ou blue team qui souhaite savoir si des utilisateurs vulnérables à ASREPROAST sont présents sur son domaine.
Lorsque nous sommes sur notre propre domaine et contrôleur de domaine, le plus simple est d'utiliser le module PowerShell "ActiveDirectory" qui permet de communiquer avec ADSI (Active Directory Services Interface). Nous pouvons notamment cibler l'attribut "useraccountcontrol" pour extraire les utilisateurs disposant de l'attribut "Do not require Kerberos preauthentication", exemple :
Nous avons la même liste utilisateur qu'obtenue via notre requête "ldapsearch" bien entendu, avec un filtre sur ceux qui ont déjà l'attribut "Do not require Kerberos authentication", mais nous utilisons ici des outils légitimes et plus accessibles pour les administrateurs système. J'ai notamment ajouté le "DN" et l'attribut "Enabled" en sortie de la commande (via le "Format-Table" ou "ft").
B. Corriger les comptes vulnérables
Une fois cette liste à disposition, il convient tout d'abord de déterminer :
Pourquoi ils sont/ont été utilisés, pour quels besoins, services et systèmes ?
Est-ce ce qu'ils sont toujours utilisés aujourd'hui ? (date de dernière authentification, dernier changement de mot de passe, journaux d'évènements)
Est-ce que l'attribut "Do not require Kerberos authentication" est vraiment utile et répond à un besoin fonctionnel ?
Une fois que ces questions ont toutes une réponse claire pour chaque compte, la décision de désactiver cet attribut peut être prise.
Corriger ASREPRoast via l'interface graphique
Depuis la console "Utilisateurs et ordinateurs Active Directory", effectuez un clic droit sur le compte utilisateur concerné, puis "Propriétés. Il faut ensuite se rendre dans "Compte" et localiser l'option suivante :
Désactivation de l'attribut "Do not require Kerberos preauthentication" sur l'Active Directory.
Une fois décochée, nous pouvons appliquer nos changements. La modification prend effet immédiatement.
Corriger ASPREPRoast via Powershell
Il est aussi possible de modifier la valeur de cet attribut en PowerShell via ADSI. Le cmdlet "Set-ADAccountControl" est fournie par le module PowerShell "ActiveDirectory" :
À nouveau, la modification est prise en compte immédiatement.
Mesure complémentaire en cas de besoin fonctionnel
Si l'attribut "Do not require Kerberos preauthentication" est nécessaire et répond à un besoin identifié et justifié, alors il convient de mettre un mot de passe très, très robuste à ce compte. L'idée est que même si un TGT est récupéré, l'attaquant ne puisse pas casser le hash qu'il contient en vue de récupérer le mot de passe en clair de l'utilisateur. Optez donc pour un mot de passe à plus de 30 caractères.
Dans l'idéal, il est également nécessaire de prévoir un renouvellement périodique de ces mots de passe afin de réduire leur exposition dans le temps. Si l'attaquant dispose de tout le temps disponible devant lui pour casser le hash contenu dans le TGT, alors il finira peut-être par y arriver (peut-être au bout de plusieurs années). Mais si le mot de passe du compte est changé tous les six mois, il n'aura potentiellement pas le temps de l'exploiter une fois qu'il l'aura cassé. Il s'agit d'une mesure de sécurité supplémentaire.
Limiter la propagation suite à une compromission
Il convient également de s'assurer que le compte qui dispose légitimement de l'attribut "Dot not require Kerberos preauthentication" possède des droits limités sur le domaine et le système d'information. La revue des ACL, appartenances aux groupes et l'application du principe de moindre privilège (configuration fine et minimaliste des droits pour répondre uniquement aux fonctions métiers) permettra de limiter au maximum les actions possibles de l'attaquant en cas de compromission du compte.
Changement de mot de passe
Enfin, il est à noter que si le compte a eu jusque-là cet attribut, n'importe quel utilisateur de votre domaine a peut être déjà récupéré un TGT et obtenu son mot de passe, ou est en train de tenter de le casser. Ces mesures de correction doivent donc s'accompagner d'un changement de mot de passe afin qu'un attaquant exploitant ou ayant exploité cette faiblesse ne puisse pas réutiliser le mot de passe compromis pour ce compte, ce qui sera possible même si l'attribut en question a été décoché.
C. Détecter une attaque ASREPRoast
Du point de vue du défenseur, nous allons également nous intéresser aux possibilités de détection d'une attaque ASREPRoast passée ou en cours sur le système d'information.
Détection via les journaux d'évènements
L'exploitation de l'ASREPRoast génère, comme toute interaction avec l'Active Directory, des évènements. Cependant, il n'est pas aisé de les distinguer clairement des activités légitimes et quotidiennes des utilisateurs du domaine. Il faut savoir que lorsqu'un "AS-REQ" est effectué sur un compte non vulnérable à l'ASREPRoast (et donc, échoue), aucun évènement de sécurité n'est généré. Seule l'émission d'un ticket Kerberos génère un évènement avec l'eventID 4768.
L'event ID 4768 est enregistré sur le contrôleur de domaine chaque fois qu'un TGT est émis. Il indique que le KDC a reçu une demande de TGT (AS-REQ) et qu'il a émis un TGT en réponse. L'évènement journalisé contient alors quelques détails intéressants sur la demande.
La requête est émise avec une authentification valide, auquel cas un TGT est émis en réponse à l'"AS-REQ".
La requête porte sur un utilisateur ayant l'attribut "Do not require Kerberos authentication", auquel cas pas besoin d'authentification, le TGT est tout de même émis en réponse à l'"AS-REQ".
Voici l'évènement tel qu'il apparaitra dans l'observateur d'évènement lors d'une demande de TGT classique, avec authentification (utilisation ici de "impacket-getTGT") :
EventID 4768 suite à une demande et émission de TGT classique, avec authentification.
On voit clairement qu'un TGT a été demandé et émis pour l'utilisateur "IT-CONNECT\mmartin" par le client "192.168.56.104". Nous allons également garder dans un coin de notre mémoire les informations relatives au "Type de pré-authentification" et "Type de chiffrement du ticket". Je réalise maintenant la même opération à destination du compte "IT-CONNECT\rdubois" et avec un outil offensif qui va directement demander un TGT sans authentification préalable (utilisation de "netexec") :
EventID 4768 suite à une demande et émission de TGT à la suite d'une attaque ASREPROast via "netexec".
Les informations journalisées sont globalement les mêmes lors d'une demande et émission d'un TGT sur un compte ne nécessitant pas la pré-authentification. Cependant, on peut noter deux exceptions (à noter que le résultat est le même lors d'une exploitation avec "impacket-getNPUsers") :
Le "Type de chiffrement du ticket" est passé à "0x17" au lieu de "0x12".
Le "Type de pré-authentification" est passé à "0" au lieu de "2".
L'utilisation d'un chiffrement à "0x17" (RC4-HMAC) est un comportement typique des outils d'attaque qui downgrade (abaissent) le niveau de chiffrement utilisé pour le chiffrement du TGT afin de rendre le cassage de son contenu plus aisé. Par défaut, le niveau de chiffrement "0x12" entraine l'utilisation du AES256-CTS-HMAC-SHA1-96 (Source : 4768(S, F): A Kerberos authentication ticket (TGT) was requested). Voilà un premier élément caractéristique d'une attaque ASREPRoast avec des méthodes et outils classiques.
Egalement, la documentation Microsoft est limpide concernant les valeurs du "Type de pré-authentification" :
La demande de TGT avec une valeur "0" à "Type de pré-authentification" est donc également un signal intéressant à surveiller. Pour finir sur cette détection, je vous propose une requête KQL (pour ELK) qui permet d'identifier les événements de demande/émission d'un TGT avec un chiffrement faible (RC4) ou sans pré-authentification :
event.code:4768 AND (winlog.event_data.TicketEncryptionType: 0x17 OR winlog.event_data.PreAuthType: 0)
Pour détailler un peu la requête. Il s'agit d'un filtre sur les évènements Windows ayant un évènement ID 4768 et qui ont, soit un "TicketEncryptionType" à "0x17" (RC4), soit un "PreAuthType" à "0". Voici le résultat sur l'ELK de mon lab (avec moins d'activité qu'un vrai SI, bien sûr) :
Visualisation dans ELK des évèenemtn caractértistique d'une attaque ASREPRoast
Pas de doute, il y a eu une activité suspecte sur mon SI entre 17h45 et 18h15, des TGT sans pre-authentification et avec un algorithme de chiffrement faible ont été demandés.
Surveiller les modifications des attributs utilisateurs
Pour aller plus loin, vous pouvez également chercher et surveiller les event ID 4738 (A user account was changed) et 5136 (A directory service object was modified) qui apparaissent lorsqu'un attribut utilisateur est modifié :
Journalisation de la modification d'un attribut utilisateur via l'eventID 4738.
Plutôt que la compromission, vous visualiserez alors tous les évènements d'activation/désactivation de l'attribut concerné sur des comptes utilisateurs, ce qui permettra de retrouver le moment où la vulnérabilité a été introduite sur le compte concerné. Là aussi, il faudra aller plus loin pour réellement identifier le nom de l'attribut modifié et s'assurer de n'obtenir que les alertes relatives à l'attribut "Do not require Kerberos preauthentication". Egalement, voici un exemple de requête filtre KQL pour cet évènement :
event.code:4738 AND winlog.event_data.UserAccountControl:*2096*
Voici l'aperçu d'un tel évènement dans la console ElasticSearch :
Visualisation de l'eventID 4738 relatif à l'ajout de l'attribut "Do not requiere kebreroas pre-authentication" dans ElasticSearch.
Utilisation d'un honey account
Si vous maitrisez correctement la sécurité de votre système d'information, notamment avec un SIEM et un SOC (Security Operation Center) efficaces, alors vous pouvez envisager la mise en place d'un honey account, ou "compte pot de miel". L'idée est de créer un compte utilisateur volontairement vulnérable à ASREPRoast afin que sa compromission génère un évènement de sécurité activement surveillé par la blue team.
Pour cela, il faut notamment être sûr que ce compte ne sera jamais utilisé de façon légitime par un utilisateur ou un service du SI. Ainsi, si une demande de TGT pour ce compte spécifique apparait dans les journaux d'évènement, ce sera forcément dû à une attaque ASREPRoast en cours.
Attention : La création et la gestion d'un compte pot de miel nécessitent une attention particulière. Il faut s'assurer que les politiques de sécurité et les procédures de surveillance sont bien établies pour garantir que le compte reste contrôlé et qu'il ne devienne pas une vulnérabilité supplémentaire. Il faut notamment s'assurer que l'honey account ait un mot de passe très robuste afin que le hash contenu dans son TGT ne soit jamais cassé, ce qui permettrait à l'attaquant d'obtenir un compte valide sur le domaine.
VI. Conclusion
J'espère que cet article vous a plu et que vous avez maintenant une meilleure idée des risques liés à cette attaque et de la façon de s'en protéger. J'ai essayé de faire en sorte qu'il soit complet en abordant le point de vue des attaquants comme des défenseurs.
N'hésitez pas à donner votre avis dans les commentaires ou sur notre Discord !
). Il faut à nouveau faire un clic droit sur l'objet puis "Réinitialiser le mot de passe" : 
