Как мы восстановили бизнес клиента после атаки шифровальщика за 18 часов

Пятница, 23:14. У клиента упала 1С, на файловом сервере появились файлы с расширением .babuk и записка: 4.2 BTC или прощай данные. К субботнему вечеру компания уже принимала заказы. Рассказываю поэтапно — что именно мы делали, что сработало, что нет, и где нам просто повезло.

Я Евгений Сергеевич Семёнов, руковожу ITfresh. С 2010 года — IT-аутсорсинг для компаний до 50 рабочих мест в Москве. За 15 лет практики через мои руки прошло около двадцати инцидентов с шифровальщиками. Этот — самый показательный за последние два года. Поэтому разобрал его во всех деталях.

Клиент и инфраструктура

Заказчик — оптовик, продаёт стройматериалы по Москве и области. 35 рабочих мест в офисе на Складочной, ещё 12 удалёнщиков на торговых точках. Серверный парк на момент атаки выглядел так:

• HV-01 — Hyper-V на Windows Server 2019, 256 GB RAM, два массива RAID10. Пять виртуалок: контроллер домена, файловый сервер, сервер 1С, MSSQL, RDS-ферма.
• NAS-01 — Synology RS3621xs+ на 96 ТБ, промежуточное хранилище для бэкапов Veeam.
• BACKUP-LTO — внешний LTO-8 с ротацией картриджей. Последний цикл — два месяца назад. Ленты лежали в сейфе у директора в кабинете.
• Mikrotik CCR2004 в роли маршрутизатора, фаервол по портам, VPN L2TP/IPSec для удалёнщиков.

Сразу скажу: до инцидента этот клиент у нас не обслуживался. Технический директор позвонил по рекомендации в 23:38 — через 24 минуты после начала атаки.

Как разворачивались события

Хронология — восстановлена позже из логов Windows и Mikrotik:

• 17:42 — сотрудник склада Мария И. открыла вложение в письме, замаскированном под акт сверки от контрагента. Файл назывался Акт_сверки_03.2026.pdf.exe. Дроппер.
• 17:43–22:30 — пять часов тишины. Дроппер не шумел: просто прописал persistence через HKCU\Software\Microsoft\Windows\CurrentVersion\Run и запланированную задачу. За это время атакующие через C2-канал изучили сеть, выгребли хеши локальных аккаунтов через mimikatz, подобрали пароль к сервисной учётке svc_backup — а она, по классической ошибке, имела права доменадмина.
• 22:30 — через psexec под учёткой svc_backup на все машины домена развернули полезную нагрузку. Babuk — семейство не новое, но с обновлённым крипто-стэком.
• 23:00–23:14 — параллельное шифрование. За 14 минут зашифровано около 4.7 ТБ: файловый сервер, базы 1С и MSSQL, все рабочие станции, которые не выключили на ночь.
• 23:14 — оператор не открыл номенклатуру в 1С, увидел на рабочем столе How_To_Restore_Your_Files.txt, позвонил техдиру.

Первые 30 минут: остановить кровь

Когда подключился по защищённому каналу — через свой резервный VPN, не клиентский, на скомпрометированный лезть нельзя — первым делом я не стал ничего восстанавливать. Это классическая ошибка инхаус-команды: сразу тянуть из бэкапов. Сначала — изоляция.

Алгоритм первого получаса:

1. На Mikrotik заблокировал весь трафик внутренних подсетей в интернет, кроме адреса моего ноутбука. Команда (упрощённо):

   /ip firewall filter
   add chain=forward action=drop src-address=192.168.10.0/24 \
     comment="EMERGENCY: ransomware containment"
   add chain=forward action=accept src-address=192.168.10.5 \
     comment="Admin laptop allowed"

2. На Hyper-V остановил все виртуальные машины через Stop-VM -Force — чтобы шифровальщик не продолжал работу, если ещё не закончил.
3. Физически выдернул патч-корд из Synology, не отправляя в shutdown: ОС была нужна для форензик-анализа.
4. Контроллер домена был отключён — загрузил его в Safe Mode, сменил пароли всех сервисных аккаунтов, отключил svc_backup, занулил krbtgt дважды. Это сбрасывает Kerberos golden tickets, если атакующие успели их выпустить.

Шаг с krbtgt в малом бизнесе пропускают почти всегда. Зря. Атакующий с правами доменадмина в 60% случаев первым делом крадёт хеш krbtgt — и потом может возвращаться в сеть даже после смены всех пользовательских паролей.

Идентификация штамма

Параллельно залил образец зашифрованного файла и записку на id-ransomware.malwarehunterteam.com. Результат: Babuk, версия 2024 года, модифицированный ChaCha20. Публичного декриптора нет — проверил No More Ransom, базу Emsisoft, запросил знакомых из CERT.

Платить выкуп — не вариант. Идём в бэкапы.

Аудит бэкапов: главный момент истины

Вот ради чего и стоит читать этот кейс. Схема 3-2-1 у клиента была — формально. По факту:

• Veeam Backup & Replication крутился внутри того же домена, под доменной учёткой с правами доменадмина. Репозиторий — Synology по SMB. Атакующие зашифровали и его. Все бэкапы за 30 дней — уничтожены.
• Снапшоты Synology — настроены, retention 7 дней. Но злоумышленники не добрались до web-интерфейса DSM — пароля у них не было. Снапшоты уцелели. Это нас и спасло.
• LTO-картриджи — последний полный бэкап от 17 февраля 2026 года, два месяца назад. Единственный по-настоящему иммутабельный носитель.

Решение: восстанавливаемся из снапшотов Synology плюс инкрементная сборка по LTO и журналы транзакций MSSQL.

Восстановление: пошагово

Шаг 1. Чистая среда

На скомпрометированный гипервизор данные не восстанавливают. В кладовке у клиента пылился старый DL360 Gen9 — поставил на него свежий Windows Server 2022: новая парольная политика, MFA через RD Gateway, SMBv1 отключён, белый список приложений через AppLocker.

Шаг 2. Восстановление файлового сервера

Зашёл на Synology по SSH, убедился, что снапшоты Btrfs живые:

ssh admin@192.168.10.250
sudo btrfs subvolume list /volume1/files | grep -i snap
sudo btrfs subvolume snapshot -r \
  /volume1/@syno_snapshot/files/GMT+03-2026.04.17-04.00.01 \
  /volume1/files_restore_safe

Снапшот за 04:00 пятницы оказался чистым — атака началась позже. Перегнал данные через rsync на новый файловый сервер на DL360. 4.7 ТБ по 10G-линку — примерно 380 МБ/с. Передача заняла чуть больше трёх часов.

Шаг 3. Восстановление 1С и MSSQL

Базы 1С жили на MSSQL Server 2019. Актуальные mdf/ldf зашифрованы. В снапшоте за 04:00 есть копия mdf-файла, но без транзакционного журнала за рабочий день.

Выручил log shipping, который у клиента был настроен с интервалом 15 минут на отдельную виртуалку — она жила на NAS-01, но в своём LXC-контейнере с отдельной учёткой. До неё атакующие не добрались.

Восстановил БД с применением журналов до 17:35 пятницы — то есть чуть раньше момента, когда дроппер начал активность, чтобы не притащить его изменения:

RESTORE DATABASE [unf]
FROM DISK = N'D:\restore\unf_full_20260417_0400.bak'
WITH NORECOVERY, REPLACE;

RESTORE LOG [unf]
FROM DISK = N'D:\restore\unf_log_20260417_1730.trn'
WITH STOPAT = '2026-04-17T17:35:00', RECOVERY;

DBCC CHECKDB ([unf]) WITH NO_INFOMSGS;

CHECKDB прошёл без ошибок. Потеря данных — около 6 часов: с 17:35 пятницы до момента детекции. По счастью, вечер — активных операций почти не было, кроме одной отгрузки на складе. Около 40 строк документов реализации восстановили вручную по бумажным накладным к понедельнику.

Шаг 4. Active Directory

Контроллер домена был зашифрован. Восстанавливать его из бэкапа я не стал: слишком велик риск, что атакующие оставили persistence — модифицированные GPO или скрытые учётки. Поступил иначе:

• Поднял чистый домен с нуля на Server 2022.
• Из старого NTDS.dit (вытащил его из снапшота NAS) выгрузил список пользователей и групп, импортировал через PowerShell:

# Экспорт со старого NTDS.dit через ntdsutil offline:
# ntdsutil "ac in ntds" "ifm" "create full c:\ifm" q q

# Импорт списка пользователей в новый домен:
Import-Csv users.csv | ForEach-Object {
    New-ADUser -Name $_.Name -SamAccountName $_.SAM `
      -UserPrincipalName "$($_.SAM)@itf-client.local" `
      -AccountPassword (ConvertTo-SecureString "TempP@ss2026!" -AsPlainText -Force) `
      -ChangePasswordAtLogon $true -Enabled $true
}

Все пользователи получили временные пароли с обязательной сменой при первом входе. Реквизиты разослал через Telegram-бота — он у меня специально заготовлен для таких случаев.

Шаг 5. Рабочие станции

33 машины из 35 — скомпрометированы. Восстанавливать по одной и долго, и опасно: спящие импланты можно не заметить. Ночью запустил PXE-развёртывание. Образ Windows 11 с Sysprep — уже с агентом Wazuh и ESET на борту — разлился на все станции к утру субботы. Пользовательские профили подтянулись с файлового сервера через Folder Redirection, настроенное ещё до инцидента.

Тайминг по факту

Что сделано после: профилактика

За три недели после инцидента мы полностью перестроили защиту. Ключевые изменения:

• Иммутабельный репозиторий Veeam. Отдельный Linux-сервер с Hardened Repository, доступ только через xinetd на специальный порт, авторизация исключительно по ключу. Файлы закрываются immutable-флагом на 14 дней.
• Wazuh SIEM. Агент развернули на всех серверах и рабочих станциях. Правило: больше 100 изменений файлов в минуту — алерт плюс автоблокировка пользовательской сессии. Сам сервер Wazuh — на отдельной виртуалке вне домена.
• MFA через Microsoft Authenticator на VPN, RDP-Gateway и все административные входы.
• Тейринг администраторов по модели Microsoft: Tier 0 (доменадмины) — только с выделенных терминалов, Tier 1 (серверы), Tier 2 (рабочие станции).
• Запрет SMBv1, отключение PowerShell v2, ASR-правила Defender через GPO.
• Изолированная сеть для бэкапов — отдельный VLAN, видит только резервный сервер и хранилища.
• Ежеквартальный SureBackup-прогон — автоматический скрипт восстанавливает виртуалки в изолированную лабораторию и проверяет загружаемость.

Главные выводы для собственника бизнеса

Если дочитали до этого места, уже понятно: дело не в шифровальщике. Шифровальщик — это симптом. Корневые причины этой атаки:

1. Слабый пароль у сервисной учётки с правами доменадмина — и вообще такой учётке эти права не нужны.
2. Резервный сервер сидел в том же домене, что и продакшн.
3. MFA не было нигде, кроме интернет-банка.
4. Сотрудники ни разу не проходили обучение по распознаванию фишинга.
5. Последний LTO-бэкап — двухмесячной давности. RPO в 60 дней для торговой компании — это катастрофа.

Что это стоило в деньгах: потерянные 6 часов данных восстановили вручную, прямого простоя бизнеса не было — атака пришла в нерабочее время. Мой счёт за работу составил 280 тыс. рублей, оборудование и лицензии — ещё 540 тыс. Случись та же история в среду в 11 утра — простой обошёлся бы клиенту в 4-5 миллионов в день как минимум.

Часто задаваемые вопросы