Как мы восстановили бизнес клиента после атаки шифровальщика за 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 часов.

Шаг 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 или скрытых учёток. Вместо этого:

• Поднял новый чистый домен на сервере 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
}

Все пользователи получили временные пароли, обязательную смену при входе и SMS-уведомление с реквизитами через 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 миллионов в день минимум.

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