Détection des attaques Tycoon 2FA AiTM à travers Entra ID et Google Workspace

Tycoon 2FA est actuellement la plateforme de Phishing-as-a-Service (PhaaS) la plus prolifique parmi les kits de phishing AiTM. Observé pour la première fois en août 2023 et attribué à Storm-1747 (selon Microsoft Threat Intelligence), ce kit fournit des capacités clés en main de type "adversary-in-the-middle" (AiTM) qui permettent de contourner l'authentification multifactorielle et de voler des jetons de session authentifiés à partir des comptes Microsoft 365 et Google Workspace. À son apogée, Tycoon 2FA représentait environ 62% des tentatives d'hameçonnage bloquées par Microsoft, touchant plus de 500 000 organisations par mois.

Malgré un démantèlement coordonné en mars 2026 mené par Microsoft et Europol, avec le soutien de Cloudflare, SpyCloud, eSentire et d'autres partenaires, qui a permis de saisir plus de 300 domaines, les opérateurs se sont adaptés en l'espace de quelques semaines. Fin avril 2026, eSentire a documenté des campagnes combinant les techniques de Tycoon et les flux d'hameçonnage OAuth Device Code, et le kit reste l'entrée n°1 du tracker de tendances des logiciels malveillants d'ANY.RUN.

Fonctionnement de Tycoon 2FA

Le mécanisme AiTM

Tycoon 2FA fonctionne comme un proxy inversé entre la victime et le fournisseur d'identité légitime (Entra ID ou Google). Il ne s'agit pas d'un collecteur d'informations statiques. Il reproduit le flux de connexion réel en temps réel :

1. La victime reçoit un courriel d'hameçonnage contenant un lien ou un code QR intégré dans une pièce jointe PDF, SVG, HTML ou PPTX.
2. Le lien passe par une chaîne de redirection multicouche. Le kit effectue des empreintes digitales du navigateur, des défis CAPTCHA et des contrôles anti-analyse avant de présenter la page de connexion.
3. La victime voit une réplique au pixel près de la page de connexion de Microsoft ou de Google, qui inclut souvent la marque de l'organisation cible, récupérée de manière dynamique à partir du service réel.
4. Les données d'identification sont transmises en temps réel au fournisseur d'identité légitime. Le véritable défi MFA est déclenché et renvoyé par procuration à la victime.
5. La victime termine l'AMF normalement. Le fournisseur d'identité émet un jeton de session. Le proxy intercepte ce jeton avant qu'il n'atteigne le navigateur de la victime.
6. L'attaquant détient désormais un jeton d'accès entièrement authentifié.

Le cookie de session est la valeur que l'opérateur monétise. Une fois capturé, l'AMF n'a plus lieu d'être car l'opérateur rejoue les jetons frappés après l'AMF.

Deux variantes structurelles dans la rotation actuelle

Deux variantes distinctes du kit que nous avons analysées étaient en cours d'utilisation :

" WebSocket AiTM (le flux 2FA classique de "Tycoon 2FA) : La victime s'authentifie par l'intermédiaire d'un proxy hébergé par le kit qui transmet le trafic à Microsoft ou Google via WebSocket (Socket.IO) et capture le cookie de session post-MFA. Le contrôleur client JavaScript du kit maintient un canal bidirectionnel en temps réel avec le serveur C2, relayant les informations d'identification et les réponses d'authentification au fur et à mesure que la victime tape. Ces réponses comprennent des jetons d'accès et de rafraîchissement frappés pour utilisation.

Abus d'attribution de code d'appareil (Microsoft uniquement) : Le relais du kit obtient un code d'appareil à partir du point de terminaison oauth2/devicecode de Microsoft avec Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) en tant que client, l'affiche à la victime par le biais d'un code de vérification "" lure, et échange le code contre des jetons d'accès/de rafraîchissement après que la victime s'est connectée sur le site légitime microsoft.com/devicelogin. point final.

Techniques d'évasion

Le kit utilise des mécanismes anti-analyse à plusieurs niveaux, confirmés par la décompilation de JavaScript :

• Filtrage des chercheurs basé sur l'IP : Avant d'afficher un contenu, le kit appelle api.ipapi.is (ou un service équivalent) pour vérifier l'adresse IP du visiteur par rapport à une liste de fournisseurs d'hébergement/de services en nuage (Leaseweb, M247, DigitalOcean, Linode, Amazon, OVH, Hetzner, Google, Microsoft, Cloudflare, Akamai, Fastly, stockée sous forme de chaînes inversées pour éviter l'analyse statique). Les visiteurs de l'infrastructure en nuage sont redirigés vers un site leurre inoffensif.
• Détection de bot/tool : Vérifie la présence de navigator .webdriver (Selenium), window.callPhantom / window._phantom (PhantomJS), et "Burp" dans la chaîne du user-agent. La détection déclenche une redirection vers about:blank.
• Blocage des outils de développement : Intercepte les raccourcis clavier des outils de développement (F12, Ctrl+Shift+I/J/C, Ctrl+U, équivalents macOS) et désactive les menus contextuels du clic droit.
• Piège du débogueur : Une boucle setInterval exécutée toutes les 100 ms insère une instruction de débogage et mesure le temps d'exécution. Si les DevTools sont ouverts (l'exécution s'interrompt à >100ms), la victime est redirigée vers un site leurre.
• Disparition du DOM : le JavaScript malveillant disparaît du DOM après son exécution, ne laissant aucune trace pour l'inspection statique.
• Chiffrement par victime : La charge utile utilise un chiffrement personnalisé en deux étapes (décalage de César + XOR avec un flux de clés généré par le PRNG) alimenté par des valeurs par session. La graine, la clé et le blob crypté sont générés côté serveur pour chaque victime, ce qui rend impossible la détection statique des signatures.
• Ciblage de la plate-forme : Sur les ordinateurs de bureau Linux, il écrit une chaîne vide pour masquer la page : il est probable que les utilisateurs de Linux sont plus susceptibles d'être des chercheurs en sécurité.
• Faux CAPTCHA : un CAPTCHA personnalisé à grille d'images remplace le Turnstile de Cloudflare dans la variante actuelle. Des images provenant d'Unsplash dans une grille 3×3 permettent une vérification humaine avant le chargement de la page d'hameçonnage.

Pour les campagnes ciblant Google, le leurre de premier saut est souvent mis en scène sur l'infrastructure légitime de Google, telle que Google Storage ou Google Sites, bien que des domaines contrôlés par l'opérateur ou compromis soient également observés. Lorsque Google utilise son propre hébergement, l'origine storage.googleapis.com ou sites.google.com fournit une couverture de réputation intégrée avant que la victime n'atteigne le relais AiTM.

Dans d'autres cas, l'adresse électronique de la victime est remplie automatiquement et le bouton "Next" est cliqué automatiquement : la victime arrive directement sur la page du mot de passe, ce qui donne l'impression qu'elle est déjà partiellement authentifiée (ce qui accroît la confiance) :

var emailcheck = "victim@email.corp";
// ...
function tryfindingele(email) {
   emailinputcheck.value = email;
   emailsectionelecheck.querySelector(".btn-blue-next-btn").click();
}
if (emailcheck !== "0") { tryfindingele(emailcheck); }

Microsoft 365 / Entra ID

Une architecture opérationnelle à deux niveaux

Le modèle opérationnel actuel de Tycoon 2FA se divise en deux niveaux d'infrastructure distincts, chacun ayant son propre ASN, son propre rôle et sa propre signature comportementale. Les défenseurs à la recherche d'un modèle unique attraperont un niveau et manqueront l'autre.

Tier 1 - Kit Relais

Le backend automatisé qui gère l'acquisition et le renouvellement des jetons. Caractéristiques :

• Les IP de sortie de Cloud-VPS des fournisseurs d'hébergement (Alibaba Cloud, ASNs similaires de VPS bon marché), tournent sur plusieurs IP dans différents blocs /16 au cours d'un même engagement.
• Agents utilisateurs du client HTTP Node.js : node (nu, UA Node.js par défaut), axios/1.15.2, node-fetch/1.0, undici.
• Application client : Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e), utilisé par la suite avec Device Registration Service (DRS) pour frapper un primaryRefreshToken (PRT).
• Progression du type de jeton : incomingTokenType : none (authentification initiale de la victime) > refreshToken (boucle de renouvellement du relais de kit, répétée sur des IP tournantes) > Rogue Device Registration > primaryRefreshToken (relecture de l'outillage, portée plus large).
• Inscriptions non interactives : Après l'exécution du code de dispositif interactif initial, les opérations de jeton suivantes sont des rafraîchissements de serveur à serveur.

Tier 2 - Console de l'opérateur

L'homme (ou l'outil de simulation humaine) qui effectue la reconnaissance après la compromission. Caractéristiques :

• La sortie d'un FAI ou d'un proxy en forme de résidence, généralement un petit ASN qui n'est pas présent dans les flux de menaces des fournisseurs d'hébergement. Plusieurs IP dans un seul /24, tous agissant de manière coordonnée.
• Un seul agent utilisateur de navigateur (par exemple, Firefox sur Windows) fixe sur toutes les IP du cluster. Un outil configuré, pas des utilisateurs indépendants.
• Connexion interactive par navigateur aux applications web de Microsoft : Mon profil, Mes identifiants, Gestion des approbations Microsoft, Outlook Web et OfficeHome.
• Un seul c_sid (identifiant de session du client dans les journaux d'activité du graphique) partagé par toutes les IP, confirmant une session unique répartie dans le pool.
• Tempo opérationnel : apparaît généralement 10 à 20 minutes après la première émission réussie de jetons par le relais. L'écart représente la fenêtre de transfert du kit à l'opérateur.

Le signal de détection durable à plusieurs niveaux : Deux ASN distincts (l'un en nuage, l'autre en forme résidentielle) s'authentifiant comme le même utilisateur principal en quelques minutes. Les règles de l'ASN unique permettent d'attraper un échelon ; le pivot entre les échelons est l'indicateur de confiance élevé.

Énumération de l'API graphique après la compromission

Une fois que la console d'opérateur dispose d'un jeton valide, elle lance une série d'appels à l'API Microsoft Graph, généralement des dizaines de requêtes en l'espace de 30 à 60 secondes, qui atteignent des points d'extrémité de reconnaissance de grande valeur :

Indicateurs télémétriques clés de la reconnaissance automatisée post-compromission :

• Volume et vitesse : 20-30+ appels dans une fenêtre de 30-60 secondes, chacun touchant un point de terminaison différent.
• Méthodes HTTP mixtes : GET pour la plupart des points d'extrémité, POST pour des actions telles que getResourceTenants.
• Paramètres de requête structurés : $select, $top=999, $count=true - optimisés pour une extraction maximale de données par appel.
• Utilisation de l'API /beta/ : Utilisation disproportionnée par les outils offensifs par rapport à la navigation normale sur le portail.
• Succès/échec mitigé : Certains points d'extrémité renvoient 400 ou 403 (le kit sonde tout indépendamment), tandis que la plupart renvoient 200. Les tentatives de reconnaissance qui ont échoué sont toujours des tentatives de reconnaissance.
• C_DeviceId vide : Le jeton a été délivré à un appareil non géré et non enregistré.
• Applications de première partie avec de vastes champs d'application pré-consentis : Les jetons pour Mon profil ont des portées incluant RoleManagement.ReadWrite.Directory, MailboxSettings.ReadWrite, UserAuthenticationMethod.ReadWrite, et User.RevokeSessions.All - tous pré-consentis, ne nécessitant pas de demande de consentement OAuth.

Persistance du dispositif-PRT

Comme indiqué précédemment, le kit peut établir une persistance de l'enregistrement des appareils qui survit aux playbooks de révocation de session standard. Le mécanisme :

1. Le jeton de rafraîchissement MAB est remplacé par un jeton d 'accès dont l'aud est urn :ms-drs:enterpriseregistration.windows.net (même identifiant de client, nouvelle audience, pas de demande de consentement).
2. Le kit utilise le jeton d'accès urn :ms-drs:enterriseregistration.windows.net pour POST endpoint EnrollmentServer/device avec une CSR PKCS#10 générée localement, des métadonnées synthétiques de l'appareil et un blob de clé de transport. DRS crée un objet périphérique, attribue un identifiant au périphérique, signe et renvoie un certificat de périphérique.
3. Le kit crée un JWT contenant le jeton de rafraîchissement de l'utilisateur, le signe RS256 avec la clé privée de l'appareil et intègre le certificat de l'appareil dans l'en-tête du JWT. Il envoie cette information à login.microsoftonline.com/common/oauth2/token. en tant que JWT bearer grant. Entra valide la signature par rapport au certificat et renvoie l'EPR ainsi qu'une clé de session cryptée (JWE).
4. Lorsqu'un défenseur déclenche la procédure revokeSignInSessions (qui invalide tous les jetons de niveau utilisateur et les jetons d'actualisation), l'outillage de l'appareil reste valide car l'appareil est un principal distinct dans Entra ID.
5. À partir des nouvelles IP de relais, le kit utilise l'outillage et la clé de session pour signer des assertions HMAC-SHA256 par demande vers /oauth2/token, en négociant des jetons d'accès pour toute première partie de client_id qu'il nomme (Teams, Outlook, OneDrive, Office, Intune).

Pourquoi la révocation des sessions n'arrête-t-elle pas Tycoon 2FA ?

Cela signifie que la séquence standard de réponse à un incident, à savoir "révoquer les sessions > réinitialiser le mot de passe", est insuffisante. Les défenseurs doivent énumérer et supprimer les dispositifs enregistrés avant de révoquer les sessions afin de rompre la chaîne dispositif-PRT de manière atomique.

Nuances de détection - Microsoft

La protection de l'identité peut ne pas signaler l'infrastructure du kit. Les adresses IP de sortie actuelles de Tycoon 2FA font l'objet d'une rotation agressive et peuvent ne pas figurer dans le corpus de risques de Microsoft. Les défenseurs qui s'appuient uniquement sur les signaux de risque Entra ID pour la détection AiTM ne verront rien.

c_sid dans les journaux d'activité du graphique n'est PAS l'ID de l'objet de l'utilisateur. Il s'agit d'un identifiant de session/contexte de sécurité. Les analystes qui filtrent les journaux d'activité Graph par c_sid == user_object_id obtiendront des résultats vides et concluront que l'attaquant n'a pas utilisé de jetons Graph. Le pivot correct de la chasse est l'IP source + l'appId, croisé avec les journaux de connexion pour faire correspondre l'IP à l'utilisateur.

La géolocalisation n'est pas fiable pour les IP des fournisseurs de services en nuage. Le même kit relais IP peut être géolocalisé dans différentes villes au cours de la même session de connexion. L'ASN est le seul enrichissement fiable pour les règles de détection.

Visibilité de la frappe des jetons. La frappe ou l'émission de jetons n'est pas enregistrée ; les événements d'authentification utilisant ces jetons proposent un signal de chasse plus réactif.

Entra ID Protection Statut d'utilisateur à risque. Entra ID protection analyse les événements de connexion, les sessions, les jetons et autres pour appliquer un niveau de risque et un statut aux utilisateurs. aiConfirmedSafe a été observé pendant le relais de niveau 2 , indiquant que l'utilisateur ne court aucun risque. Des anomalies de risque utilisateur ont ensuite été identifiées sur la base de l'anomalousToken, ce qui a permis de replacer l'utilisateur dans une situation de risque moyen. Il suffit d'exclure de l'étiquetage de Microsoft les événements pour lesquels aiConfirmedSafe peut rendre les organisations aveugles aux faux négatifs.

Google Workspace

Kit relais à un étage

La variante Google fonctionne comme un relais de kit à un seul niveau, sans la console d'opérateur distincte que l'on trouve du côté de Microsoft. Plusieurs IP de relais de kit (généralement des ASN d'hébergement bon marché comme Clouvider, Host Telecom ou similaires) authentifient le même utilisateur en l'espace de quelques minutes, chacun exécutant la même séquence de quatre événements :

1. login_success mot de passe validé (T+0.000s)
2. login_verification avec is_second_factor: true - le kit transmet le code TOTP/SMS/push en temps réel, complétant le 2SV (T+0.000s)
3. token : autoriser pour le client OAuth Chrome de Google (77185425430) (T+0.4 à 0.6s)
4. DEVICE_REGISTER_UNREGISTER_EVENT (le nouvel appareil est enregistré par Google grâce à l'authentification du profil) (T+0,6 à 1,2s)

Cette compression d'environ 1 seconde est le signe d'une connexion automatisée.

Le kit autorise systématiquement le même client OAuth à chaque session de relais :

La portée OAuthLogin est la portée de connexion interne de démarrage de Chrome. Il ne s'agit pas d'une portée de plan de données (elle n'accorde pas en soi l'accès à Gmail, Drive ou Calendar). Le rayon d'action du kit à partir de cette portée unique est lié à une connexion de longue durée capable de devenir une session Chrome Sync, et non un accès direct à une boîte aux lettres ou à un fichier sans autres appels d'échange de jetons.

L'événement token.authorize d'un VPS ASN confirme que l'autorisation se produit côté serveur pendant le relais, et non depuis l'appareil de la victime, ce qui le rend suspect, quelle que soit l'intention de l'opérateur.

Kit architecture JavaScript (variante Google)

La décompilation de la variante WebSocket ciblant Google révèle une architecture à cinq couches :

Les champs de saisie du site 15 reprennent toutes les méthodes 2FA de Google : mot de passe, TOTP, SMS, appel vocal, codes de sauvegarde, courriel de récupération, vérification par téléphone, repli de la clé de sécurité, invite mobile et changement forcé du mot de passe. Le nom de l'événement Socket.IO "recieveid" (notez la faute de frappe) est une empreinte cohérente du kit.

Nuances de détection - Google

Le Centre d'alerte Google peut rester silencieux. Même lorsque plusieurs connexions à partir de plusieurs ASN touchent le même utilisateur en l'espace de quelques minutes, les enregistrements du Centre d'alerte peuvent ne pas être transmis à l'API d'alerte. Les messages d'alerte de sécurité de la boîte aux lettres de la victime de Google ne constituent pas une solution de remplacement, car ils sont envoyés à la boîte de réception de l'utilisateur compromis, et non à la surface d'administration.

is_suspicious ne peut pas être déclenché. Les adresses IP de relais de kits provenant d'ASN d'hébergement bon marché peuvent ne pas figurer dans le corpus de risques de Google. Les défenseurs qui s'appuient sur ce champ comme signal principal auront des angles morts. Dans l'engagement canari, is_suspicious était faux sur chaque login_success à partir des quatre IP du kit, à la fois chez Clouvider et chez Host Telecom.

Pas de user-agent sur les événements de connexion : Les événements de connexion à l'API Reports ne comprennent pas de données relatives à l'agent utilisateur ou à l'empreinte digitale de l'appareil. Les détections basées sur l'AU qui fonctionnent du côté d'Entra (node / axios / undici) n'ont pas d'équivalent direct sur Google.

La visibilité du flux de travail OAuth est superficielle : L'événement token.authorize de Google fait apparaître l'identifiant du client, app_name, client.type, et scope.value, et c'est l'ensemble complet. Il n'y a pas d'identifiant de ressource distinct de l'étendue, pas de champ de type de subvention, ni de champ de type de jeton entrant.

La plupart des flux auxiliaires restent silencieux : pas de google_workspace.context_aware_access se sont déclenchés (malgré cinq nouveaux enregistrements d'appareils pour l'utilisateur) et aucun enregistrement du Centre d'alerte n'a atteint l'API d'alerte. L'empreinte du kit n'existe que dans trois flux : connexion, jeton et appareil. Les chasses qui dépendent d'un autre flux ne détecteront pas ce kit.

Tycoon 2FA sur Entra ID et Google Workspace

La variante M365 est plus lourde sur le plan opérationnel, et l'enregistrement fournit de nombreux détails avant et après la compromission de l'identité. La variante Google Workspace est plus légère (seules des ouvertures de session ont été observées), mais la journalisation par défaut manque d'un contexte important.

Règles de détection du comportement de Tycoon 2FA

Nous avons expédié des règles de détection à travers les sources de télémétrie de Microsoft et de Google couvrant l'ensemble de la chaîne d'attaque : l'hameçonnage AiTM initial, le relais de jeton, la reconnaissance de la console de l'opérateur et la persistance de l'appareil.

Microsoft - Kit de détection de relais

Entra ID Potential AiTM Sign-In via OfficeHome (Tycoon2FA) - Il s'agit d'une détection à signal élevé qui se déclenche sur les connexions Auth Broker ou OfficeHome à Graph/Exchange avec des agents utilisateurs de type Node.js (node, axios, undici). Capture les opérations de jetons côté serveur de l'étage de relais du kit.

M365 Potential AiTM UserLoggedIn via Office App (Tycoon2FA ) - Même logique de détection que la règle d'ouverture de session d'Entra mais par rapport au journal d'audit unifié M365 pour les locataires qui ingèrent o365.audit au lieu de (ou en plus de) journaux d'ouverture de session d'Entra.

Entra ID OAuth Device Code Phishing via AiTM : Détecte les ouvertures de session interactives réussies par code de dispositif via l'Auth Broker ciblant Exchange, Graph, ou SharePoint. Attrape spécifiquement la variante d'abus device-code-grant.

Entra ID Microsoft Authentication Broker Sign-In to Unusual Resource : détecte les connexions Auth Broker réussies lorsque la ressource cible ne fait pas partie de l'ensemble des premières parties généralement observées. Capture l'échange de jetons FOCI vers des API ou des applications d'entreprise inattendues.

Microsoft - Détection de la persistance

Entra ID Register Device with Unusual User Agent (Azure AD Join) : Détecte les événements d'enregistrement de dispositifs réussis lorsque l'agent utilisateur n'est pas l'un des clients d'enregistrement natifs connus (Dsreg, DeviceRegistrationClient, Dalvik). Attrape le jeu de persistance device-PRT du kit provenant également de l'agent utilisateur axios :

Énumération de l'API graphique après la compromission (ES|QL)

Pour la reconnaissance post-compromission du niveau de la console opérateur, nous avons élaboré une règle ES|QL qui classe chaque requête Microsoft Graph API dans l'une des cinq catégories de reconnaissance et qui se déclenche lorsque 4 ou plus de catégories distinctes sont atteintes dans la fenêtre d'agrégation (<= 60s) :

Microsoft Graph Multi-Category Reconnaissance Burst capture l'énumération systématique post-compromission tout en filtrant l'utilisation organique des portails. L'activité normale d'un utilisateur peut toucher une ou deux de ces catégories, mais le fait de toucher 4 ou plus de catégories de reconnaissance distinctes au cours d'une seule session dans une courte fenêtre (33 secondes) est l'empreinte digitale de l'outil automatisé.

Google - Kit de relais et de détection de persistance

Google Workspace Impossible Travel Login - Règle ES|QL utilisant *st_distance()* des fonctions géospatiales pour détecter les connexions réussies à partir d'emplacements impliquant un déplacement plus rapide que 800 km/h avec une séparation d'au moins 500 km. Capture le modèle de relais de kit multi-ASN où plusieurs IP dans différentes géolocalisations authentifient le même utilisateur en l'espace de quelques minutes :

Connexion d'un utilisateur de Google Workspace à partir d'un ASN atypique - nouvelle règle qui détecte la première fois qu'un utilisateur de Google Workspace se connecte avec succès à partir d'un ASN source donné au cours d'une fenêtre historique de 14 jours.

Google Workspace Device Registration After OAuth from Suspicious ASN : règle de séquence EQL détectant l'autorisation OAuth pour le client Chrome (77185425430.apps.googleusercontent.com) à partir d'un ASN d'hébergement bon marché, suivie dans les 30 secondes par l'enregistrement d'un appareil avec l'état du compte REGISTERED.

Rafale d'enregistrements d'appareils Google Workspace pour un seul utilisateur - Détecte les rafales d'événements d'enregistrement d'appareils Google Workspace pour le même utilisateur, lorsqu'au moins trois valeurs distinctes sont émises dans une fenêtre d'une minute.
google_workspace.device.id distinctes sont émises dans une fenêtre d'une minute :

Automatiser le confinement avec Elastic Workflows

Une fois que le contenu de la détection est en place, l'étape suivante est le temps qui s'écoule entre l'alerte et l'action. La fenêtre de transfert du kit Tycoon 2FA M365 à l'opérateur que nous avons décrite précédemment est de 10 à 20 minutes, c'est-à-dire le temps qui s'écoule entre la première émission réussie de jetons par le relais du kit et le moment où la session de l'opérateur commence sa reconnaissance graphique après la compromission.

Une intervention manuelle du SOC prend généralement plus de temps que ce délai, c'est pourquoi l'opérateur effectue le travail de reconnaissance avant l'atterrissage du confinement. C'est en comblant cette lacune que l'on peut agir sur la détection.

Elastic Workflows, livré avec la pile (9.4+), permet aux règles de détection d'invoquer des workflows personnalisés avec un pipeline d'étapes défini en YAML pour chaque alerte.

En tant que PoC, nous avons construit un flux de travail personnalisé relié à une règle de détection Entra ID Potential AiTM Sign-In via OfficeHome (Tycoon2FA) qui reflète les actions de réponse requises.

À chaque alerte, le flux de travail :

1. Acquiert un Graph bearer via client_credentials (une fois par exécution).
2. PATCH le UPN compromis avec accountEnabled: false pour stopper les nouvelles authentifications.
3. Enumère les registeredDevices et les ownedDevices de l'utilisateur.
4. DELETE chaque principal de périphérique, ce qui invalide réellement un outillage lié à un périphérique.
5. POSTs à revokeSignInSessions pour invalider les jetons de rafraîchissement au niveau de l'utilisateur et les cookies de session.
6. Ouvre un cas Kibana alimenté par le contexte d'alerte pour l'audit post-IR (réinitialisation du mot de passe, examen de la méthode d'authentification, audit de l'octroi d'OAuth).

La chaîne s'exécute en moins de 10 secondes de bout en bout contre Microsoft Graph, bien en deçà de la fenêtre de transfert de 10 à 20 minutes de Tycoon 2FA. La session de niveau opérateur n'a jamais l'occasion de commencer la reconnaissance.

Le modèle s'étend au-delà de cette règle. La même forme de flux de travail fonctionne pour toute détection d'identité dans le nuage qui bénéficie d'un confinement immédiat : Inscriptions AiTM, voyages impossibles, consentements OAuth illicites, escalade des rôles, fatigue MFA, enregistrement anormal d'appareils. Reliez la règle à un flux de travail qui appelle l'API cloud appropriée et le SOC obtient un confinement au niveau des secondes.

Défense contre les attaques Tycoon 2FA AiTM

• Déployez un système MFA résistant à l'hameçonnage : les clés de sécurité FIDO2 et les clés d'accès sont les seules méthodes à l'abri du vol de session AiTM. TOTP, SMS et MFA basée sur le push peuvent tous faire l'objet d'une procuration.
• Assurez la conformité des appareils grâce à l'accès conditionnel : Exigez des appareils gérés et conformes pour l'émission de jetons. Il s'agit de la mesure de contrôle la plus efficace contre le vol de jetons AiTM.
• Bloquer les flux de codes de dispositifs : La politique d'accès conditionnel de Block device code flow rejette proprement le relais de kit lors de la phase d'octroi (erreur 53003). Activez-la pour tous les utilisateurs, à l'exception des scénarios kiosque/sans tête explicitement approuvés.
• Activer la protection des jetons (token binding) : Lier les jetons à l'appareil pour lequel ils ont été émis. Un jeton volé, rejoué à partir d'un autre appareil, est rejeté.
• Permettre l'évaluation continue de l'accès (CAE) : Révocation des jetons en temps quasi réel lorsque les conditions de risque changent.
• Enable Security Defaults in Entra ID (uniquement pour les locataires sans accès conditionnel personnalisé) : rejette l'authentification ancienne telle que ROPC et bloque le flux de code de l'appareil par défaut. L'activation des valeurs par défaut de la sécurité désactive les stratégies personnalisées de l'autorité de certification, ce qui ne s'applique donc pas aux locataires qui utilisent déjà une autorité de certification granulaire.

MITRE ATT&CK Mapping

Références

• Microsoft Security Blog - Inside Tycoon2FA : Comment un kit d'hameçonnage AiTM de premier plan a fonctionné à grande échelle (mars 2026)
• Analyse du logiciel malveillant Tycoon 2FA, aperçu par ANY.RUN
• Cloudflare - Tycoon 2FA Takedown (mars 2026)
• SpyCloud - Tycoon 2FA Takedown (en anglais): Au cœur de la perturbation de l'infrastructure mondiale de l'hameçonnage (mars 2026)
• eSentire - Les opérateurs Tycoon 2FA adoptent OAuth Device Code Phishing (mai 2026)
• Sekoia - Tycoon 2FA : une analyse approfondie de la dernière version du kit de phishing AiTM (mars 2024)