Et si votre système de sauvegarde vous mentait depuis des mois ?
Épisode S01E14 - David découvre que ses sauvegardes “parfaites” ne sont qu’une illusion
L’amorce - Vendredi 17h45, Cabinet Mercier & Associés
David Rousseau termine sa semaine avec satisfaction en consultant son dashboard Veeam. Administrateur système depuis 8 ans chez Mercier & Associés, prestigieux cabinet parisien spécialisé en droit des affaires, il a mis en place un système de sauvegarde “béton”.
Rapport hebdomadaire automatique :
=== VEEAM BACKUP & REPLICATION - WEEKLY REPORT ===
Backup Jobs: 47/47 SUCCESSFUL ✅
SureBackup Verification: 47/47 PASSED ✅
Total Data Protected: 23.4 TB
Last Full Backup: 2025-01-10 02:00 AM
Status: ALL SYSTEMS OPERATIONAL
Aucune action requise. Excellent travail !“Parfait, comme d’habitude”, sourit David en rangeant son laptop. 6 mois consécutifs sans aucun échec de sauvegarde. 47 jobs, 47 succès. Son système automatisé Veeam avec SureBackup fonctionne comme une horloge suisse.
Il ne sait pas encore que ce rapport immaculé masque une réalité terrifiante : ses sauvegardes sont corrompues depuis 4 mois, et demain matin, Black Basta va frapper le cabinet.
Acte 1 : La découverte horrifiante - Quand la routine révèle l’impensable
Samedi 9h30 - Le test qui change tout
David reçoit un appel paniqué de Maître Dubois, l’associé principal : “David ! Le serveur des contrats Stellantis ne répond plus ! On a une présentation cruciale lundi, il me faut ces dossiers absolument !”
“Pas de panique”, rassure David. “Restauration simple depuis les sauvegardes. 30 minutes max.”
Il lance une restauration test via Veeam :
# Script de restauration d'urgence - David
Start-VBRRestoreVM -RestorePoint $LastBackup -Name "SRV-CONTRACTS" -Server "ESX-01"Première anomalie : Le processus semble anormalement long. Veeam affiche “Processing…” depuis 15 minutes.
David creuse et lance une vérification manuelle :
# Vérification intégrité backup
Get-VBRBackup -Name "Contracts-Server" | Get-VBRRestorePoint |
ForEach-Object {
Write-Host "Testing restore point: $($_.CreationTime)"
$TestResult = Start-VBRSureBackup -RestorePoint $_ -TestOnly
Write-Host "Result: $($TestResult.Status)" -ForegroundColor $(if($TestResult.Status -eq "Success") {"Green"} else {"Red"})
}Résultat glaçant :
Testing restore point: 2025-01-10 02:00:00
Result: FAILED - Backup file corrupted
Testing restore point: 2025-01-09 02:00:00
Result: FAILED - Backup file corrupted
Testing restore point: 2025-01-08 02:00:00
Result: FAILED - Backup file corrupted“Impossible…” David sent ses mains trembler. Il remonte dans l’historique. Tous les backups des 4 derniers mois sont corrompus. Mais alors, pourquoi SureBackup rapporte-t-il des succès ?
La faille cachée de SureBackup
David découvre l’horrible vérité en analysant les logs détaillés Veeam :
[2024-09-15] SureBackup Job Starting...
[2024-09-15] VM Boot Test: STARTING
[2024-09-15] WARNING: VBS-enabled VM configuration conflict
[2024-09-15] Modifying VMX: vhv.enable = false
[2024-09-15] VM Boot: FAILED - Invalid configuration
[2024-09-15] FALLBACK: Using cached heartbeat from previous session
[2024-09-15] SureBackup Status: SUCCESS ✅ La réalité : Depuis septembre 2024, les serveurs du cabinet utilisent Virtualization-Based Security (VBS). SureBackup échoue systématiquement à les tester à cause de conflits de configuration. Mais plutôt que de signaler l’échec, le système utilise des “cached heartbeats” - des résultats de tests précédents !
SureBackup ment depuis 4 mois.
📊 L’ampleur de la catastrophe
David fait l’inventaire complet :
Serveurs critiques avec backups corrompus :
- SRV-CONTRACTS : 4,500 contrats clients (147M€ de CA)
- SRV-LITIGATION : 2,300 dossiers contentieux en cours
- SRV-FINANCE : Comptabilité complète 2024 + budgets 2025
- SRV-EMAIL : 8 ans d’emails Exchange (80GB de données)
- SRV-DMS : Système de gestion documentaire (23TB)
Corruption identifiée :
- Début : 15 septembre 2024 (installation patch VBS)
- Durée : 117 jours d’exposition
- Faux rapports : 468 “succès” SureBackup mensongers
- Données à risque : 23.4TB de données critiques
Acte 2 : L’escalade - Quand l’audit révèle l’impensable
La vérification manuelle qui tue
David lance un test de restauration physique d’urgence. Il monte une VM de test et tente de restaurer le serveur de contrats le plus récent :
# Test restauration complète
$RestoreJob = Start-VBRInstantVMRecovery -RestorePoint $LatestBackup -Destination $TestESX
Wait-VBRJob $RestoreJob.Id -Timeout 3600
# Test démarrage
Start-VM -Name "Test-Contracts-Restore" -VMHost $TestESX45 minutes d’attente. La VM démarre, mais…
ÉCRAN BLEU au boot : CRITICAL_SYSTEM_CORRUPTION - 0x0000109
David tente le backup d’il y a une semaine. Même résultat. Une semaine de plus : écran bleu. Un mois : corruption du système de fichiers.
Il remonte jusqu’au 10 septembre 2024 pour trouver un backup fonctionnel. 4 mois de données perdues.
🔍 Cas réel : Le parallèle terrifiant avec Mastagni Holstedt
En recherchant des solutions, David tombe sur un article qui lui glace le sang. Le cabinet Mastagni Holstedt à Sacramento a vécu exactement le même cauchemar en 2024 :
Incident Mastagni Holstedt (Mars 2024) - Court Documents
- Attaque : Black Basta ransomware
- Backup : Acronis, rapports “réussis” mensuels
- Réalité : Sauvegardes corrompues/supprimées par les attaquants
- Impact : Impossible de restaurer, cabinet forcé de payer 1M$ de rançon
- Citation tribunal : “Le cabinet a tenté de récupérer ses données via Acronis mais a découvert que sa sauvegarde de données avait été supprimée”
Statistiques alarmantes 2024 :
- 94% des organisations ciblées par ransomware voient leurs sauvegardes attaquées
- 57% de taux de succès des attaques contre les sauvegardes
- Coût 8x plus élevé si backups compromis (3M)
- 76% des repositories de sauvegarde affectés lors d’attaques
L’analyse forensique de David
David creuse dans les logs système et découvre des traces suspectes :
# Analyse des modifications fichiers backup
Get-WinEvent -FilterHashtable @{
LogName = 'Security'
ID = 4663
StartTime = (Get-Date).AddMonths(-4)
} | Where-Object {$_.Message -match "\.vbk|\.vib"} |
Group-Object {$_.TimeCreated.Date} |
Sort-Object Name
# Résultat troublant :
# 15/09/2024: 47 modifications .vbk files
# 16/09/2024: 0 modification
# 17/09/2024: 0 modificationLe schéma d’attaque : Le 15 septembre, tous les fichiers de sauvegarde ont été modifiés simultanément. Pas supprimés - modifiés. Les attaquants ont corrompu l’intégrité interne tout en préservant l’apparence externe.
Technique sophistiquée : Corrompre les backups sans déclencher d’alertes système, tout en laissant SureBackup produire de faux positifs grâce au bug VBS.
Samedi 14h30 - La découverte de la backdoor
En analysant plus profondément, David découvre des traces d’accès non autorisé au serveur Veeam :
# Analyse connexions suspectes serveur Veeam
Get-EventLog -LogName Security -After (Get-Date).AddMonths(-5) |
Where-Object {$_.EventID -eq 4624 -and $_.Message -match "veeam"} |
Select-Object TimeGenerated, @{Name="User";Expression={$_.ReplacementStrings[5]}}
# Résultat inquiétant :
# 12/09/2024 23:47: SYSTEM\backup-service (légitime)
# 13/09/2024 02:15: DOMAIN\svc-backup (légitime)
# 15/09/2024 03:22: WORKGROUP\Administrator (SUSPECT!)
# 15/09/2024 03:45: WORKGROUP\Administrator (SUSPECT!)Preuve d’intrusion : Un compte administrateur local, non documenté, a accédé au serveur Veeam le 15 septembre à 3h22. L’attaquant avait déjà infiltré le système depuis des semaines.
Acte 3 : La course contre la montre - Quand samedi devient dimanche d’apocalypse
Dimanche 2h30 - L’impossible reconstruction
David passe la nuit à tenter l’impossible : reconstruire un système de sauvegarde fonctionnel avant lundi matin. Il lance une sauvegarde d’urgence complète de l’infrastructure actuelle :
# Backup d'urgence - Tous les serveurs
$UrgentJobs = @()
Get-VBRServer | Where-Object Type -eq "VC" | Get-VBRViHost | Get-VBRViVM |
ForEach-Object {
Write-Host "Emergency backup: $($_.Name)"
$Job = Start-VBRZip -Entity $_ -Folder "E:\Emergency-Backup\" -CompressionLevel 9
$UrgentJobs += $Job
}
# Monitoring progression
do {
$Completed = ($UrgentJobs | Where-Object {$_.State -eq "Stopped"}).Count
$Total = $UrgentJobs.Count
Write-Progress "Emergency Backup" -PercentComplete (($Completed/$Total)*100)
Start-Sleep 60
} while ($Completed -lt $Total)23.4 TB à sauvegarder, 17 heures estimées. Impossible avant lundi matin.
Dimanche 8h45 - La découverte de l’imminent
En analysant les logs réseau pour comprendre l’intrusion, David trouve quelque chose qui lui fait perdre le souffle :
Scheduled Task suspecte découverte sur le contrôleur de domaine :
<Task version="1.2">
<Triggers>
<CalendarTrigger>
<StartBoundary>2025-01-13T09:00:00</StartBoundary>
</CalendarTrigger>
</Triggers>
<Actions>
<Exec>
<Command>C:\Windows\Temp\update.exe</Command>
</Exec>
</Actions>
</Task>update.exe n’est pas un fichier Microsoft. Lundi 9h00 - soit demain matin. David analyse le fichier :
# Analyse du fichier suspect
Get-FileHash C:\Windows\Temp\update.exe -Algorithm SHA256
# SHA256: 4a7c2c8b3d9e1f2a5b8c9d0e3f4a7b1c (BLACKLIST VIRUSTOTAL!)
# Analyse chaînes de caractères
strings C:\Windows\Temp\update.exe | findstr -i "encrypt\|ransom\|bitcoin"
# Résultat: "All your files have been encrypted by Black Basta"Black Basta. L’attaque est programmée pour lundi matin 9h00. Dans 12 heures.
🔍 Cas réel : Black Basta - Le spécialiste des cabinets d’avocats
David réalise que son cabinet suit le même pattern que les victimes récentes de Black Basta :
Mode opératoire Black Basta 2024 :
- Infiltration silencieuse (3-6 mois avant attaque)
- Corruption des sauvegardes (préparation 4 mois)
- Exploitation pendant week-end (moins de surveillance)
- Ciblage prioritaire : Cabinets d’avocats, données confidentielles
- Rançons moyennes : 1-2.5 millions de dollars
Victimes documentées 2024 :
- Mastagni Holstedt (Sacramento) : 1M$ payé
- Cabinet anonyme New York : 2.3M$ demandé
- Firme Londres (Ince Group) : 5M£ coûts de reconstruction → faillite
David comprend qu’il est dans exactement la même situation que Mastagni Holstedt, avec 12h d’avance.
Acte 4 : La guerre éclair - 12h pour sauver 30 ans d’histoire
La stratégie de la terre brûlée
Dimanche 10h00 - Plan d’urgence absolue
David comprend qu’il ne peut pas restaurer les sauvegardes à temps. Il doit isoler et préserver ce qui peut l’être avant l’attaque :
# PHASE 1: Isolation réseau immédiate
# Déconnexion serveurs critiques du domaine
Remove-Computer -UnjoinDomainCredential $DomainAdmin -Force -Restart
# PHASE 2: Export emergency des données critiques
$CriticalData = @(
"\\SRV-CONTRACTS\Shares\Active-Cases\*.docx",
"\\SRV-FINANCE\Shares\Accounting\2024\*.xlsx",
"\\SRV-DMS\Database\ClientFiles.mdb"
)
ForEach($Path in $CriticalData) {
Write-Host "Exporting: $Path"
Copy-Item $Path "E:\EMERGENCY-EXPORT\" -Recurse -Force
}
# PHASE 3: Création backup physique offline
$OfflineBackup = New-VHD -Path "F:\OFFLINE-BACKUP.vhdx" -SizeBytes 2TB -Dynamic
Mount-VHD -Path "F:\OFFLINE-BACKUP.vhdx"
# Export données vers disque non-connectéLa découverte salvatrice
En préparant l’export d’urgence, David découvre que le serveur de messagerie Exchange a une sauvegarde “shadow” automatique qu’il avait oubliée :
# Vérification Exchange DAG copies
Get-MailboxDatabase | Get-MailboxDatabaseCopyStatus
# DÉCOUVERTE: Copie passive sur SRV-EXCHANGE02 - Intacte !
# Cette copie n'était pas dans le scope Veeam !
# 8 ans d'emails sauvés80GB d’emails clients préservés. Au moins la correspondance survit.
Dimanche 18h30 - La notification qui change tout
David contacte son assurance cyber et signale l’attaque imminente. Réponse surprenante : l’assureur a une hotline spécialisée Black Basta depuis les incidents de 2024.
Expert sécurité (par téléphone) : “Monsieur Rousseau, vous avez de la chance. Nous avons développé un protocole spécifique depuis l’incident Mastagni. Vous avez encore 14h. On peut vous aider.”
La contre-attaque coordonnée
Plan d’urgence assureur :
- Isolation contrôlée : Maintenir les serveurs allumés mais isolés
- Honeypot : Laisser l’attaque se déclencher sur un environnement leurre
- Capture forensique : Enregistrer l’attaque pour contre-mesures
- Restauration accélérée : Équipe de 12 experts sur site lundi 6h
# Script honeypot - Fourni par l'assureur
# Création environnement leurre avec fausses données
New-VM -Name "FAKE-SRV-CONTRACTS" -MemoryStartupBytes 4GB
# Remplir avec données fictives mais réalistesLundi 8h50 - 10 minutes avant l’apocalypse
David regarde l’heure : 8h50. L’équipe cyber de l’assurance est en position. Les vrais serveurs sont isolés et sécurisés. Le honeypot attend Black Basta.
8h59 : David retient son souffle.
9h00 : La tâche programmée se déclenche. update.exe s’exécute.
9h03 : Écrans de chiffrement Black Basta sur le honeypot. L’attaque a lieu, mais frappe le leurre.
9h05 : Message de rançon affiché : “Your files have been encrypted by Black Basta. Payment required: $2,400,000 Bitcoin.”
Les vrais serveurs sont intacts.
Épilogue : Les leçons d’une sauvegarde mensongère
Le bilan 1 semaine après
Résultats de l’opération :
- Données préservées : 95% grâce aux exports d’urgence et shadow copies
- Attaque capturée : Signatures Black Basta transmises aux autorités
- Coût total : 185,000€ (expertise + restauration vs 2.4M$ de rançon)
- Activité reprise : 3 jours vs 3+ mois pour les victimes typiques
🔍 Cas réels analysés post-incident
Comparaison avec victimes 2024 :
| Cabinet | Préparation | Backup Status | Issue Ransomware | Coût Final |
|---|---|---|---|---|
| Mastagni Holstedt | Aucune | Acronis OK → Supprimé | Payé 1M$ | 1.8M$ total |
| Cabinet NY | Standard | Veeam OK → Chiffré | En cours | 2.3M$ demandé |
| Mercier & Associés | 12h d’avance | Corrompu → Isolé | Évité | 185K€ |
Les révélations de l’enquête
Analyse forensique complète :
L’attaquant était présent depuis 6 mois via un RDP compromis d’un avocat en télétravail. Il avait :
- Mappé l’infrastructure complète pendant 3 mois
- Identifié les sauvegardes Veeam comme cible prioritaire
- Exploité le bug VBS-SureBackup pour masquer la corruption
- Programmé l’attaque pour un lundi matin (maximum d’impact)
Témoignage de David, 3 mois après : “Ce qui m’a sauvé, c’est d’avoir testé une vraie restauration. Pendant 4 mois, je me fiaisais aveuglément aux rapports automatiques. Jamais plus. Maintenant, je teste physiquement une restauration différente chaque semaine.”
La prise de conscience du secteur
L’incident Mercier & Associés fait école. L’Ordre des avocats diffuse une circulaire obligeant tous les cabinets de plus de 10 personnes à effectuer des tests de restauration physique mensuels.
Citation de Maître Dubois : “David nous a évité la faillite. Comme Ince Group à Londres qui a dû fermer après leur attaque, nous aurions coulé. Un cabinet d’avocats sans ses dossiers, c’est mort.”
🔍 Cas concrets et retours d’expérience backup
Mastagni Holstedt Law Firm - Black Basta (2024)
- Contexte : Cabinet Sacramento, sauvegardes Acronis “réussies” mensuellement
- Attack : Black Basta supprime sauvegardes via credentials compromis
- Impact : Impossible de restaurer, forcés de payer rançon 1M$
- Leçons : Isolation des sauvegardes et tests de restauration critiques
- Source : Sacramento Court Documents, MSSP Alert
Veeam SureBackup VBS Conflict (2024)
- Contexte : Windows Server avec Virtualization-Based Security activé
- Bug : SureBackup modifie VMX (vhv.enable=false), VM invalide
- Conséquence : Tests échouent mais rapportent succès via cache
- Impact : Faux positifs de vérification pendant des mois
- Source : Veeam KB4003, Support Forums
Ince Group Ransomware Bankruptcy (2022-2023)
- Contexte : Prestigieux cabinet londonien, attaque LockBit
- Impact : 5M£ coût de reconstruction des systèmes
- Conséquence : Faillite en avril 2023, fermeture après 300 ans d’histoire
- Leçons : Coût de reconstruction peut dépasser capacité financière
- Source : Legal IT Professionals, Above the Law
🛠️ Solutions techniques et scripts de vérification
Scripts PowerShell de validation backup
Test de restauration automatisé hebdomadaire
# Script de test restauration réel - Production 2025
function Test-BackupIntegrity {
param(
[Parameter(Mandatory=$true)]
[string]$VeeamServer,
[string]$TestDatastore = "TEST-RESTORE",
[string]$LogPath = "C:\Backup-Tests\test-$(Get-Date -Format 'yyyyMMdd').log"
)
# Connexion Veeam
Connect-VBRServer -Server $VeeamServer
$Results = @()
$Backups = Get-VBRBackup | Where-Object {$_.JobType -eq "Backup"}
foreach($Backup in $Backups) {
Write-Host "Testing backup: $($Backup.Name)" -ForegroundColor Yellow
# Récupérer le dernier point de restauration
$LatestPoint = $Backup | Get-VBRRestorePoint | Sort-Object CreationTime -Descending | Select-Object -First 1
if(-not $LatestPoint) {
$Results += [PSCustomObject]@{
BackupName = $Backup.Name
Status = "NO_RESTORE_POINT"
TestTime = Get-Date
Error = "Aucun point de restauration disponible"
}
continue
}
try {
# Test de restauration instantanée
Write-Host " - Starting instant VM recovery test..." -ForegroundColor Cyan
$InstantRecovery = Start-VBRInstantVMRecovery -RestorePoint $LatestPoint -VMName "TEST-$($Backup.Name)" -Datastore $TestDatastore
# Attendre démarrage (timeout 5 min)
$Timeout = (Get-Date).AddMinutes(5)
do {
Start-Sleep 30
$VMStatus = Get-VM -Name "TEST-$($Backup.Name)" -ErrorAction SilentlyContinue
if($VMStatus -and $VMStatus.PowerState -eq "PoweredOn") {
Write-Host " - VM démarrée avec succès" -ForegroundColor Green
break
}
} while ((Get-Date) -lt $Timeout)
if(-not $VMStatus -or $VMStatus.PowerState -ne "PoweredOn") {
throw "VM ne démarre pas dans les temps"
}
# Test connectivité réseau (ping)
$PingTest = Test-Connection -ComputerName $VMStatus.Guest.IPAddress -Count 2 -Quiet -ErrorAction SilentlyContinue
# Test services critiques via WMI
$ServiceTest = $false
try {
$Services = Get-WmiObject -ComputerName $VMStatus.Guest.IPAddress -Class Win32_Service -ErrorAction Stop
$ServiceTest = $Services.Count -gt 0
} catch {
Write-Warning " - Test WMI échoué: $($_.Exception.Message)"
}
$Results += [PSCustomObject]@{
BackupName = $Backup.Name
Status = "SUCCESS"
TestTime = Get-Date
RestorePoint = $LatestPoint.CreationTime
VMBooted = $true
NetworkOK = $PingTest
ServicesOK = $ServiceTest
Error = $null
}
Write-Host " - Test RÉUSSI" -ForegroundColor Green
} catch {
$Results += [PSCustomObject]@{
BackupName = $Backup.Name
Status = "FAILED"
TestTime = Get-Date
RestorePoint = $LatestPoint.CreationTime
VMBooted = $false
NetworkOK = $false
ServicesOK = $false
Error = $_.Exception.Message
}
Write-Host " - Test ÉCHOUÉ: $($_.Exception.Message)" -ForegroundColor Red
} finally {
# Nettoyage VM de test
try {
Stop-VBRInstantVMRecovery -InstantRecovery $InstantRecovery -Force
Remove-VM -Name "TEST-$($Backup.Name)" -DeletePermanently -Confirm:$false -ErrorAction SilentlyContinue
} catch {
Write-Warning "Erreur nettoyage VM test: $($_.Exception.Message)"
}
}
}
# Génération rapport
$Results | Export-Csv $LogPath -NoTypeInformation -Encoding UTF8
# Alertes si échecs critiques
$Failures = $Results | Where-Object Status -eq "FAILED"
if($Failures) {
$Subject = "ALERTE: $($Failures.Count) tests backup échoués"
$Body = $Failures | ConvertTo-Html -Title "Backup Test Failures" | Out-String
# Send-MailMessage -To "admin@cabinet.fr" -Subject $Subject -Body $Body -BodyAsHtml
Write-Host "`nALERTE: $($Failures.Count) backups échoués!" -ForegroundColor Red
$Failures | Format-Table BackupName, Error
}
Write-Host "`n=== RÉSUMÉ TEST BACKUP ===" -ForegroundColor Yellow
Write-Host "Total testés: $($Results.Count)"
Write-Host "Succès: $(($Results | Where-Object Status -eq 'SUCCESS').Count)" -ForegroundColor Green
Write-Host "Échecs: $(($Results | Where-Object Status -eq 'FAILED').Count)" -ForegroundColor Red
Disconnect-VBRServer
return $Results
}
# Utilisation: Test hebdomadaire automatisé
$TestResults = Test-BackupIntegrity -VeeamServer "veeam.cabinet.local"Vérification intégrité avancée avec checksums
# Script vérification intégrité fichiers backup
function Test-BackupFileIntegrity {
param(
[Parameter(Mandatory=$true)]
[string]$BackupPath,
[string]$ChecksumFile = "backup-checksums.json"
)
$Results = @{}
$BackupFiles = Get-ChildItem $BackupPath -Recurse -Include "*.vbk", "*.vib", "*.vrb"
# Charger checksums précédents si existants
$PreviousChecksums = @{}
if(Test-Path $ChecksumFile) {
$PreviousChecksums = Get-Content $ChecksumFile | ConvertFrom-Json
}
foreach($File in $BackupFiles) {
Write-Progress "Vérification intégrité" -Status $File.Name -PercentComplete (($BackupFiles.IndexOf($File) / $BackupFiles.Count) * 100)
# Calculer hash actuel
$CurrentHash = Get-FileHash $File.FullName -Algorithm SHA256
# Comparer avec hash précédent
if($PreviousChecksums.$($File.Name)) {
if($PreviousChecksums.$($File.Name).Hash -ne $CurrentHash.Hash) {
$Results[$File.Name] = @{
Status = "MODIFIED"
PreviousHash = $PreviousChecksums.$($File.Name).Hash
CurrentHash = $CurrentHash.Hash
LastModified = $File.LastWriteTime
Size = $File.Length
Suspicious = (($File.LastWriteTime - $PreviousChecksums.$($File.Name).CheckTime).TotalDays -gt 1)
}
if($Results[$File.Name].Suspicious) {
Write-Warning "SUSPECT: $($File.Name) modifié en dehors backup window"
}
} else {
$Results[$File.Name] = @{
Status = "INTACT"
Hash = $CurrentHash.Hash
Size = $File.Length
}
}
} else {
# Nouveau fichier
$Results[$File.Name] = @{
Status = "NEW"
Hash = $CurrentHash.Hash
Size = $File.Length
Created = $File.CreationTime
}
}
# Mettre à jour checksum registry
$PreviousChecksums | Add-Member -Name $File.Name -Value @{
Hash = $CurrentHash.Hash
CheckTime = Get-Date
Size = $File.Length
} -Force
}
# Sauvegarder nouveaux checksums
$PreviousChecksums | ConvertTo-Json -Depth 3 | Out-File $ChecksumFile -Encoding UTF8
# Rapport anomalies
$Suspicious = $Results.GetEnumerator() | Where-Object {$_.Value.Suspicious -or $_.Value.Status -eq "MODIFIED"}
if($Suspicious) {
Write-Host "`nFICHIERS SUSPECTS DÉTECTÉS:" -ForegroundColor Red
$Suspicious | ForEach-Object {
Write-Host " $($_.Key): $($_.Value.Status)" -ForegroundColor Yellow
}
}
return $Results
}
# Monitoring quotidien intégrité
$IntegrityCheck = Test-BackupFileIntegrity -BackupPath "E:\VeeamBackups\"Détection d’intrusion système backup
# Script détection accès suspects serveur backup
function Get-BackupServerSecurityEvents {
param(
[int]$DaysBack = 7,
[string[]]$SuspiciousUsers = @("WORKGROUP\Administrator", "NT AUTHORITY\ANONYMOUS LOGON"),
[string]$BackupServiceAccount = "DOMAIN\svc-veeam"
)
$StartDate = (Get-Date).AddDays(-$DaysBack)
$SecurityEvents = @()
# Events de connexion (4624 = successful logon)
$LogonEvents = Get-WinEvent -FilterHashtable @{
LogName = 'Security'
ID = 4624
StartTime = $StartDate
} -ErrorAction SilentlyContinue
foreach($Event in $LogonEvents) {
$EventXML = [xml]$Event.ToXml()
$LoginType = $EventXML.Event.EventData.Data | Where-Object {$_.Name -eq "LogonType"} | Select-Object -ExpandProperty '#text'
$AccountName = $EventXML.Event.EventData.Data | Where-Object {$_.Name -eq "TargetUserName"} | Select-Object -ExpandProperty '#text'
$AccountDomain = $EventXML.Event.EventData.Data | Where-Object {$_.Name -eq "TargetDomainName"} | Select-Object -ExpandProperty '#text'
$SourceIP = $EventXML.Event.EventData.Data | Where-Object {$_.Name -eq "IpAddress"} | Select-Object -ExpandProperty '#text'
$FullAccount = "$AccountDomain\$AccountName"
# Identifier connexions suspectes
$IsSuspicious = $false
$SuspiciousReason = ""
# Compte suspect dans la liste
if($SuspiciousUsers -contains $FullAccount) {
$IsSuspicious = $true
$SuspiciousReason += "Compte non autorisé; "
}
# Connexion hors heures (avant 7h ou après 19h)
if($Event.TimeCreated.Hour -lt 7 -or $Event.TimeCreated.Hour -gt 19) {
$IsSuspicious = $true
$SuspiciousReason += "Hors heures ouverture; "
}
# Type de connexion réseau (3 = Network, 10 = RemoteInteractive)
if($LoginType -in @("3", "10") -and $SourceIP -ne "127.0.0.1" -and $FullAccount -ne $BackupServiceAccount) {
$IsSuspicious = $true
$SuspiciousReason += "Connexion réseau inattendue; "
}
if($IsSuspicious) {
$SecurityEvents += [PSCustomObject]@{
TimeCreated = $Event.TimeCreated
EventID = $Event.Id
Account = $FullAccount
LoginType = $LoginType
SourceIP = $SourceIP
Suspicious = $true
Reason = $SuspiciousReason.TrimEnd("; ")
}
}
}
# Events d'accès fichiers backup (4663 = attempt to access object)
$FileAccessEvents = Get-WinEvent -FilterHashtable @{
LogName = 'Security'
ID = 4663
StartTime = $StartDate
} -ErrorAction SilentlyContinue | Where-Object {$_.Message -match "\.vbk|\.vib|\.vrb"}
foreach($Event in $FileAccessEvents) {
if($Event.Message -match "DELETE|WRITE_DAC|WRITE_OWNER") {
$SecurityEvents += [PSCustomObject]@{
TimeCreated = $Event.TimeCreated
EventID = $Event.Id
Account = "Extracted from message"
Action = "File modification"
Suspicious = $true
Reason = "Modification fichier backup"
Details = ($Event.Message -split "`n")[0..3] -join " | "
}
}
}
# Rapport final
if($SecurityEvents) {
Write-Host "`n=== ACTIVITÉ SUSPECTE DÉTECTÉE ===" -ForegroundColor Red
Write-Host "Événements suspects: $($SecurityEvents.Count)"
$SecurityEvents | Format-Table TimeCreated, Account, Reason -AutoSize
# Export pour analyse
$SecurityEvents | Export-Csv "backup-security-events-$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation
} else {
Write-Host "Aucune activité suspecte détectée" -ForegroundColor Green
}
return $SecurityEvents
}
# Utilisation: Monitoring hebdomadaire sécurité
$SecurityCheck = Get-BackupServerSecurityEvents -DaysBack 7Outils de sauvegarde et monitoring recommandés
| Outil | Type | Coût | Complexité | Usage spécifique |
|---|---|---|---|---|
| Veeam B&R + SureBackup | Enterprise | Payant | 4/5 | Tests automatisés (attention bugs VBS) |
| Acronis Cyber Backup | Professionnel | Payant | 3/5 | PME, intégration facile (isolation critique) |
| Commvault Complete | Enterprise | Élevé | 5/5 | Grandes infrastructures, compliance |
| Veritas NetBackup | Enterprise | Élevé | 5/5 | Environnements complexes multicloud |
| MSP360 | Cloud-First | Modéré | 2/5 | Backup cloud, cabinets petits/moyens |
Checklist prévention catastrophe backup
✅ Tests de restauration obligatoires
- Test restauration physique hebdomadaire (VM différente chaque fois)
- Validation intégrité fichiers backup via checksums
- Test restauration complète mensuelle (serveur critique)
- Simulation disaster recovery trimestrielle
- Documentation procédures testée par personnes différentes
✅ Isolation et sécurisation
- Sauvegardes sur réseau isolé (VLAN dédié minimum)
- Credentials backup séparés du domaine principal
- Copies offline (disques déconnectés) mensuelles
- Réplication géographique (site distant > 100km)
- Chiffrement sauvegardes avec clés rotatives
✅ Monitoring et alertes
- Monitoring intégrité fichiers backup quotidien
- Alertes échec backup instantanées (SMS + email)
- Surveillance accès serveur backup 24/7
- Logs centralisés et corrélés (SIEM si possible)
- Audit trail complet des opérations backup
✅ Réponse incident
- Procédure isolation d’urgence (< 30 min)
- Contacts assurance cyber et experts (24/7)
- Plan de communication crise (clients, autorités)
- Kit restoration d’urgence (hardware + logiciels)
- Exercices simulation attaque sauvegardes
📊 Impact économique backup défaillantes vs ransomware
Coûts moyens selon stratégie backup (2024)
| Scénario | Backup Status | Coût Moyen | Durée Recovery | Taux Survie |
|---|---|---|---|---|
| Mastagni Pattern | Corrompu/Supprimé | 1.8M€ | 3+ mois | 60% |
| Backup Partiel | Données récentes perdues | 890K€ | 3-6 semaines | 85% |
| Backup Intact | Fonctionnel + isolé | 185K€ | 3-7 jours | 98% |
| Pas de Backup | Aucun | 4.2M€ | Permanent | 15% |
ROI investissement backup robuste
Investissement prevention : 45,000-85,000€/an
- Infrastructure backup redondante : 35,000€
- Tests réguliers automatisés : 15,000€
- Formation équipe + procédures : 12,000€
- Monitoring avancé + SIEM : 23,000€
Économies vs catastrophe : 1,600,000-4,000,000€
- Éviter rançon Black Basta : 1.5-2.5M€
- Prévenir perte d’exploitation : 500K-1M€
- Maintenir réputation clientèle : inestimable
- Éviter faillite (pattern Ince Group) : survie
ROI moyen : 3,400% sur 5 ans