97 % des victimes de ransomware avaient le MFA : où sont les angles morts ?
Activer l'authentification multifacteur ne suffit plus, à lui seul, à écarter le risque de ransomware. Deux rapports récents montrent que l'écrasante majorité des victimes avaient pourtant le MFA activé — la vraie question n'est plus « l'avez-vous activé ? » mais « où, précisément, ne l'avez-vous pas activé ? ».
Le rapport State of Ransomware 2026 de Sophos, mené auprès de 2 158 responsables IT et cybersécurité dans 17 pays ayant subi une attaque par ransomware dans l'année, livre un chiffre qui mérite d'être pris au sérieux : 79 % des attaques ont commencé par une approche basée sur l'identité, et parmi les victimes dont l'attaque provenait spécifiquement d'identifiants compromis, 97 % avaient activé le MFA sous une forme ou une autre. Le rapport complémentaire 2026 Active Adversary Report, basé sur 661 interventions de réponse à incident, précise le tableau : les causes racines sont liées à l'identité dans 67 % des cas, et le MFA manquait là où il aurait réellement été utile dans 59 % des cas — un schéma récurrent où les comptes SaaS sont protégés, mais pas les VPN, les consoles d'administration ni les applications anciennes.
Ce chiffre de 97 % ne veut pas dire que le MFA est inefficace. Il signifie que, dans la plupart des environnements, le MFA couvre une partie du périmètre d'authentification — souvent le cloud et les applications SaaS — en laissant d'autres chemins d'entrée complètement découverts.
Le MFA contourné
Le phishing AiTM (adversary-in-the-middle) — intercepte le jeton de session juste après la validation du second facteur, rendant le MFA inutile a posteriori — c'est le mécanisme de campagnes documentées comme BigBear 2.0.
La fatigue MFA — des sollicitations répétées jusqu'à ce que l'utilisateur valide par lassitude ou par erreur.
Le vol de cookies de session — par un infostealer, qui permet de rejouer une session déjà authentifiée sans jamais repasser par le second facteur.
L'ingénierie sociale contre le support informatique — pour obtenir une réinitialisation de mot de passe ou un réenrôlement du MFA sur un appareil contrôlé par l'attaquant.
Le MFA simplement absent
Le MFA appliqué au niveau d'un fournisseur d'identité cloud (Entra ID, par exemple) ne couvre pas les authentifications Kerberos ou NTLM traitées directement par les contrôleurs de domaine. Un attaquant en possession d'un mot de passe Active Directory valide peut ainsi passer par un VPN RADIUS, une passerelle RDP ou une ouverture de session Windows classique sans jamais rencontrer le MFA cloud sur son chemin — ce n'est pas un contournement technique, c'est simplement un périmètre non couvert.
Les angles morts qui reviennent le plus souvent
Les méthodes de secours faibles — le SMS reste vulnérable au SIM swapping et à l'interception ; une méthode de repli faible abaisse le niveau de sécurité de toute la chaîne, puisque l'attaquant ciblera précisément ce chemin.
Les groupes d'exclusion MFA jamais revus — des exceptions « temporaires » accordées à un service ou un compte s'accumulent, sans revue, jusqu'à constituer une véritable liste de cibles.
Les réseaux considérés « de confiance » — dispenser de MFA toute connexion depuis le réseau interne suppose que l'attaquant n'y est jamais entré — une hypothèse de plus en plus fragile.
Les comptes locaux — un compte administrateur local sans second facteur, souvent avec le même mot de passe répété sur tous les postes, sert de rebond idéal une fois un premier poste compromis.
Réduire ces angles morts concrètement
Cartographier chaque chemin d'authentification — pour chaque point d'entrée — Microsoft 365, VPN, RDP, ouverture de session Windows, consoles d'administration, prestataires, comptes locaux — identifier la source d'authentification réelle et la présence effective d'un second facteur.
Prioriser selon l'exposition — traiter en premier les services accessibles depuis Internet qui n'exigent encore qu'un mot de passe.
Gouverner les exclusions MFA — un propriétaire par groupe d'exclusion, une justification par membre, une revue régulière plutôt qu'un empilement silencieux.
Privilégier des méthodes résistantes au phishing — les passkeys plutôt que le SMS, en limitant les méthodes de secours disponibles.
Encadrer les comptes locaux — Windows LAPS pour éviter un mot de passe local identique sur tout le parc, et limiter les ouvertures de session locale au strict nécessaire.
Sécuriser le processus de support — vérifier réellement l'identité avant toute réinitialisation de mot de passe ou tout réenrôlement MFA.
Tenir cette cartographie à jour n'est pas qu'une bonne pratique : elle recoupe directement des exigences réglementaires comme NIS 2 et le référentiel ReCyF de l'ANSSI (MFA pour les accès distants, revue annuelle des comptes et des droits). Une supervision continue de l'infogérance (voir notre offre de supervision et RMM) et un plan de sauvegarde testé (voir notre offre de sauvegarde et continuité d'activité) ne remplacent pas cette cartographie, mais en sont le complément naturel si un chemin non couvert finit malgré tout par être exploité. Vous voulez savoir où se trouvent vos propres angles morts d'authentification ? Parlons-en.
Une question ?
Envie d'un avis technique sincère sur votre sécurité ?
Nos experts analysent vos pratiques réelles — pas seulement vos documents — et vous disent honnêtement où vous en êtes.
[email protected]Net System srl · Rue de Botrange 61, 4950 Waimes +32 80 87 00 17
