Cette publication est une collection de divers scénarios d'attaque courants sur Microsoft Entra ID (anciennement connu sous le nom d'Azure Active Directory) et de la manière dont ils peuvent être atténués ou détectés.
Cette publication est un recueil de divers scénarios d'attaque courants sur Microsoft Entra et de la manière dont ils peuvent être atténués ou détectés. Tous les scénarios, informations et commentaires inclus sont basés sur les expériences des contributeurs lors de leurs simulations d'attaque, de scénarios pratiques ou réels.
Il doit être considéré comme un document vivant, qui sera mis à jour au fur et à mesure de l'évolution des pratiques et des changements dans les techniques d'attaque et de défense. Nous invitons les experts en identité ou en sécurité de la communauté à collaborer sur cette publication et à apporter des mises à jour, des retours, des commentaires ou des ajouts supplémentaires.
Dans tous les chapitres, nous suivons les mêmes directives concernant la structure des chapitres. Lors de la lecture, vous pouvez vous attendre à trouver :
Les sections suivantes contiennent une brève description de chaque chapitre que vous pouvez trouver dans le « Entra ID Attack & Defense Playbook ».
L'idée initiale de créer le « Azure AD Attack & Defense Playbook » est venue de Thomas Naunheim. Notre premier appel Teams a eu lieu quelque part à l'automne 2020, où Thomas a présenté l'idée et elle a été immédiatement adoptée.
Le premier chapitre portait sur l'attaque « Password Spray », où nous nous sommes fortement concentrés sur le mécanisme de détection d'Entra ID Protection (anciennement connu sous le nom d'Azure AD Identity Protection) pour détecter les attaques de type « pulvérisation de mots de passe ». Au cours du premier chapitre, nous avons appris que le temps calendaire nécessaire à la finalisation de la recherche pourrait être nettement plus long que prévu en raison de la complexité de la recherche et des différents angles d'approche. Le cadrage, comme dans tout type de travail de projet, est extrêmement important.
Avec les derniers chapitres, nous avons eu la chance d'impliquer d'autres membres de la communauté dans le projet, comme Joosua Santasalo, Fabian Bader et Christopher Brumm, en tant que partenaires d'échange et relecteurs.
Le MITRE ATT&CK Framework est couramment utilisé pour cartographier les Tactiques, Techniques & Procédures (TTP) des actions adverses et pour émuler les défenses des organisations dans le monde entier. Dans ce playbook, nous utilisons le framework MITRE ATT&CK v11 dans tous les chapitres pour faire correspondre les Techniques, Tactiques & Procédures (TTP) aux scénarios d'attaque. Cela aidera les Blue Teams à construire des défenses pour les scénarios correspondants.
Vous pouvez vous attendre à trouver plusieurs règles de détection dans les chapitres individuels, basées sur le scénario d'attaque spécifique. Parce que le playbook contient un grand nombre de règles de détection, nous avons décidé de créer une visualisation qui contient tous les scénarios d'attaque mappés aux TTP. Tenez également compte du fait que chaque chapitre individuel dispose d'une visualisation pour le scénario d'attaque correspondant.
Ouvrir dans MITRE ATT&CK Navigator
Les capacités de détection associées aux produits de sécurité Microsoft (Microsoft Defender XDR, Microsoft Sentinel, Azure Entra ID Connect, Microsoft Defender for Cloud) seront couvertes dans la partie détection des scénarios d'attaque. Les modèles de règles personnalisés pour Microsoft Sentinel, développés pour le playbook, sont également mappés aux TTP. Les règles de détection sont disponibles sous forme de modèle de règle Microsoft Sentinel (prêt à déployer) au format JSON (modèle ARM) ici.
Ouvrir dans MITRE ATT&CK Navigator
Remarque : Nous avons utilisé le mappage TTP existant des modèles de règles Microsoft Sentinel et la corrélation des incidents Microsoft 365. Certaines détections n'offrent pas une couverture complète de MITRE ATT&CK et ne sont pas incluses dans cette visualisation.
En règle générale, un chapitre a pris environ 1 à 2 mois de temps calendaire, il a donc fallu un effort considérable pour rassembler les quatre (4) chapitres et l'annexe. Au cours des deux (2) dernières années, nous avons mené des recherches sur les scénarios suivants :
« Une attaque par pulvérisation de mots de passe consiste à attaquer plusieurs noms d'utilisateur à l'aide de mots de passe courants, dans une approche unifiée de force brute, afin d'obtenir un accès non autorisé. »
Le chapitre a été initialement créé en novembre 2020 et mis à jour en novembre 2021 pour inclure les dernières mises à jour des produits de sécurité de Microsoft Ignite 2021.
Le chapitre contient une brève description de l'attaque et des outils utilisés pour simuler une attaque de type pulvérisation de mots de passe. Dans la partie détection, plusieurs solutions de sécurité Microsoft sont utilisées, telles que Microsoft Sentinel et Defender for Cloud Apps.
En marge, il y a également quelques considérations pour l'environnement sur site et ADFS, si celui-ci est toujours utilisé.
Pulvérisation de mots de passe
« Dans une attaque par octroi illicite de consentement, l'attaquant crée une application enregistrée dans Azure qui demande l'accès à des données telles que les coordonnées, les e-mails ou les documents. L'attaquant amène ensuite un utilisateur final à accorder à cette application le consentement d'accéder à ses données, soit par une attaque de phishing, soit en injectant du code illicite dans un site web de confiance. Une fois que l'application illicite a obtenu le consentement, elle dispose d'un accès au niveau du compte aux données, sans avoir besoin d'un compte organisationnel.
Les mesures de remédiation normales, comme la réinitialisation des mots de passe des comptes compromis ou l'exigence d'une authentification multifacteur (MFA) sur les comptes, ne sont pas efficaces contre ce type d'attaque, car il s'agit d'applications tierces et externes à l'organisation. Ces attaques exploitent un modèle d'interaction qui suppose que l'entité qui appelle les informations est une automatisation et non un humain. »
Le chapitre contient une description de l'attaque et une explication de l'importance de sécuriser et de surveiller les activités autour du framework de consentement d'Entra ID. Dans le chapitre sur la détection, nous avons utilisé les solutions suivantes :
Parce que le sujet est vaste et compliqué, la partie atténuation contient des instructions et des détails sur la façon de réduire la surface d'attaque dans votre environnement.
Dans les deux scénarios d'attaque suivants, nous nous sommes concentrés sur les principaux de service privilégiés dans les pipelines de publication Azure DevOps (ADO) et sur la visibilité (potentiellement) limitée dans l'audit.
ADO est un vaste sujet et, dans ce chapitre, le périmètre se limite uniquement aux scénarios mentionnés ci-dessus. Le même cheminement est suivi ici :
Lorsque nous avons travaillé sur ce chapitre, nous avons passé beaucoup de temps sur les techniques de détection, ce qui était compliqué principalement à cause du schéma des journaux d'audit ADO. Néanmoins, le travail acharné porte ses fruits et nous avons pu atteindre notre objectif défini et détecter les attaques dans Microsoft Sentinel.
Le chapitre contient des informations approfondies sur la sécurisation de l'environnement Azure DevOps dans la partie atténuation.
Dans ce document, nous nous concentrons principalement sur le scénario suivant :
Hors périmètre : l'élévation de privilèges et les chemins d'attaque depuis le serveur AADC en direction d'Active Directory (y compris l'abus du compte connecteur Azure AD DS).
Le dernier chapitre, publié le 14 mars 2022, porte entièrement sur l'abus du compte de service de synchronisation Microsoft Entra Connect. Pour être précis, le compte AAD Connect est responsable de l'exécution des actions côté Azure AD.
Le sujet et le scénario d'attaque ont été extrêmement intéressants pour le travail de recherche et, même si j'ai beaucoup travaillé avec Microsoft Entra Connect par le passé, je dois admettre que j'ai beaucoup appris au cours de la période de deux (2) derniers mois. Nous avons fait des découvertes intéressantes que nous n'avions pas remarquées auparavant.
Si vous avez lu jusqu'ici, je vous encourage à consulter les requêtes KQL pour Microsoft Sentinel que nous avons créées lors de nos travaux de recherche.
Microsoft a introduit Windows 11 avec l'exigence d'utiliser une puce Trusted Platform Module (TPM). Cela a considérablement accru les capacités d'utilisation des fonctionnalités de sécurité de Windows 11, notamment une couche de protection supplémentaire pour les scénarios d'authentification basés sur le cloud. Le jeton Primary Refresh (PRT) et d'autres clés pertinentes peuvent être bien protégés par le TPM sous Windows 11, mais aussi sous Windows 10 et les versions de Windows Server à partir de 2016. Compte tenu de cela, dans ce document, nous nous concentrons principalement sur les scénarios suivants :
L'objectif de l'Entra ID Security Config Analyzer est de fournir une solution qui extrait la configuration de sécurité d'Entra ID des points de terminaison sélectionnés de l'API Microsoft Graph et ingère les données dans Log Analytics. Azure Workbook est utilisé pour la visualisation des données et Microsoft Sentinel peut être utilisé pour créer des alertes/incidents lorsqu'un changement de configuration critique est détecté.
L'image suivante décrit l'architecture de la solution EIDSCA, la solution utilisée et les flux de données :
Architecture de référence pour intégrer EIDSCA dans un environnement Microsoft Sentinel. Les données seront ingérées dans le même espace de travail que Sentinel. Cela dépend de votre implémentation et de votre conception si vous souhaitez avoir une intégration vers un espace de travail Sentinel dédié, opérationnel ou existant.
Les contrôles EIDSCA sont également utilisés dans Maester, plus d'informations dans la documentation Maester
Différents jetons jouent un rôle crucial dans l'authentification cloud. Il est donc important de comprendre leur mécanisme et la manière dont les adversaires peuvent les exploiter s'ils tombent entre de mauvaises mains. Comprendre cela peut aider à construire une protection contre les attaques d'identité.
Le vol de jetons se produit lorsqu'un adversaire accède aux jetons et les compromet. Une fois volés, l'adversaire peut rejouer les jetons volés et accéder au compte compromis. Dans un scénario AiTM, l'adversaire peut contourner l'exigence de MFA, car les revendications MFA sont déjà incluses dans le jeton et les exigences d'authentification sont satisfaites. Par conséquent, l'adversaire accède à l'environnement. Nous détaillerons le scénario, la détection et l'atténuation plus loin dans ce document.
Pour trouver plus d'informations sur les jetons de sécurité Entra ID, consultez les ressources Microsoft Learn suivantes :
Le chapitre du playbook Entra ID Attack & Defense « Replay of Primary Refresh (PRT) and other issued tokens from an Azure AD joined device » éclaire le rejeu du PRT, du jeton d'accès et du jeton d'actualisation :
Dans ce chapitre, nous nous concentrons sur le type d'attaque Adversary-in-the-Middle (AiTM) où l'adversaire intercepte le cookie de session de la victime puis le rejoue pour accéder au service de connexion.
Les cybercriminels utilisent actuellement des techniques de phishing AiTM pour contourner à grande échelle les protections d'authentification multifacteur (MFA). Ces techniques avancées sont démocratisées et amplifiées par le modèle économique cybercriminel du phishing-as-a-service (PhaaS), qui a engendré plusieurs offres de services depuis 2021.
Aujourd'hui, le nombre de plateformes PhaaS capables d'AiTM n'a cessé de croître tout au long de 2023-2024, les services existants ajoutant des capacités AiTM à leurs plateformes et les services nouvellement créés intégrant nativement des techniques de phishing AiTM. Bien que les formes traditionnelles de phishing d'identifiants existent toujours, le nombre d'attaques de phishing AiTM dépasse celles qui n'en sont pas capables.
L'objectif ultime du phishing AiTM est de voler les identifiants des utilisateurs et les cookies de session. Les navigateurs stockent les cookies de session pour permettre aux utilisateurs d'accéder aux services sans avoir à s'authentifier à plusieurs reprises. Le phishing AiTM cible les cookies de session et les identifiants afin de contourner les protections MFA traditionnelles.
Plus d'informations sur PhaaS :
Tout service web moderne implémente une session avec un utilisateur après une authentification réussie, afin que l'utilisateur n'ait pas à s'authentifier à chaque nouvelle page visitée.
Cette fonctionnalité de session est rendue possible par un cookie de session émis par le service d'authentification après l'authentification initiale. Le cookie de session sert de preuve au serveur web que l'utilisateur a été authentifié et conserve une session active sur le site web.
Dans une attaque de phishing AiTM, un attaquant intercepte le cookie de session de l'utilisateur ciblé et le rejoue ensuite pour accéder au service de connexion. Comme le cookie démontre que la vérification MFA a déjà été réussie (revendication incluse dans le jeton), il satisfait à l'exigence MFA, permettant à l'attaquant de contourner les protections MFA et d'accéder au compte utilisateur compromis.
Dans le phishing AiTM via un proxy inverse, le proxy est déployé entre un utilisateur et le site web ou l'application légitime que l'utilisateur souhaite visiter (comme les portails de connexion Microsoft ou LinkedIn). Le proxy inverse transmet les requêtes de l'utilisateur au service réel et intercepte les réponses. Ce type de configuration permet à l'attaquant de voler et d'intercepter le mot de passe de la cible ainsi que le cookie de session qui prouve sa session active et authentifiée avec le site web.
Les kits de phishing populaires parmi les attaquants sont : EvilGinx, Modlishka, Muraena et "Office 365" (EvilProxy). Ces kits de phishing permettent aux attaquants de mener des attaques de phishing AiTM à l'aide de serveurs proxy inverses.
Remarque : dans de nombreuses campagnes, l'application ciblée a été OfficeHome dans les journaux Entra ID.
Schéma de l'attaque de phishing AiTM via proxy inverse (figure initiale issue des rapports Microsoft Defender XDR Threat Intelligence).
Une autre méthode AiTM est appelée 'AiTM phishing through synchronous relay'. Dans ce type d'attaque, une copie ou une imitation d'une page de connexion est présentée à la cible, comme dans les attaques de phishing traditionnelles. Si un utilisateur fournit ses identifiants sur cette page, les identifiants sont stockés sur un serveur contrôlé par l'attaquant, où l'instance du kit de phishing, y compris son panneau d'administration, est installée. En substance, cela signifie que les saisies de l'utilisateur sont volées, notamment les identifiants de connexion, les codes d'authentification à deux facteurs (MFA) et les cookies de session.
Les serveurs de relais sont généralement fournis et contrôlés par le groupe d'acteurs à l'origine du développement et par les parties prenantes responsables de la plateforme PhaaS. Un exemple de ce type de groupe est Storm-1295, qui est derrière la plateforme PhaaS Greatness, selon les rapports Microsoft Threat Intelligence.
Schéma du phishing AiTM via relais synchrone (figure initiale issue des rapports Microsoft Defender XDR Threat Intelligence).
Mise à jour ou nouveau contenu (Pull Request) : Comme déjà mentionné, nous souhaitons avoir un document vivant porté par la communauté Entra ! Partagez vos résultats et vos idées dans le cadre de ce projet ! Envoyez une pull request pour ajouter votre contenu à ce projet.
Issues/Contenu obsolète : Les fonctionnalités de protection ou les outils évoluent continuellement. Mettez à jour le contenu obsolète (dans le cadre d'une pull request) ou créez une issue pour le signaler.
Relecteur : Nous recherchons également des experts souhaitant relire ou discuter du contenu existant ou nouveau avant publication !
Retour d'expérience : N'hésitez pas à suggérer des scénarios d'attaque/défense qui pourraient intéresser la communauté. Nous les ajouterons au backlog et à la collection d'idées !
Il s'agit d'un projet communautaire et non d'une solution ou d'un produit officiel.Le code ou tout autre échantillon de requête est fourni "AS IT IS" sans garantie d'aucune sorte, expresse ou implicite, y compris, mais sans s'y limiter, les garanties implicites de qualité marchande et/ou d'adéquation à un usage particulier. Cet échantillon n'est pris en charge par aucun programme ou service d'assistance. Nous déclinons en outre toute garantie implicite, y compris, sans limitation, toute garantie implicite de qualité marchande ou d'adéquation à un usage particulier. L'intégralité du risque découlant de l'utilisation ou de l'exécution de l'échantillon et de la documentation demeure avec vous. En aucun cas nous, ses auteurs ou toute autre personne impliquée dans la création, la production ou la livraison du script ne serons responsables de quelque dommage que ce soit (y compris, sans limitation, les dommages pour perte de bénéfices, interruption d'activité, perte d'informations commerciales ou autres pertes pécuniaires) découlant de l'utilisation ou de l'impossibilité d'utiliser l'échantillon ou la documentation, même si Microsoft a été informé de la possibilité de tels dommages.
 Sami Lamppu 💬 📖 |  Thomas Naunheim 💬 📖 |
 Joosua Santasalo 💬 📖 |  Markus Pitkäranta 💬 📖 |  Christopher Brumm 💬 📖 |  Fabian Bader 💬 📖 |  Nestori Syynimaa 💬 📖 |  Robbe Van den Daele 💬 📖 |
