Okta/SSO visés par vishing: FIDO2 contre le contournement MFA

Incident avéré (janvier 2026) : des comptes SSO Okta/Microsoft ont été compromis via une campagne de vishing + proxy AiTM capturant identifiants et codes MFA en temps réel. IOC public : inclusivity-team[.]onrender.com. Une MFA résistante au phishing (FIDO2/WebAuthn) répond à l’obligation de sécurité de l’article 32 RGPD.

Les faits

Le 22 janvier 2026, BleepingComputer rapporte qu’une campagne active de vishing cible des entreprises pour voler des identifiants SSO (Okta, Microsoft Entra, Google). Les attaquants se font passer pour l’IT, dirigent vers un site d’hameçonnage “homme‑du‑milieu” (AiTM), interceptent l’authentification et relaient en direct les défis MFA. L’infrastructure a notamment utilisé un serveur Socket.IO hébergé sur inclusivity-team[.]onrender.com (IOC public). Les domaines de phishing imitent le nom de l’entreprise, souvent avec “internal” ou “my”, afin de capter l’authentification SSO puis d’exfiltrer des données (ex. CRMs) à des fins d’extorsion. Okta recommande explicitement une MFA résistante au phishing (passkeys FIDO2/WebAuthn, FastPass) face à ces kits adaptatifs. Source : BleepingComputer, 22/01/2026.

Dans les semaines suivantes, Microsoft a aussi alerté sur une vague de hameçonnage de grande ampleur (35 000 utilisateurs visés en trois jours, QR codes et pages “entreprise” très abouties) qui contourne les MFA traditionnelles et vise la prise de session. Ces campagnes confirment la tendance 2026 : l’AiTM, le “device code phishing” et les QR codes malveillants érodent l’efficacité des OTP/push. Voir synthèse TechRadar, 05/2026 et BleepingComputer, 19/02/2026.

IOC à surveiller (extraits publics)

• inclusivity-team[.]onrender.com (C2 Socket.IO) — source
• Noms de domaine typosquattés de type <entreprise>internal[.]com, my<entreprise>[.]com (patterns observés) — source

Le cadre légal qui s’applique

• RGPD — Article 32 : obligation de mesures techniques et organisationnelles “appropriées au risque”, dont l’authentification et la résilience, avec preuve d’évaluation régulière de l’efficacité. Texte officiel : EUR‑Lex. La CNPD renvoie à ces exigences : CNPD — Chapitre IV. Pour un rappel opérationnel au Luxembourg, voir nos contenus dédiés RGPD et conformité CNPD.
• Attentes concrètes du régulateur : authentification proportionnée aux risques (administrateurs, SSO, données sensibles), résistance aux menaces connues (phishing/AiTM), et capacité à démontrer le “state of the art” (FIDO2/WebAuthn reconnus comme résistants au phishing). Orientation ENISA sur NIS2 : ENISA, 26/06/2025.

Conclusion juridique : ne pas déployer une authentification résistante au phishing sur des accès à fort impact — alors que l’AiTM est une menace active — expose à un manquement à l’article 32.

La solution technique à déployer

MFA résistante au phishing (FIDO2/WebAuthn/passkeys) :

• Principe : authentification par clé publique avec “origin binding” (le défi est signé pour le domaine réel ; un proxy d’hameçonnage ne peut pas le rejouer). Pas de secret partagé, pas d’OTP interceptable, pas de push validable sous dictée.
• En pratique : activer FIDO2/WebAuthn au niveau de l’IdP (Okta, Entra ID, etc.), émettre des passkeys liées au domaine, et exiger une “force d’authentification” résistante au phishing pour :
  • comptes à privilèges (administration IT, sécurité),
  • SSO portail/courriel/SaaS exposés,
  • actions sensibles (changement de règles, export massif).
• Contrôles associés :
  • Token binding/antihijacking, réduction de durée de session, révocations rapides,
  • Politiques d’accès conditionnel exigeant “phishing‑resistant”,
  • Blocage des méthodes faibles (SMS/OTP/push) pour les comptes critiques,
  • Détection AiTM (signaux d’empreinte navigateur réseau, IP/TLS anormaux).
• Références : ISO/IEC 27001:2022 (A.5.17, A.8.2), NIST SP 800‑63B (AAL2/AAL3), CIS v8 (Safeguard 6).

Comment Luxgap déploie cela

• Gouvernance ISO 27001 : cadrage “par les risques”, Politique d’authentification, preuves RGPD art. 32 (revues d’efficacité, métriques d’adoption, rapports de tests). Si besoin d’un pilotage externalisé, notre offre de CISO externalisé sécurise la trajectoire.
• SOC managé 24/7 : intégration des journaux IdP (Entra/Okta), corrélation de signaux AiTM (device code anormal, signatures TLS proxy, SSO depuis ASN suspect), alertes et IOC blocking (dont inclusivity-team[.]onrender.com). Voir nos capacités de détection d’incident SOC managé.
• Plateforme e‑learning : modules “anti‑vishing/QR” avec simulations et attestations, complétant le standard technique. Parcours dédiés via nos offres de sensibilisation cyber.

Cas concret au Luxembourg ou en UE

Une société de services financiers (UE) dépendante d’Okta a subi des tentatives de vishing ciblant l’équipe finance. En 6 semaines :

• passage des administrateurs et des comptes “paiement” en FIDO2/passkeys avec policies “phishing‑resistant only” ;
• blocage des OTP/push pour ces rôles et réduction des durées de session ;
• règles SIEM cherchant les patterns AiTM (User‑Agent/TLS incohérents, device code hors périmètre) et IOC blocking (dont inclusivity-team[.]onrender.com) ;
• micro‑formation “anti‑vishing/QR” de 12 minutes.

Résultat : deux tentatives ultérieures ont échoué (authentification refusée car non FIDO2) ; alertes SOC corrélées en < 5 minutes avec blocage automatique. Pour un accompagnement local, consultez nos ressources dédiées à la cybersécurité au Luxembourg.

Premiers pas concrets

• Cherchez des traces : dans les logs Entra/Okta, filtrez les évènements “device code” et connexions depuis nouveaux ASN ; bloquez immédiatement toute communication vers inclusivity-team[.]onrender.com et recherchez des accès aux domaines “<entreprise>internal[.]com”/“my<entreprise>[.]com”.
• Figez la cible : décidez quels rôles et applications exigent “phishing‑resistant only” (administrateurs, SSO, mail, finance).
• Activez FIDO2/WebAuthn à l’IdP : pilotez avec 20 comptes clés (IT/sécurité/finance), fournissez clés physiques si nécessaire, et documentez la procédure de récupération.
• Durcissez les politiques : réduisez la durée des sessions, désactivez SMS/OTP/push pour les comptes critiques, exigez l’“authentication strength” résistante au phishing.
• Entraînez les équipes : un micro‑module sur le vishing + QR codes et une consigne claire “jamais de validation dictée au téléphone”.

Sources officielles

• Incident et IOCs : BleepingComputer — Okta SSO accounts targeted in vishing-based data theft attacks (22/01/2026) ; contexte complémentaire : BleepingComputer — Device code vishing (19/02/2026), TechRadar — campagne 35 000 utilisateurs (05/2026).
• Cadre légal : RGPD — Article 32 (EUR‑Lex) ; rappel CNPD Luxembourg : Chapitre IV — CNPD.
• Référence technique UE : ENISA — NIS2 Technical Implementation Guidance (26/06/2025) — recommande l’authentification résistante au phishing pour les accès critiques.

En synthèse : ce qui vient d’arriver (vishing + AiTM avec IOC public) est précisément ce que FIDO2/WebAuthn empêche “par conception”. Sous l’article 32 RGPD, déployer une MFA résistante au phishing sur les comptes et systèmes à fort enjeu n’est plus une option : c’est une mesure appropriée et vérifiable.

Contactez‑nous pour planifier un pilote passkeys FIDO2 et un durcissement IdP.