Quand l’écran de rançon apparaît, l’attaquant est déjà chez vous depuis des heures, parfois depuis plus d’une semaine. Le chiffrement est la dernière étape d’une intrusion que l’on peut observer, ralentir et souvent arrêter avant. Voici ce que montrent deux intrusions documentées, ce que font les attaquants phase par phase, les traces qu’ils laissent, et ce qui coûte le moins cher à mettre en place.
Ce qu’il faut retenir
- Le délai entre l’accès et le chiffrement varie de 2 heures à 9 jours dans les deux intrusions détaillées par The DFIR Report en 2025. Il n’existe pas de « fenêtre de 72 heures » garantie : il faut détecter tôt, pas compter sur le temps.
- L’annuaire est visé en quelques heures. Selon Sophos (661 cas, novembre 2024 à octobre 2025), le délai médian entre l’accès et la première tentative contre Active Directory est de 3,4 heures.
- 88,1 % des rançongiciels sont déployés hors des heures ouvrées (même étude) : ce qui compte, c’est qui reçoit l’alerte à 2 h du matin un dimanche.
- Les mêmes gestes reviennent : identifiants valides, nouveaux comptes administrateurs, outils d’accès distant légitimes, archivage et envoi de données, puis suppression des sauvegardes. Chacun laisse une trace.
- Les failles utilisées sont connues. Les huit CVE citées dans l’avis conjoint CISA sur Akira figurent toutes au catalogue KEV, avec la mention d’utilisation par des rançongiciels.
Le chiffrement n’est pas le début de l’attaque
Le rapport Active Adversary Report 2026 de Sophos analyse 661 dossiers de réponse à incident et de détection managée traités entre le 1er novembre 2024 et le 31 octobre 2025. Il relève une durée de présence (dwell time) médiane de trois jours, et une vitesse d’attaque contre l’annuaire en forte hausse : la médiane du délai entre l’accès au système et la tentative d’accès à Active Directory est de 3,40 heures, soit 70 % de moins que l’année précédente. Le délai entre cette tentative et la détection de l’attaque, lui, a augmenté de 16 %.
Deux précisions pour ne pas sur-interpréter : la durée de présence médiane de trois jours concerne l’ensemble des dossiers de l’étude (les dossiers de réponse à incident toutes causes ont une médiane de 5 jours, ceux qui ne sont pas des rançongiciels de 6 jours), et il s’agit de médianes, donc de la moitié des cas de part et d’autre. Ce sont des ordres de grandeur, pas des délais garantis.
Deux intrusions réelles, deux vitesses
2 heures : une faille Confluence, puis LockBit
Dans l’intrusion décrite par The DFIR Report en février 2025, l’attaquant exploite la faille CVE-2023-22527 (exécution de code à distance sans authentification, score CVSS de 10) sur un serveur Confluence exposé. Le délai total jusqu’au chiffrement est de 2 h 06 min 14 s.
- Une dizaine de minutes après l’accès : téléchargement et exécution d’un stager Metasploit avec l’utilitaire Windows
mshta.exe. - Vingt minutes après l’accès : Mimikatz est exécuté sur la machine d’entrée.
- 1 h 11 après l’accès : exfiltration depuis un serveur de fichiers avec Rclone vers le service Mega.
- Environ 2 h : PDQ Deploy et l’exécutable LockBit sont copiés sur la machine d’entrée puis sur le contrôleur de domaine. LockBit est d’abord lancé à la main en RDP sur le serveur de sauvegarde et le serveur de fichiers, puis déployé plus largement avec PDQ Deploy.
Un outil légitime de déploiement de logiciels sert ici à distribuer le rançongiciel : le rapport précise qu’il a été utilisé pour faciliter le déploiement de LockBit.
178 heures : une connexion RDP avec des identifiants valides, puis Lynx
Dans l’intrusion décrite en décembre 2025, tout commence début mars 2025 par une connexion RDP réussie sur un système exposé sur Internet. Aucune tentative échouée n’est observée depuis la même adresse : l’attaquant possédait déjà des identifiants valides, sans doute achetés ou issus d’un logiciel voleur d’identifiants, selon l’analyse du rapport.
- Dix minutes après la connexion : l’attaquant identifie un contrôleur de domaine et s’y connecte avec un autre compte, administrateur de domaine, lui aussi vraisemblablement volé auparavant.
- Sur le contrôleur de domaine : création de deux comptes, dont un dont le nom imite un compte existant à un caractère près, immédiatement ajoutés à des groupes privilégiés, dont Domain Admins ; installation d’AnyDesk.
- Puis une pause de six jours. L’attaquant revient, lance un balayage réseau, utilise NetExec pour une pulvérisation de mots de passe, archive des partages de fichiers et les envoie vers un service de partage temporaire (temp.sh).
- Environ neuf heures plus tard, il revient d’une autre adresse pour explorer d’autres contrôleurs de domaine et des hyperviseurs.
- Le neuvième jour : connexion à un serveur de sauvegarde, suppression des tâches de sauvegarde, puis déploiement de Lynx sur ce serveur, puis sur d’autres serveurs de sauvegarde et de fichiers.
Le rapport donne un temps total « juste sous 178 heures ». La leçon n’est pas la lenteur : entre la création de comptes administrateurs le premier jour et le chiffrement, neuf jours se sont écoulés pendant lesquels une alerte sur ces comptes aurait pu tout arrêter.
Phase par phase : ce qu’ils font, où c’est visible, ce qui les arrête
Le tableau ci-dessous rassemble ce que rapportent ces deux études et l’avis conjoint #StopRansomware : Akira (FBI, CISA et partenaires, mis à jour le 13 novembre 2025). Les colonnes « visible » et « arrête » reprennent les recommandations du guide #StopRansomware de la CISA et notre lecture des observations.
| Phase | Observé | Où c’est visible | Ce qui l’arrête |
|---|---|---|---|
| Accès initial | VPN sans MFA (Akira), identifiants volés ou achetés, RDP exposé (Lynx), faille sur un serveur exposé (Confluence, SonicWall, Cisco) | Connexions VPN ou RDP anormales : pays, heure, compte | MFA résistant à l’hameçonnage ; correctifs des failles du catalogue KEV ; pas de RDP exposé |
| Découverte | SoftPerfect Network Scanner, Advanced IP Scanner, net user, whoami, tasklist | Balayages internes depuis un poste ou un serveur qui n’en fait jamais | Segmentation ; alerte sur le balayage interne |
| Identifiants | Mimikatz (20 min dans le cas LockBit), LaZagne, Kerberoasting, copie de NTDS.dit | Accès à la mémoire du processus LSASS, utilisation de ntdsutil | Comptes d’administration séparés ; gestion des accès privilégiés sur les contrôleurs de domaine |
| Comptes et persistance | Nouveaux comptes (itadm, « administratr »), ajout à Domain Admins | Événements 4720, 4728, 4732 (voir plus bas) | Alerte immédiate sur toute création de compte privilégié |
| Accès distant | AnyDesk, LogMeIn, RustDesk, MobaXterm, Cloudflare Tunnel | Outils d’accès distant non inventoriés, y compris exécutables portables | Liste blanche d’applications ; inventaire des outils autorisés |
| Vol de données | 7-Zip, WinRAR, FileZilla, puis Rclone, WinSCP, temp.sh, Mega | Volume sortant anormal, quel que soit le port | Filtrage sortant ; alerte sur les services de partage inconnus |
| Sabotage de la reprise | Suppression des tâches de sauvegarde (Lynx), copies shadow effacées par PowerShell (Akira), failles Veeam CVE-2023-27532 et CVE-2024-40711 | Commandes vssadmin, wmic shadowcopy, wbadmin, bcdedit | Copie immuable et hors domaine (voir notre article sur les sauvegardes) |
| Déploiement | PDQ Deploy (LockBit) ; RDP vers les serveurs de fichiers et de sauvegarde (Lynx) | Copie du même exécutable sur de nombreux serveurs en peu de temps | Restriction des comptes autorisés à déployer ; segmentation |
Les failles utilisées sont déjà dans le catalogue KEV
L’avis Akira cite huit CVE utilisées pour l’accès initial ou l’élévation de privilèges : CVE-2020-3259, CVE-2020-3580 et CVE-2023-20269 (Cisco ASA et FTD), CVE-2023-28252 (Windows), CVE-2024-37085 (VMware ESXi), CVE-2023-27532 et CVE-2024-40711 (Veeam Backup & Replication) et CVE-2024-40766 (SonicWall SonicOS). Nous les avons recoupées avec le catalogue KEV de la CISA (version du 27 septembre 2026) : les huit y figurent, marquées comme utilisées par des campagnes de rançongiciels. C’est aussi le cas de la CVE-2023-22527 (Confluence) de l’intrusion en deux heures.
C’est l’argument le plus concret pour traiter ce catalogue comme une liste de priorités : nous l’avons analysé dans notre article sur le catalogue KEV. Notez que le VPN et le logiciel de sauvegarde, deux équipements de sécurité, figurent dans cette liste : ils exigent le même délai de correction que le reste.
Où voir l’attaquant : cinq alertes à faible coût
Toutes les traces ci-dessous existent déjà dans les journaux de Windows, à condition que la stratégie d’audit correspondante soit activée (« Audit User Account Management » pour les créations de comptes, « Audit Security Group Management » pour les groupes).
- Toute création de compte (événement 4720) sur un contrôleur de domaine en dehors d’un processus de création connu.
- Tout ajout à un groupe privilégié (événements 4728 pour un groupe global comme Domain Admins, 4732 pour un groupe local comme Administrateurs). Alerte immédiate, jour et nuit.
- Toute connexion RDP réussie (événement 4624, type de session 10 « RemoteInteractive ») depuis une adresse externe, ou vers un contrôleur de domaine ou un serveur de sauvegarde depuis un poste qui n’y va jamais.
- Tout outil d’accès distant qui n’est pas dans votre inventaire (AnyDesk, RustDesk, LogMeIn), y compris les exécutables portables.
- Toute commande qui détruit les moyens de reprise :
vssadmin delete shadows,wmic shadowcopy delete,wbadmin delete,bcdedit, suppression de tâches de sauvegarde.
Pour un premier contrôle manuel des trois premières, voici une commande PowerShell à lancer sur un contrôleur de domaine. Elle utilise Get-WinEvent avec un filtre XPath, syntaxe documentée par Microsoft ; nous ne l’avons pas exécutée pour cet article (pas de domaine Windows dans notre banc d’essai), testez-la d’abord sur un environnement non critique :
# Créations de comptes et ajouts à des groupes, sur les 7 derniers jours
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4720,4728,4732,4756; StartTime=(Get-Date).AddDays(-7)} |
Select-Object TimeCreated, Id, @{n='Détail';e={($_.Message -split "`n")[0..12] -join ' '}}
# Connexions RDP réussies (type 10) sur les 24 dernières heures
Get-WinEvent -LogName Security -FilterXPath "*[System[(EventID=4624) and TimeCreated[timediff(@SystemTime) <= 86400000]] and EventData[Data[@Name='LogonType']='10']]" |
Select-Object TimeCreated, @{n='Compte';e={$_.Properties[5].Value}}, @{n='Source';e={$_.Properties[18].Value}}Une alerte n’a de valeur que si quelqu’un la reçoit. L’étude de Sophos montre que la quasi-totalité des rançongiciels est déployée en dehors des heures ouvrées : la question à se poser est donc celle de l’astreinte, pas seulement celle de l’outil.
Les cinq décisions qui changent l’issue
- Un MFA résistant à l’hameçonnage sur tous les accès distants (VPN, RDP, messagerie, comptes d’administration). L’intrusion Lynx commence par des identifiants valides, et l’avis Akira décrit des accès par des VPN dépourvus de MFA.
- Corriger en priorité les failles du catalogue KEV sur les équipements exposés : VPN, pare-feu, serveurs de collaboration, logiciel de sauvegarde.
- Aucun accès RDP direct depuis Internet ; l’administration passe par un bastion, comme le décrit notre article sur le bastion.
- Des comptes d’administration séparés des comptes du quotidien, et une alerte sur toute création de compte ou changement de groupe privilégié.
- Une copie de sauvegarde que ces comptes ne peuvent pas supprimer : c’est ce qui décide de l’issue quand tout le reste a échoué.
Si vous voyez ces signes maintenant
Le guide #StopRansomware donne la conduite à tenir. Les points qui comptent le plus lorsque l’attaquant est encore actif :
- Isoler de façon coordonnée et communiquer hors bande (téléphone) : l’attaquant peut surveiller la messagerie. S’il comprend qu’il est découvert, il peut se déplacer pour garder son accès ou déployer le rançongiciel plus largement avant l’isolement.
- Si plusieurs systèmes ou sous-réseaux sont touchés, couper le réseau au niveau du commutateur plutôt que machine par machine.
- Ne pas éteindre les machines sauf impossibilité de les déconnecter : l’extinction détruit les traces en mémoire.
- Chercher les traces antérieures : un rançongiciel révèle souvent une compromission plus ancienne et non traitée, dont l’accès a parfois été vendu.
- Vérifier avant de restaurer : restaurer depuis une sauvegarde sans avoir trouvé l’accès de l’attaquant le laisse en place.
Pour ce dernier point, voir notre article sur le sanity check après incident.
Auto-évaluation : six questions
- Qui reçoit, un dimanche à 2 h du matin, l’alerte de création d’un compte administrateur de domaine ?
- Savez-vous, en moins d’une heure, quels comptes ont créé des comptes ou modifié des groupes privilégiés la semaine dernière ?
- Vos accès VPN et RDP exigent-ils un MFA résistant à l’hameçonnage, sans exception ?
- Votre équipement VPN, votre pare-feu et votre logiciel de sauvegarde ont-ils tous été corrigés des failles du catalogue KEV ?
- Un outil d’accès distant inconnu sur un serveur déclencherait-il une alerte ?
- Avez-vous une copie de sauvegarde qu’un administrateur de domaine ne peut pas supprimer ?
En résumé
Un rançongiciel est le dernier acte d’une intrusion, pas son début. Entre les deux, il y a une suite de gestes que l’on connaît : des identifiants valides, un compte administrateur créé, un outil d’accès distant légitime, des données envoyées vers l’extérieur, des sauvegardes effacées. Chacun est visible pour qui regarde les bons événements, et la plupart sont bloqués par des mesures ordinaires : MFA, correctifs prioritaires, séparation des comptes, copie immuable. Le délai, lui, ne se négocie pas : deux heures dans un cas, neuf jours dans l’autre.
Transparence : cet article a été rédigé avec l’aide d’un assistant Claude. Les délais et les faits techniques proviennent des rapports cités, relus sur les pages sources en septembre 2026 ; les recoupements avec le catalogue KEV ont été faits sur le fichier officiel de la CISA (version 2026.09.27). La commande PowerShell n’a pas été exécutée. Les colonnes « où c’est visible » et « ce qui l’arrête » mêlent recommandations officielles et lecture de l’auteur.
À lire aussi
- Sauvegardes : la règle 3-2-1-1-0 : la copie que les identifiants volés ne peuvent pas effacer.
- MFA : toutes les authentifications fortes ne se valent pas : hameçonnage, fatigue MFA et récupération de compte.
Sources
- The DFIR Report, « Confluence Exploit Leads to LockBit Ransomware » (24 février 2025) : thedfirreport.com
- The DFIR Report, « Cat’s Got Your Files: Lynx Ransomware » (17 décembre 2025) : thedfirreport.com
- Sophos, « The 2026 Active Adversary Report » : sophos.com
- CISA, FBI et partenaires, « #StopRansomware: Akira Ransomware » (AA24-109A, mis à jour le 13 novembre 2025) : cisa.gov
- CISA, « #StopRansomware Guide » : cisa.gov
- CISA, catalogue Known Exploited Vulnerabilities : cisa.gov
- Microsoft Learn, événements de sécurité 4720, 4732 et 4624 : learn.microsoft.com