Vue lecture

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.

Phishing : Darcula cible Android et l’iPhone par l’intermédiaire de Google Messages et iMessage

Darcula, c'est le nom d'une nouvelle plateforme de type "Phishing-as-a-Service" (PhaaS) qui permet d'usurper l'identité de différentes marques et organisations à partir de 20 000 domaines dans le but de voler les identifiants des utilisateurs sur mobile, aussi bien sur Android que sur iPhone. Faisons le point sur cette menace.

Alors que la plateforme Tycoon 2FA cible les utilisateurs de Microsoft 365 et Gmail sur ordinateur, Darcula quant à lui s'intéresse plutôt aux utilisateurs de smartphones Android et d'iPhone. Pour cela, des messages malveillants sont envoyés aux utilisateurs directement sur Google Messages (via le protocole RCS) et iMessage. Nous notons l'abandon du SMS traditionnel au profit du protocole RCS et d'iMessage, ce qui permet aux cybercriminels d'envoyer des messages protégés par le chiffrement de bout en bout, contrairement aux SMS. Ainsi, il n'est pas possible d'analyser le contenu du message pour le bloquer avant qu'il n'atteigne l'appareil de l'utilisateur.

Darcula : 200 modèles prêts à l'emploi

Le kit Darcula peut être utilisé par les cybercriminels pour usurper l'identité de services de livraison, mais aussi de services financiers, gouvernementaux, fiscaux, de sociétés de télécommunications, ou encore des compagnies aériennes. Au total, les abonnés ont accès à 200 modèles de messages et de pages malveillantes pour usurper l'identité des marques. Le contenu s'adapte également en fonction de la langue locale de l'utilisateur pris pour cible.

"La plateforme Darcula prétend prendre en charge environ 200 modèles d'hameçonnage, couvrant un large éventail de marques basées dans plus de 100 pays différents.", peut-on lire dans un rapport mis en ligne par Netcraft.

Source : Netcraft

Les cybercriminels n'ont qu'à choisir une marque et un script de configuration s'occupe d'effectuer la configuration dans un conteneur Docker. D'ailleurs, la plateforme Darcula utilise le registre de conteneurs Harbor pour héberger l'image Docker.

L'utilisation du protocole RCS et de iMessage

L'utilisation du protocole RCS et d'iMessage pour émettre les messages malveillants obligent les pirates à contourner certaines restrictions. Il y a notamment des restrictions pour l'envoi en masse de messages. Du côté d'Apple, c'est interdit, ce qui conduit les cybercriminels à utiliser plusieurs comptes Apple ID différents et des fermes d'iPhone pour envoyer les messages. Chez Google, une restriction a été récemment mise en place pour empêcher les appareils rootés d'envoyer ou de recevoir des messages RCS.

En complément, iMessage intègre une protection un peu plus contraignante pour les cybercriminels : l'utilisateur peut cliquer sur un lien présent dans un iMessage uniquement s'il a déjà communiqué avec l'expéditeur du message en question. Pour cela, le message indique clairement à l'utilisateur qu'il doit répondre au message par un "Y" ou un "1" afin de pouvoir accéder au lien.

Darcula - Phishing iMessage exemple
Source : Darcula

Darcula, une plateforme en pleine croissance

"Au total, Netcraft a détecté plus de 20 000 domaines liés à la cybercriminalité, répartis sur 11 000 adresses IP, qui ciblent plus de 100 marques.". De nombreux domaines en ".com" et ".top" sont utilisés par les cybercriminels et un tiers des hôtes sont protégés par les services de Cloudflare.

Par ailleurs, le document de Netcraft précise également 120 domaines supplémentaires sont créés chaque jour dans le but d'héberger des pages de phishing. Preuve que cette plateforme de PhaaS est en pleine croissance. À chaque fois, l'objectif des pirates est le même : voler les données confidentielles et/ou bancaires des utilisateurs, en fonction du template utilisé.

Même si nous tous plus ou moins habitués à recevoir ces messages suspects, restons vigilants...

Source

The post Phishing : Darcula cible Android et l’iPhone par l’intermédiaire de Google Messages et iMessage first appeared on IT-Connect.

Mettez à jour Google Chrome pour vous protéger de 7 vulnérabilités, dont 2 zero-day

Mardi 26 mars 2024, Google a publié une nouvelle version de son navigateur Chrome dans le but de corriger 7 vulnérabilités, dont 2 failles de sécurité zero-day découvertes lors du Pwn2Own 2024 de Vancouver. Faisons le point sur cette mise à jour !

Les utilisateurs de Google Chrome sur Windows Mac et Linux vont pouvoir passer par la case maintenance : l'entreprise américaine a mis en ligne plusieurs versions pour protéger ses utilisateurs. Tout d'abord, nous allons évoquer les deux failles de sécurité zero-day découvertes et exploitées lors du Pwn2Own 2024, une compétition de hacking.

La première vulnérabilité, associée à la référence CVE-2024-2886, a été découverte par Seunghyun Lee (@0x10n) de KAIST Hacking Lab, le 21 mars 2024. Il s'agit d'une faiblesse de type "use after free" présente dans WebCodecs.

La seconde vulnérabilité, associée à la référence CVE-2024-2887, a été découverte par Manfred Paul de l'équipe Trend Micro Zero Day Initiative. Il s'agit d'une faiblesse de type "type confusion" présente dans le composant WebAssembly. Ces deux vulnérabilités sont considérées comme importantes.

Par ailleurs, d'autres vulnérabilités ont été reportées directement à Google, notamment la faille de sécurité critique CVE-2024-2883, découverte par Cassidy Kim le 3 mars 2024. Il s'agit d'une vulnérabilité de type "use after free" dans ANGLE.

Pour vous protéger, vous devez mettre à jour Google Chrome pour passer sur les versions 123.0.6312.86/.87 pour Windows et Mac, ainsi que la version 123.0.6312.86 pour Linux. Les versions antérieures sont vulnérables. Vous pouvez obtenir plus d'informations dans le bulletin de sécurité de Google.

Pour rappel, suite aux vulnérabilités découvertes à l'occasion de cette compétition de hacking, la Fondation Mozilla a mis en ligne une nouvelle version pour son navigateur afin de combler deux failles de sécurité zero-day : Firefox 124.0.1. Enfin, sachez que Manfred Paul est le grand gagnant de cette édition du Pwn2Own Vancouver 2024 grâce à plusieurs vulnérabilités découvertes dans Mozilla Firefox, Apple Safari, Google Chrome et Microsoft Edge.

The post Mettez à jour Google Chrome pour vous protéger de 7 vulnérabilités, dont 2 zero-day first appeared on IT-Connect.

En 72 heures, le botnet TheMoon a compromis 6 000 routeurs ASUS

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.

Source

The post En 72 heures, le botnet TheMoon a compromis 6 000 routeurs ASUS first appeared on IT-Connect.

Le kit de phishing Tycoon 2FA contourne le MFA et cible les comptes Microsoft 365 et Gmail !

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 proxy qui 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.

Source

The post Le kit de phishing Tycoon 2FA contourne le MFA et cible les comptes Microsoft 365 et Gmail ! first appeared on IT-Connect.

Sécurité de l’Active Directory : comprendre et se protéger de l’attaque ASREPRoast

I. Présentation

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) auprès des services du domaine, lui permettant d'accéder à ceux-ci 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.
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 n'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".
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.

Cette attaque est très connue des attaquants, si bien qu'elle dispose de son propre TTP (Tactics, Technics and Procedures) dans le framework MITRE ATT&CK : T1558.004- Steal or Forge Kerberos Tickets: AS-REP Roasting.

B. Dans le détail

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".
"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-REQ" 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.
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 n'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) à différents services :

Transmission d'un TGT par le service Keberos suite à une authentification réussie.
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".
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 utiliser ce TGT pour demander des TGS aux services du domaine et y accéder.

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.
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.
Paramétrage d'un mot de passe faible sur le compte utilisateur.

Voilà, notre Lab d'entrainement est prêt !

IV. Point de vue de l'attaquant

Soyez vigilant à n'exploiter ou même tenter de découvrir cette vulnérabilité que si vous y êtes autorisé. Pour rappel : Code pénal : Chapitre III : Des atteintes aux systèmes de traitement automatisé de données

A. Trouver une liste de noms

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 :

ldapsearch -v -x -D "[email protected]" -W -b "DC=it-connect,DC=tech"  -H "ldap://ad01.it-connect.tech" "(&(objectClass=user))" sAMAccountName |grep "sAMAccountName:" |cut -d " " -f 2 > /tmp/userlist

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".
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)) :

impacket-GetNPUsers -usersfile /tmp/userlist -request -format hashcat -outputfile /tmp/IMPACKET_asreproast_blackbox.txt -dc-ip 192.168.56.102 'it-connect.tech/'

L'outil netexec (NXC), également très présent dans les opérations offensives, peut aussi être utilisé :

netexec ldap 192.168.56.102 -u /tmp/userlist -p '' -d it-connect.tech --asreproast /tmp/NXC-asreproast_blackbox.out
  • ASREPRoast en boite grise

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 :

impacket-GetNPUsers -request -format hashcat -outputfile ASREProastables.txt -dc-ip 192.168.56.102 'it-connect.tech/mmartin:MyPassword1!'  -outputfile /tmp/IMPACKET_asreproast_greybox.txt

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 :

netexec ldap 192.168.56.102 -u mmartin -p 'MyPassword1!' --asreproast /tmp/NXC-asreproast_greybox.txt

Voici le résultat attendu pour "impacket-GetNPUsers" et "netexec" :

Utilisation de "impacket-gtNPUsers" et "netexec" pour la réalisation d'une attaque ASREPRoast.
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.
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" :

.\Rubeus.exe asreproast /format:hashcat /outfile:hashes.asreproast

Voici le résultat attendu :

Utilisation de "Rubeus.exe" pour la réalisation d'une attaque ASREPRoast.
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 :

Get-ADUser -Filter 'useraccountcontrol -band 4194304' -Properties useraccountcontrol | Format-Table name, DistinguisedName, Enabled

Voici le résultat attendu :

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.
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" :

PS C:\> Set-ADAccountControl -Identity rdubois -DoesNotRequirePreAuth $false

À 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.

https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4768

Cet évènement apparait donc si :

  • 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.
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"
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.
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.
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 !

The post Sécurité de l’Active Directory : comprendre et se protéger de l’attaque ASREPRoast first appeared on IT-Connect.

Phishing : plus de 100 organisations en Europe et aux États-Unis impactées par StrelaStealer

Une centaine d'organisations situées aux États-Unis et en Europe ont été victime d'une nouvelle campagne malveillante visant à déployer le malware StrelaStealer ! Voici ce qu'il faut savoir sur cette menace.

L'Unit42 de Palo Alto Networks a publié un rapport au sujet de la menace StrelaStealer, un logiciel malveillant repéré pour la première fois en novembre 2022. Après avoir infecté une machine, son objectif est de voler les informations d'identification des comptes de messagerie dans les applications Outlook et Thunderbird.

Alors qu'à la base ce malware ciblait principalement les utilisateurs hispanophones, il s'avère que les cybercriminels ont fait évoluer leur plan : désormais l'Europe et les États-Unis sont pris pour cible. Pour cela, les pirates n'hésitent pas à traduire en plusieurs langues les fichiers utilisés par ce malware, ce qui le rend polyglotte et lui permet de s'adapter à la cible.

Comme beaucoup d'autres logiciels malveillants, StrelaStealer est distribué par l'intermédiaire de phishing. Depuis la fin du mois de janvier, l'Unit42 a détecté une forte hausse de l'activité avec un important volume d'e-mails malveillants envoyés par jour. L'Unit42 évoque jusqu'à 500 organisations ciblées par jour et il y a eu des victimes : "Récemment, nos chercheurs ont identifié une vague de campagnes StrelaStealer à grande échelle touchant plus de 100 organisations dans l'UE et aux États-Unis.", peut-on lire dans le rapport. Dans la grande majorité des cas, ce sont les organisations du secteur des nouvelles technologies qui ont été les plus visées.

Source : Unit42

La chaine d'infection de StrelaStealer

Les pirates ont fait évoluer la chaine d'infection du malware StrelaStealer. Désormais, l'e-mail malveillant contient une pièce jointe au format ZIP qui a pour objectif de déposer des fichiers JScript sur la machine de la victime. Dans le cas où ces scripts sont exécutés, ils déposent un fichier batch et un fichier encodé en base64, qui donne lieu à une DLL qui sera exécutée via rundll32.exe afin de déployer le payload StrelaStealer.

Le schéma ci-dessous, issu du rapport d'Unit42 permet de comparer l'ancienne et la nouvelle chaine d'infection.

Source : Unit42

Si le logiciel malveillant est déployé, il vole les identifiants mémorisés dans Outlook et Thunderbird et ces informations sont immédiatement envoyées aux attaquants par l'intermédiaire d'un serveur C2.

Une fois de plus, méfiance avec les e-mails...

Source

The post Phishing : plus de 100 organisations en Europe et aux États-Unis impactées par StrelaStealer first appeared on IT-Connect.

La faille matérielle GoFetch affecte les puces Apple M1, M2 et M3 et ne peut pas être corrigée !

GoFetch, c'est le nom d'une attaque qui exploite une faille de sécurité importante découverte dans les puces Apple M1, M2 et M3 utilisées par les générations les plus récentes de Mac. La particularité de cette vulnérabilité : elle ne peut pas être corrigée, à moins d'impacter très fortement les performances des puces fabriquées par Apple. Faisons le point !

Une équipe de chercheurs du MIT Computer Science & Artificial Intelligence Laboratory (CSAIL) a mis au point une technique d'attaque baptisée GoFetch, qui exploite une faille de sécurité matérielle présente dans les puces Apple Silicon. Cette attaque de type "side-channel" cible une fonction d'optimisation matérielle appelée Data Memory-dependent Prefetcher (DMP).

Le DMP est une fonction intégrée dans les puces Apple et qui a pour objectif d'aider le processeur à deviner les données dont il pourrait avoir besoin ensuite afin d'optimiser les performances (principe du prefetch). Dans le cas présent, l'attaque permet de tromper la fonction DMP afin qu'elle révèle des informations sensibles stockées en mémoire.

En effet, en exploitant GoFetch, un attaquant pourrait extraire des clés cryptographiques stockées sur un Mac (OpenSSL Diffie-Hellman, Go RSA, CRYSTALS Kyber et Dilithium) dans le but de contourner les opérations de chiffrement effectuées directement par la puce Apple Silicon. Il serait possible de compromettre les clés utilisées par divers algorithmes de chiffrement. In fine, ceci facilite l'accès aux données stockées sur le Mac.

Pour mener à bien cette attaque, l'attaquant doit convaincre la victime d'exécuter un malware (par l'intermédiaire d'un e-mail malveillant, par exemple). Le malware doit être exécuté en parallèle de l'application prise pour cible, et ce, pendant un certain temps afin de pouvoir voler la clé.

Comment se protéger de la faille GoFetch ?

GoFetch fait référence à une faille de sécurité matérielle dans l'architecture même des puces Apple, donc en raison de sa nature, il ne sera pas possible de corriger directement la vulnérabilité. L'intégration d'un correctif ou d'une mesure d'atténuation va passer par la couche logicielle.

Le problème, c'est que la mise en œuvre d'un quelconque correctif va très fortement dégrader les performances des puces Apple, en particulier les deux premières générations : Apple M1 et M2. D'ailleurs, au passage, cette histoire n'est pas sans rappeler les failles de sécurité Meltdown et Spectre qui touchaient de nombreux processeurs Intel et AMD et dont la correction impactait également les performances du processeur.

Pour en savoir plus, vous pouvez consulter le site officiel de GoFetch. Sur ce site, il est d'ailleurs précisé qu'un code PoC sera mis en ligne prochainement... Apple ne s'est pas encore exprimé au sujet de GoFetch. Affaire à suivre...

The post La faille matérielle GoFetch affecte les puces Apple M1, M2 et M3 et ne peut pas être corrigée ! first appeared on IT-Connect.

Dans Firefox 124.0.1, Mozilla a corrigé deux failles de sécurité zero-day !

Quelques jours après avoir dévoilé Firefox 124.0, la fondation Mozilla a mis en ligne la version 124.0.1 de Firefox dans le but de patcher deux failles de sécurité zero-day ! Voici ce qu'il faut savoir sur ces vulnérabilités.

Le mardi 19 mars 2024, la fondation Mozilla a publié la version 124.0 de son navigateur Firefox, dans le but de corriger 12 failles de sécurité, dont cinq vulnérabilités importantes et une vulnérabilité critique. D'ailleurs, cette faille de sécurité critique, associée à la référence CVE-2024-2615, pourrait permettre à un attaquant d'exécuter du code arbitraire sur la machine de l'utilisateur.

Puis, le vendredi 22 mars 2024, Mozilla a mis en ligne une nouvelle version de son navigateur Firefox : 124.0.1. Cette fois-ci, l'objectif est de corriger deux failles de sécurité zero-day découvertes et exploitées un jour plus tôt lors de la compétition de hacking Pwn2Own Vancouver 2024.

D'ailleurs, à l'occasion de cette compétition de hacking, les participants sont parvenus à découvrir 29 failles de sécurité dans différents produits. En ce qui concerne les vulnérabilités dans Firefox, elles ont été découvertes par Manfred Paul (récompensé à auteur de 100 000 dollars) pour avoir exploité une faille de type "out-of-bounds write" (CVE-2024-29943) permettant d'exécuter du code à distance et d'échapper à la sandbox de Mozilla Firefox en exploitant une faiblesse dans une fonction du navigateur (CVE-2024-29944). Manfred Paul est membre de la Trend Micro Zero Day Initiative.

Dans son bulletin de sécurité, Mozilla a apporté quelques détails supplémentaires sur ces vulnérabilités qui affectent les versions desktop de son navigateur Firefox. Pour le moment, elles ne sont pas exploitées par les cybercriminels.

Pour vous protéger, vous devez passer sur Firefox 124.0.1 ou Firefox ESR 115.9.1, en fonction de la version que vous utilisez. Enfin, nous pouvons saluer la réactivité des équipes de Mozilla pour la correction de ces deux failles de sécurité, ainsi que Manfred Paul, grand gagnant de cette édition avec 25 points Master of Pwn. Grâce aux vulnérabilités qu'il a découvertes dans Mozilla Firefox, Apple Safari, Google Chrome et Microsoft Edge, il a pu empocher 202 500 dollars de gain en cash.

Source

The post Dans Firefox 124.0.1, Mozilla a corrigé deux failles de sécurité zero-day ! first appeared on IT-Connect.

Cette faille critique dans FortiClient EMS permet d’exécuter du code à distance en tant que SYSTEM

Une faille de sécurité critique présente dans la solution FortiClient Enterprise Management Server (EMS) de chez Fortinet est activement exploitée par les cybercriminels ! Voici ce qu'il faut savoir sur cette menace !

Le 12 mars 2024, Fortinet a mis en ligne un bulletin de sécurité pour informer ses utilisateurs de la présence d'une vulnérabilité critique (score CVSSv3 de 9.3 sur 10) présente dans la solution FortiClient EMS.

Associée à la référence CVE-2023-48788, il s'agit d'une faiblesse de type "injection SQL" permettant à un attaquant non authentifié d'exécuter du code ou des commandes à distance sur la machine vulnérable. Autrement dit, un attaquant en mesure de communiquer avec un serveur vulnérable peut exécuter du code avec les privilèges SYSTEM dans le but de compromettre la machine.

Dans ce même bulletin de sécurité, nous pouvons lire ceci : "Cette vulnérabilité est exploitée dans la nature". De plus, mercredi 20 mars 2024, les chercheurs en sécurité de chez Horizon3.ai ont mis en ligne un rapport et un exploit PoC au sujet de cette faille de sécurité. Cet exploit se présente sous la forme d'un script Python et il est disponible sur GitHub.

"Pour transformer cette vulnérabilité d'injection SQL en exécution de code à distance, nous avons utilisé la fonctionnalité xp_cmdshell intégrée de Microsoft SQL Server.", peut-on lire dans le rapport d'Horizon3.ai. Cette fonction n'est pas activée par défaut sur SQL Server, ce qui explique de jouer certaines commandes en amont par l'intermédiaire de l'injection SQL.

Une recherche sur Shodan montre qu'il y a actuellement 446 serveurs FortiClient EMS exposés sur Internet, dont 13 en France et au Canada, 8 en Suisse et 4 en Belgique.

Shodan - CVE-2023-48788 - 21 mars 2024

Comment se protéger ?

Voici un tableau récapitulatif avec la liste des versions affectées et la liste des versions qui intègrent un correctif de sécurité pour la CVE-2023-48788.

Version (branche)Versions vulnérablesSolution
FortiClientEMS 7.27.2.0 à 7.2.2Mettre à niveau vers 7.2.3 ou supérieur
FortiClientEMS 7.07.0.1 à 7.0.10Mettre à niveau vers 7.0.11 ou supérieur

Source

The post Cette faille critique dans FortiClient EMS permet d’exécuter du code à distance en tant que SYSTEM first appeared on IT-Connect.

Avec l’IA, GitHub va détecter et corriger les vulnérabilités dans votre code !

"Code Scanning Autofix", c'est le nom de la nouvelle fonctionnalité lancée par GitHub ! Elle a pour objectif d'analyser votre code à la recherche de vulnérabilités, et surtout, d'automatiser la correction à votre place.

La fonctionnalité "Code Scanning Autofix" est disponible en beta publique, et elle est activée par défaut sur tous les dépôts privés des utilisateurs de GitHub Advanced Security. Elle bénéficie de l'intelligence artificielle au travers de GitHub Copilot et CodeQL, ce dernier étant le moteur d'analyse de code développé par GitHub pour automatiser les contrôles de sécurité.

Au sein de son article de blog, GitHub annonce que la correction automatique du code "couvre plus de 90% des types d'alertes en JavaScript, Typescript, Java et Python, et propose des suggestions de code permettant de corriger plus des deux tiers des vulnérabilités trouvées avec peu ou pas de modifications."

Il est à noter que cette fonctionnalité ne va pas uniquement corriger le code, elle va aussi prendre le temps de vous expliquer en langage naturel la suggestion de correction permettant d'améliorer la sécurité de votre code. GitHub précise que le développeur peut accepter, modifier ou rejeter la suggestion proposée par l'IA. L'analyse peut être effectuée sur un ou plusieurs fichiers, ainsi que sur les dépendances d'un projet.

Source : GitHub

Cette fonctionnalité est particulièrement intéressante pour augmenter le niveau de sécurité du code produit par les développeurs. Ceci permet d'avoir un suivi en "temps réel" de son code et de pouvoir être proactif dans la détection de vulnérabilités. Néanmoins, il faut garder à l'esprit que l'IA peut tenter de corriger une vulnérabilité, mais le correctif est-il réellement complet ? Il semble important de s'en assurer.

Dans les prochains mois, GitHub ajoutera la prise en charge de deux autres langages : C# et Go. En attendant, je vous laisse avec la vidéo de présentation de cette nouveauté :

Pour en savoir plus, vous pouvez consulter cette documentation officielle.

The post Avec l’IA, GitHub va détecter et corriger les vulnérabilités dans votre code ! first appeared on IT-Connect.

19 millions de mots de passe en clair exposés dans des instances Firebase mal configurées !

Des chercheurs en sécurité sont parvenus à mettre la main sur 19 millions de mots de passe en clair exposés au sein d'instances Firebase mal configurées ! Accessibles publiques, n'importe qui pouvait accéder à ces informations sensibles. Faisons le point sur cette découverte !

Firebase est une plateforme proposée par Google permettant le développement d'applications web et mobile, ainsi que la création de bases de données. Comme tous les services, une mauvaise configuration peut être lourde de conséquence... Ceci est l'occasion de rappeler que les incidents de sécurité ne sont pas systématiquement associés à une vulnérabilité.

D'ailleurs, trois chercheurs en sécurité ont pris l'initiative d'analyser plus de cinq millions de domaines à la recherche d'instances mal configurées ou sans règles de sécurité. S'ils ont mené ces travaux, ce n'est pas par hasard. En effet, récemment, ils sont parvenus à obtenir des droits d'administrateur, puis de super-administrateur sur une instance de Firebase utilisée par la solution Chattr. Cette découverte a poussé les chercheurs à analyser les serveurs exposés sur Internet.

Des noms, des e-mails, des mots de passe, des factures, etc.

Ce scan, qui aura nécessité environ 1 mois, a permis d'identifier 916 sites web vulnérables, avec certaines bases de données Firestore accessibles en écriture. Sur ces instances vulnérables, les chercheurs sont parvenus à collecter plus de 125 millions d'enregistrements avec des données associés à des utilisateurs, avec notamment des adresses e-mail, des noms, des mots de passe, des numéros de téléphone et des informations de facturation avec des coordonnées bancaires.

  • Noms : 84 221 169
  • Emails : 106 266 766
  • Numéros de téléphone : 33 559 863
  • Mots de passe : 20 185 831
  • Informations de facturation (coordonnées bancaires, factures, etc.) : 27 487 924

Le pire, c'est que 98% des mots de passe découverts sont en texte clair (soit 19 867 627 mots de passe). Ceci est regrettable, car Firebase propose toutes les options nécessaires pour éviter d'exposer les mots de passe. Il s'agit clairement d'une mauvaise configuration.

Ensuite, les chercheurs ont pris le temps d'identifier et de contacter toutes les entreprises concernées afin de les notifier. Au total, en 13 jours, ils ont envoyé 842 e-mails. Même s'ils n'ont pas obtenu de réponse, il est à noter que 25% des entreprises notifiées ont fait le nécessaire pour sécuriser leur instance Firebase.

Source

The post 19 millions de mots de passe en clair exposés dans des instances Firebase mal configurées ! first appeared on IT-Connect.

Passez sur Firefox 124 pour vous protéger de cette faille de sécurité critique (CVE-2024-2615) !

Firefox 124 a été publié par la fondation Mozilla ! Quelles sont les nouveautés de cette version ? Parlons-en, mais nous allons surtout nous intéresser à une faille de sécurité critique corrigée par les développeurs.

Ce mardi 19 mars 2024, la fondation Mozilla a publié la version 124.0 de son navigateur Firefox. Une nouvelle version associée à la publication d'une page qui regroupe toutes les nouveautés apportées à cette version.

Firefox 124 introduit de nouvelles options d'accessibilité, avec notamment la prise en charge du mode de navigation par curseur dans le lecteur PDF du navigateur. De plus, Firefox View est désormais capable de trier vos onglets par activité récente (par défaut) ou par ordre de tabulation. A noter également que la disponibilité de Qwant a été étendue à toutes les langues de la région France, ainsi qu'à la Belgique, l'Italie, les Pays-Bas, l'Espagne et la Suisse.

12 failles de sécurité corrigées par Firefox 124

Par ailleurs, et ce que nous allons évoquer maintenant, les développeurs ont corrigé 12 failles de sécurité, dont cinq vulnérabilités importantes et une vulnérabilité critique. Associée à la référence CVE-2024-2615, cette vulnérabilité a été découverte par Paul Bone et les membres de Mozilla Fuzzing Team. Il s'agit d'un problème de sécurité dans la mémoire.

Le bulletin de sécurité de Mozilla est clair : cette vulnérabilité pourrait permettre à un attaquant d'exécuter du code arbitraire sur la machine de l'utilisateur.

La faille de sécurité CVE-2024-2615 affecte uniquement le navigateur Mozilla Firefox. Toutefois, Mozilla a corrigé plusieurs vulnérabilités dans la version Firefox ESR, ainsi que dans son client de messagerie Thunderbird.

Voici la liste des produits et versions affectés par différentes vulnérabilités :

  • Firefox versions antérieures à 124
  • Firefox ESR versions antérieures à 115.9
  • Thunderbird versions antérieures à 115.9

Le CERT-FR a publié un avis de sécurité au sujet de ces vulnérabilités présentes dans les produits de Mozilla : "Certaines d'entre elles permettent à un attaquant de provoquer un problème de sécurité non spécifié par l'éditeur, une exécution de code arbitraire à distance et une atteinte à la confidentialité des données.", peut-on lire.

Maintenant, c'est à vous de faire le nécessaire pour mettre à jour les applications Firefox et Thunderbird.

The post Passez sur Firefox 124 pour vous protéger de cette faille de sécurité critique (CVE-2024-2615) ! first appeared on IT-Connect.

Hack The Box – Résoudre la box Manager : outils, méthodes et recommandations pour se protéger

I. Présentation

Dans cet article, je vous propose la résolution de la machine Hack The Box Manager, de difficulté "Medium".

Hack The Box est une plateforme en ligne qui met à disposition des systèmes vulnérables appelées "box". Chaque système est différent et doit être attaqué en adoptant la démarche d'un cyberattaquant. L'objectif est d'y découvrir les vulnérabilités qui nous permettront de compromettre les utilisateurs du système, puis le compte root ou administrateur.

Ces exercices permettent de s’entraîner légalement sur des environnements technologiques divers (Linux, Windows, Active directory, web, etc.), peuvent être utiles pour tous ceux qui travaillent dans la cybersécurité (attaquants comme défenseurs) et sont très formateurs 🙂

Je vais ici vous détailler la marche à suivre pour arriver au bout de cette box en vous donnant autant de conseils et ressources que possible. N'hésitez pas à consulter les nombreux liens qui sont présents dans l'article.

Cette solution est publiée en accord avec les règles d'HackThebox et ne sera diffusée que lorsque la box en question sera indiquée comme "Retired".

Technologies/attaques abordéesWindows, Kerberos, Active Directory, Brute force, MSSQL, AD-CS
Outils utilisésnmap, kerbrute, impacket, evil-winrm, certipy

Retrouvez tous nos articles Hack The Box via ce lien :

II. Résolution de la box Manager

A. Découverte et énumération

Pour l'instant, nous ne disposons que de l'adresse IP de notre cible. Commençons par un scan réseau à l'aide de l'outil nmap pour découvrir les services exposés sur le réseau, et pourquoi pas leurs versions.

Technique d'attaque (MITRE ATT&CK) : T1046 - Network Service Discovery

$nmap --max-retries 1 -T4 -sS -A -v --open -p- 10.10.11.236

Nmap scan report for 10.10.11.236
PORT      STATE SERVICE       VERSION
53/tcp    open  domain        Simple DNS Plus
80/tcp    open  http          Microsoft IIS httpd 10.0
   |_http-server-header: Microsoft-IIS/10.0
   | http-methods: 
   |   Supported Methods: OPTIONS TRACE GET HEAD POST
   |_  Potentially risky methods: TRACE
   |_http-title: Manager
88/tcp    open  kerberos-sec  Microsoft Windows Kerberos (server time: 2023-10-25 18:44:02Z)
135/tcp   open  msrpc         Microsoft Windows RPC
139/tcp   open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp   open  ldap          Microsoft Windows Active Directory LDAP (Domain: manager.htb0., Site: Default-First-Site-Name)
445/tcp   open  microsoft-ds?
464/tcp   open  kpasswd5?
593/tcp   open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp   open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: manager.htb0., Site: Default-First-Site-Name)
1433/tcp  open  ms-sql-s      Microsoft SQL Server 2019 15.00.2000.00; RTM
    | ms-sql-info: 
    |   10.10.11.236:1433: 
    |     Version: 
    |       name: Microsoft SQL Server 2019 RTM
    |       number: 15.00.2000.00
    |       Product: Microsoft SQL Server 2019
    |       Service pack level: RTM
    |       Post-SP patches applied: false

5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
    |_http-title: Not Found
    |_http-server-header: Microsoft-HTTPAPI/2.0
9389/tcp  open  mc-nmf        .NET Message Framing

Nous voyons ici clairement que nous sommes sur un système d'exploitation Windows sans pare-feu. Nous pouvons également comprendre, grâce aux ports exposés, qu'il s'agit d'un Active Directory. Les Active Directory sont quasiment les seuls systèmes à exposer un service Kerberos (port TCP/88), un service DNS (TCP/53) ainsi que les services RPC et SMB habituels (TCP/135, TCP/139 et TCP/445). Nous voyons également un service de base de données MSSQL sur le port TCP/1433, beaucoup moins commun sur un Active Directory.

Technique d'attaque (MITRE ATT&CK) : T1087.002 - Account Discovery: Domain Account

Un annuaire Active Directory est une cible des plus intéressantes pour un attaquant, c'est LA cible principale puisque sa compromission nous donne accès aux clés du domaine (littéralement). Problème ici, nous n'avons aucun identifiant valide et toutes nos tentatives de trouver une CVE ou un service mal configuré avec un accès anonyme se sont soldées par un échec. Nous allons devoir y aller "à l'aveugle" grâce à une fonctionnalité (et non pas une vulnérabilité) du service Kerberos : l'authentification (AS-REQ).

Lorsqu'un utilisateur souhaite interagir avec le service Kerberos de notre AD, il doit au préalable être authentifié (sauf cas spécifiques avec l'attribut DONT_REQ_PREAUTH, bref). Il se trouve que le service Kerberos permet, nativement, l'énumération des utilisateurs lors de la phase d'authentification (c'est-à-dire avant authentification). Voyons cela de plus près :

Dans la trace réseau ci-dessus, j’envoie un paquet de type "AS_REQ" (Authentication Service Request) au service Kerberos ciblé. Celui-ci me répond avec un message "KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN" (Client not found in Kerberos database). Plutôt explicite, le nom d'utilisateur spécifié n'est pas reconnu par le service Kerberos, il n'existe pas. Voyons ce que cela donne avec un nom d'utilisateur qui existe forcément dans un Active Directory : administrator/administrateur :

La réponse est différente. Nous ne sommes certes pas authentifiés, mais nous avons obtenu une information : le compte administrator existe au sein de l'Active Directory et le service Kerberos nous l'indique indirectement par un changement dans sa réponse.

Nous venons ici de voir ce qu'est une énumération d'utilisateur. Beaucoup plus commune au sein des applications web, l'attaquant est en mesure de savoir, sans être authentifié, si un login utilisateur existe ou n'existe pas. Cela en exploitant un comportement "binaire" du service interrogé qui peut être un message d'erreur, mais aussi un temps de réponse différent.

On ne fait pas grand chose avec cette information, mais l'authentification reposant sur un login et un mot de passe, nous avons ici déjà 50% de l'information à découvrir. Avec du temps et un bon dictionnaire, nous pourrons obtenir une liste de comptes valides, qui deviendront alors des cibles pour nos prochaines attaques.

Cette "faiblesse" est très connue des attaquants et son exploitation est implémentée dans de très nombreux outils visant les Active Directory. Ici, nous allons utiliser l'outil "kerbrute", il se démarque notamment par sa rapidité :

[user@kali-user:/opt/statistically-likely-usernames$ kerbrute userenum -d manager.htb --dc 10.10.11.236 service-accounts.txt -o kerbrute_validUsers_service.txt
2023/10/25 14:20:17 >  [+] VALID USERNAME:       [email protected]
2023/10/25 14:20:17 >  [+] VALID USERNAME:       [email protected]
2023/10/25 14:20:17 >  [+] VALID USERNAME:       [email protected]]()

Je vous dois ici quelques explications. Tout d'abord, le domaine "manager.htb", d’où sort-il ? Nous l'avons en fait obtenu grâce à "nmap" et ses premières opérations d'énumération. Le nom de domaine est divulgué à dessein par l'Active Directory et ses services DNS et LDAP, comment s'authentifier auprès de lui sinon ?

Également, le dictionnaire que j'utilise ici est "service-accounts.txt". Elle provient de l'excellente ressource statistically-likely-usernames. Il s'agit d'une liste de nom (dictionnaires) contenant des noms utilisateur qui, statistiquement, ont de grandes chances de se retrouver dans un Active Directory. Il peut s'agir de nom de services, de noms utilisés pour des tests ou de noms "communs", comme John Smith, Eric Dupont, etc. Encore mieux, les différents dictionnaires proposés sont formatés en fonction des nomenclatures les plus communes. Pour John Smith, on trouvera par exemple le login "john.smith", "j.smith", "jsmith", "john.s". Le seul problème de cette ressource est qu'elle contient majoritairement des noms anglais.

Bref, grâce à "kerbrute", qui a exploité l'énumération utilisateur via l'"AS_REQ" Kerberos et une liste de nom de service statistiquement probable, nous parvenons à identifier le compte "operator".

B. Mot de passe faible et MSSQL

Je renseigne les noms des utilisateurs trouvés dans une liste que je pourrais réutiliser ensuite :

echo "operator" > logins.txt
echo "guest" > logins.txt
echo "administrator" > logins.txt

Il nous faut à présent trouver le mot de passe correspondant à ce compte. Nous allons utiliser "netexec" pour effectuer une authentification via SMB en utilisant les logins identifiés :

Technique d'attaque (MITRE ATT&CK) : T1110.001 - Brute Force: Password Guessing

$ netexec smb 10.10.11.236 -u logins.txt -p logins.txt --no-bruteforce                
SMB         10.10.11.236    445    DC01             [*] Windows 10.0 Build 17763 x64 (name:DC01) (domain:manager.htb) (signing:True) (SMBv1:False)
SMB         10.10.11.236    445    DC01             [+] manager.htb\operator:operator  

Ici, nous allons utiliser notre liste de login à la fois comme entrée du paramètre "-u" (username) et "-p" (password). Avec l'option "--no-bruteforce", l'outil saura que l'on souhaite faire une attaque de type user as pass. Autrement dit, tenter une seule authentification par compte, avec comme mot de passe login utilisateur.

Dans un contexte réaliste, il faut être très vigilant lors de la réalisation d'une authentification avec un compte utilisateur. La réalisation de quelques tentatives d'authentification infructueuses peut bloquer le compte utilisateur pendant plusieurs minutes et perturber un service ou l'activité de l’utilisateur. Avant toute opération, il est nécessaire au minimum de connaitre la politique de mot de passe et de verrouillage en place. La difficulté principale étant que cet élément n'est récupérable qu'en étant authentifié.

Via une attaque de type user as pass, nous sommes sûrs de réaliser qu'une seule tentative d'authentification par compte, les chances de verrouillage sont donc bien moindres.

Notre attaque nous a permis de découvrir que le compte "operator" utilise également "operator" comme mot de passe. Cela est loin d'être rare dans un contexte réalise et c'est d'autant plus le cas pour les comptes non nominatifs comme les comptes de tests ou de service ("formation", "scan", "accueil", "test2023", etc.).

Nous sommes à présent authentifiés sur le domaine ! Il s'agit d'une grande avancée puisque cela nous permet de récupérer un (très) grand nombre d'informations à propos de celui et des différents objets qu'il gère. Nous allons à présent tenter de nous authentifier avec ce compte sur tous les services exposés par le système cible :

Technique d'attaque (MITRE ATT&CK) : T1021 - Remote Services

$ impacket-mssqlclient -windows-auth operator:[email protected]
SQL (MANAGER\Operator  guest@master)>

Succès ! Nous avons donc découvert un compte utilisateur du domaine qui a la permission de s'authentifier sur le service de base de données MSSQL. À partir de cet accès, tentons de découvrir les possibilités qui s'offrent à nous. Exploitation d'une version obsolète, vol de données sensibles, exécution de commande ?

Technique d'attaque (MITRE ATT&CK) : T1505.001 - Server Software Component: SQL Stored Procedures

Après plusieurs tentatives d'énumération, je découvre notamment que beaucoup d'instruction permettant classiquement l'exécution de commande ne sont pas autorisées pour mon utilisateur. Une exception apparait cependant parmi les nombreux cas d'usage de ma todo-list: "EXEC xp_dirtree" :

SQL (MANAGER\Operator  guest@master)> select @@version;

Microsoft SQL Server 2019 (RTM) - 15.0.2000.5 (X64) 
        Sep 24 2019 13:48:23 
        Copyright (C) 2019 Microsoft Corporation
        Express Edition (64-bit) on Windows Server 2019 Standard 10.0 <X64> (Build 17763: ) (Hypervisor)

SQL (MANAGER\Operatorest@master)> EXEC xp_dirtree 'C:\inetpub\wwwroot', 1, 1

Cette commande permet de lister le contenu d'un répertoire du système :

Technique d'attaque (MITRE ATT&CK) : T1083 - File and Directory Discovery

about.html
contact.html
css
images
index.html
js
service.html
web.config
website-backup-27-07-23-old.zip

Dans le résultat du listing du contenu du répertoire web, on découvre notamment une archive ZIP oubliée (un cas bien plus classique que l'on pourrait le croire). Cela signifie que cette archive est téléchargeable depuis le service web exposé, il suffisait de trouver son nom, ce qui est chose faite à présent.

Technique d'attaque (MITRE ATT&CK) : T1552.001 - Unsecured Credentials: Credentials In Files

$ wget http://10.10.11.236/website-backup-27-07-23-old.zip
$ unzip website-backup-27-07-23-old.zip
$ cat .old-conf.xml 
[...]
         <user>[email protected]</user>
         <password>R4v3nBe5tD3veloP3r!123</password>

À l'intérieur de l'archive se trouve notamment un fichier XML contenant des identifiants utilisateur. Encore une fois, il va être important ici de tenter ces identifiants sur tous les services exposés. Il peut s'agir d'un compte ayant des droits d'accès à un nouveau partage SMB, ou au service MSSQL avec l'accès à des commandes ou base de données supplémentaires, etc.

Technique d'attaque (MITRE ATT&CK) : T1021.006 - Remote Services: Windows Remote Management

$ evil-winrm -i 10.10.11.236 -u raven -p 'R4v3nBe5tD3veloP3r!123'
*Evil-WinRM* PS C:\Users\Raven\Desktop> type user.txt
14895a[REDACTED]5846a502

Cet utilisateur nous permet l'accès au service WinRM du système !

L'accès au service WinRM est le résultat de l'assignation de permissions spécifiques à cet utilisateur ou de l'appartenance à un groupe de permissions (généralement Remote Management Users). Lors d'une intrusion, l'attaquant cherchera à cibler des utilisateurs avec ce genre de permissions spéciales, car ils seront certains d'obtenir par la suite un accès interactif à des systèmes.

C. ADCS : Manipulation des certificats

Parmi la très longue liste des éléments à étudier pour un attaquant lorsqu'il parvient à obtenir un accès authentifié à un domaine Active Directory figure les templates de certificats et la configuration du service ADCS. De nombreuses attaques et outils d'exploitation ont été rendus publiques en 2021 par SpectorOps à ce sujet.

Active Directory Certificate Services est un service Windows Server facilitant la création, la distribution et la gestion de certificats numériques. Les certificats générés par ADCS sont utilisés pour sécuriser les communications en chiffrant les données, authentifier les utilisateurs, garantir l'intégrité des données, permettre des connexions sécurisées au sein du domaine, etc.

Il s'agit tout simplement de la PKI (Public Key Infrastructure) de votre domaine, en gardant à l'esprit qu'un certificat permet également l'authentification, il s'agit d'une cible de choix pour un attaquant.

Nous pouvons commencer par nous assurer qu'un service ADCS existe bien sur le domaine cible, cela à distance depuis Linux à l'aide de l'outil "netexec" :

Ici, "netexec" nous confirme bien que le serveur "DC01.manager.htb" est également le service ADCS du domaine. À présent, nous pouvons tenter d'énumérer les templates de certificats existants au sein de ce service. L'ADCS permet l'émission de certificats avec des paramètres pré-définis grâce à des objets AD appelés template, ou modèles de certificat. Ces templates sont des ensembles de politiques d'inscription et de paramètres de certificat qui contiennent des informations telles que l'usage pouvant être fait du certificat, son temps de validité, qui peut demander la génération d'un certificat, pour quel type d'objet, etc.

Vous pouvez voir la gestion, création et détention d'un certificat comme le cas des badges d'accès dans un bâtiment sécurisé. Les agents d'accueil peuvent créer des badges pour des visiteurs ? Mais peut-être pas pour tous les étages ? Existe-t-il une borne de self-enrollement pour tous les visiteurs ? À quels étages peuvent-ils eux-mêmes se donner accès ? Est-ce qu'un agent d'accueil peut se créer un badge au nom du PDG ? Qui génère le badge des agents d'accueil ? Toutes ces questions peuvent être mises en parallèle avec les attaques sur ADCS.

L'outil "Certipy" peut notamment être utilisé pour découvrir ces configurations de templates, exemple :

pip3 install certipy-ad
certipy-ad find -u '[email protected]' -p 'R4v3nBe5tD3veloP3r!123' -dc-ip 10.10.11.236 -stdout

Voici un extrait du résultat de la commande "certipy-ad" :

L'outil nous a permis de lister la configuration de 33 templates, dont 11 activés. Nous voyons ensuite un bout de la configuration de l'autorité de certification. Entre autres, nous pouvons nous intéresser à la configuration du template 0, histoire de voir ce que cette configuration peut nous apprendre :

Ce template se nomme "KerberosAuthentication", nous voyons notamment que les certificats générés à l'aide de ce template peuvent être utilisés pour l'authentification client ("Client Authentication : True"), mais aussi pour l'authentification côté serveur ("Extended Key usage: Server Authentication") par exemple. La section "Permissions" nous intéresse particulièrement puisqu'elle permet de savoir qui peut utiliser ce template pour enroller (générer) un certificat. Ici, que des membres des groupes "administrateurs".

Si l'on revient au résultat initial, on peut constater que "certipy-ad" nous a indiqué avoir trouvé une configuration dangereuse lors de l'affichage de la configuration de l'autorité de certification :

Au travers l'analyse automatique de la configuration, il semble que l'attaque ESC7 soit exploitable sur ce service ADCS.

Le terme "ESC" fait ici référence à "Escalation". Il s'agit d'une nomenclature choisie par les SpecterOps pour identifier les différentes faiblesses de configuration, et donc attaques, liées à l'AD-CS. Il en existe aujourd'hui 14 (de ESC1 à ESC14 donc). Pour aller en détail sur chacune des exploitations, je vous oriente vers Hacktrickz

ESC7 est donc le cas d'une configuration trop permissive donnée à un utilisateur ou un groupe d'utilisateurs sur l'autorité de certification elle-même.

Comme tout objet AD, l'autorité de certification possède des ACL (Access-Controle List) afin de gérer les actions réalisables par d'autres objets (utilisateurs, groupes, ordinateurs, etc.). Les deux droits principaux ici sont le droit "ManageCA" (« Administrateur CA » ) et le droit "ManageCertificates" ( « Gestionnaire de certificats ».). Si un attaquant prend le contrôle d'un utilisateur qui possède ces droits (ici : "raven"), il pourra alors approuver les demandes de certificat en attente.

Technique d'attaque (MITRE ATT&CK) : T1649 - Steal or Forge Authentication Certificates

L'exploitation de cette vulnérabilité repose sur le fait que les utilisateurs disposant de ces droits peuvent émettre des demandes de certificat, qui, même s'ils échoueront dans un premier temps, pourrons ensuite être approuvés grâce au droit "ManageCertificates".

Le modèle de certificat "SubCA" est par défaut vulnérable à ESC1, mais seuls les administrateurs peuvent utiliser ce template dans le modèle. Ainsi, un utilisateur peut toujours demander à s'inscrire à la "SubCA", ce qui sera refusé. Nous obtiendrons alors notre demande "en attente", qui nous approuverons ensuite avec l'utilisateur compromis ("raven"), qui possède les droits "ManageCertificates".

L'attaque ESC1 est l'un des cas de figure les plus simples. Il concerne les templates qui autorisent la prise en compte de l'attribut SAN (Subject Alternative Name). Celui-ci permet tout simplement à l'utilisateur à définir, en plus de son nom, d'autres noms pour lesquels le certificat sera valide (à tout hasard, administrateur). L'utilisateur demande alors un certificat qui sera valide pour l'utilisateur demandeur (Mickael) mais il inclut dans sa demande un champ supplémentaire disant : le certificat que tu vas me signer sera aussi valide pour "administrateur".

La simplicité de l'attaque est parfois difficile à cerner ("c'est aussi bateau que ça ?") : la réponse est oui.

Voici les pré-requis de l'attaque :

Nous disposons déjà de la permission "ManageCA" grâce à l'utilisateur "raven". Nous pouvons alors nous ajouter les droits "Manage Certificates" (nous sommes maitres de l'autorité de certification, logique que nous puissions nous ajouter les droits de gérer les certificats) :

$ certipy-ad ca -ca 'manager-DC01-CA' -add-officer raven -u [email protected] -p 'R4v3nBe5tD3veloP3r!123' -dc-ip 10.10.11.236
Certipy v4.7.0 - by Oliver Lyak (ly4k)

[*] Successfully added officer 'Raven' on 'manager-DC01-CA'

Le pré-requis n°2 est également atteint, retournons dans notre énumération des templates pour voir si le pré-requis 3 l'est aussi (template "SubCA" activé) :

Tous nos prérequis sont là. Nous pouvons commencer par demander un certificat basé sur le template "SubCA". Cette demande sera refusée, nous ne sommes pas membres des groupes autorisés à s'enroller (regardez le contenu de l'attribut "Enrollment Permissions"). Mais, nous obtiendrons tout de même une clé privée (générée par nous-même, pour notre demande) et notre ID de demande (notez l'option "-upn" dans laquelle nous indiquons le SAN à ajouter au certificat) :

certipy-ad req -ns 10.10.11.236 -ca 'manager-DC01-CA'  -template SubCA -u [email protected] -p 'R4v3nBe5tD3veloP3r!123' -dc-ip 10.10.11.236 -upn [email protected]

Ici, nous venons de demander à l'autorité de certification la création d'un certificat pour l'utilisateur "[email protected]" (grâce à l'attribut SAN) en utilisant le template "SubCA". Vous noterez que bien que ce template soit activé, notre utilisateur ("raven") n'est pas membre des groupes autorisés à utiliser ce template. La demande est donc refusée. Avec nos permissions "ManageCA" et "ManageCertificates", nous pouvons ensuite approuver la demande de certificat ayant échoué avec la commande suivante :

$ certipy-ad ca -ca 'manager-DC01-CA' -issue-request 14  -u '[email protected]' -p 'R4v3nBe5tD3veloP3r!123'  -dc-ip 10.10.11.236                                                                                                          
Certipy v4.7.0 - by Oliver Lyak (ly4k)

[*] Successfully issued certificate

Et enfin, nous pouvons récupérer le certificat émis avec la commande "req" et le paramètre "-retrieve" :

certipy-ad req -ca 'manager-DC01-CA' -target dc01.manager.htb  -template SubCA -u [email protected] -p 'R4v3nBe5tD3veloP3r!123' -dc-ip 10.10.11.236 -retrieve 14

Nous pouvons à présent récupérer le hash NTLM de l'administrateur du domaine en utilisant ce certificat. Il faut pour cela demander un TGT via PKINIT (extension Kerberos prenant en compte les certificats), une fonctionnalité de "backup" y a été ajoutée pour permettre l'authentification sur les services/OS ne prenant pas en compte Kerberos.

Technique d'attaque (MITRE ATT&CK) : T1021.006 - Remote Services: Windows Remote Management

Avec le hash du compte "administrator", nous pouvons effectuer une authentification via la technique pass-the-hash :

$ evil-winrm -i $IP -u administrator -H ae5064c2f62317332c88629e025924ef
*Evil-WinRM* PS C:\Users\Administrator\Desktop> type root.txt
42fabc6[REDACTED]0ff4d

Nous sommes désormais administrateur du contrôleur de domaine, nous avons les clés du royaume !

III. Résumé de l'attaque

Voici une description de l'attaque réalisée en utilisant les TTP (Tactics, Techniques and Procedures) du framework MITRE ATT&CK :

TTP (MITRE ATT&CK)Détails
T1046 - Network Service DiscoverRéalisation d'un scan réseau via "nmap" et découverte de multiple services
T1087.002 - Account Discovery: Domain AccountEnumération d'utilisateur via "kerbrute" et la wordlist "statistically-likely-usernames"
T1110.001 - Brute Force: Password GuessingAttaque "user as pass" sur les comptes du domaine découverts via "netexec", découverte d'identifiants valides
T1021 - Remote ServicesAuthentification sur le service MSSQL avec le compte "operator" compromis
T1505.001 - Server Software Component: SQL Stored ProceduresExécution de commande partielle MSSQL
T1083 - File and Directory DiscoveryDécouverte des fichiers locaux du serveur Windows via MSSQL et exfiltration d'une archive ZIP depuis la racine du service web
T1552.001 - Unsecured Credentials: Credentials In FilesDécouverte d'identifiants de l'utilisateur du domaine "raven" dans l'archive ZIP exfiltrée
T1021.006 - Remote Services: Windows Remote ManagementAuthentification via winRM et LDAP, puis découverte du service AD-CS via "Certipy"
T1649 - Steal or Forge Authentication CertificatesUtilisation de Ccertipy" pour forger un certificat valide pour le compte administrateur du domaine via ESC7, puis ESC1
T1021.006 - Remote Services: Windows Remote ManagementAuthentification avec le compte administrateur du domaine

IV. Notions abordées

A. Côté attaquant

Les premières étapes de compromission de ce serveur sont (hélas) très réalistes. Il est étonnant de voir que la plupart des vulnérabilités sur un domaine proviennent de négligences humaines. Ce genre d'attaque et d'énumération sont à ne jamais oublier sur un domaine. Il faut également savoir adapter ses dictionnaires (et plus largement ses outils) en fonction du contexte métier ou de la langue de la cible.

Nous avons vu lors de l'exploitation du service MSSQL que connaitre ou savoir se documenter rapidement sur les commandes et fonctionnalités natives qui permettent une exploitation est un atout. Ici la commande utilisée ("xp_dirtree") est totalement native à MSSQL, le fait le compte compromis puisse l'utiliser est une faiblesse probablement due à des droits trop permissifs, mais c'est ce qui nous a permis de compromettre le serveur. Sur chaque service de base de données, voir chaque version, il existe des commandes comme celles-ci qui permettent d'écrire ou lire des données sur le serveur, voire exécuter des commandes. Difficile de tout retenir, il faut plutôt opter pour une documentation personnelle ou une banque de liens externes pour être sûr de rester à jour et d'avoir tout sous la main lorsque l'on en aura besoin.

L'attaque sur ADCS est bien entendu ce qui vaut à cette box la notation "Medium" à mon sens. Il faut ici avoir de bonnes notions de l'aspect métier et fonctionnels d'une PKI pour ensuite comprendre l'attaque à réaliser. Cela nous permet de rappeler qu'avant d'apprendre à attaquer, il faut connaitre les bases de l'administration système, de la cryptographie et du développement. Également, il serait difficile de trouver ce genre de vulnérabilité sur un service aussi spécifique qu'ADCS seul sans y passer des dizaines d'heures. Les attaques sur ADCS ont été rendues publiques en 2021 et il fallait bien entendu assurer sa veille technologique afin d'inclure ses faiblesses dans notre méthodologie d'audit d'environnement AD. Pour la pratique, je vous conseille bien sûr cette box Hack the box, mais aussi le lab Try Hack Me suivant : AD Certificate Templates

B. Côté défenseur

Pour sécuriser ce système, nous pouvons proposer plusieurs recommandations :

Recommandation n°1 : il est recommandé de mettre en place une politique de mot de passe robuste interdisant notamment les mots de passe faibles avec un seul alphabet ou le "user as pass". L'application de cette recommandation doit notamment se baser sur le document Recommandations relatives à l'authentification multifacteur et aux mots de passe de l'ANSSI. Côté détection, il est recommandé de surveiller les journaux d'authentification pour détecter les échecs de connexion au niveau du domaine. Si les échecs d'authentification sont nombreux sur une courte période de temps, il peut y avoir une tentative de force brute en cours. Le centralisation des logs et l'utilisation d'un SIEM peuvent ici grandement aider.

Recommandation n°2 : nous pouvons également recommander de supprimer l'archive ZIP située à la racine du service web. Les archives contiennent souvent des données sensibles (configurations, mots de passe) et leur place n'est pas sur un service web accessible sans authentification. Il est recommandé de les stocker dans un emplacement sécurisé, accessible uniquement par des utilisateurs authentifiés. Pour aller plus loin, nous pouvons également recommander de stocker les archives de configuration et de code source de façon chiffrée et, en complément, de durcir la configuration du service web pour interdire l'accès aux fichiers de backup (.zip, .tar, etc.) directement dans la configuration Apache.

Recommandation n°3 : il peut être recommandé d'améliorer la sécurité du service ADCS. De multiples bonnes pratiques existent à ce sujet, mais doit en premier lieu être effectuée une revue des ACL sur les templates de certificats et sur l'autorité de certification afin de s'assurer que seuls des groupes légitimes sont autorisés à y effectuer des actions sensibles. De manière générale, il est d'ailleurs toujours recommandé de passer par des groupes pour l'attribution des droits que l'attribution directe à un utilisateur.

Recommandation n°4 : il est recommandé d'appliquer une séparation stricte des usages sur les services du système d'information. Les services de base de données et de gestion des certificats répondent à des fonctions métiers et de sécurité différents et doivent être positionnés sur des serveurs distincts. Cela afin de rendre plus difficile pour un attaquant la propagation de sa compromission d'un service à l'autre. Pour aller plus loin, il est recommandé de consulter le document La défense en profondeur appliquée aux systèmes d’information de l'ANSSI. (Soyons francs, cette recommandation est plutôt pour le principe, les services sont ici mutualisés sur un même serveur, car Hack The Box ne propose qu'une machine à la fois :D. Mais consultez quand même ce document, très intéressant ! 🙂 ).

J’espère que cet article vous a plu ! N'hésitez pas à donner votre avis dans les commentaires ou sur notre Discord!

Enfin, si vous voulez accéder à des cours et modules dédiés aux techniques offensives ou défensives et améliorer vos compétences en cybersécurité, je vous oriente vers Hack The Box Academy, utilisez ce lien d'inscription (je gagnerai quelques points 🙂 ) : Tester Hack the Box Academy

The post Hack The Box – Résoudre la box Manager : outils, méthodes et recommandations pour se protéger first appeared on IT-Connect.

❌