Ransomware : de l'Alerte Wazuh à la Remédiation, Guide Pas à Pas

Ce tutoriel reprend, presque à l'identique, la méthodologie que nous appliquons en clientèle lorsqu'une alerte ransomware remonte dans notre SOC. L'objectif est pédagogique, vous montrer, commande par commande, comment on passe d'une alerte brute dans Wazuh à une décision argumentée (faux positif ou incident confirmé), puis à l'isolement, la collecte de preuves et la remédiation. Gardez-le comme référence si vous débutez en réponse à incident, chaque étape indique ce qu'on cherche, la commande exacte, et comment interpréter le résultat.

Le point de départ, l'alerte Wazuh

Tout commence par une alerte qui remonte dans le SOC. Sur un déploiement Wazuh orienté détection ransomware, on s'appuie typiquement sur trois familles de règles.

• Détection comportementale FIM, Wazuh surveille des répertoires sensibles via syscheck et déclenche une alerte quand un grand nombre de fichiers sont renommés ou modifiés en très peu de temps, signature typique d'un chiffrement massif.
• Détection par extension, une règle corrèle l'apparition d'extensions inhabituelles (.locked, .encrypted, .crypt, ou des extensions propres à une famille connue comme Akira, Conti, Ryuk).
• Détection de commandes suspectes via Sysmon, Wazuh ingère les logs Sysmon (Event ID 1) et déclenche sur des exécutions comme vssadmin delete shadows, wbadmin delete catalog, bcdedit /set recoveryenabled no ou cipher /w.

Exemple simplifié d'une règle locale qui corrèle une modification de clé de registre suspecte avec un processus inhabituel, base de l'alerte de notre cas pratique :

<rule id="100210" level="10">
  <if_group>sysmon_event13</if_group>
  <field name="win.eventdata.targetObject" type="pcre2">(?i)\SOFTWARE\.*\scheduler</field>
  <description>Modification suspecte d'une clé de registre liée à un scheduler</description>
  <group>registry_changed,ransomware_indicator,</group>
</rule>

Dans notre cas, l'alerte pointe un PID 9164 qui a modifié la clé HKLM\SOFTWARE\Lenovo\SystemUpdatePlugin\scheduler, avec pour parent le PID 3024. Rien ne dit encore s'il s'agit d'un vrai outil Lenovo ou d'un processus qui usurpe ce nom, c'est exactement le travail de l'étape 1.

Étape 1 — Validation rapide de l'alerte

Objectif : confirmer que le processus et son parent sont légitimes avant d'aller plus loin.

Identifier le processus incriminé :

Get-CimInstance Win32_Process |
Where-Object {$_.ProcessId -eq 9164} |
Select ProcessId,ParentProcessId,Name,CommandLine

On regarde trois choses, le nom de l'exécutable correspond-il vraiment à Lenovo (chemin dans Program Files, signature attendue), la ligne de commande contient-elle des arguments anormaux (base64, chemin temporaire, PowerShell encodé), et le ParentProcessId correspond-il à ce qu'on attend (un service Windows légitime, pas cmd.exe ou powershell.exe lancé depuis un emplacement inhabituel).

Vérifier le processus parent :

Get-CimInstance Win32_Process |
Where-Object {$_.ProcessId -eq 3024} |
Select ProcessId,Name,CommandLine

Vérifier la clé de registre modifiée :

reg query "HKLM\SOFTWARE\Lenovo\SystemUpdatePlugin\scheduler"

Étape 2 — Vérifier si un chiffrement est déjà en cours

Objectif : déterminer si on est encore en phase de reconnaissance ou si le chiffrement a déjà démarré, ce qui change complètement l'urgence de la réponse.

Recherche d'extensions de ransomware connues :

Get-ChildItem C:\ -Recurse -ErrorAction SilentlyContinue |
Where-Object {
  $_.Extension -match "locked|encrypted|crypt|lock|akira|conti|ryuk"
}

Recherche de notes de rançon :

Get-ChildItem C:\ -Recurse -ErrorAction SilentlyContinue |
Where-Object {
  $_.Name -match "README|RECOVER|DECRYPT|HOW_TO_RESTORE"
}

Vérifier l'activité disque en cours :

Get-Process |
Sort-Object CPU -Descending |
Select -First 20

Un processus inconnu qui consomme énormément de CPU/IO en tête de liste, au moment même de l'alerte, est un signal fort d'un chiffrement actif. Si vous avez accès à un moniteur de ressources, une activité disque en écriture massive et soutenue confirme le diagnostic.

Étape 3 — Vérifier les sauvegardes Windows (Shadow Copies)

Objectif : un ransomware opérationnel supprime quasi systématiquement les clichés instantanés avant ou pendant le chiffrement, pour empêcher toute restauration facile. Vérifier leur présence est à la fois un indicateur de compromission et une information critique pour la suite.

# Lister les clichés instantanés existants
vssadmin list shadows

# Vérifier l'état du service VSS
vssadmin list writers

# Rechercher une suppression récente dans les journaux d'événements
Get-WinEvent -LogName Application |
findstr /i "vssadmin shadow"

Étape 4 — Vérifier les commandes ransomware classiques

Objectif : chercher la trace directe des commandes que la quasi-totalité des familles de ransomware exécutent avant de chiffrer, pour désactiver la récupération native de Windows.

Historique PowerShell de l'utilisateur :

Get-Content "$env:APPDATA\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt"

Recherche dans les journaux Sysmon :

Get-WinEvent -LogName Microsoft-Windows-Sysmon/Operational |
findstr /i "vssadmin wbadmin bcdedit cipher"

Commande	Effet
vssadmin delete shadows	Supprime les clichés instantanés, empêche la restauration native
wbadmin delete catalog	Supprime le catalogue de sauvegardes Windows Server
bcdedit /set recoveryenabled no	Désactive la réparation au démarrage
cipher /w	Écrase les données déjà supprimées sur le disque, anti-forensique

Étape 5 — Vérifier la propagation latérale

Objectif : un ransomware moderne, en particulier dans un scénario opéré manuellement, cherche presque toujours à se propager latéralement avant de déclencher le chiffrement en masse. Cette étape détermine si l'incident est limité au poste ou s'étend au reste du parc.

# Sessions SMB entrantes
net session

# Partages réseau actifs
net use

# Connexions réseau actives et ports en écoute
netstat -ano

# Présence du service PsExec (mouvement latéral classique)
Get-Service PSEXESVC

Si PSEXESVC existe ou si vous observez des connexions SMB sortantes vers d'autres postes du parc que le compte concerné n'a normalement pas de raison de contacter, il faut considérer que l'incident dépasse le poste initial et étendre l'investigation aux machines cibles identifiées dans net session / netstat.

Étape 6 — Isolement immédiat

Objectif : couper toute communication réseau du poste pour stopper le chiffrement en cours et empêcher toute propagation supplémentaire, sans éteindre la machine, on perdrait la mémoire vive, précieuse pour la suite de l'investigation.

Disable-NetAdapter -Name Ethernet -Confirm:$false
Disable-NetAdapter -Name Wi-Fi -Confirm:$false

Étape 7 — Collecte forensique

Objectif : figer un maximum d'informations volatiles avant toute action de remédiation (redémarrage, réinstallation), pour permettre l'analyse post-incident et, le cas échéant, la qualification juridique de l'attaque.

tasklist /v > C:\Temp\process.txt
netstat -ano > C:\Temp\network.txt
sc query > C:\Temp\services.txt
schtasks /query /v /fo list > C:\Temp\schtasks.txt
query user > C:\Temp\users.txt

Ces exports couvrent les processus en cours avec leur contexte utilisateur, les connexions réseau actives au moment du gel, les services installés (souvent utilisés pour la persistance), les tâches planifiées (vecteur de persistance très fréquent) et les sessions utilisateurs ouvertes. Copiez immédiatement ce dossier C:\Temp hors du poste avant toute autre manipulation.

Étape 8 — Décision MDR et rapport de clôture

Objectif : trancher, sur la base des sept étapes précédentes, entre faux positif et incident confirmé, puis déclencher la suite adaptée.

Clôture rapide si :

• Aucun fichier chiffré
• Aucun IOC ransomware (pas de commande suspecte, pas de note de rançon)
• Aucun mouvement latéral
• Clé de registre Lenovo confirmée légitime
• Processus et parent confirmés légitimes

→ Verdict : Faux Positif / Activité système légitime. On documente l'alerte, on ajuste éventuellement la règle Wazuh pour réduire le bruit, et on referme le ticket.

Escalade IR N2/N3 si :

• Fichiers chiffrés
• Suppression des Shadow Copies
• VSS désactivé
• bcdedit modifié
• Propagation SMB/RDP
• PsExec détecté

→ Verdict : Suspicion de ransomware active. On passe en mode gestion de crise.

Et après, la remédiation

Les étapes 1 à 8 couvrent la phase de détection, confirmation et confinement. Une fois l'incident confirmé et le poste isolé, la remédiation proprement dite suit généralement cette séquence.

• Éradication, identifier et supprimer le vecteur initial (pièce jointe, identifiants compromis, vulnérabilité exploitée) sur tous les points d'entrée identifiés, pas seulement le poste initial.
• Réinitialisation des identifiants, tout compte ayant pu être exposé (comptes locaux, comptes AD ayant ouvert une session, comptes de service) doit voir son mot de passe changé, en priorité les comptes à privilèges.
• Restauration depuis une sauvegarde saine, ne jamais restaurer depuis une sauvegarde dont la date est postérieure au moment estimé de la compromission initiale, souvent bien antérieur à la détection. Un scan de la sauvegarde avant restauration est indispensable.
• Reconstruction plutôt que nettoyage, sur un poste confirmé compromis, la réinstallation complète est presque toujours préférable à un nettoyage manuel, dont on ne peut jamais garantir l'exhaustivité.
• Post-mortem, consigner la chronologie complète (vecteur initial, délai de détection, actions réalisées), et ajuster les règles de détection Wazuh/EDR sur la base des IOC observés pour ce cas précis.

Mini-rapport type de fin d'intervention

Questions fréquentes

Comment savoir si une alerte ransomware Wazuh est un faux positif ?
On valide en croisant plusieurs signaux, la légitimité du processus et de son parent, l'absence de fichiers chiffrés ou de note de rançon, la présence des Shadow Copies, et l'absence de commandes comme vssadmin delete shadows dans l'historique ou les logs Sysmon.

Quelles commandes PowerShell vérifier en premier lors d'une alerte ransomware ?
En priorité, identifier le processus et son parent avec Get-CimInstance Win32_Process, rechercher des extensions et notes de rançon avec Get-ChildItem, puis vérifier l'état des Shadow Copies avec vssadmin list shadows.

Faut-il éteindre un poste suspecté d'être infecté par un ransomware ?
Non, il faut isoler le poste du réseau plutôt que l'éteindre, pour stopper le chiffrement et la propagation sans perdre la mémoire vive, précieuse pour l'investigation forensique qui suit.