(1) Reconnaissance (J-7) : LinkedIn et OSINT pour cibler Marie. (2) Accès initial (T+0) : device code phishing M365, session valide volée sans mot de passe. (3) Cartographie (T+15 min) : lecture Outlook et OneDrive, identification d'un compte de service. (4) Escalade (T+1h) : Kerberoasting du compte de service, hash craqué offline. (5) Mouvement latéral (T+2h) : Pass-the-Hash + abus ADCS ESC1, obtention Domain Admin. (6) Persistance (T+3h) : porte dérobée, exfiltration des données critiques. (7) Coup de grâce (T+4h) : déploiement ransomware sur tout le parc.
Phase 1, Reconnaissance (J-7 à J-1)
Une semaine avant l'attaque, le futur attaquant n'a même pas encore touché l'infrastructure. Il fait son travail sur LinkedIn et les sites publics : organigramme officiel, équipe IT (le DSI a un profil LinkedIn riche, il est tech, il aura activé la MFA), service compta (Marie, 6 ans d'ancienneté, profil moins exposé, gère les paiements fournisseurs), photos d'événements (qui se tutoie avec qui, qui est en vacances en ce moment).
L'attaquant choisit Marie comme cible, pas le DSI. Logique d'attaquant : on attaque le maillon faible, pas le maillon fort. Marie est dans le service qui valide les virements, elle a accès aux outils de paiement, elle reçoit en permanence des emails de fournisseurs, donc habituée à ouvrir des pièces jointes et à cliquer sur des liens de factures. Profil parfait.
Ce qui aurait aidé à cette étape : une réduction de la surface OSINT publique (notamment pour les fonctions sensibles), une politique de communication LinkedIn cadrée pour l'équipe, et, surtout, une formation phishing spécifique pour les services exposés (compta, RH, achat), pas un module générique annuel.
Phase 2, Accès initial (T+0, 9h47)
L'attaquant envoie à Marie un email qui ressemble à une notification Microsoft 365 légitime : « Action requise, autoriser ce nouvel appareil ». Ce n'est pas du phishing classique avec un faux site de login. C'est du device code phishing : Marie est invitée à entrer un code à 8 caractères sur la vraie page Microsoft (microsoft.com/devicelogin). Quand elle le fait, c'est l'appareil de l'attaquant qui se retrouve autorisé sur son compte. Pas de mot de passe volé. Pas de MFA contournée. Marie a autorisé elle-même l'attaquant, sans s'en rendre compte.
L'attaquant reçoit instantanément un token OAuth valide sur le compte de Marie. À partir de ce moment, pour Microsoft 365, c'est Marie qui se connecte. Le journal d'authentification ne montre rien d'anormal au premier coup d'œil. Pour le détail technique de cette attaque, voir notre analyse complète du device code phishing.
Ce qui aurait stoppé l'attaque ici : une policy Conditional Access qui bloque le device code flow pour tous les utilisateurs qui n'en ont pas un besoin métier identifié. Dans 80 % des PME, ce flow n'a aucune utilité opérationnelle, il est juste activé par défaut. Le désactiver via Conditional Access prend 15 minutes, coûte zéro, et casse cette chaîne d'attaque dès la première étape.
Phase 3, Cartographie interne (T+15 min)
Depuis la session de Marie, l'attaquant ne lance pas tout de suite des outils bruyants. Il lit Outlook, OneDrive et Teams. Il y trouve : l'organigramme à jour, les contrats client, des notes internes mentionnant « SQL-SVC » comme nom de compte de service utilisé par le logiciel comptable, un partage OneDrive avec un fichier passwords_temp.txt oublié par un prestataire en 2024 contenant trois mots de passe « anciens » mais réutilisés ailleurs.
Cette phase de reconnaissance interne dure 30 à 45 minutes. À la fin, l'attaquant a une cartographie complète : il sait quoi cibler, dans quel ordre, et il a déjà des pistes de comptes secondaires.
Ce qui aurait aidé : détection comportementale via un EDR/SIEM (téléchargement massif de fichiers OneDrive en peu de temps depuis une nouvelle IP = anomalie), policies de gouvernance OneDrive (pas de fichier passwords.txt qui traîne), et un audit régulier des partages M365 pour purger les anciens.
Phase 4, Escalade de privilèges (T+1h)
Marie est une utilisatrice standard. Elle ne peut rien faire de critique sur le réseau interne. L'attaquant doit donc monter en privilèges. Depuis sa session, il observe qu'il peut joindre l'Active Directory interne via le VPN configuré sur le poste de Marie. Premier réflexe : tenter un Kerberoasting.
Le Kerberoasting exploite une caractéristique du protocole Kerberos : n'importe quel utilisateur authentifié peut demander un ticket de service (TGS) pour n'importe quel compte de service. Le ticket retourné est chiffré avec le mot de passe du compte de service. Si ce mot de passe est faible, l'attaquant peut le craquer offline avec hashcat ou john, sans alerter le système. Marie a accès à la requête, le KDC répond, le ticket arrive. Le compte cible : svc-sql_user, repéré en phase 3.
Mot de passe : Password2026!. Craqué en 11 minutes avec un dictionnaire enrichi de variations courantes. Au bout d'1h après le clic de Marie, l'attaquant a maintenant les droits du compte de service SQL, administrateur de la base de paie.
Ce qui aurait stoppé l'attaque : des mots de passe forts (25+ caractères, générés aléatoirement) sur tous les comptes de service AD. Au-delà de 20-25 caractères vraiment aléatoires, le Kerberoasting devient économiquement non viable (des années de calcul). Audit AD préventif tous les 6 mois pour identifier les comptes Kerberoastables. Mise en place de gMSA (Group Managed Service Accounts) qui font tourner les mots de passe automatiquement.
Phase 5, Mouvement latéral et Domain Admin (T+2h)
Avec les droits du compte SQL, l'attaquant accède au serveur de paie. Sur ce serveur, il extrait le hash NTLM d'un compte administrateur local mémorisé en cache. Avec cette empreinte, il peut s'authentifier sur d'autres serveurs sans connaître le mot de passe en clair, c'est l'attaque Pass-the-Hash, vieille de 20 ans mais toujours efficace quand les machines partagent des credentials.
De serveur en serveur, il finit par toucher un poste qui a accès à l'autorité de certification interne (CA-PKI). Et là, il scanne les templates ADCS disponibles. Un template est mal configuré (ADCS ESC1) : il permet à n'importe quel utilisateur authentifié de demander un certificat au nom de n'importe qui d'autre, y compris d'un Domain Admin. L'attaquant demande un certificat « au nom de » l'administrateur du domaine, le récupère, l'utilise pour s'authentifier sur le Domain Controller, et obtient les droits Domain Admin. Temps écoulé : 2 heures depuis le clic de Marie.
Ce qui aurait stoppé l'attaque : désactiver l'authentification NTLM pour casser Pass-the-Hash, auditer les templates ADCS avec Certify ou Certipy pour identifier les ESC1 à ESC8 et les corriger, segmentation réseau forte (un poste utilisateur ne devrait pas pouvoir parler à l'AD CA directement), et un EDR sérieux qui détecte les outils de dumping de credentials (Mimikatz, secretsdump, etc.). Voir notre article dédié sur le durcissement Active Directory.
Phase 6, Persistance et exfiltration (T+3h)
Avec les droits Domain Admin, l'attaquant peut faire ce qu'il veut. Première action : installer une persistance. Création d'un compte administrateur secondaire avec un nom anodin (« svc-monitoring »), planification d'une tâche de connexion régulière vers un serveur de commande externe, modification de la configuration de Defender pour exclure le dossier où il va déposer ses outils.
Deuxième action : exfiltrer les données critiques. Pas pour le ransomware (ça vient juste après), mais pour la double extorsion : « payez la rançon pour déchiffrer ET pour qu'on ne publie pas vos données ». L'attaquant identifie le contenu sensible (fichiers RH, dossiers clients, contrats, bases comptables), le copie sur un serveur cloud externe via une connexion HTTPS standard pour ne pas alerter le proxy. Volume exfiltré : 47 Go en 50 minutes.
Ce qui aurait aidé : détection DLP sur les volumes anormaux sortants, segmentation des données les plus sensibles avec accès journalisé, alertes IDS sur les connexions HTTPS atypiques. Et surtout : sauvegardes immutables et offline que l'attaquant ne peut pas atteindre depuis le SI compromis.
Phase 7, Coup de grâce (T+4h, 13h45)
La phase finale est la plus rapide. L'attaquant utilise les droits Domain Admin pour déployer le ransomware via une stratégie de groupe (GPO) : un script lancé au prochain démarrage ou à l'heure programmée. À 13h45, sur tous les postes et serveurs simultanément, les fichiers sont chiffrés, les sauvegardes locales effacées, les Shadow Copies supprimées. Un message s'affiche : 15 Bitcoin pour récupérer les données, 72 heures avant publication.
Marie n'a même pas eu le temps de finir son déjeuner. L'entreprise est paralysée. Première constatation du dirigeant à 14h : « personne ne peut plus travailler ». Première constatation du RSSI à 14h30 : « les sauvegardes locales sont mortes aussi ». Première constatation de l'avocat à 16h : « il va falloir notifier la CNIL dans les 72h ».
Tableau récap : MITRE ATT&CK, détection, mitigation
| Phase | Technique MITRE ATT&CK | Détection possible | Mitigation prioritaire |
|---|---|---|---|
| 1, Reconnaissance | T1589 (Gather Victim Identity Info) | Difficile (passif) | Hygiène OSINT, formation phishing ciblée |
| 2, Accès initial | T1566.001 (Phishing) + T1078.004 (Cloud Accounts) | Logs M365 anomalie geo, device code requests | Conditional Access bloque device code flow + MFA FIDO2 |
| 3, Cartographie | T1213 (Data from Information Repositories) | EDR comportemental, volume download anormal | DLP M365, gouvernance partages OneDrive |
| 4, Escalade | T1558.003 (Kerberoasting) | Demandes TGS massives, alertes Defender for Identity | Mots de passe forts comptes service + gMSA |
| 5, Mouvement latéral | T1550.002 (Pass-the-Hash) + T1649 (ADCS abuse) | EDR, audit AD CA, logs 4769/4624 | Désactiver NTLM, audit Certify/Certipy, segmentation |
| 6, Persistance + exfil | T1098 (Account Manipulation) + T1041 (Exfil over C2) | Création compte admin inattendu, gros volumes HTTPS | Alertes création admin AD, DLP, proxy strict |
| 7, Impact | T1486 (Data Encrypted for Impact) | EDR ransomware, désactivation Shadow Copy | Sauvegardes immutables offline + EDR |
Quelques variantes de point d'entrée à connaître
Le scénario décrit utilise le device code phishing M365, mais l'entrée initiale n'est qu'une variable. Les autres portes d'entrée régulièrement observées en 2026 :
- RDP exposé sur Internet sans MFA : encore très fréquent sur les serveurs de PME (notamment terminal serveur), exploité par brute force ou credential stuffing en quelques heures.
- VPN sans MFA : un mot de passe d'utilisateur acheté sur le dark web (entre 3 et 25 $ par compte selon la taille de l'entreprise) suffit à entrer.
- Faille connue non patchée : Microsoft Exchange, Confluence, Jenkins, ConnectWise, Citrix, les CVE critiques sortent toutes les semaines, et beaucoup de PME ont 30 à 90 jours de retard sur les patchs.
- Wi-Fi guest mal segmenté : depuis le parking, accès au réseau interne sans passer par la moindre auth.
- Supply chain via un prestataire : compromission du prestataire IT externalisé qui a un accès admin permanent au SI client.
- USB drop / social engineering physique : clé USB déposée sur le parking, technicien faux EDF qui demande l'accès au local technique, ingénierie sociale par téléphone vers la secrétaire.
La règle constante : la chaîne d'attaque après l'entrée initiale (phases 3 à 7) est la même quel que soit le point d'entrée. C'est pour ça qu'investir dans la défense interne (durcissement AD, ADCS, segmentation, EDR) protège contre tous les scénarios, alors que se focaliser uniquement sur le périmètre ne protège que contre un seul.
Ce que ça coûte de se faire couper la chaîne avant T+4h
Pour une PME de 50 à 200 personnes, casser cette chaîne au plus tôt (idéalement en phase 2 ou 3) coûte beaucoup moins cher qu'on ne le croit. Ordre de grandeur :
- Phase 2, Bloquer le device code flow + déployer MFA FIDO2 : 0 € de licence (déjà incluse Microsoft 365 Business Premium), 1 à 2 jours de prestation = 1 200 à 2 400 € HT.
- Phase 4, Audit Kerberoast + mise en gMSA des comptes services : 1 à 2 jours = 1 200 à 2 400 € HT.
- Phase 5, Audit ADCS + désactivation NTLM : 2 à 3 jours = 2 400 à 3 600 € HT.
- Sauvegardes immutables offline : 200 à 800 € HT/mois selon volumétrie.
- EDR sur tout le parc : 4 à 8 € HT/poste/mois.
À comparer aux 80 000 à 350 000 € de coût moyen d'une attaque ransomware réussie sur une PME française en 2024 (chiffres ANSSI), sans compter la perte de chiffre d'affaires pendant l'arrêt (5 à 21 jours en moyenne) et la sanction CNIL potentielle.
Audit ciblé Conditional Access M365 + durcissement AD (Kerberoasting, ADCS) + EDR check + recommandations priorisées. À partir de 4 500 € HT.
