Terrance DeJesus

Microsoft Entra ID OAuth Phishing et détections

Un cours accéléré sur les stratégies d'hameçonnage et de détection d'Entra ID OAuth dans la nature (ItW)

40 minutes de lectureDetection Engineering
Microsoft Entra ID OAuth Phishing et détections

Préambule

Les membres de l'équipe TRADE (Threat Research and Detection Engineering) d'Elastic se sont récemment intéressés à une nouvelle catégorie de menaces ciblant les flux de travail OAuth dans Microsoft Entra ID (anciennement Azure AD). Cette recherche a été inspirée par le récent blog de Volexity, Phishing for Codes : Russian Threat Actors Target Microsoft 365 OAuth Workflows, qui attribue une campagne de phishing OAuth sophistiquée contre des ONG à l'acteur de menace désigné UTA0352.

L'enquête de Volexity présente des preuves irréfutables de la manière dont les attaquants ont abusé des applications Microsoft de confiance pour contourner les défenses traditionnelles. À l'aide de flux OAuth légitimes et de l'outil open-source ROADtools, les acteurs ont créé des URL d'authentification Microsoft personnalisées, récolté des jetons de sécurité et les ont exploités pour usurper l'identité d'utilisateurs, élever les privilèges et exfiltrer des données via Microsoft Graph - notamment en téléchargeant des courriels Outlook et en accédant à des sites SharePoint.

Alors que leur rapport documente en détail le contenu de l' attaque, notre équipe chez Elastic s'est attachée à comprendre le comment. Nous avons émulé la chaîne d'attaque dans un environnement contrôlé afin d'explorer directement les mécanismes d'abus de jetons, d'enregistrement des appareils et d'enrichissement des jetons. Cette expérience pratique a permis de mieux comprendre les rouages de l'implémentation OAuth de Microsoft, l'utilisation pratique de ROADtools, les mesures d'atténuation recommandées et, surtout, les stratégies de détection efficaces pour identifier et répondre à des activités similaires.

OAuth dans Microsoft Entra ID

Microsoft Entra ID met en œuvre OAuth 2.0 pour permettre un accès délégué aux services Microsoft 365 tels que Outlook, SharePoint et Graph API. Alors que la spécification OAuth est normalisée(RFC6749), Entra ID introduit des comportements et des types de jetons uniques qui influencent le fonctionnement de l'accès délégué et la manière dont les adversaires les exploitent.

Dans le cas de l'accès délégué, une application est autorisée à agir au nom d'un utilisateur connecté, en fonction des autorisations demandées par l'application et acceptées par l'utilisateur ou l'administrateur. Ce modèle est courant dans les environnements d'entreprise où les applications récupèrent les courriels, les fichiers ou les données de répertoire d'un utilisateur sans demander à chaque fois des informations d'identification.

Un flux typique d'autorisation déléguée comprend

Demande d'autorisation (OAuth 2.0 Authorization Code Grant): L'application demande l'accès à une ressource (par exemple, Graph) avec des portées spécifiques (par exemple, Mail.Read, offline_access). Ils sont ajoutés en tant que paramètres à l'URI.

  • client_id: ID de l'application (par exemple, VSCode)
  • Response_type: Détermine le type de subvention du flux de travail OAuth (par ex. code de l'appareil, code d'authentification)
  • Portée: Permissions demandées pour la ressource cible (par ex. Mail.Read, offline_access)
  • Redirect_uri: Où envoyer nos codes d'autorisation
  • État: Protection CSRF
  • Login_hint: Pré-remplit le nom d'utilisateur

Authentification de l'utilisateur (OpenID Connect): Entra ID authentifie l'utilisateur par le biais d'une politique (mot de passe, MFA, confiance dans l'appareil).

  • Authentification à facteur unique (SFA)
  • Authentification multifactorielle (AMF)
  • Device Trust (Hybrid Join, Intune compliance)
  • Politiques d'accès conditionnel (PAC)
  • Authentification unique (SSO)

Consentement : Le consentement détermine si l'application peut recevoir un code d'autorisation et quels sont les champs d'application autorisés.

  • Les champs d'application autorisés par l'utilisateur (par ex. Mail.Read, offline_access)
  • Admin-Consentement des champs d'application requis (par ex. Directory.ReadWrite) nécessite une approbation élevée.

Émission de jetons: L'application reçoit un code d'autorisation, puis l'échange contre :

  • Jeton d'accès - jeton de courte durée utilisé pour appeler des API telles que Graph.
  • Refresh Token (RT) - jeton à durée de vie plus longue permettant d'obtenir silencieusement de nouveaux jetons d'accès.
  • Jeton d'identité - Décrit l'utilisateur authentifié ; présent dans les flux OpenID.
  • (Facultatif) Jeton de rafraîchissement primaire : si l'utilisateur se trouve sur un appareil connecté à un domaine ou enregistré, un jeton de rafraîchissement primaire (PRT) peut permettre un SSO silencieux et des flux de jetons supplémentaires sans interaction de la part de l'utilisateur.
  • Réclamations de jetons : Les revendications sont des paires clé-valeur intégrées dans les jetons JWT qui décrivent l'utilisateur, l'application, l'appareil, les champs d'application et le contexte de l'authentification.

Qu'est-ce qu'une URL de phishing MSFT OAuth ?

Avant d'examiner les principales conclusions du rapport de Volexity qui nous aident à élaborer notre stratégie de détection, il est important de définir exactement ce qu'est une URL de phishing Microsoft OAuth.

Comme décrit précédemment, Microsoft Entra ID s'appuie sur ces URL pour déterminer quelle application (client) demande l'accès, au nom de quel utilisateur principal, à quelle ressource et avec quelles autorisations. Une grande partie de ce contexte est intégrée directement dans les paramètres de la demande d'autorisation OAuth, ce qui en fait une source essentielle de métadonnées pour les adversaires comme pour les défenseurs.

Voici un exemple d'URL de phishing aligné sur le flux d'octroi du code d'autorisation, adapté du blog de Volexity :

https://login.microsoftonline[.]com/organizations/oauth2/v2.0/authorize?state=https://mae.gov[.]ro/[REMOVED]&client_id=aebc6443-996d-45c2-90f0-388ff96faa56&scope=https://graph.microsoft.com/.default&response_type=code&redirect_uri=https://insiders.vscode.dev/redirect&login_hint=<EMAIL HERE>

Décortiquons quelques-uns des éléments clés :

  • login.microsoftonline.com - Le point final d'authentification Microsoft Entra ID.
  • /oauth2/v2.0/authorize - point de terminaison MSFT Entra ID OAuth v2.0 pour les processus d'autorisation
  • state - Valeur facultative utilisée pour empêcher le CSRF et maintenir l'état de l'application. Il est parfois utilisé de manière abusive pour dissimuler des redirections d'hameçonnage.
  • client_id - L'identifiant de l'application à l'origine de la demande. Il peut s'agir d'applications de Microsoft (comme VSCode, Teams) ou d'applications tierces malveillantes enregistrées par des adversaires.
  • scope - Définit les autorisations demandées par l'application (par exemple, Mail.Read, offline_access). La portée .default est souvent utilisée pour les flux d'informations d'identification des clients afin d'obtenir des autorisations pré-consenties.
  • response_type=code - Indique que le flux demande un code d'autorisation, qui peut ensuite être échangé contre un jeton d'accès et/ou de rafraîchissement.
  • redirect_uri - Où Entra ID enverra la réponse après l'authentification de l'utilisateur. Si un attaquant contrôle cet URI, il obtient le code ou il s'agit d'un URI géré par MSFT qui est valide.
  • login_hint - Spécifie l'utilisateur cible (par exemple, alice @ tenant.onmicrosoft.com). Souvent pré-rempli pour réduire les frictions lors de l'hameçonnage.

Remarque : cet exemple illustre une URL de phishing Microsoft Entra ID OAuth courante, mais il existe de nombreuses variantes. Les adversaires peuvent ajuster des paramètres tels que l'identifiant du client, les champs d'application, les types de subventions ou les URI de redirection en fonction de leurs objectifs spécifiques, qu'il s'agisse d'obtenir un accès permanent, d'exfiltrer des courriels ou d'escalader les privilèges par le biais de subventions de consentement plus larges.

Pourquoi est-ce important ?

Ces paramètres étant personnalisables, les adversaires peuvent facilement intervertir les valeurs pour les adapter à leurs opérations. Par exemple :

  • Ils peuvent utiliser un identifiant client Microsoft légitime pour se fondre dans des applications inoffensives.
  • Ils peuvent utiliser un fichier .default pour contourner les demandes de consentement spécifiques.
  • Ils dirigeront le redirect_uri vers un site qu'ils contrôlent afin de collecter le code d'autorisation.
  • Ils peuvent cibler des utilisateurs spécifiques qu'ils ont pu identifier au cours de leur reconnaissance.
  • Ils peuvent ajuster les autorisations pour cibler les ressources en fonction de leurs besoins opérationnels.

Une fois la cible authentifiée, l'objectif est simple : obtenir un code d'autorisation. Ce code est ensuite échangé (souvent à l'aide d'outils tels que ROADtools) contre un jeton de rafraîchissement et/ou un jeton d'accès, ce qui permet à l'attaquant de faire des appels à l'API Graph ou de pivoter vers d'autres services Microsoft 365 , le tout sans autre interaction de la part de l'utilisateur.

Abstraction des résultats clés de Volexity

Pour la détection des menaces, il est essentiel de comprendre les protocoles comme OAuth, la mise en œuvre du flux de travail dans Microsoft Entra ID, et les métadonnées contextuelles sur les comportements et/ou les mesures prises par l'adversaire concernant cette opération.

L'enquête et les recherches menées par Volexity nous permettent d'identifier les différentes variantes de phishing OAuth signalées. Nous avons décidé de les décomposer pour faciliter la compréhension :

OAuth Phishing To Access Graph API as VSCode Client On-Behalf-Of Target User Principal: Ces URL sont similaires à notre exemple "What Defines an MSFT OAuth Phishing URL" - l'objectif final étant un jeton d'accès à Graph API avec des permissions par défaut.

  • Les URL d'hameçonnage OAuth étaient personnalisées et pointaient vers "authorize" endpoint.
  • Les identifiants des clients étaient spécifiquement des VSCode ("aebc6443-996d-45c2-90f0-388ff96faa56").
  • La ressource/le champ d'application était MSFT Graph ("https://graph.microsoft.com/.default") avec .default autorisations
  • Les flux d'octroi de jetons étaient un code d'authentification (response_type=code)
  • Les URI de redirection correspondaient à des domaines MSFT légitimes (insiders[.]vscode[.]dev ou vscode-redirect[.]azurewebsites[.]net)
  • Les indices de connexion étaient le principal utilisateur spécifique ciblé (pas les principaux services).
  • L'adversaire a demandé à la cible d'ouvrir l'URL, de s'authentifier et de partager le code d'autorisation (1.AXg....)

À partir de là, l'adversaire serait en mesure de faire une demande au point de terminaison du jeton OAuth de MSFT(https://login.microsoftonline.com/[tenant_id]/oauth2/v2.0/token) et d'échanger le jeton de rafraîchissement contre un jeton d'accès. Cela suffit pour permettre à l'adversaire d'accéder à l'API Graph et aux ressources normalement disponibles pour l'utilisateur. Ces indicateurs seront déterminants pour l'élaboration de nos stratégies de détection et de chasse présentées plus loin dans ce blog.

Phishing OAuth pour l'enregistrement d'un appareil en tant que MSFT Auth Broker: Ces URL sont uniques car elles sont enchaînées avec l'utilisation ultérieure de ROADtools pour enregistrer un appareil virtuel, échanger un RT contre un PRT, et nécessitent l'enrichissement du PRT pour permettre l'accès au courrier électronique via l'API graphique et l'accès à Sharepoint.

  • Les URL de phishing OAuth étaient personnalisées et pointaient vers authorize(https://login.microsoftonline.com/[tenant_id]/oauth2/v2.0/authorize). point final
  • Les identifiants des clients étaient spécifiquement ceux de MSFT Authentication Broker ("29d9ed98-a469-4536-ade2-f981bc1d605e").
  • La ressource/le champ d'application est le service d'enregistrement des appareils (DRS) ("01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9").
  • Les flux d'octroi de jetons étaient un code d'authentification (response_type=code)
  • L'URI de redirection inclut le point de jonction de domaine basé sur le cloud (généralement utilisé lors de l'installation de Windows ou de l'Autopilot).
  • L'indice de connexion contient l'adresse électronique principale de l'utilisateur (Cible)
  • La demande est en fin de compte pour un jeton ADRS

Si l'utilisateur est victime d'un hameçonnage et ouvre l'URL, l'authentification fournira un jeton ADRS nécessaire à l'adversaire pour enregistrer un appareil et obtenir ensuite un EPR avec la clé privée de l'appareil et le fichier PEM.

Le blog de Volexity contient également des informations supplémentaires sur le suivi de l'activité de l'identité compromise via l'ID de l'appareil enregistré, ainsi que sur l'activité post-compromission après qu'une demande 2FA approuvée a été identifiée, permettant à l'adversaire de télécharger le courrier électronique de la cible avec une session liée à l'appareil nouvellement enregistré.

Grâce à cette compréhension de chaque tentative d'hameçonnage, notre prochain objectif est de reproduire ces tentatives dans notre propre locataire MSFT aussi précisément que possible afin de recueillir des données pour des détections plausibles.

Nos efforts d'émulation

Très bien - à ce stade, nous avons couvert les principes fondamentaux d'OAuth et la façon dont Microsoft Entra ID les met en œuvre. Nous avons décomposé ce qui définit une URL de phishing Microsoft OAuth, décodé ses paramètres critiques et tiré des informations clés de l'excellente enquête de Volexity afin d'identifier les indicateurs alignés sur ces flux de travail de phishing.

Mais la théorie et un coup d'œil dans le carnet de Volexity ne nous mènent pas bien loin.

Pour bien comprendre le point de vue de l'attaquant, la chaîne complète d'exécution, les bizarreries des outils, les pièges subtils et les possibilités d'abus, nous avons décidé de mettre la main à la pâte avec des tests en boîte blanche. Nous avons recréé le processus d'hameçonnage OAuth dans notre propre locataire, en émulant tout, de la récolte de jetons à l'accès aux ressources. L'objectif ? Aller au-delà des indicateurs statiques et mettre en évidence les fils d'Ariane comportementaux que les défenseurs peuvent détecter de manière fiable.

Entrons dans le vif du sujet.

Produits requis

Pour commencer, il est bon de partager quelques détails sur notre environnement de recherche et de détection des menaces dans Azure.

  • Locataire Azure établi : TENANT.onmicrosoft.com
  • Domaine Sharepoint établi : DOMAIN.sharepoint.com
  • IdP natif Microsoft Entra ID - Permettre notre IAM
  • Licences Microsoft 365 (P2) pour tous les utilisateurs
  • Flux des journaux d'activité Azure vers EventHub
  • Microsoft Entra ID Sign-In Logs Streaming to EventHub (en anglais)
  • Microsoft Entra ID Audit Logs Streaming to EventHub
  • Journaux d'audit de Microsoft Graph transmis en continu à EventHub
  • Microsoft 365 Journaux d'audit en continu vers EventHub
  • L'intégration d'Elastic Azure et de M365 est activée pour la numérisation des logs à partir d'EventHub
  • Utilisateur Admin de base activé avec CAP nécessitant MFA
  • MSFT Authenticator App sur mobile pour l'émulation 2FA
  • Windows 10 Desktop avec NordVPN (Adversary Box)
  • Point de terminaison macOS (boîte de la victime)

Notez que si nous pouvons suivre les flux de travail à partir d'un seul point d'extrémité, nous avons souvent besoin de données qui reflètent des adresses sources distinctes afin de permettre aux développeurs de détecter les variations d'un voyage impossible.

Scénario 1 : Phishing OAuth en tant que client VSCode

Émulation

Pour émuler la technique de phishing documentée par Volexity, nous avons construit un script Python pour générer une URL d'autorisation OAuth 2.0 à l'aide de Microsoft Entra ID. L'URL lance un flux d'octroi de code d'autorisation, en usurpant l'identité de l'application Visual Studio Code pour demander un accès délégué à l'API Microsoft Graph.

Nous avons configuré l'URL avec les paramètres suivants :

{
  "client_id": "aebc6443-996d-45c2-90f0-388ff96faa56",
  "response_type": "code",
  "redirect_uri": "insiders.vscode.dev/redirect",
  "scope": "https://graph.microsoft.com/.default",
  "login_hint": "user @ tenant.onmicrosoft.com",
  "prompt": "select_account",
  "state": "nothingtoseehere"
}

Figure 1 : Paramètres de l'URL d'hameçonnage OAuth

Cette URL est partagée avec la cible (dans notre cas, un utilisateur test de MacOS). Lorsqu'il est ouvert, il authentifie l'utilisateur et complète le flux de travail OAuth. À l'aide d'outils de développement de navigateur, nous capturons le code d'autorisation renvoyé dans l'URI de redirection, exactement ce que les attaquants ont demandé à leurs victimes de renvoyer.

Après avoir reçu le code, nous envoyons une requête POST à :

{token_url: "https://login.microsoftonline.com/organizations/oauth2/v2.0/token"}

Cet échange utilise le type de subvention authorization_code, en transmettant le code, l'ID du client et l'URI de redirection. Microsoft renvoie un jeton d'accès, mais pas de jeton de rafraîchissement. Vous vous demandez peut-être pourquoi ?

Le champ d'application https://graph.microsoft.com/.default demande à Microsoft d'émettre un jeton porteur pour toutes les autorisations graphiques déjà accordées à l'application VSCode au nom de l'utilisateur. Il s'agit d'une portée statique, tirée de l'enregistrement de l'application, qui n'inclut pas les portées dynamiques comme Mail.Read ou offline_access.

La documentation de Microsoft indique que

"Les clients ne peuvent pas combiner un consentement statique (.default) et un consentement dynamique dans une même demande.

Par conséquent, en essayant d'inclure offline_access à côté de .default entraîne une erreur. Si l'attaquant souhaite obtenir un jeton de rafraîchissement, il doit éviter .default et demander explicitement l'accès hors ligne et les champs d'application délégués nécessaires (par exemple, Mail.Read) - en supposant que l'enregistrement de l'application les prenne en charge.

Avec le jeton d'accès en main, nous sommes passés à un second script pour interagir avec l'API Microsoft Graph. L'objectif est d'extraire des messages électroniques du compte de la victime, comme le ferait un pirate.

Pour ce faire, nous avons inclus le jeton d'accès en tant que Bearer JWT dans l'en-tête d'autorisation et avons effectué une requête GET vers le point de terminaison suivant :

{graph_url: "https://graph.microsoft.com/v1.0/me/messages"}

La réponse renvoie un tableau JSON d'objets de courrier électronique. À partir de là, il suffit de parcourir les résultats et d'analyser les métadonnées utiles telles que l'expéditeur, l'objet et l'heure de réception.

Pour tester les privilèges plus étendus du jeton, nous avons également tenté d'énumérer les sites SharePoint en utilisant :

{graph_search_url: "https://graph.microsoft.com/v1.0/sites?search=*"}

La demande a échoué avec une erreur d'accès refusé - ce qui nous amène à une question importante : pourquoi l'accès au courrier électronique a-t-il fonctionné, alors que l'accès à SharePoint n'a pas fonctionné ? La raison en est que le client de première partie (VSCode : aebc6443-996d-45c2-90f0-388ff96faa56) n'a pas d'autorisations déléguées par défaut avec Graph for Sharepoint - comme prédéfini par Microsoft. Nous savons donc que l'adversaire est limité dans ce à quoi il peut accéder.

Pour nous en assurer, nous avons décodé le jeton d'accès afin d'identifier le SCP associé à VSCode avec .default permissions au graphique - Vérification de l'absence de sites.* autorisé par Microsoft.

Il s'agit de l'une des variantes décrites par Volexity, mais elle nous aide à mieux comprendre les processus qui se déroulent en coulisses pour l'adversaire - ainsi que les ressources, OAuth, et plus encore pour Microsoft Entra ID.

Une fois l'émulation terminée, il s'agit maintenant d'identifier les signaux de haute fidélité qui sont viables pour la détection SIEM et la chasse aux menaces. Nous nous concentrons sur les observables de comportement dans les journaux Microsoft Entra ID et Microsoft Graph.

Détection

Signal 1 - Microsoft Entra ID OAuth Phishing en tant que client de Visual Studio Code

Un flux OAuth 2.0 (autorisation) et OpenID Connect (authentification) a été réalisé avec succès à l'aide de l'application Microsoft Visual Studio Code (VSCode). La connexion a été effectuée au nom de l'utilisateur principal hameçonné, ce qui a permis de déléguer l'accès à Microsoft Graph avec .default. autorisations.

event.dataset: "azure.signinlogs" and
event.action: "Sign-in activity" and
event.outcome: "success" and
azure.signinlogs.properties.user_type: "Member" and
azure.signinlogs.properties.authentication_processing_details: *Oauth* and
azure.signinlogs.category: "NonInteractiveUserSignInLogs" and
(
  azure.signinlogs.properties.resource_display_name: "Microsoft Graph" or
  azure.signinlogs.properties.resource_id: "00000003-0000-0000-c000-000000000000"
) and (
  azure.signinlogs.properties.app_id: "aebc6443-996d-45c2-90f0-388ff96faa56" or
  azure.signinlogs.properties.app_display_name: "Visual Studio Code"
)

Signal 2 - Réutilisation de sessions Microsoft Entra avec accès suspect au graphique

Si les langages de requête traditionnels tels que KQL sont excellents pour filtrer et visualiser des événements individuels, ils posent problème lorsqu'une détection repose sur la corrélation de plusieurs enregistrements à travers des ensembles de données, le temps et les identifiants. C'est là qu'ES|QL (Elasticsearch Query Language) devient essentiel. Ces types de corrélations multi-événements, de logique temporelle et de normalisation des champs sont difficiles, voire totalement impossibles, dans les langages d'interrogation statiques basés sur des filtres comme KQL, sans écrire plusieurs requêtes disjointes et les corréler manuellement après coup.

Cette détection repose sur la corrélation de plusieurs événements rapprochés mais provenant de sources de données différentes, à savoir les journaux de connexion et l'activité Microsoft Graph. L'objectif est de détecter toute réutilisation suspecte du même identifiant de session sur plusieurs adresses IP, ce qui pourrait indiquer un détournement de session ou un abus de jetons. Pour des raisons de place dans cette publication, vous pouvez consulter la règle de détection proprement dite dans la section Règles de détection. Pour mieux illustrer le flux de la requête et sa signification, vous trouverez ci-dessous un diagramme à un niveau plus élevé.

[ FROM logs-azure.* ]
        |
        |  ← Pulls events from all relevant Microsoft Cloud datasets:
        |     - azure.signinlogs (authentication)
        |     - azure.graphactivitylogs (resource access)
        ↓
[ WHERE session_id IS NOT NULL AND IP NOT MICROSOFT ASN ]
        |
        |  ← Filters out Microsoft-owned infrastructure (e.g., internal proxy,
        |     Graph API relays) using ASN checks.
        |  ← Ensures session ID exists so events can be correlated together.
        ↓
[ EVAL session_id, event_type, time_window, etc. ]
        |
        |  ← Normalizes key fields across datasets:
        |     - session_id (from signin or Graph)
        |     - user ID, app ID, event type ("signin" or "graph")
        |  ← Buckets events into 5-minute windows using DATE_TRUNC()
        ↓
[ KEEP selected fields ]
        |
        |  ← Retains only what's needed:
        |     session_id, timestamp, IP, user, client ID, etc.
        ↓
[ STATS BY session_id + time_window ]
        |
        |  ← Groups by session and time window to compute:
        |     - unique IPs used
        |     - apps involved
        |     - first and last timestamps
        |     - whether both signin and graph occurred
        ↓
[ EVAL time_diff + signin_to_graph_delay ]
        |
        |  ← Calculates:
        |     - time_diff: full session duration
        |     - delay: gap between signin and Graph access
        ↓
[ WHERE types_count > 1 AND unique_ips > 1 AND delay <= 5 ]
        |
        |  ← Flags sessions where:
        |     - multiple event types (signin + graph)
        |     - multiple IPs used
        |     - all occurred within 5 minutes
        ↓
[ Output = Suspicious Session Reuse Detected ]

Signal 3 - Microsoft Entra ID Sign-Ins simultanés avec propriétés suspectes

Cette détection permet d'identifier les connexions suspectes dans Microsoft Entra ID lorsqu'un utilisateur s'authentifie à l'aide du flux de code de l'appareil sans MFA ou des connexions à l'aide du client VSCode. Lorsque la même identité se connecte à partir de deux ou plusieurs adresses IP distinctes dans un court laps de temps en utilisant l'une ou l'autre méthode, cela peut indiquer un rejeu de jeton, un hameçonnage OAuth ou une activité de l'adversaire au milieu (AitM).

[ FROM logs-azure.signinlogs* ]
        |
        |  ← Pulls only Microsoft Entra ID sign-in logs
        ↓
[ WHERE @timestamp > NOW() - 1h AND event.outcome == "success" ]
        |
        |  ← Filters to the last hour and keeps only successful sign-ins
        ↓
[ WHERE source.ip IS NOT NULL AND identity IS NOT NULL ]
        |
        |  ← Ensures the sign-in is tied to a user and IP for correlation
        ↓
[ KEEP fields: identity, app_id, auth_protocol, IP, etc. ]
        |
        |  ← Retains app/client, IP, auth method, and resource info
        ↓
[ EVAL detection flags ]
        |
        |  ← Labels events as:
        |     - device_code: if MFA not required
        |     - visual_studio: if VS Code client used
        |     - other: everything else
        ↓
[ STATS BY identity ]
        |
        |  ← Aggregates all sign-ins per user, calculates:
        |     - IP count
        |     - Device Code or VSCode usage
        |     - App/client/resource details
        ↓
[ WHERE src_ip >= 2 AND (device_code_count > 0 OR vsc > 0) ]
        |
        |  ← Flags users with:
        |     - Sign-ins from multiple IPs
        |     - And either:
        |         - Device Code w/o MFA
        |         - Visual Studio Code app
        ↓
[ Output = Potential OAuth Phishing or Token Misuse ]

Bien que cette variante de l'hameçonnage OAuth n'ait pas la persistance totale offerte par les jetons de rafraîchissement ou l'outillage, elle permet aux adversaires d'accéder une seule fois aux données sensibles des utilisateurs, telles que les courriels, par le biais de canaux légitimes. Cet exercice nous aide à comprendre les limites et les capacités de la technologie statique .default. l'influence des enregistrements d'applications et la façon dont Microsoft Graph joue un rôle central dans la post-authentification. Cela renforce également une leçon plus large : toutes les attaques de phishing OAuth ne sont pas égales. Certains visent la longévité (comme nous le verrons plus loin) grâce à des jetons de rafraîchissement ou à l'enregistrement des appareils, tandis que d'autres se concentrent sur le vol immédiat de données par l'intermédiaire de clients de première partie. Il est essentiel de comprendre les nuances pour une logique de détection précise.

Scénario 2 : Phishing OAuth pour l'enregistrement d'un appareil

Comme nous l'avons indiqué précédemment, Volexity a également signalé un autre scénario de phishing ciblant les victimes, cette fois dans le but d'enregistrer un appareil virtuel et d'obtenir un outillage. Bien que cette approche nécessite plus d'étapes de la part de l'adversaire, le résultat est un jeton qui offre beaucoup plus d'utilité pour mener à bien ses opérations. Pour nos efforts d'émulation, nous avons dû élargir notre palette d'outils et nous appuyer sur ROADtools, tout comme l'adversaire l'a fait pour rester précis, mais plusieurs autres scripts python ont été créés pour les actions initiales d'hameçonnage et post-compromission.

Émulation

En commençant par l'hameçonnage initial, nous avons adapté notre script Python pour créer une URL OAuth différente qui serait envoyée à notre victime. Cette fois-ci, l'accent a été mis sur l'ID de notre client de première partie, à savoir le courtier d'authentification de Microsoft, qui demande un jeton de rafraîchissement avec offline_access et redirige vers l'URI du point d'arrivée de l'appareil de connexion du domaine en nuage d'Entra ID.

{
  "client_id": "29d9ed98-a469-4536-ade2-f981bc1d605e",
  "response_type": "code",
  "response_mode": "query",
  "redirect_uri": "https://login.microsoftonline.com/WebApp/CloudDomainJoin/8",
  "resource": "01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9",
  "state": "nothingtoseehere"
}

En cas de succès et d'authentification de notre victime, le flux de travail OAuth se termine et l'utilisateur est redirigé vers l'URI spécifié avec un code d'autorisation ajouté dans les paramètres de la requête. Une fois de plus, ce code est la pièce maîtresse, il doit être partagé avec l'adversaire afin d'être échangé contre des jetons. Dans notre cas, une fois que l'URL de phishing est ouverte et que la cible s'authentifie, nous capturons le code d'autorisation intégré dans la redirection et l'utilisons pour demander des jetons au point de terminaison Microsoft Entra ID token.

C'est là que les choses deviennent intéressantes. En réponse à la demande de jetons, nous recevons trois types de jetons : un jeton d'accès, un jeton de rafraîchissement et un jeton d'identification. Vous vous demandez peut-être pourquoi nous obtenons plus qu'un simple jeton d'accès ? La réponse se trouve dans les champs d'application que nous avons initialement demandés : openid, offline_access et profile.

  • openid nous accorde un jeton d'identification, qui fait partie de la couche OpenID Connect et confirme l'identité de l'utilisateur - c'est votre artefact d'authentification (authN).
  • offline_access fournit un jeton de rafraîchissement, ce qui nous permet de maintenir une session et de demander de nouveaux jetons d'accès sans avoir à nous réauthentifier, ce qui permet un accès persistant mais est essentiel pour notre utilisation avec ROADtx.
  • Le jeton d'accès lui-même est utilisé pour autoriser les demandes d'API protégées telles que Microsoft Graph, ce qui représente l'autorisation (authZ).

Avec ces trois jetons, nous avons tout : l'authentification, l'autorisation et la continuité de la session à long terme. C'est suffisant pour passer d'un simple jeu d'hameçonnage OAuth à un ancrage plus durable - comme l'enregistrement d'un nouvel appareil dans Microsoft Entra ID.

Relions maintenant les points. Un outillage nécessite l'enregistrement d'un appareil valide, qu'Entra ID reconnaît par le biais d'un certificat d'appareil et d'une clé privée. C'est là que ROADtx entre en jeu. Étant donné que notre premier phishing OAuth a usurpé l'identité d'un flux d'appareils connecté et que le client utilisé était le Microsoft Authentication Broker (un client de première partie qui interagit avec le Device Registration Service), nous avons déjà le bon jeton d'accès en main pour interagir avec le DRS. Remarquez que dans l'objet retourné, la portée est adrs_access, ce qui indique l'accès à Azure DRS et est important pour les détections ultérieures.

A partir de là, nous déposons simplement l'objet JSON reçu de notre échange de jetons dans le fichier .roadtool_auth fichier. Ce fichier est consommé nativement par ROADtools, qui utilise les jetons stockés pour procéder à l'enregistrement de l'appareil, achevant ainsi le passage de l'adversaire à la persistance et préparant le terrain pour l'obtention d'un outillage valide.

Après avoir obtenu les jetons, nous les préparons pour ROADtx en reformatant le JSON. ROADtx attend des clés en camelCase, et nous devons également inclure l'identifiant du client du Microsoft Authentication Broker en tant que _clientId. Cette configuration nous permet d'exécuter la commande refreshtokento, qui prend notre jeton de rafraîchissement et l'échange contre un nouveau JWT lié au DRS - en particulier, le principal de service urn :ms-drs:enterpriseregistration.windows.net.

Une fois que cela est en place, nous utilisons la commande device pour simuler l'enregistrement d'un nouveau dispositif. Cette opération ne nécessite pas de machine virtuelle ou d'hôte physique car il s'agit d'un enregistrement en arrière-plan qui crée simplement une entrée dans Entra ID. En cas de succès, nous obtenons un identifiant de dispositif valide, un certificat codé PEM et une clé privée, tous nécessaires pour simuler un dispositif hybride valide dans l'écosystème Microsoft.

Une fois l'identité de notre appareil établie, nous invoquons la commande prt. Cette opération utilise le jeton de rafraîchissement, le certificat de l'appareil et la clé privée pour créer un nouvel outillage - un justificatif d'identité hautement privilégié qui lie efficacement la confiance de l'utilisateur et de l'appareil dans Microsoft Entra ID.

Et juste comme ça - whollah ! - nous avons une PRT.

Mais pourquoi faire tout cela ? Pourquoi enregistrer un appareil, générer un certificat et obtenir un outillage alors que nous disposons déjà d'un jeton d'accès, d'un jeton d'identification et d'un jeton de rafraîchissement ?

Parce que l'outillage est la clé de l'émulation complète de l'identité de l'utilisateur et de l'appareil. Considérez-le comme un jeton d'octroi de tickets de type Kerberos dans le monde d'Entra ID, mais plutôt comme un jeton d'octroi de jetons. Avec un outillage valide :

  • Un adversaire peut demander de nouveaux jetons d'accès et d'identification pour des applications tierces telles qu'Outlook, SharePoint ou Teams sans avoir besoin de l'interaction de l'utilisateur.
  • L'outillage permet une authentification unique (SSO) transparente à travers de multiples services, en contournant le MFA et d'autres politiques d'accès conditionnel (CAP) qui, en général, relanceraient l'utilisateur. Cet aspect est crucial pour la persistance, car la PAC et l'AMF constituent souvent des obstacles considérables pour les adversaires.
  • Il prend en charge la persistance à long terme, car l'outillage peut être renouvelé silencieusement et exploité au fil des sessions tant que l'identité de l'appareil reste fiable.

Et ce qui est peut-être le plus dangereux, c'est que l'outillage permet aux adversaires de se faire passer pour un appareil et une combinaison d'utilisateurs totalement conformes et reliés à un domaine, contournant ainsi la plupart des contrôles de détection et de réponse conventionnels, ce qui rend la frontière entre ce qui est bénin et ce qui est suspect extrêmement ténue pour les chasseurs et les analystes.

Cela fait de l'outillage un atout incroyablement précieux ou un atout qui permet un mouvement latéral secret, une escalade des privilèges et un accès approfondi aux services Microsoft 365 . Il ne s'agit plus seulement d'entrer, mais de rester indétecté.

N'oublions pas l'activité post-compromis...

ROADtx propose quelques commandes puissantes fréquemment utilisées par les adversaires - prtenrich et browserprtauth. Par exemple, nous pouvons accéder à la plupart des services d'interface utilisateur basés sur un navigateur dans la suite Microsoft en fournissant notre PRT qui comprend les métadonnées nécessaires à l'authentification et à l'autorisation - qui appartenait à l'origine à notre victime de phishing (moi), mais qui est en fait le courtier d'authentification de Microsoft agissant en son nom.

Volexity a également signalé qu'après l'enregistrement de l'appareil et l'acquisition de l'outillage, une demande de 2FA a été envoyée à la victime initiale, approuvée et utilisée pour accéder à des courriels via SharePoint. Bien qu'ils ne précisent pas exactement comment les demandes ont été faites - il est raisonnable de supposer que l'adversaire a utilisé l'outillage pour s'authentifier via un client Microsoft de première partie - l'accès réel aux données se faisant via Microsoft Graph. Graph reste une cible populaire après une compromission, car il sert d'API centrale pour la plupart des ressources de Microsoft 365 .

Pour commencer, utilisons ROADtx pour nous authentifier auprès de notre outillage où Microsoft Teams est notre client et Microsoft Graph notre ressource. En utilisant la commande prtauth avec notre outillage, nous sommes en mesure d'obtenir un nouveau jeton d'accès et un jeton de rafraîchissement, ce qui démontre clairement l'utilité de l'outillage en tant que jeton d'octroi de jetons au sein de la structure d'identité de Microsoft.

Une fois notre jeton d'accès obtenu, nous l'insérons dans un script Python personnalisé pour commencer à énumérer nos sites, lecteurs et éléments SharePoint, ce qui nous permet d'identifier les fichiers intéressants et de télécharger leur contenu.

Avec cette émulation, nous avons montré comment les adversaires peuvent enchaîner le phishing OAuth avec le courtier d'authentification de Microsoft et obtenir les informations d'identification nécessaires pour utiliser ROADtx afin d'acquérir un outillage. Cet outillage devient alors un utilitaire important après la compromission pour accéder aux fichiers sensibles, énumérer les ressources du locataire et bien plus encore.

Passons maintenant à la question suivante : quels sont les signaux plausibles et précis permettant de détecter cette activité ?

Détection

Signal 1 - Microsoft Entra ID OAuth Phishing en tant que Microsoft Authentication Broker

Identifie les cas où un principal utilisateur initie un flux de code d'autorisation OAuth en utilisant le Microsoft Authentication Broker (MAB) en tant que client et le Device Registration Service (DRS) en tant que ressource cible. Cette détection se concentre sur les cas où un seul identifiant de session est réutilisé sur deux ou plusieurs adresses IP distinctes dans un court laps de temps, et où au moins une requête provient d'un navigateur - un comportement généralement associé à l'hameçonnage.

[ FROM logs-azure.signinlogs-* ]
        |
        |  ← Pulls all Microsoft Entra ID sign-in logs
        ↓
[ WHERE app_id == MAB AND resource_id == DRS ]
        |
        |  ← Filters to OAuth auth code requests targeting
        |     Microsoft Authentication Broker + Device Reg Service
        ↓
[ EVAL session_id + is_browser ]
        |
        |  ← Extracts session ID and flags browser-based activity
        ↓
[ STATS BY 30-minute window, user, session_id ]
        |
        |  ← Groups logins within same session and time window,
        |     then aggregates:
        |       - user/session/token identifiers
        |       - distinct IPs and geo info
        |       - user agent, browser presence
        |       - app/resource/client info
        ↓
[ WHERE ip_count ≥ 2 AND session_id_count == 1 ]
        |
        |  ← Identifies reuse of a single session ID
        |     across ≥ 2 different IP addresses
        ↓
[ AND has_browser ≥ 1 AND auth_count ≥ 2 ]
        |
        |  ← Requires at least one browser-based request
        |     and at least two total sign-in events
        ↓
[ Output = Suspicious OAuth Flow with Auth Broker for DRS ]

Signal 2 - Demande de jeton ADRS suspecte par Microsoft Auth Broker

Identifie les événements de connexion Microsoft Entra ID où un utilisateur principal s'authentifie à l'aide d'un jeton de rafraîchissement délivré au client Microsoft Authentication Broker (MAB), en ciblant le service d'enregistrement des appareils (DRS) avec la portée OAuth adrs_access. Ce schéma peut indiquer un accès au DRS basé sur un jeton après un phishing de code d'autorisation initial ou un flux d'enregistrement d'appareil.

event.dataset: "azure.signinlogs" and azure.signinlogs.properties.app_id : "29d9ed98-a469-4536-ade2-f981bc1d605e" and azure.signinlogs.properties.resource_id : "01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9" and azure.signinlogs.properties.authentication_processing_details.`Oauth Scope Info`: *adrs_access* and azure.signinlogs.properties.incoming_token_type: "refreshToken" and azure.signinlogs.properties.user_type: "Member"

Signal 3 - Enregistrement d'un dispositif inhabituel dans Entra ID

Détecte une séquence d'événements du journal d'audit Entra ID indiquant une activité potentielle d'enregistrement d'appareil malveillant à l'aide d'un jeton de rafraîchissement, généralement observée après un hameçonnage OAuth. Ce modèle imite le comportement d'outils tels que ROADtx, où un appareil Windows nouvellement enregistré (avec une version de système d'exploitation codée en dur 10.0.19041.928) est ajouté par le service d'enregistrement des appareils, suivi de l'attribution de l'utilisateur et du propriétaire. Tous les événements doivent partager le même identifiant de corrélation et se produire dans une fenêtre d'une minute, ce qui suggère fortement une automatisation ou un enregistrement par script plutôt qu'un comportement légitime de l'utilisateur.

sequence by azure.correlation_id with maxspan=1m
[any where event.dataset == "azure.auditlogs" and azure.auditlogs.identity == "Device Registration Service" and azure.auditlogs.operation_name == "Add device" and azure.auditlogs.properties.additional_details.value like "Microsoft.OData.Client/*" and (
  azure.auditlogs.properties.target_resources.`0`.modified_properties.`1`.display_name == "CloudAccountEnabled" and 
azure.auditlogs.properties.target_resources.`0`.modified_properties.`1`.new_value: "[true]") and azure.auditlogs.properties.target_resources.`0`.modified_properties.`3`.new_value like "*10.0.19041.928*"]
[any where event.dataset == "azure.auditlogs" and azure.auditlogs.operation_name == "Add registered users to device" and azure.auditlogs.properties.target_resources.`0`.modified_properties.`2`.new_value like "*urn:ms-drs:enterpriseregistration.windows.net*"]
[any where event.dataset == "azure.auditlogs" and azure.auditlogs.operation_name == "Add registered owner to device"]

Signal 3 - Entra ID RT to PRT Transition du même utilisateur et du même appareil

Cette détection permet d'identifier le moment où un utilisateur de Microsoft Entra ID s'authentifie pour la première fois à l'aide d'un jeton de rafraîchissement délivré au Microsoft Authentication Broker (MAB), suivi de peu par l'utilisation d'un jeton de rafraîchissement primaire (PRT) provenant du même dispositif. Cette séquence est rare dans le comportement normal d'un utilisateur et peut indiquer qu'un adversaire a réussi à enregistrer un appareil et à obtenir un accès permanent à l'aide d'outils tels que ROADtx. En filtrant l'activité liée au service d'enregistrement des appareils (DRS) lors de la deuxième étape, la règle se concentre sur l'utilisation de l'outillage après l'enregistrement pour accéder à d'autres services Microsoft 365 .

Ce comportement suggère fortement une compromission basée sur des jetons et une émulation de session à long terme, en particulier lorsque la confiance dans le dispositif est établie silencieusement. Il est essentiel de détecter cette transition entre le jeton de rafraîchissement et l'outillage pour mettre en évidence des signaux fiables de phishing OAuth et de persistance post-compromission.

sequence by azure.signinlogs.properties.user_id, azure.signinlogs.properties.device_detail.device_id with maxspan=1d
  [authentication where 
    event.dataset == "azure.signinlogs" and
    azure.signinlogs.category == "NonInteractiveUserSignInLogs" and
    azure.signinlogs.properties.app_id == "29d9ed98-a469-4536-ade2-f981bc1d605e" and
    azure.signinlogs.properties.incoming_token_type == "refreshToken" and
    azure.signinlogs.properties.device_detail.trust_type == "Azure AD joined" and
    azure.signinlogs.properties.device_detail.device_id != null and
    azure.signinlogs.properties.token_protection_status_details.sign_in_session_status == "unbound" and
    azure.signinlogs.properties.user_type == "Member" and
    azure.signinlogs.result_signature == "SUCCESS"
  ]
  [authentication where 
    event.dataset == "azure.signinlogs" and
    azure.signinlogs.properties.incoming_token_type == "primaryRefreshToken" and
    azure.signinlogs.properties.resource_display_name != "Device Registration Service" and
    azure.signinlogs.result_signature == "SUCCESS"
  ]

Signal 4 - Utilisation inhabituelle de l'outillage et dispositif enregistré pour l'utilisateur principal

Cette détection apparaît lorsqu'un utilisateur de Microsoft Entra ID enregistre un nouveau dispositif qui n'a pas été vu auparavant au cours des derniers 7 jours - un comportement souvent associé à des campagnes de phishing OAuth qui enchaînent l'enregistrement de dispositifs basé sur ROADtx. Dans ces attaques, les adversaires trompent les utilisateurs en autorisant l'accès au Microsoft Authentication Broker (MAB) ciblant le DRS, obtiennent un RT, puis utilisent ROADtx pour enregistrer silencieusement un faux dispositif Windows et monnayer un PRT. Cette règle émet une alerte lorsqu'un utilisateur principal s'authentifie à partir d'un identifiant de périphérique nouvellement observé, en particulier si la session n'est pas liée, ce qui est caractéristique du rejeu de jeton ou de l'usurpation de périphérique. Étant donné que les outillages nécessitent un dispositif enregistré et de confiance, ce signal joue un rôle essentiel dans l'identification du moment où un adversaire est passé de l'abus de jetons de base à un accès persistant et furtif aligné sur une compromission à long terme.

event.dataset: "azure.signinlogs" and
    event.category: "authentication" and
    azure.signinlogs.properties.user_type: "Member" and
    azure.signinlogs.properties.token_protection_status_details.sign_in_session_status: "unbound" and
    not azure.signinlogs.properties.device_detail.device_id: "" and
    azure.signinlogs.properties.user_principal_name: *

Nouveaux termes Valeurs :

  • azure.signinlogs.properties.user_principal_name
  • azure.signinlogs.properties.device_detail.device_id

Cette émulation nous a permis de valider l'ensemble du flux de travail de l'attaquant - de l'hameçonnage pour obtenir le consentement à l'établissement de la confiance dans l'appareil et à la création d'un outillage pour une persistance à long terme. En enchaînant les abus OAuth avec l'enregistrement des appareils, les adversaires peuvent satisfaire les CAP, se faire passer pour des terminaux conformes et se déplacer latéralement dans les environnements cloud, souvent sans déclencher les contrôles de sécurité traditionnels.

Ces nuances sont importantes. Lorsqu'ils sont considérés isolément, des événements individuels tels que l'émission de jetons ou l'enregistrement de dispositifs peuvent sembler anodins. Mais lorsqu'ils sont mis en corrélation avec les journaux de connexion, les données d'audit et les métadonnées des jetons, ils révèlent une piste distincte de compromission de l'identité.

Détails télémétriques clés pour la détection et l'abus

Tout au long de nos efforts d'émulation et de détection, certains artefacts de télémétrie se sont avérés essentiels pour distinguer les activités OAuth bénignes des abus malveillants. Il est essentiel de comprendre comment ces champs apparaissent dans les journaux Microsoft Entra ID - et comment les attaquants les manipulent - pour une chasse efficace et une ingénierie de détection. Qu'il s'agisse des identifiants des clients et des types de subventions, de la conformité des appareils, des types de jetons ou des résultats de l'accès conditionnel, ces signaux révèlent les attaques basées sur l'identité. Nous avons dressé ci-dessous une liste des plus importants d'entre eux et de la manière dont ils peuvent nous aider.

ID de l'application cliente (client_id): Identifie l'application à l'origine de la demande OAuth. Les clients de première partie (par exemple VSCode, Auth Broker) peuvent être utilisés abusivement pour se fondre dans la masse. Les clients tiers peuvent être malveillants ou non examinés - ils représentent souvent des attaques par consentement mutuel. Principalement utilisé pour identifier les utilisations risquées ou inattendues d'applications.

Ressource cible (resource_id / resource_display_name): Définit le service MSFT auquel on accède (par ex. MSFT Graph ou Teams). Les cibles à forte valeur ajoutée sont les suivantes : Graph API, SharePoint, Outlook, Teams et Directory Services. Le ciblage des ressources est souvent déterminé par les objectifs de l'attaquant.

Type de principal (user_type): Indique si la connexion a été effectuée par un membre (utilisateur) ou un principal de service. Les campagnes de phishing ciblent presque toujours les comptes des membres. Cela permet de faciliter le filtrage dans la logique de détection, mais aussi d'associer les demandes inhabituelles des clients de première partie à celles des mandants de l'utilisateur.

Type de subvention OAuth (authentication_processing_details): Clé pour comprendre comment le jeton a été obtenu - codes d'autorisation, jetons de rafraîchissement, codes d'appareil, informations d'identification du client, etc. Alors que les jetons de rafraîchissement et la réutilisation des codes d'appareil sont des signaux de haute fidélité de la post-compromission.

Géolocalisation: Nous permet d'identifier les inscriptions atypiques (par ex. pays rare vu) ou voyage impossible (même utilisateur à partir de lieux éloignés en peu de temps). Combinés aux identifiants de session et de corrélation, ils peuvent révéler un détournement de jeton, une compromission d'identité postérieure ou un mouvement latéral.

Métadonnées des appareils (device_detail, trust_type, compliance_state): Comprend les identifiants des appareils, le système d'exploitation, les types de confiance, la conformité, l'état géré, etc. L'enregistrement de l'appareil et la délivrance de l'outillage sont liés à ces métadonnées. Les adversaires ont souvent pour objectif de satisfaire le CAP et d'obtenir un accès de confiance persistant.

Protocoles et types d'authentification (authentication_protocol / incoming_token_type): Indique si la session était basée sur OAuth ou si l'AMF a été utilisée. Les sources de jetons entrantes sont celles qui sont utilisées pour cette demande et qui fournissent authN ou authZ. Utile pour détecter la réutilisation de jetons et les inscriptions non interactives.

Matériel d'authentification et contexte de la session: Les jetons utilisés peuvent être déduits du type de jeton reçu, de l'état de protection du jeton et de l'identifiant de la session. La réutilisation d'une session, une longue durée de session ou plusieurs adresses IP liées à une même session sont souvent le signe d'un abus.

Statut de la politique d'accès conditionnel: Évaluée lors de l'émission du jeton, elle influence toutefois fortement l'octroi de l'accès. Cela permet d'identifier les échappatoires à la PAC, les résultats politiques inattendus ou les facteurs de risque.

Champs d'application et comportement de consentement: Les champs d'application demandés apparaissent dans les paramètres SCP ou OAuth capturés dans les journaux de connexion. Les indicateurs d'abus incluent offline_access, .default, ou des champs d'application larges comme Mail.ReadWrite. La télémétrie du consentement peut aider à déterminer si l'utilisateur a approuvé une application suspecte.

Conclusion

La mise en œuvre d'OAuth par Microsoft Entra ID est une arme à double tranchant : elle permet des expériences d'authentification puissantes et transparentes, mais expose également les adversaires à de nouvelles possibilités d'exploiter la confiance, la persistance de la session et les voies d'attaque de l'enregistrement de l'appareil.

En reproduisant les techniques de phishing OAuth observées par Volexity, notre équipe a pu valider la façon dont les attaquants abusent des applications Microsoft légitimes, des flux de jetons et des outils open-source pour obtenir un accès furtif aux données sensibles. Nous avons prolongé ce travail par une émulation pratique, en nous plongeant dans les mécanismes de l'hameçonnage OAuth et des flux de travail, des métadonnées et de l'acquisition des jetons de sécurité, en aidant à faire émerger des indicateurs comportementaux que les défenseurs peuvent détecter.

Nos résultats renforcent un point essentiel : L'abus d'OAuth ne repose pas sur des logiciels malveillants ou l'exécution de code. Il arme l'identité, le consentement et la réutilisation des jetons - ce qui rend les contrôles de sécurité traditionnels difficiles - et explique pourquoi la détection basée sur les journaux, la corrélation et l'analyse comportementale sont si importantes.

Nous espérons que les artefacts d'émulation, les règles de détection et les leçons partagées ici aideront les défenseurs de la communauté à mieux comprendre - et à détecter/chasser - cette catégorie évolutive de menaces d'identité basées sur le cloud.

Si vous utilisez Elastic, nous avons mis en libre accès toutes les règles de détection présentées dans ce blog pour vous aider à démarrer. Et si vous chassez dans un autre SIEM, nous vous encourageons à adapter la logique et à ajuster votre environnement en conséquence.

L'identité est le nouveau périmètre - et il est temps que nous la traitions comme telle. Restez en sécurité et bonne chasse !

Règles de détection

Références :

Partager cet article

XFacebookLinkedInReddit