Alors que les entreprises continuent d’être piratées à longueur de journée, les équipes informatiques et de sécurité renforcent sans cesse leurs défenses dans l’espoir d’éradiquer les attaquants de leurs réseaux. La (relative) bonne nouvelle, c’est que les fournisseurs de logiciels et de matériel de sécurité débordent d’offres de produits et de services conçues pour vous aider. Nombre d’entre eux promettent même de tenir les mauvais acteurs à l’écart de vos systèmes 24 heures sur 24, 7 jours sur 7 !
Il vous suffit donc de sortir votre carte bancaire, d’installer l’un de ces produits et de passer une bonne nuit, n’est-ce pas ? Malheureusement, lors des tests d’intrusion que nous réalisons pour des clients dans tout le pays, nous constatons encore et encore que ces solutions de sécurité coûteuses présentent d’importantes zones aveugles. Beaucoup ne parviennent même pas à détecter complètement les attaques les plus élémentaires. Et les produits de sécurité doivent aussi être affinés pour votre environnement ; les paramètres par défaut ne couvrent pas toutes les problématiques propres à votre environnement.
Dans cet article, nous allons vous montrer comment exécuter certaines de ces attaques « faciles pour les hackers » afin de tester l’efficacité des services de sécurité de votre organisation. Pour disposer d’un véritable outil commercial avec lequel mener ces attaques, nous avons choisi une solution de sécurité appelée InsightIDR, de Rapid7, que nous avons installée dans notre environnement de laboratoire.
InsightIDR repose sur un SIEM et évolue pour devenir essentiellement une solution XDR couvrant les terminaux, l’analyse du trafic réseau, l’UEBA, la réponse aux incidents et bien plus encore. Lors de nos tests, nous avons relevé plusieurs problèmes courants dans les systèmes SIEM. La bonne nouvelle, c’est que les fournisseurs réagissent à ces problèmes : ils préfèrent les apprendre de la bouche de spécialistes « white hat » et de clients plutôt que des mauvais acteurs, et nous avons échangé avec Rapid7 tout au long de nos travaux. Nous avons trouvé Rapid7 réactif et facile à solliciter, ce qui est un bon signe pour l’assistance aux utilisateurs et revêt une importance cruciale en cybersécurité. Rapid7 travaille sur plusieurs correctifs correspondant à nos constatations — dont certains concernaient des problèmes connus dont l’entreprise avait déjà connaissance — et nous mettrons donc cet article à jour dans quelques mois pour rendre compte de l’achèvement de ces travaux. Nous avons également inclus les commentaires de Rapid7 à plusieurs endroits.
À notre connaissance, c’est l’une des rares fois où les résultats de tests sont publiés pour un produit de cybersécurité de cette ampleur ; notre objectif est donc principalement pédagogique. Nous vous encourageons à utiliser cet article comme guide pour mener vos propres tests internes de solutions de sécurité. Nous nous sommes concentrés sur plusieurs « tirs d’avertissement » détectables qui peuvent se produire lors d’une attaque (ou d’un test d’intrusion) et qui vous permettront de savoir que de mauvaises choses se trament en coulisses. Si une ou plusieurs de ces attaques ne sont pas détectées, demandez à vos fournisseurs de créer une signature correspondante. Le résultat sera un produit plus robuste pour l’ensemble de leurs utilisateurs.
Nous avons également créé un guide de prise en main de Rapid7 InsightIDR pour rendre compte de nos impressions sur la facilité d’utilisation et les fonctionnalités du produit. Nous avons trouvé le produit facile à installer et à configurer en quelques heures seulement, et avons immédiatement commencé à recevoir des notifications concernant des événements de sécurité importants. Dans cet article, nous nous intéressons aux attaques courantes que nous menons lors des tests d’intrusion et à la manière dont le système InsightIDR de Rapid7 y a réagi.
Tester la capacité d’InsightIDR à détecter les attaques
- Énumération d’Active Directory
- Pulvérisation de mots de passe
- Kerberoasting
- AS-REP Roasting
- Empoisonnement du trafic réseau
- Extraction des hachages des contrôleurs de domaine
- Attaques Pass the Hash (PTH)
- Conclusion
Une fois l’agent installé sur tous les systèmes de notre environnement de test, nous étions prêts à simuler les actions qu’effectuerait un attaquant ou un opérateur de rançongiciel afin de voir quels types de menaces de sécurité seraient détectés. (Remarque : nombre des attaques ci-dessous sont tirées de Light Pentest LITE: eBook Edition, un guide pratique, étape par étape, conçu pour les tests d’intrusion des réseaux internes.)
Énumération d’Active Directory
L’une des premières choses que nous faisons lors d’un test d’intrusion consiste à essayer d’en apprendre davantage sur l’environnement Active Directory du client. Les configurations d’Active Directory, en particulier celles qui sont en production depuis plusieurs années, regorgent souvent de chemins d’attaque difficiles à repérer si l’on ne regarde pas de plus près sous le capot.
L’un des outils que nous utilisons pour énumérer Active Directory est SharpHound, qui aspire les informations sur tous les objets de l’annuaire et leurs relations du point de vue de la sécurité. SharpHound propose de nombreux paramètres de configuration que vous pouvez ajuster pour rendre la collecte de données plus discrète, mais nous l’exécutons généralement « toutes portes ouvertes », comme ceci :
sharphound.exe -d pwn.town -c all
L’option -d pwn.town indique notre domaine, et -c all indique à SharpHound de recueillir toutes les données sur l’environnement Active Directory.
InsightIDR n’a pas détecté l’exécution de SharpHound. Cela n’a toutefois rien de surprenant, car nous n’avons encore jamais vu de solution de sécurité le détecter.
La bonne nouvelle, c’est qu’InsightIDR sera bientôt capable de détecter cette attaque. Rapid7 nous a déclaré : « Nous travaillons sur une détection de l’énumération d’Active Directory à l’aide de SharpHound, qui devrait selon nous être possible grâce aux événements des journaux Windows. Elle devrait probablement être disponible d’ici la fin de l’année. »
Pulvérisation de mots de passe
Au début d’un test d’intrusion, nous voulons vérifier si nous pouvons accéder à d’autres comptes utilisateurs Active Directory. Une méthode populaire et relativement discrète consiste à effectuer une pulvérisation de mots de passe, en essayant de se connecter à chaque compte une seule fois avec un mot de passe que nous savons que les utilisateurs sont susceptibles d’employer. D’après notre expérience, les utilisateurs adorent les combinaisons saison + année. Nous avons donc téléchargé Rubeus et tenté de nous connecter à chaque compte utilisateur avec la syntaxe suivante :
rubeus.exe spray /password:Spring2022! /outfile:pwned.txt
L’option spray indique à Rubeus que nous effectuons une pulvérisation de mots de passe ; /password:Spring2022! spécifie le mot de passe à utiliser pour cette pulvérisation, et /outfile:pwned.txt enregistre les identifiants valides dans un fichier texte appelé pwned.txt.
InsightIDR n’a pas détecté nos tentatives de pulvérisation de mots de passe. Nous constatons que les solutions de sécurité sont très efficaces pour vous avertir lorsqu’un compte est verrouillé, mais dans ce cas nous n’essayons de nous connecter à chaque compte qu’une seule fois ; les comptes restent donc actifs.
Rapid7 nous a indiqué qu’un pot de miel que nous n’avions pas configuré aurait été utile. Voici la réponse de l’entreprise : « Pour la pulvérisation de mots de passe, nous avons deux détections : la première concerne l’utilisateur leurre que vous n’aviez pas configuré pendant le test, et la seconde est une détection de force brute qui recherche une série d’authentifications échouées depuis un même hôte. Notre seuil est d’au moins 100 utilisateurs différents (nos plus petits clients en comptent environ 500). Nous réévaluons actuellement ce seuil. »
Kerberoasting
Le Kerberoasting est l’une de nos attaques préférées. Son explication technique peut devenir assez dense ; nous vous recommandons donc de consulter cet article de Black Hills Information Security pour une analyse approfondie. Cependant, lorsque nous parlons de Kerberoasting, nous nous trouvons généralement dans une salle remplie de responsables et de dirigeants qui veulent simplement une explication claire de l’attaque et des raisons pour lesquelles ils devraient s’en préoccuper. Nous disons donc quelque chose comme ceci :
« En gros, n’importe quel compte Active Directory peut dire : “Hé, Active Directory, pourrais-tu me donner les hachages de tous les comptes de service associés, par exemple, à IIS et à SQL ?” Et l’environnement Active Directory répond joyeusement : “Pas de problème, Bri-guy, LES VOICI !” »
Cette attaque est plus facile à comprendre lorsqu’on la voit en action. Pour vérifier si un environnement est vulnérable à l’attaque par Kerberoasting, nous pouvons à nouveau utiliser Rubeus avec la syntaxe suivante :
rubeus.exe kerberoast
Comme on peut le voir ici, le compte utilisateur Ray de notre laboratoire est vulnérable au Kerberoasting. Nous pouvons donc transférer le hachage du compte vers une machine dédiée au cassage de mots de passe très puissante et tenter de retrouver le mot de passe en clair. Dans les environnements de production, les comptes vulnérables au Kerberoasting que nous rencontrons appartiennent souvent au groupe Domain Admins et leurs mots de passe sont rarement renouvelés. Cela signifie que si nous parvenons à casser ces comptes, nous pourrions avoir le contrôle total du domaine avant l’heure de la collation du matin !
InsightIDR n’a pas détecté la tentative de Kerberoasting. Ce n’est toutefois pas totalement surprenant, car nous n’avons vu que quelques solutions de sécurité générer une alerte pour cette attaque spécifique. Des solutions comme Blumira ont cependant mis en place une détection et rendent même leur code pour un identifiant leurre de Kerberoasting accessible au public.
Réponse de Rapid7 : « Plusieurs de nos clients s’inquiètent du kerberoasting et nous travaillons activement sur une détection de ce type d’activité, qui devrait être opérationnelle d’ici la fin de l’été. Notre principale préoccupation est actuellement de procéder d’une manière qui limite les faux positifs. »
AS-REP Roasting
À l’instar du Kerberoasting, l’AS-REP Roasting est une technique que n’importe quel compte Active Directory peut utiliser pour accéder aux hachages des mots de passe des comptes. Un très bon article de Stealthbits présente les aspects techniques fondamentaux de cette attaque. Mais dans une salle réunissant des personnes techniques et non techniques, nous expliquons l’attaque ainsi :
Avec l’attaque par AS-REP Roasting, n’importe quel utilisateur d’Active Directory peut en substance dire : « Hé, Active Directory, si certains comptes utilisateurs sont configurés pour ne pas exiger de préauthentification Kerberos, donne-moi quelques données chiffrées sur cet utilisateur afin que je puisse les récupérer hors ligne et les casser ! »
Pour trouver les utilisateurs vulnérables dans Active Directory, vous pouvez utiliser la commande PowerShell suivante :
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $True} -Properties DoesNotRequirePreAuth
Pour tout utilisateur renvoyé par cette commande, vous pouvez l’ouvrir dans l’outil Utilisateurs et ordinateurs Active Directory et cliquer sur l’onglet Compte pour voir la configuration vulnérable :
Puisque nous voulons voir les utilisateurs vulnérables et leurs hachages, nous allons utiliser Rubeus une nouvelle fois :
rubeus.exe asreproast:
InsightIDR n’a pas détecté la tentative d’AS-REP Roasting. Comme pour le Kerberoasting, nous avons constaté que très peu de solutions de sécurité génèrent une alerte pour cette attaque. Là encore, les utilisateurs peuvent probablement s’attendre à une détection de la part de Rapid7 dans un avenir proche.
Empoisonnement du trafic réseau
Si nous ne parvenons pas à progresser avec la pulvérisation de mots de passe, le Kerberoasting et l’AS-REP Roasting, nous utiliserons divers outils pour empoisonner certains protocoles de trafic réseau vulnérables, tels que NBT-NS (NetBIOS Name Service), LLMNR (Link-Local Multicast Name Resolution) et mDNS (multicast DNS).
Pour mieux visualiser cette attaque, imaginez un scénario dans lequel l’utilisatrice Sally ouvre l’Explorateur Windows et essaie d’accéder au serveur PT-APP01 mais fait une faute de frappe dans le nom du serveur en ajoutant un zéro et saisit \\pt-app001. Après quelques instants, une fenêtre contextuelle lui indiquera « Windows ne peut pas accéder à \\pt-app001 ». Rien de grave, n’est-ce pas ? En réalité, quelque chose de bien plus sinistre pourrait se produire en arrière-plan !
Si, en tant qu’attaquants, nous exécutons des outils d’empoisonnement réseau tels que Inveigh, nous pouvons écouter Sally faire ce genre de fautes de frappe, puis les intercepter. Regardez cette illustration pour vous faire une idée de ce à quoi cela ressemble :
En substance, la machine de Sally demande au serveur DNS où trouver \\pt-app001, et lorsque le serveur DNS ne parvient pas à le trouver, la machine de Sally lance des appels au reste du réseau en utilisant des protocoles non sécurisés (NBT-NS, LLMNR et mDNS). À ce moment-là — BOUM ! — nous piégeons sa machine pour qu’elle nous envoie le nom d’utilisateur et le hachage du mot de passe de Sally.
Pour lancer cette attaque contre le trafic réseau, nous pouvons utiliser Inveigh :
inveigh.exe -nbns y -llmnr y -mdns y:
Cette syntaxe indique à Inveigh de démarrer et d’empoisonner le trafic non sécurisé NBT-NS, LLMNR et mDNS.
Après un certain temps, nous devrions voir apparaître dans le journal d’Inveigh des entrées semblables à celle-ci :
Nous pouvons maintenant prendre le hachage de l’utilisateur Beverly et tenter de le casser.
InsightIDR n’a pas détecté l’empoisonnement du réseau, mais comme InsightIDR est un outil basé sur les terminaux, nous ne nous y attendions pas. Cependant, si vos solutions de sécurité examinent l’ensemble du trafic réseau en plus de l’activité des terminaux, nous vous recommandons d’exécuter Inveigh pour voir s’il génère des alertes. Vous pouvez également utiliser un excellent outil gratuit permettant de détecter les attaques par empoisonnement réseau, appelé CanaryPi.
La bonne nouvelle est qu’une solution est également en préparation, selon Rapid7 : « Nous disposons effectivement d’une détection pour cela, que nous avons testée par le passé sur un outil appelé Responder, et elle s’est déclenchée. Nous avons essayé de l’utiliser avec l’outil que vous avez employé (inveigh), mais nous ne sommes pas parvenus à la déclencher. Nous cherchons à comprendre pourquoi, mais nous allons bientôt la rendre opérationnelle. »
Extraction des hachages des contrôleurs de domaine
Si nous parvenons à capturer et à casser les identifiants d’un membre du groupe Domain Admins, nous allons ensuite extraire tous les noms d’utilisateur et les hachages de mots de passe d’Active Directory. L’outil mimikatz fonctionne parfaitement pour cela :
lsadump::dcsync /domain:pwn.town /all /csv:
Cette syntaxe indique à Mimikatz de produire la liste de tous les utilisateurs du domaine pwn.town et de leurs hachages dans un format CSV propre :
À notre avis, cette attaque spécifique est la pire chose qui puisse arriver à votre environnement Active Directory. Pourquoi ? Eh bien, si l’attaquant dispose de ces informations et se trouve toujours à l’intérieur de votre réseau, il peut mener des attaques pass-the-hash (PTH) pour agir dans Active Directory en usurpant l’identité de l’utilisateur de son choix ! Et même si vous éliminez le point d’appui des attaquants dans votre environnement, ils peuvent parvenir à casser certains de ces hachages et à regagner immédiatement l’accès à votre réseau par e-mail, VPN, VDI, etc.
InsightIDR a bien détecté la présence de mimikatz.exe sur les terminaux équipés de l’agent InsightIDR. Cependant, lorsque nous avons extrait les hachages Active Directory depuis un terminal non surveillé à l’aide de impacket, InsightIDR n’a généré aucune alerte. Traditionnellement, nous voyons les solutions de sécurité générer une alerte lors de l’extraction des hachages. Et même si c’est une bonne nouvelle, c’est aussi assez frustrant, car la solution a essentiellement détecté le « coup de grâce » Active Directory de l’attaquant.
Attaques Pass the Hash (PTH)
Armés des hachages que nous avons extraits d’Active Directory, nous pouvons utiliser un outil comme CrackMapExec pour « faire passer » le hachage sur le réseau vers d’autres systèmes :
cme smb 10.0.7.0/24 -u brian -H PASSWORD-HASH-FOR-BRIAN:
Dans cette syntaxe, cme appelle CrackMapExec, smb indique le protocole à utiliser, 10.0.7.0/24 précise le sous-réseau des systèmes auxquels nous allons « pulvériser » le hachage, -u brian indique l’utilisateur Brian, et -H PASSWORD-HASH-FOR-BRIAN correspond au hachage du mot de passe de Brian :
Comme vous pouvez le voir, nous avons « pulvérisé » ce hachage sur l’ensemble du sous-réseau 10.0.7.0/24 et constaté que non seulement la combinaison utilisateur/hachage est valide, mais qu’il s’agit également d’un compte doté de privilèges élevés sur de nombreux systèmes, comme l’indique Pwn3d!).
InsightIDR n’a pas détecté les attaques pass-the-hash. En général, nous constatons que les outils de protection des terminaux et de détection et réponse sur les terminaux (EDR) des entreprises génèrent des alertes lorsqu’ils détectent un comportement pass-the-hash.
Tester votre environnement pour détecter les « signaux d’alerte »
Il est important de noter que ce type d’angle mort est courant dans de nombreux SIEM. Dans un monde idéal, nous pourrions agiter une baguette magique et trouver une combinaison de solutions de sécurité qui rendrait votre réseau inviolable. En attendant, nous estimons toutefois qu’il existe de nombreux « signaux d’alerte » détectables susceptibles de se produire lors d’une attaque (ou d’un test d’intrusion) et de vous indiquer que de mauvaises choses se trament en coulisses. Nous vous encourageons à utiliser cet article comme guide pour effectuer vos propres tests internes des solutions de sécurité. Si une ou plusieurs de ces attaques ne sont pas détectées, demandez à vos fournisseurs de leur créer une signature. Et si vous recherchez une nouvelle solution de surveillance et de journalisation, consultez notre questionnaire SIEMple SIEM. Il contient une liste de questions à poser avant-vente pour mieux comprendre ce que la solution fait ou ne fait pas, ainsi que des tests techniques supplémentaires que vous pouvez effectuer afin de déterminer si la solution détecte et/ou bloque efficacement les menaces.
Découvrez les autres grandes solutions SIEM
À lire ensuite :