Последний инцидент, который я разбирал на postmortem, выглядел как учебник по «как делать не надо». Компания с выстроенным бэкап-процессом: ежедневное копирование на выделенный Veeam-сервер, еженедельный вынос на tape. Шифровальщик отработал за 47 минут. Когда команда полезла восстанавливаться - репозиторий Veeam зашифрован, каталог tape-библиотеки удалён, а VSS-снимки на Windows-серверах кто-то тихо стёр ещё за двое суток до запуска payload. Это не случайность и не побочный эффект. Это Recovery Denial - целенаправленная тактика, которую ransomware-группировки отточили до уровня стандартной операционной процедуры.
По данным Mandiant/Google Cloud (M-Trends 2025, Threat Horizons), уничтожение возможностей восстановления до запуска шифрования - одна из самых частых тактик ransomware-группировок. Логика простая: если жертва восстановится из бэкапов, платить выкуп незачем. Поэтому современные группировки вкладывают в разведку backup-инфраструктуры не меньше ресурсов, чем в разработку самих шифровальщиков. Бэкап - не страховка, а цель номер один.
Дальше - конкретика: какие TTP используют атакующие против систем резервного копирования, как их ловить, и как выстроить DR-инфраструктуру, которая переживёт Recovery Denial.
Что такое Recovery Denial и почему правило 3-2-1 больше не спасает
Recovery Denial - совокупность техник, цель которых - лишить жертву возможности восстановить данные без уплаты выкупа. В терминологии MITRE ATT&CK это покрывается несколькими техниками:-
Ссылка скрыта от гостей- удаление теневых копий, отключение служб восстановления, выключение Windows Recovery Environment
-
Ссылка скрыта от гостей- целенаправленное уничтожение файлов бэкапов
- T1489 (Service Stop) - остановка служб резервного копирования и баз данных перед шифрованием
Организации учатся восстанавливаться - и группировки удваивают усилия по уничтожению бэкапов. Recovery Denial - их ответ на растущую зрелость защиты.
Как ransomware-группировки уничтожают резервные копии: разбор атаки на бэкапы
Разберём конкретные TTP - то, что я наблюдал в реальных инцидентах и что подтверждается публичными отчётами.Удаление теневых копий и отключение системных механизмов восстановления
Первое, что делает практически любой современный шифровальщик. Команды настолько стандартные, что их можно считать «визитной карточкой» ransomware:
Код:
vssadmin delete shadows /all /quiet
wmic shadowcopy delete
bcdedit /set {default} bootstatuspolicy ignoreallfailures
bcdedit /set {default} recoveryenabled no
wbadmin delete catalog -quietvssadmin и wmic (на случай если одна из команд заблокирована), потом отключение Windows Recovery Environment через bcdedit, и наконец удаление каталога Windows Backup через wbadmin. Пояс, подтяжки и скотч - всё разом.Что критично: эти команды часто выполняются за дни до запуска шифрования. Атакующий хочет убедиться, что удаление теневых копий прошло тихо и SOC не дёрнулся.
Уничтожение backup-агентов и каталогов (T1485, T1489)
Более продвинутые группировки не ограничиваются VSS. Они проводят полноценную разведку backup-инфраструктуры:
Код:
# Разведка: ищем Veeam-серверы в домене
Get-ADComputer -Filter 'ServicePrincipalName -like "*veeam*"' -Properties ServicePrincipalName
# Разведка: какие backup-процессы крутятся
Get-Process | Where-Object {$_.Name -match "veeam|backup|arcserve|commvault|acronis"}
# Останавливаем службы Veeam
Get-Service -DisplayName "*Veeam*" | Stop-Service -Force
# Гасим SQL-экземпляр с каталогом Veeam
Stop-Service -Name "MSSQL`$VEEAMSQL" -Force
Ссылка скрыта от гостей
для остановки backup-агентов, антивирусов и баз данных. Цель двойная: помешать восстановлению и разблокировать файлы баз данных для шифрования.На одном инциденте группировка, действовавшая по модели LockBit, после получения доступа к Veeam-серверу отработала по чёткому плану:
- Остановила все службы Veeam
- Удалила файлы конфигурации и каталог бэкапов из SQL-базы
- Зашифровала сами файлы
.vbkи.vibна репозитории - И только после этого запустила шифрование на production-серверах
Компрометация backup-инфраструктуры через lateral movement
Самый паршивый сценарий - когда атакующий не просто удаляет бэкапы, а получает полный контроль над backup-инфраструктурой. Типичные ошибки, которые делают бэкапы уязвимыми (по материалам The Hacker News и моей практике):- Backup-серверы в общем домене AD. Скомпрометировали контроллер домена - Veeam-сервер в нагрузку.
- Общие учётные записи. Сервисная учётка Veeam с правами Domain Admin - не редкость, а норма во многих средах. Лично видел это в каждом втором аудите.
- Сетевой доступ без сегментации. Backup-сервер доступен из пользовательского VLAN - заходи кто хочешь.
- Хранилище на SMB/NFS-шарах. Если backup-репозиторий - просто сетевая шара, атакующий с правами администратора зашифрует его наравне с production-данными.
Детектирование recovery denial атак на DR-инфраструктуру
Обнаружить Recovery Denial можно и нужно до запуска шифрования. Вот конкретные точки, за которые стоит зацепиться.Sigma-правила для обнаружения уничтожения резервных копий
Базовое правило для детектирования удаления теневых копий:
YAML:
title: Shadow Copy Deletion via Vssadmin or WMIC
id: c947b146-0abc-4ef4-b0c7-3c2e80b2a2b3
status: stable
description: Detects shadow copy deletion commands commonly used by ransomware
logsource:
category: process_creation
product: windows
detection:
selection_vssadmin:
CommandLine|contains|all:
- 'vssadmin'
- 'delete'
- 'shadows'
selection_wmic:
CommandLine|contains|all:
- 'shadowcopy'
- 'delete'
selection_bcdedit:
CommandLine|contains|all:
- 'bcdedit'
- 'recoveryenabled'
- 'no'
condition: selection_vssadmin or selection_wmic or selection_bcdedit
level: critical
tags:
- attack.impact
- attack.t1490
YAML:
title: Backup Service Stop Detection
id: f3a2e891-45cd-4a1b-9c2f-8d7e6f5a4b3c
status: experimental
description: Detects stopping of backup-related services
logsource:
category: process_creation
product: windows
detection:
selection_cmd:
CommandLine|contains:
- 'Stop-Service'
- 'net stop'
- 'sc stop'
selection_target:
CommandLine|contains:
- 'veeam'
- 'backup'
- 'arcserve'
- 'acronis'
- 'commvault'
condition: selection_cmd and selection_target
level: high
tags:
- attack.impact
- attack.t1489Мониторинг аномалий в backup-задачах
Sigma-правила ловят конкретные команды. Но атакующий может действовать тоньше: не удалять бэкапы, а подкрутить retention policy, чтобы старые копии удалились «естественным» путём. Или сдвинуть расписание так, чтобы новые копии просто не создавались. Тихо, аккуратно, без единого алерта.Для Veeam-инфраструктуры я мониторю через Veeam ONE или PowerShell-скрипты:
Код:
# Аудит: проверяем, когда последний раз бэкап отработал успешно
# Если больше 48 часов - что-то не так
# Для Veeam v11/v12: запускать из Veeam PowerShell console
if (!(Get-PSSnapin -Name VeeamPSSnapIn -ErrorAction SilentlyContinue)) {
Add-PSSnapin VeeamPSSnapIn
}
$threshold = (Get-Date).AddHours(-48)
$jobs = Get-VBRJob
foreach ($job in $jobs) {
$lastSession = Get-VBRBackupSession | Where-Object {$_.JobId -eq $job.Id} |
Where-Object {$_.Result -eq "Success"} |
Sort-Object EndTime -Descending |
Select-Object -First 1
if ($lastSession.EndTime -lt $threshold -or $null -eq $lastSession) {
Write-Warning "ALERT: Job '$($job.Name)' has no successful backup in 48h"
# Отправка в SIEM/Telegram/Email - на ваш вкус
}
}
Код:
# Аудит: кто-то менял конфигурацию backup-заданий?
Get-WinEvent -LogName "Veeam Backup" |
Where-Object {$_.Id -in @(40000, 40001, 40100)} |
Select-Object TimeCreated, Message -First 20- Остановка backup-служб вне окна обслуживания
- Изменение retention policy на минимальные значения (классика - ставят 1 день)
- Удаление backup-заданий или репозиториев
- Массовые ошибки backup-сессий без очевидной причины
- Новые учётки с правами на backup-инфраструктуру, которых вчера не было
Практический hardening: immutable backup и DR безопасность инфраструктуры
Теория - ладно, перейдём к конкретным мерам. Я выстраиваю защиту backup-инфраструктуры в три эшелона.Immutable storage:
Ссылка скрыта от гостей
и Linux Hardened Repository
Immutable backup - копия, которую невозможно изменить или удалить в течение заданного периода, даже имея root-доступ к хранилищу. Единственная настоящая гарантия от Recovery Denial при полной компрометации инфраструктуры.Вариант 1: Linux Hardened Repository (Veeam)
Veeam начиная с v11 поддерживает Hardened Repository на Linux. Защита строится на комбинации immutable-атрибута (
chattr +i) и отсутствии постоянного привилегированного доступа к серверу:
Bash:
# На Linux-сервере, выделенном под backup-репозиторий
# 1. Создаём пользователя без постоянных sudo-прав
useradd -m -s /bin/bash veeamrepo
# 2. Временно даём sudo для первичной настройки (Veeam требует при добавлении)
echo "veeamrepo ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers.d/veeam
# 3. После добавления репозитория в Veeam - СРАЗУ убираем sudo
rm /etc/sudoers.d/veeam
# 4. Отключаем SSH для этого пользователя - ему туда больше не надо
echo "DenyUsers veeamrepo" >> /etc/ssh/sshd_config
systemctl restart sshdchattr +i) на файлы бэкапов. Атрибут защищает от удаления на уровне непривилегированного пользователя. Но root может снять его через chattr -i - поэтому реальная защита держится на отсутствии постоянного root/sudo доступа, отключении SSH root login и сетевой изоляции сервера.Вариант 2: MinIO с Object Lock
Для тех, кто использует S3-совместимое хранилище:
Bash:
# Создаём bucket с Object Lock
mc mb --with-lock myminio/immutable-backups
# Ставим retention policy - 30 дней в compliance mode
mc retention set --default compliance 30d myminio/immutable-backupsRBAC и изоляция учётных записей backup-инфраструктуры
Основной принцип: backup-инфраструктура не должна зависеть от Active Directory. Если AD скомпрометирован - backup должен продолжать работать. Точка.Что делать на практике:
- Veeam-сервер вне домена. Локальные учётки или отдельный trust-домен
- Dedicated service accounts с минимальными правами:
Код:
# Аудит: смотрим, от чего работают службы Veeam
$veeamServices = Get-WmiObject Win32_Service |
Where-Object {$_.DisplayName -like "*Veeam*"}
foreach ($svc in $veeamServices) {
Write-Output "Service: $($svc.DisplayName)"
Write-Output "Account: $($svc.StartName)"
Write-Output "---"
}
# Проверяем, не затесался ли svc_veeam в Domain Admins (спойлер: часто да)
Get-ADUser -Identity "svc_veeam" -Properties MemberOf |
Select-Object -ExpandProperty MemberOf- MFA для доступа к консоли Veeam. С Veeam v12 поддерживается нативно - грех не включить
- Сетевая сегментация: backup VLAN с whitelist-доступом только с management-станций
Стратегия 3-2-1-1-0 - расширенная защита от шифровальщиков
Классическая 3-2-1 эволюционировала. The Hacker News описывает стратегию 3-2-1-1-0, и лично я считаю её минимальным стандартом. Понять, зачем нужны бэкапы и как их правильно организовать, полезно до того, как выстраивать защиту от их уничтожения:| Компонент | Описание | Реализация |
|---|---|---|
| 3 копии | Три экземпляра данных | Production + local backup + remote |
| 2 типа носителей | Разные технологии хранения | Disk + Object Storage (или tape) |
| 1 offsite | Копия вне основной площадки | Cloud / удалённый ЦОД |
| 1 immutable или air-gapped | Копия, недоступная для модификации | S3 Object Lock / Linux Hardened Repo |
| 0 ошибок верификации | Автоматическая проверка восстановимости | Veeam SureBackup / автотесты |
Последний пункт - ноль ошибок - катастрофически недооценён. Я видел среды, где бэкапы создавались годами, но ни разу не проверялись на восстановление. В момент атаки выяснялось, что восстановиться невозможно - повреждённые каталоги, несовместимость версий, битые метаданные. Бэкап Шрёдингера: пока не попробуешь восстановить - он одновременно работает и нет.
Код:
# Автоматическая верификация через Veeam SureBackup
$sureJob = Get-VBRSureBackupJob -Name "Verify-Critical-Servers"
Start-VBRSureBackupJob -Job $sureJob
# Проверяем результат - если failed, летит алерт
$lastRun = Get-VBRSureBackupSession |
Where-Object {$_.JobName -eq "Verify-Critical-Servers"} |
Sort-Object EndTime -Descending | Select-Object -First 1
if ($lastRun.Result -ne "Success") {
Send-MailMessage -To "soc@company.com" -Subject "SureBackup FAILED" `
-Body "Verification failed: $($lastRun.Description)"
}Восстановление после ransomware атаки: пошаговый план
Когда Recovery Denial уже произошла и часть backup-инфраструктуры скомпрометирована - критичен порядок действий. Паника - враг номер два (после самого шифровальщика).Шаг 1. Изоляция backup-инфраструктуры.
Прежде чем проверять, что уцелело - изолируйте backup-серверы от сети. Атакующий может всё ещё сидеть внутри и добивать оставшиеся копии, пока вы оцениваете ущерб.
Bash:
# На Linux backup-сервере: немедленная изоляция
# Сначала сбрасываем ВСЕ соединения (включая возможные C2-каналы)
conntrack -F 2>/dev/null; ss -K dst 0/0 2>/dev/null
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Разрешаем только конкретный management IP (без ESTABLISHED,RELATED -
# чтобы не сохранять потенциальные reverse shell / C2-соединения)
iptables -A INPUT -s 10.0.100.5/32 -j ACCEPT
iptables -A OUTPUT -d 10.0.100.5/32 -j ACCEPTПроверяйте все эшелоны: immutable storage, tape, cloud-реплики, offsite. Начинайте с самых изолированных - они с наибольшей вероятностью не затронуты.
Шаг 3. Форензика backup-сервера.
Перед восстановлением нужно понять, как атакующий попал в backup-инфраструктуру. Восстановитесь через тот же скомпрометированный вектор - и через неделю всё повторится. Velociraptor или аналогичный инструмент для сбора артефактов:
YAML:
# Velociraptor: собираем следы компрометации Veeam
name: Custom.Windows.Veeam.ForensicTriage
sources:
- name: ConfigModifications
query: |
SELECT FullPath, Mtime, Size
FROM glob(globs="C:\\Program Files\\Veeam\\**\\*.config")
WHERE Mtime > timestamp(epoch=now() - 604800)
- name: AnomalousLogins
query: |
SELECT * FROM parse_evtx(
filename="C:\\Windows\\System32\\winevt\\Logs\\Security.evtx")
WHERE EventID IN (4624, 4625)
AND Computer LIKE "%veeam%"Никогда не восстанавливайте в ту же скомпрометированную инфраструктуру. Разверните минимальную чистую среду (можно в cloud), восстановите критичные системы, убедитесь в отсутствии persistence - и только потом мигрируйте обратно.
Шаг 5. Post-incident hardening.
По результатам расследования - закрыть конкретный вектор. Не абстрактные рекомендации «улучшить безопасность» (это ни о чём), а конкретные изменения: вынести Veeam из домена, включить immutability, перестроить сетевую сегментацию.
Чеклист hardening backup-инфраструктуры против ransomware
Этот чеклист я использую при аудите backup-инфраструктуры на purple team-сессиях. Каждый пункт закрывает конкретный вектор Recovery Denial:| Мера | Закрываемая техника | Приоритет |
|---|---|---|
| Immutable repository (S3 Object Lock / Hardened Linux Repo) | T1485, T1486 | Критичный |
| Veeam-сервер вне домена AD | Lateral movement через AD compromise | Критичный |
| Отдельные credentials для backup (не Domain Admin) | Credential reuse, T1078 | Критичный |
| Sigma-правила на vssadmin/wmic/bcdedit в SIEM | T1490 | Высокий |
| Мониторинг остановки backup-служб | T1489 | Высокий |
| MFA на консоль управления backup | T1078 | Высокий |
| Сетевая сегментация backup VLAN | Lateral movement | Высокий |
| SureBackup / автоматическая верификация | Silent backup corruption | Высокий |
| Air-gapped копия (tape / offline disk) | Полная компрометация сети | Средний |
| Регулярные DR-учения (tabletop + восстановление) | Все Recovery Denial TTP | Средний |
Заключение
Recovery Denial - не теоретическая угроза из отчётов, а стандартная фаза kill chain современных ransomware-операций. Группировки целенаправленно вкладываются в разведку и уничтожение backup-инфраструктуры, потому что это напрямую влияет на вероятность получения выкупа. Защита от программ-вымогателей требует понимания всей цепочки атаки - от первоначального проникновения до уничтожения возможностей восстановления.Защита резервных копий от ransomware требует архитектурного подхода: immutable storage, изоляция backup-инфраструктуры от основного домена, RBAC с минимальными привилегиями, непрерывный мониторинг и регулярная верификация восстановимости. Стратегия 3-2-1-1-0 - минимальный стандарт, ниже которого опускаться нельзя.
Если вы не проверяли устойчивость своей backup-инфраструктуры к Recovery Denial - возьмите чеклист выше и пройдитесь по нему. Прямо сегодня. Потому что ransomware-группировка, которая уже сидит в вашей сети (а median dwell time по M-Trends 2025 - 10 дней), проверит его за вас.
Последнее редактирование модератором:
