Tycoon 2FA : attaque « device code » contre la MFA Microsoft

Excerpt — Le 12 mai 2026, eSentire a documenté une campagne Tycoon 2FA qui abuse le “device code” Microsoft pour voler des jetons OAuth sans demander de mot de passe. Voici comment une MFA résistante au phishing (FIDO2/WebAuthn) répond à l’article 32 RGPD.

Les faits

Le 12 mai 2026, l’équipe TRU d’eSentire détaille une campagne active réutilisant le kit de phishing Tycoon 2FA pour détourner le flux “OAuth Device Authorization Grant” de Microsoft 365. Le scénario est simple et redoutable : un email de facture ou de message vocal renvoie à une URL de suivi légitime (ex. events.trustifi[.]com), puis à un sous‑domaine jetable Cloudflare Workers (ex. cookies.28gholland[.]workers[.]dev). Après plusieurs couches d’anti‑analyse côté navigateur, la page affiche un “device code” et demande à la victime de le saisir sur microsoft.com/devicelogin, c’est‑à‑dire sur un formulaire Microsoft authentique. La victime consent alors, sans s’en rendre compte, à l’application “Microsoft Authentication Broker” (AppId 29d9ed98‑a469‑4536‑ade2‑f981bc1d605e), ce qui remet au pirate des jetons OAuth fonctionnels pour Exchange Online, Graph et OneDrive, tout en ressemblant à une activité normale dans Entra.

Des IOCs publics permettent la chasse et le blocage :

• Domaines/URLs : events.trustifi[.]com/api/o/v1/click/<id> (lien de suivi légitime abusé), cookies.28gholland[.]workers[.]dev (redirection), shivacrio[.]com/bytecore~tx1j8 (domaine de “Check Domain” servant de garde anti‑analyse) — eSentire publie une regex URLScan pour les détecter.
• AppIds : 29d9ed98‑a469‑4536‑ade2‑f981bc1d605e (Microsoft Authentication Broker), 4765445b‑32c6‑49b0‑83e6‑1d93765276ca (OfficeHome, variante credential‑relay).
• User‑Agents opérateur : “node”, “undici” observés en back‑end d’automatisation (polling des statuts d’authentification).

Ce mode opératoire confirme l’érosion des OTP/push face aux attaques modernes (AiTM, consent phishing, device code). En février 2026, BleepingComputer signalait déjà des attaques “device code vishing” exploitant des flux d’authentification légitimes pour contourner la MFA classique.

Le cadre légal qui s’applique

L’article 32 RGPD impose des “mesures techniques et organisationnelles appropriées”, compte tenu des risques, dont — à titre d’exemples — la confidentialité, l’intégrité, la disponibilité et des mesures comme le chiffrement et la capacité à résister aux incidents. En matière d’authentification, il s’agit de prouver que les mécanismes déployés sont état de l’art face aux menaces effectives (phishing, vol de session, consentements abusifs, token theft). Texte consolidé : EUR‑Lex — 2016/679, art. 32. Pour approfondir la sécurité du traitement RGPD, consultez notre page dédiée RGPD.

Pour les entités soumises à NIS 2 au Luxembourg, la détection et la gestion des incidents restent sous le regard de l’ILR (notification via SERIMA), mais l’angle de cet article est la sécurité du traitement RGPD. Une MFA résistante au phishing constitue un élément clé démontrable du respect de l’art. 32.

La solution technique à déployer

MFA résistante au phishing (FIDO2/WebAuthn + politiques d’accès conditionnel)

• Principe : les authentificateurs FIDO2/WebAuthn génèrent des clés privées liées à l’appareil (device‑bound) et au domaine (origin binding). Aucun secret réutilisable (OTP, code par SMS/push) n’est saisi sur un site potentiellement piégé : rien à intercepter.
• En pratique (Microsoft Entra, Okta, etc.) :
  • Bloquer ou restreindre le flux Device Code par Conditional Access lorsque non justifié (ou exiger un contexte géré : poste conforme, réseau approuvé).
  • Exiger FIDO2/passkeys pour les administrateurs et comptes à risque élevé ; retirer SMS/voix/email OTP.
  • Activer des protections anti‑token theft (signatures liées au device, tokens proof‑of‑possession quand disponibles), contrôler les consents OAuth (publisher vérifié, politiques d’application).
  • Surveiller dans les logs Entra sign‑in : AuthenticationProtocol=deviceCode avec ResultType=0 inattendu, AppId suspecte/inhabituelle, UA “node/undici” sur des connexions non interactives.
• Référentiels :
  • ISO/IEC 27001:2022 Annex A — A.8.5 Secure authentication, A.5.15 Access control ;
  • NIST SP 800‑63B — authentificateurs résistants au phishing ;
  • CIS Controls v8 — 6.3/6.5 (MFA étendue, admin/remote).

Comment Luxgap déploie cela

• Notre gouvernance ISO 27001 : cadrage des politiques d’authentification (cartographie des risques, cible FIDO2 par population, matrice d’habilitations), preuves de conformité article 32 (revues périodiques, KPI de réduction de surface OTP).
• Notre SOC managed 24/7 : intégration des télémétries (Entra/Okta, EDR/XDR), détection des signaux device code anormaux, chasse proactive des IOCs Tycoon 2FA et des patterns de consent phishing, runbooks de révocation de tokens et de réponse OAuth.
• Notre plateforme e‑learning : modules ciblés “ne jamais saisir un code affiché ailleurs que sur votre appareil d’authentification”, simulations de vishing/consentement anormal, certificats et mesure d’engagement pour attester privacy by design.

Cas concret au Luxembourg ou en UE

Une fiduciaire soumise à NIS 2 et traitant des données RH et financières a connu des alertes sur des authentifications deviceCode inédites via Entra. En 6 semaines, nous avons : (1) établi une politique d’accès conditionnel bloquant le device code hors postes gérés ; (2) migré les administrateurs et les utilisateurs sensibles vers passkeys FIDO2, en supprimant le SMS/push ; (3) mis en place un process de révocation de tokens et la revue hebdomadaire des consents OAuth ; (4) intégré dans le SIEM des détections sur AppId=29d9ed98-...605e et UA “node/undici”. Résultat : plusieurs tentatives ultérieures ont été bloquées au contrôle de flux, sans impact opérationnel.

Premiers pas concrets

1. Désactiver les facteurs faibles (SMS/voix/email OTP) pour les comptes à privilèges et les populations sensibles ; piloter un groupe pilote FIDO2/passkeys.
2. Dans Entra/Okta, restreindre ou bloquer le flux Device Code et forcer un contexte géré (poste conforme, réseau de confiance) quand ce flux est réellement nécessaire.
3. Mettre en place des règles SIEM : détections sur AuthenticationProtocol=deviceCode, AppId 29d9ed98‑...‑605e, UA “node/undici”, et chasse des domaines *.workers[.]dev suspects et des Check Domains type .../[a-zA-Z0-9]{1,20}[~!@$][a-zA-Z0-9]{1,20}.
4. Revoir les consents OAuth : imposer l’éditeur vérifié, restreindre les scopes sensibles, et établir un playbook de révocation/rotation de tokens.
5. Sensibiliser en 15 minutes : “si une page vous montre un code et vous envoie sur un site légitime pour le saisir, méfiez‑vous” ; alerter immédiatement le SOC.

Sources officielles

• Campagne Tycoon 2FA “device code” (IOCs, TTPs) — eSentire TRU, 12 mai 2026.
• Tendance “device code vishing” contre Entra — BleepingComputer, 19 février 2026.
• Cadre légal — RGPD, article 32 (EUR‑Lex).
• Luxembourg NIS 2 — notification via SERIMA (ILR) et page NIS 2 (ILR) pour le périmètre et l’organisation nationale.

Besoin d’accompagnement ? Contactez‑nous via la page contact.