Ingénierie sociale du helpdesk : réinitialisation MFA Okta
Comment l'ingénierie sociale du helpdesk mène à une réinitialisation MFA Okta et à la prise de compte, la séquence dans les logs, et la distinguer du support.
TL;DR. L'attaquant appelle le service d'assistance en se faisant passer pour la victime et demande une réinitialisation du mot de passe ou de la MFA. Dans le System Log, cela donne un user.mfa.factor.reset_all, user.mfa.factor.deactivate ou user.account.reset_password dont l'acteur n'est pas la cible, suivi dans les heures qui suivent d'un user.mfa.factor.activate pour la cible, en général depuis un réseau que cet utilisateur n'a jamais utilisé. Réinitialisation plus nouveau facteur : à regarder. Réinitialisation plus nouveau facteur depuis un nouvel ASN, un hébergeur ou un proxy : c'est un incident. Si la victime est administrateur, partez du principe que la suite sera un abus de privilèges et un fournisseur d'identité malveillant.
Pourquoi ça marche si bien
Une MFA forte protège la connexion, pas le processus de récupération qui l'entoure. Quand un appelant se fait passer de façon convaincante pour un salarié qui a perdu son téléphone, un agent de bonne volonté fait ce que la procédure permet : il réinitialise les facteurs pour que le « salarié » puisse enrôler un nouvel appareil. L'attaquant enrôle alors son appareil et possède le compte, MFA comprise.
Ce n'est pas théorique. En 2023, Okta Security a rapporté que des attaquants appelaient des services d'assistance informatique pour faire réinitialiser tous les facteurs MFA d'utilisateurs très privilégiés, puis utilisaient ces comptes pour prendre le contrôle d'accès Super Administrator (Okta Security : cross-tenant impersonation). L'avis CISA/FBI sur Scattered Spider décrit le groupe se faisant passer pour des salariés et du personnel informatique lors d'appels aux services d'assistance (CISA AA23-320A). MITRE ATT&CK décrit les éléments sous T1656 Impersonation, T1098.005 Device Registration et T1556.006 Multi-Factor Authentication.
La séquence dans le System Log
| # | eventType | Acteur | Cible | À noter |
|---|---|---|---|---|
| 1 | user.session.access_admin_app | agent du helpdesk | Admin Console | la session normale de l'agent |
| 2 | user.account.reset_password | agent du helpdesk | victime | acteur ≠ cible |
| 3 | user.mfa.factor.reset_all | agent du helpdesk | victime | plus aucun facteur |
| 4 | user.session.start | victime | — | nouvelle IP, nouvel ASN, nouveau user agent |
| 5 | user.mfa.factor.activate | victime | victime + facteur | l'appareil de l'attaquant |
| 6 | user.authentication.auth_via_mfa | victime | — | passe désormais la MFA avec son propre facteur |
| 7 | user.session.access_admin_app | victime | Admin Console | si la victime est admin |
Pris isolément, les points 2 et 3 sont indiscernables d'un support légitime : les réinitialisations de facteurs sont courantes. Ce sont les points 4 et 5 qui trahissent l'attaque, et plus précisément leur provenance.
Un autre indice : le vrai utilisateur s'en aperçoit généralement plus tard, quand son mot de passe ne fonctionne plus. Quelques échecs user.session.start avec INVALID_CREDENTIALS depuis le réseau habituel de l'utilisateur, des heures après la réinitialisation, c'est la victime qui essaie de se connecter.
Comment l'analyseur la détecte
L'analyseur Okta Forensics a deux règles pour ce schéma :
| Règle | Logique | Sévérité |
|---|---|---|
mfa.factor_reset_by_admin | toute réinitialisation de mot de passe ou de facteurs où acteur ≠ cible | faible (informatif) |
mfa.helpdesk_reset_then_enroll | une telle réinitialisation, puis un user.mfa.factor.activate réussi par la cible dans les 24 heures | élevée |
| — aggravation | l'enrôlement vient d'un réseau (ASN, ou IP à défaut d'ASN) que l'utilisateur n'avait pas utilisé avant la réinitialisation, ou d'un proxy, d'un hébergeur, ou d'une IP signalée par ThreatInsight | critique |
La règle faible existe pour que la chronologie montre toujours qui a réinitialisé qui ; elle ne change pas le verdict à elle seule. C'est la règle de séquence qui le fait monter. « Jamais utilisé auparavant » est calculé à partir de l'export lui-même : un export plus long (des semaines avant la réinitialisation) rend l'aggravation plus fiable. Voir limites et réglage.
Distinguer l'attaque du travail du support
Pour chaque alerte, répondez à quatre questions :
- Y a-t-il un ticket ? Une vraie réinitialisation a un ticket, un identifiant d'appelant et un agent qui se souvient de l'appel. Demandez-lui comment l'identité a été vérifiée.
- D'où vient l'enrôlement ? Regardez
client.ipAddress,securityContext.asOrgetclient.userAgent.rawUserAgentsur leuser.mfa.factor.activate. Comparez avec les connexions de l'utilisateur des semaines précédentes. Un fournisseur de VPS, un pays depuis lequel l'utilisateur n'a jamais travaillé, ou un poste Linux pour quelqu'un qui utilise toujours un portable Windows géré : c'est décisif. - Qu'a fait le compte ensuite ? Cibles SSO, accès à l'Admin Console, actions d'administration. Un utilisateur ordinaire qui ouvre sa messagerie et son application RH, c'est rassurant. Un admin qui attribue immédiatement des rôles, non.
- L'utilisateur confirme-t-il ? Appelez-le sur un numéro issu du système RH, pas sur celui donné par l'appelant.
Si la victime est administrateur
Traitez-le comme une compromission du tenant jusqu'à preuve du contraire. Pivotez sur la victime en tant qu'acteur à partir de l'enrôlement et cherchez :
user.account.privilege.grant/group.privilege.grant, en particulier Super Administrator (Super Administrator) ;system.api_token.create;system.idp.lifecycle.createet les modifications de règles de routage ;- les changements de politiques, d'authentificateurs et de zones réseau.
La démonstration sur un incident fictif suit exactement cette chaîne : une réinitialisation par le helpdesk pour un admin informatique, un enrôlement depuis un VPS, puis un octroi Super Administrator et un nouveau fournisseur d'identité.
Confinement
- Supprimez les sessions de la victime ; révoquez les jetons.
- Retirez le facteur de l'attaquant ; réinitialisez mot de passe et facteurs ; réenrôlez le vrai utilisateur en personne ou par un canal fortement vérifié.
- Passez en revue chaque attribution d'admin, jeton et fournisseur d'identité créés après la réinitialisation.
- Enquêtez sur les applications ouvertes dans la session de l'attaquant.
Durcir le helpdesk
Les recommandations d'Okta après la campagne de 2023 incluent la restriction de ce que peut faire le personnel du support et le renforcement de la vérification d'identité avant toute réinitialisation (Okta Security). Concrètement :
- Une vérification que l'appelant ne peut pas préparer : rappel sur un numéro issu du système RH, validation par le manager, ou vérification en personne ou en visio avec pièce d'identité. Des informations personnelles trouvées sur les réseaux sociaux ne constituent pas une vérification.
- Un processus plus strict pour les administrateurs : jamais de réinitialisation par simple appel téléphonique pour un compte admin.
- Alerter sur la séquence, pas sur les réinitialisations seules : réinitialisation par un tiers plus enrôlement depuis un nouveau réseau, transmise à quelqu'un qui peut appeler l'utilisateur.
- Des authentificateurs résistants au phishing pour les admins, liés à des appareils gérés, pour qu'une réinitialisation seule ne permette pas à l'attaquant d'enrôler n'importe quoi.
Pour aller plus loin
- Okta Security : Cross-Tenant Impersonation, prévention et détection
- CISA : Scattered Spider (AA23-320A)
- Détection de la fatigue MFA, l'autre moyen de passer outre un push