EvilTokens/ARToken : device‑code contre Microsoft 365 — passez à FIDO2

Excerpt — Le 3 juillet 2026, BleepingComputer et Cisco Talos ont exposé « ARToken », une plateforme liée à EvilTokens qui détourne le flux OAuth « device code » pour prendre des comptes Microsoft 365 malgré la MFA. Voici comment une MFA résistante au phishing (FIDO2/WebAuthn) et des contrôles d’accès bloquent l’attaque et prouvent l’article 32 RGPD.

Les faits

Le 3 juillet 2026, BleepingComputer a révélé qu’ARToken, une offre « phishing‑as‑a‑service » (PhaaS), exploite le Device Authorization Grant d’OAuth 2.0 (dit « device code ») pour détourner l’authentification sur Microsoft 365. Les chercheurs de Cisco Talos ont lié ARToken au kit EvilTokens sur la base d’API identiques et d’infrastructures communes. Selon les éléments publiés, l’opérateur affiche un code appareil sur une fausse page, puis pousse la victime à se rendre sur le véritable site Microsoft pour saisir ce code. Une fois l’authentification (y compris MFA) validée par l’utilisateur sur le portail légitime, l’attaquant reçoit un jeton OAuth utilisable pour lire la messagerie, créer des règles cachées, lancer des BEC et pivoter vers d’autres SaaS.

Des indicateurs de compromission (IOCs) publics sont associés à ces campagnes :

• Patrons d’API du kit : /api/device/start et /api/device/status observés par Talos et des sandboxes publiques ; en réseau, la présence de l’en‑tête X‑Antibot‑Token hors hôtes légitimes est un signal fort.
• Hébergement en grappe sur des Cloudflare Workers (noms éphémères), déjà reliés à EvilTokens/ARToken.

Ces artefacts techniques sont documentés par BleepingComputer (03/07/2026) et des analyses de sandboxes qui décrivent précisément les appels API et entêtes utilisés par les kits device‑code récents (BleepingComputer) ; voir aussi une synthèse Q2 publiée par Cisco Talos le 28 juillet 2026, qui confirme la montée du phishing comme point d’entrée n°1 et détaille le lien ARToken↔EvilTokens (Cisco Talos). Le Register relaie par ailleurs un ordre de grandeur donné par Microsoft : 10 à 15 campagnes/jour observées depuis le 15 mars 2026 (The Register).

Le cadre légal qui s’applique

Pour les entreprises au Luxembourg, en Belgique, en France, en Allemagne et dans l’UE, l’article 32 du RGPD impose des « mesures techniques et organisationnelles appropriées » pour garantir un niveau de sécurité adapté au risque, et la capacité à démontrer leur efficacité. La CNPD rappelle cette obligation et la nécessité de prouver la proportionnalité et l’effectivité des contrôles (journalisation, contrôle d’accès, authentification robuste, etc.) (Article 32, CNPD), (CNPD — Sécurité informatique: enjeux et objectifs). La jurisprudence de l’UE confirme que le responsable du traitement doit pouvoir démontrer ses mesures et leur adéquation au risque (Art. 24 et 32) (CJUE, C‑340/21). Pour situer ces obligations dans votre programme, consultez nos contenus dédiés au cadre RGPD applicable.

En pratique, un vol de jetons OAuth via device code qui expose des boîtes aux lettres et des données personnelles engage la responsabilité du responsable du traitement : il doit montrer que l’authentification déployée est résistante au phishing, que les flux à risque (device code, consentements OAuth) sont maîtrisés, et que la détection et la remédiation sont opérationnelles.

La solution technique à déployer

MFA résistante au phishing (FIDO2/WebAuthn) + politiques d’accès conditionnel adaptées à OAuth. L’objectif : éviter la capture d’identifiants et réduire à presque zéro la valeur d’un lien/piège. En complément, encadrer ou désactiver le flux device code et protéger les jetons.

• FIDO2/WebAuthn (passkeys) : authentification par clé publique (aucun secret à partager), liaison cryptographique au domaine (origin binding), empêchant les kits de proxy/MITM de réutiliser un défi. Référentiels : ISO/IEC 27001 :2022 Annexe A 5.17 (informations d’authentification), A 5.15 (contrôle d’accès) ; NIST CSF 2.0 PR.AA ; CIS Control 6.7 (Require MFA).
• Contrôles OAuth/Entra ID : restreindre ou bloquer le Device Authorization Grant si non nécessaire ; imposer des Conditional Access (conformité appareil, géolocalisation, risque) ; exiger une MFA résistante à chaque consentement ; utiliser la Token Protection quand disponible et activer Continuous Access Evaluation.
• Détections ciblées : règles SIEM/XDR sur IOCs ARToken/EvilTokens (requêtes /api/device/start, /api/device/status, entête X‑Antibot‑Token, grappes de domaines workers.dev corrélées) ; alertes sur créations de règles de boîte, consentements OAuth anormaux, et connexions device code inattendues.
• Hygiène de session : révocation proactive des refresh tokens à la moindre suspicion ; rotation des secrets d’applications ; inventaire et revue trimestrielle des apps OAuth autorisées.
• Durcissement Helpdesk : procédures d’enrôlement MFA à haute vérification pour couper court aux scénarios de social engineering (vishing) qui visent l’inscription de nouveaux facteurs.

Pourquoi cela répond à l’article 32 : vous documentez des mesures « adaptées au risque » (phishing avancé ciblant M365), traçables, testables (journaux d’authentification, règles SIEM), et proportionnées (FIDO2 pour profils à risque, politiques conditionnelles pour tous), conformément aux attentes CNPD/EDPB (CNPD), (EDPB — Sécuriser les données).

Comment Luxgap déploie cela

• Notre gouvernance ISO 27001 : cadrage des politiques d’authentification (A 5.15/5.17), matrice de risques, preuves d’efficacité (KPIs d’échecs d’authentification phishing‑résistante, revues des consentements OAuth), et dossiers Art. 32 prêts à produire en cas de contrôle CNPD.
• Notre SOC managed 24/7 : ingestion des logs Entra ID/M365, corrélation des IOCs ARToken/EvilTokens (URI/headers/destinations), détection des device code sign‑ins atypiques, playbooks SOAR de révocation de jetons et purge de règles malveillantes.
• Notre plateforme e‑learning : modules concis « reconnaître le device‑code phishing », exercices de just‑in‑time training intégrés à Microsoft 365, et certification d’achèvement pour démontrer la mesure organisationnelle (Art. 32).

Cas concret au Luxembourg ou en UE

Une société de gestion soumise à NIS 2 au Luxembourg a subi, en simulation rouge, une tentative d’hameçonnage device‑code sur ses administrateurs M365. En 6 semaines, nous avons : (1) déployé FIDO2 pour les comptes à privilèges et le personnel financier ; (2) désactivé le flux device code sauf sur quelques bornes d’affichage inventoriées ; (3) établi des politiques d’accès conditionnel (appareil conforme + emplacement de confiance) ; (4) connecté les journaux d’authentification au SIEM avec des règles sur les IOCs ARToken/EvilTokens ; (5) entraîné le support à l’enrôlement MFA « zéro vishing ». Résultat : deux tentatives réelles détectées la semaine suivante, jetons révoqués en moins de 12 minutes, aucune donnée personnelle exposée, dossier de preuve Art. 32 tenu à jour.

Premiers pas concrets

1. Cartographiez vos méthodes d’authentification (Entra ID → Authentication methods) et forcez FIDO2/WebAuthn pour les administrateurs et métiers sensibles dès cette semaine.
2. Désactivez le flux « device code » partout où il n’est pas strictement nécessaire ; à défaut, limitez‑le par accès conditionnel (appareil conforme, géo, heure ouvrée).
3. Inventoriez les applications OAuth autorisées, révoquez les jetons inactifs, et mettez en place une alerte SIEM sur toute création de règle de boîte et tout consentement high‑risk.
4. Déployez des détections sur IOCs ARToken/EvilTokens : requêtes /api/device/start / /api/device/status, entête X‑Antibot‑Token, grappes de domaines workers.dev corrélées, et device code sign‑ins hors profils approuvés.
5. Briefez le helpdesk : script de vérification d’identité renforcé avant tout enrôlement/remplacement MFA ; refusez toute demande d’enrôlement initiée par téléphone sans validation hors bande.

Sources officielles

• BleepingComputer — ARToken PhaaS exposes EvilTokens’ Microsoft 365 phishing toolkit (03/07/2026)
• Cisco Talos — IR Trends Q2 2026 : phishing et ARToken/EvilTokens (28/07/2026)
• The Register — EvilTokens device‑code phishing kit (01/07/2026)
• CNPD — RGPD, Article 32 : sécurité du traitement
• CJUE C‑340/21 — charge de la preuve et mesures appropriées (Art. 24 et 32)
• EDPB — Sécuriser les données