MFA fatigue et vol de session : les attaques qui contournent la double authentification

Vous avez activé la double authentification et annoncé au comité de direction que le sujet était réglé. Il ne l'est pas. Les attaquants ont cessé de s'acharner sur votre écran de connexion : ils le contournent. Le mot de passe compte encore, mais les deux techniques qui dominent en ce moment, le MFA fatigue et le détournement de session, traitent votre second facteur comme un ralentisseur, pas comme un mur.

Pourquoi la 2FA ne suffit plus

Le phishing classique vole un mot de passe. La MFA était la réponse : même avec le mot de passe, l'attaquant n'a pas le second facteur. Ce raisonnement a tenu jusqu'à ce que les attaquants changent de cible.

Deux bascules ont cassé le modèle :

• L'humain s'est fatigué. La MFA par notification push demande à une personne d'approuver. Or les gens approuvent des choses toute la journée. Les attaquants ont appris à retourner ce réflexe contre eux.
• La session est devenue le butin. Une fois authentifié, le serveur remet à votre navigateur un jeton de session. C'est ce jeton, pas votre mot de passe, qui prouve votre identité à chaque requête après la connexion. Volez le jeton et vous sautez le mot de passe, l'invite MFA, tout.

Les deux attaques partagent la même cause racine : l'authentification est un événement, mais l'accès est un état. Nous investissons massivement dans l'événement et presque rien dans l'état qui persiste ensuite pendant des heures, voire des jours. Pour la version longue de cet argument, lisez notre analyse de l'architecture zero trust. La version courte : ne faites jamais confiance à une session au seul motif qu'une connexion a réussi un jour.

Le MFA fatigue, aussi appelé push bombing

La mécanique est bête et redoutablement efficace. L'attaquant possède déjà le mot de passe (fuite de données, kit de phishing ou infostealer). Il se connecte. Votre téléphone s'allume avec une demande d'approbation. Il se reconnecte. Encore. Dix notifications. Cinquante notifications. À 2 heures du matin.

Tôt ou tard, l'un de ces trois scénarios se produit :

1. L'utilisateur appuie sur Approuver pour faire cesser le bruit.
2. L'utilisateur suppose que la DSI fait de la maintenance et approuve.
3. L'attaquant appelle en se faisant passer pour le support informatique et guide l'utilisateur pas à pas.

C'est toute l'attaque. Pas de zero-day, pas de malware. Elle fonctionne parce qu'une notification « Approuver / Refuser » sans contexte ne coûte rien à accepter.

Les correctifs qui changent réellement les probabilités

• Le number matching. L'écran de connexion affiche un nombre à deux chiffres que l'utilisateur doit saisir dans l'application. Un attaquant qui ne voit pas l'écran de connexion ne peut pas fournir le nombre. À lui seul, ce mécanisme élimine l'approbation à l'aveugle.
• Du contexte dans la notification. Affichez la localisation, l'application et l'adresse IP. « Connexion depuis Jakarta vers votre application de paie » est bien plus difficile à approuver machinalement qu'un bouton Approuver muet.
• Limitation de débit et blocage sur notifications répétées. Trois demandes refusées ou ignorées dans un court laps de temps devraient geler les nouvelles notifications et alerter votre SOC. Le push bombing est bruyant par nature. Détectez le volume.
• Abandonnez complètement le push pour les comptes sensibles. Le number matching est un pansement. Les facteurs résistants au phishing sont un remède (voir plus bas).

Le number matching est désormais activé par défaut dans la plupart des plateformes d'identité. Activez-le. Si votre fournisseur autorise encore un simple Approuver / Refuser pour les comptes à privilèges, c'est un constat d'audit, pas une préférence.

Le détournement de session : voler le jeton, sauter la connexion

C'est la famille d'attaques la plus dangereuse, parce qu'elle bat aussi une MFA bien configurée. Même une connexion parfaite avec number matching se termine par l'émission d'un jeton de session. Si l'attaquant obtient ce jeton, votre MFA n'a jamais voix au chapitre.

Il existe trois chemins courants vers le jeton.

1. Le phishing adversary-in-the-middle (AiTM)

C'est la technique derrière la majorité des contournements MFA modernes. L'attaquant fait tourner un proxy inverse (Evilginx et les kits du même genre ont rendu la chose accessible en quelques clics) entre la victime et le site légitime.

Le déroulé :

1. La victime clique sur un lien de phishing et atterrit sur le proxy de l'attaquant, visuellement parfait puisqu'il relaie littéralement le vrai site.
2. La victime saisit son mot de passe. Le proxy le transmet au site légitime.
3. Le site légitime déclenche l'invite MFA. La victime la valide. Number matching, TOTP, SMS : tout est satisfait, puisqu'un vrai humain se connecte réellement.
4. Le site légitime émet un cookie de session valide. Le proxy le capture au passage.
5. L'attaquant importe le cookie dans son propre navigateur et se retrouve à l'intérieur, pleinement authentifié, MFA déjà validée.

La victime a tout fait correctement et a quand même perdu. Voilà pourquoi « nous avons la MFA » ne répond pas à la question « sommes-nous résistants au phishing ».

2. Les infostealers et le vol de cookies

Pas besoin de proxy si l'on peut lire le disque de la victime. Les infostealers (RedLine, Lumma et tout le reste du marché) aspirent les magasins de cookies des navigateurs, les jetons enregistrés et les fichiers de session locaux, puis les revendent. L'acheteur charge votre session active et entre. Ni mot de passe ni MFA, puisque le jeton est déjà émis.

C'est pourquoi une compromission de poste de travail est une compromission d'identité. Ce ne sont pas deux incidents distincts. Et en Europe, si cette session accède à des données personnelles, vous êtes face à une violation de données au sens du RGPD, avec 72 heures pour notifier votre autorité de contrôle (la CNIL en France, l'INPDP en Tunisie).

3. Le vol de jetons dans les flux OAuth et API

Les jetons de rafraîchissement à longue durée de vie et les applications OAuth mal configurées sont une mine d'or discrète. Un refresh token volé peut émettre de nouveaux jetons d'accès pendant des semaines. Des jetons aux périmètres trop larges transforment une fuite en accès à tout le tenant. Si votre plateforme délivre des jetons à des intégrations tierces, chacune est un identifiant que vous ne renouvelez peut-être jamais. Nous détaillons le scoping et la rotation dans les bonnes pratiques de sécurité des API.

La défense qui tient vraiment : la MFA résistante au phishing

Voici la vérité qui dérange. Le number matching aide contre la fatigue. Il ne fait rien contre l'AiTM, puisque l'humain remet toujours un vrai identifiant à un vrai site à travers un proxy. Pour battre l'AiTM, il faut un facteur lié à l'origine, impossible à relayer.

Ce facteur, c'est FIDO2 / WebAuthn, déployé sous forme de passkeys ou de clés de sécurité physiques.

Pourquoi cela résiste à l'AiTM : l'authentificateur signe un défi qui inclut l'origine (le vrai domaine). Un proxy sur un domaine sosie produit la mauvaise origine, donc la signature ne se valide pas. Il n'y a aucun code à hameçonner, aucun cookie que l'humain puisse être piégé à transmettre. La cryptographie refuse tout simplement de fonctionner hors du domaine légitime.

Si vous ne lisez qu'un seul article complémentaire, que ce soit passkeys et authentification sans mot de passe. Pour les administrateurs, la finance et toute personne ayant accès à la production, la MFA résistante au phishing devrait être obligatoire, pas optionnelle.

Ordre de priorité pour la robustesse MFA :
  1. FIDO2 / passkeys / clés physiques     (résiste au phishing, bat l'AiTM)
  2. Push avec number matching + contexte  (bat la fatigue, pas l'AiTM)
  3. Applications TOTP                     (hameçonnable via proxy)
  4. OTP par SMS / vocal                   (hameçonnable + risque de SIM swap)

Ne déployez pas uniquement le premier niveau. Déployez-le d'abord pour les comptes dont la compromission plomberait votre trimestre.

Protéger la session elle-même

La MFA résistante au phishing protège la connexion. Il reste à protéger le jeton après son émission, car un malware ou une mauvaise configuration peuvent le saisir directement.

Lier le jeton à l'appareil

Le contrôle le plus fort est le token binding : lier cryptographiquement la session à l'appareil qui s'est authentifié, de sorte qu'un cookie volé soit inutilisable sur une autre machine. Deux mécanismes à connaître :

• DPoP (Demonstrating Proof of Possession) pour OAuth. Le client prouve à chaque requête qu'il détient une clé privée. Un jeton copié sans la clé est mort à l'arrivée.

POST /api/orders HTTP/1.1
Authorization: DPoP eyJ...access_token...
DPoP: eyJ...signed_proof_bound_to_request_and_key...

• Les sessions liées à l'appareil côté navigateur. Des standards émergents (souvent commercialisés sous le nom de device bound session credentials) rafraîchissent les cookies à l'aide d'une clé détenue par l'appareil : un cookie exfiltré expire vite et ne peut pas être réutilisé ailleurs.

Durcir les cookies, méthodiquement et sans gloire

La plupart des vols de session exploitent une gestion négligée des cookies. Les valeurs par défaut comptent :

Set-Cookie: session=...;
  HttpOnly;          // illisible en JavaScript, neutralise le vol via XSS
  Secure;            // jamais envoyé en HTTP non chiffré
  SameSite=Lax;      // limite l'envoi cross-site, réduit le CSRF
  Path=/;
  Max-Age=3600       // durée de vie courte, rayon d'impact réduit

HttpOnly à lui seul bloque toute une classe d'exfiltrations de cookies via cross-site scripting. Si votre cookie de session est lisible depuis JavaScript, corrigez cela avant tout le reste de cette page.

Réduire ce qu'un jeton volé peut faire

• Des jetons d'accès à durée de vie courte. Des minutes, pas des heures. Forcez une revalidation fréquente.
• Rotation des refresh tokens avec détection de réutilisation. Chaque rafraîchissement émet un nouveau jeton et invalide l'ancien. Si un ancien jeton réapparaît, c'est un vol : tuez toute la famille de sessions.
• Un périmètre de jeton borné. Moindre privilège par jeton. Un jeton en lecture seule qui fuit est un incident. Un jeton tout-puissant qui fuit est une violation de données.

Détecter le détournement que vous n'avez pas pu empêcher

Partez du principe qu'un jeton finira par sortir. Votre travail est de rendre sa vie courte et bruyante.

• Continuous Access Evaluation (CAE). Au lieu de faire confiance à un jeton jusqu'à son expiration, réévaluez les conditions quasiment en temps réel. Mot de passe réinitialisé, compte désactivé, localisation à risque : révoquez en pleine session, pas à l'heure suivante.
• Voyage impossible et anomalies d'appareil. Une session à Sousse à 14 h 00 et à Manille à 14 h 10, ce n'est pas un trajet domicile-travail. Signalez, exigez une réauthentification renforcée, ou tuez la session.
• Dérive de user agent et d'IP au sein d'une session. Un jeton qui passe de l'empreinte d'un portable d'entreprise à une VM cloud quelconque est volé. Alertez sur le basculement.
• Journalisez le cycle de vie de la session, pas seulement les connexions. Émission, rafraîchissement et révocation des jetons appartiennent à votre télémétrie. On n'enquête pas sur ce qu'on n'a jamais enregistré. Complétez avec la vision d'ensemble de l'observabilité : logs, métriques et traces.

Quand une alerte se déclenche, il vous faut une réponse répétée à l'avance : révoquer les sessions, faire tourner les jetons, forcer un réenrôlement résistant au phishing. Écrivez-la avant d'en avoir besoin, d'autant que le compte à rebours RGPD de 72 heures ne vous attendra pas. Notre playbook de réponse aux incidents couvre les étapes de révocation de jetons que la plupart des équipes découvrent à 3 heures du matin.

Un cadre de décision applicable dès ce trimestre

Vous ne pouvez pas tout faire d'un coup. Priorisez selon le rayon d'impact, et selon vos obligations si NIS2 ou DORA s'appliquent à vous.

1. Inventoriez les accès à privilèges. Administrateurs, finance, production, et toute personne capable de déplacer de l'argent ou des données. C'est votre niveau un.
2. Imposez la MFA résistante au phishing au niveau un. Passkeys ou clés physiques. Aucune exception, aucun repli TOTP pour ces comptes.
3. Activez le number matching et le contexte de connexion partout ailleurs. C'est votre pansement anti-fatigue pour la population large.
4. Élevez l'hygiène des cookies et des jetons au rang de politique. HttpOnly, Secure, SameSite, durées de vie courtes, rotation des refresh tokens avec détection de réutilisation. Vérifiez en revue de code, pas dans un wiki.
5. Activez la CAE et la détection d'anomalies de session. Cessez de faire confiance aux jetons pour toute leur durée de vie.
6. Répétez la révocation. Organisez un exercice sur table où un jeton est volé. Chronométrez le temps nécessaire pour tuer toutes les sessions. Si vous ne connaissez pas ce chiffre, c'est lui, le constat d'audit.

Le schéma : empêchez ce que vous pouvez avec la cryptographie, contenez le reste avec des sessions courtes, liées à l'appareil et révocables.

Check-list d'auto-audit express

• Les comptes à privilèges utilisent FIDO2 / passkeys, pas le push ni le TOTP.
• Le number matching et le contexte de connexion sont actifs pour tous les utilisateurs.
• Les cookies de session sont HttpOnly, Secure et SameSite.
• Les jetons d'accès expirent en minutes ; les refresh tokens tournent.
• La réutilisation d'un refresh token déclenche la révocation complète de la session.
• Le token binding (DPoP ou sessions liées à l'appareil) est en place pour les API sensibles.
• La CAE ou un équivalent révoque les sessions en cours sur événement de risque.
• L'émission, le rafraîchissement et la révocation des sessions sont journalisés et alertables.
• Vous avez chronométré un exercice réel de révocation de session dans les 90 derniers jours.

Si vous voulez savoir comment ces contrôles tiennent face à un opérateur réel, c'est précisément ce qu'un engagement sérieux met à l'épreuve. Voyez les fondamentaux du test d'intrusion pour comprendre comment un scénario AiTM et vol de jetons est exercé de bout en bout.

Comment Innovation T peut vous aider

Nous construisons et durcissons la couche d'authentification que les équipes livrent réellement : déploiements de passkeys, MFA résistante au phishing pour les accès à privilèges, token binding, rotation des refresh tokens et détection d'anomalies de session branchée sur votre journalisation. Pas des slides. Des contrôles opérationnels, testés contre les attaques exactes décrites ci-dessus.

Si votre 2FA n'est qu'à un proxy convaincant d'une prise de contrôle complète de session, laissez-nous la mettre sous pression et combler l'écart. Consultez nos services ou contactez l'équipe : nous tracerons votre chemin le plus court de « nous avons la MFA » à « nous sommes résistants au phishing ».