Восстановление после атаки шифровальщика: как мы спасли 50 серверов завода

Звонок от «ЗаводМеталл» поступил в 7:15 утра понедельника. Системный администратор обнаружил на рабочем столе Terminal Server файл Your_files_have_encrypted.html с требованием выкупа в биткоинах. За выходные злоумышленники зашифровали практически всю инфраструктуру.

Масштаб повреждений:

• 3 филиала, центральный офис и ДЦ — связаны через Cisco ASA 5505
• 3 гипервизора ESXi 7.x с vCenter — VM-образы зашифрованы
• Windows Server 2012R2 — все серверы AD, файловые, терминальные
• TrueNAS с бэкапами — пул ZFS уничтожен вместе со снапшотами
• Зашифровано: 4 ТБ сетевого хранилища, 10 баз 1С, 5 ТБ профилей RDP, 500 ГБ почты Exchange

Тип шифровальщика — Babuk (ChaCha20 encryption). Требование выкупа — 3 BTC (~$180K на тот момент).

Первые 2 часа — критические. Мы действовали по протоколу:

1. Изоляция сети — физически отключили uplink от интернет-провайдера и межфилиальные каналы
2. Инвентаризация — прошли по каждому серверу и рабочей станции, определяя масштаб шифрования
3. Сохранение улик — сняли образы RAM с работающих серверов и скопировали логи до их перезаписи
4. Блокировка учётных записей — сбросили пароли всех доменных и локальных администраторов

# Снятие образа RAM для форензики (Linux-сервер)
sudo apt install lime-forensics-dkms
sudo insmod /lib/modules/$(uname -r)/updates/dkms/lime.ko "path=/mnt/evidence/ram-dump.lime format=lime"

# Для Windows — используем WinPmem
winpmem_mini_x64.exe memdump.raw

# Копируем Windows Event Logs на внешний носитель
robocopy C:\Windows\System32\winevt\Logs E:\Evidence\EventLogs /MIR

# Копируем логи ESXi
scp root@esxi-host:/var/log/hostd.log /mnt/evidence/esxi/
scp root@esxi-host:/var/log/vobd.log /mnt/evidence/esxi/
scp root@esxi-host:/var/log/auth.log /mnt/evidence/esxi/

Важно: мы не перезагружали и не переустанавливали серверы до завершения сбора улик. Каждое действие документировали с таймстампами.

Анализ Windows Event Viewer на контроллере домена показал картину атаки:

# Поиск успешных входов RDP за последние 7 дней
# Event ID 4624, Logon Type 10 (RemoteInteractive)
Get-WinEvent -FilterHashtable @{
    LogName='Security'
    Id=4624
} | Where-Object {
    $_.Properties[8].Value -eq 10
} | Select-Object TimeCreated,
    @{N='User';E={$_.Properties[5].Value}},
    @{N='Source';E={$_.Properties[18].Value}} |
    Sort-Object TimeCreated

Хронология атаки:

1. Пятница 22:30 — успешный вход через RDP с внешнего IP (VPN из Нидерландов) под учётной записью доменного администратора
2. 22:35-22:45 — горизонтальное перемещение: атакующий зашёл на все серверы через RDP, используя те же креденшалы
3. 22:50 — запуск шифровальщика на каждом сервере вручную (не через GPO или PsExec — признак скрипткиддиса)
4. 23:00 — шифрование файловых серверов и NAS
5. 23:15 — атака на ESXi через vCenter (использовали тот же пароль администратора)
6. 23:30 — уничтожение пула ZFS на TrueNAS

Вектор атаки: RDP-порт (3389) был проброшен напрямую в интернет через NAT на Cisco ASA. Пароль доменного администратора — Company2024! — был подобран брутфорсом. Логи показали 47 000 неуспешных попыток входа за предыдущий месяц.

Анализ трафика у провайдера не выявил массового вывода данных — атакующие не крали файлы, только шифровали. Это характерно для RaaS (Ransomware-as-a-Service) — автоматизированная атака без ручного анализа инфраструктуры.

Руководство «ЗаводМеталл» спросило: «Может, проще заплатить?». Наша позиция — не платить, и вот почему:

• Нет гарантии расшифровки: по статистике CISA, 20% жертв, заплативших выкуп, не получают ключ дешифрования
• Babuk с утёкшим билдером: исходники Babuk утекли в 2021, шифровальщик собран из публичного билдера — у оператора может просто не быть ключа
• Финансирование криминала: оплата мотивирует повторные атаки
• Повторная атака: 80% заплативших подвергаются повторной атаке в течение года

Вместо оплаты мы сфокусировались на восстановлении из доступных источников.

Несмотря на то что ZFS-пул был уничтожен, мы попробовали восстановить данные инструментами low-level recovery:

# Попытка импорта разрушенного ZFS-пула
zpool import -f -D tank
# Ошибка: cannot import 'tank': no such pool available

# Поиск остатков пула на дисках
zdb -l /dev/sda
# Нашли vdev labels, но пул повреждён

Коммерческие инструменты дали результат:

1. UFS Explorer — не обнаружил ZFS-структуры
2. Reclaime — нашёл zpool.cache, позволивший частично собрать пул
3. Klennet ZFS Recovery — обнаружил 1.6 млн файлов в различных ZFS-транзакциях

Удалось восстановить:

• 9 ТБ пользовательских профилей — 100%
• Сетевые файловые ресурсы — 100%
• Бэкапы Veeam — частично (часть повреждена)

Восстановление базы 1С (130 ГБ):

# Извлечение из повреждённого бэкапа Veeam дало ошибку:
# "LZ4 block decompression error"

# После получения исправленных DLL от техподдержки Veeam
# база была извлечена, но SQL Server показал повреждения:
DBCC CHECKDB('1c_main') WITH NO_INFOMSGS;
-- Msg 8928: Object 'dbo.v8_1CV8LOG': index errors found

# Поэтапное восстановление:
ALTER DATABASE [1c_main] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DBCC CHECKDB('1c_main') WITH REPAIR_REBUILD;
-- Если не помогло:
DBCC CHECKDB('1c_main') WITH REPAIR_ALLOW_DATA_LOSS;
ALTER DATABASE [1c_main] SET MULTI_USER;

# Экспорт конфигурации 1С и пересоздание базы
# Конфигуратор 1С → Администрирование → Выгрузить информационную базу

База стала рабочей. Потеряли данные за последние 2 дня (пятницу и субботу), которые бухгалтерия восстановила вручную.

Параллельно с восстановлением данных мы пересобирали инфраструктуру с нуля — использовать скомпрометированные системы нельзя:

# 1. Новый ESXi 8.0 на каждый гипервизор — чистая установка с USB
# 2. Новый Active Directory — старый домен считаем скомпрометированным

# Установка нового DC на Windows Server 2022
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
Install-ADDSForest -DomainName "zavod.local" \
  -SafeModeAdministratorPassword (Read-Host -AsSecureString)

# 3. Новый TrueNAS Scale с правильной схемой бэкапов
# ZFS pool с зеркалированием:
zpool create -f backup mirror /dev/sda /dev/sdb
zfs create backup/veeam
zfs create backup/fileserver
zfs set compression=lz4 backup
zfs set atime=off backup

# Автоматические снапшоты каждые 4 часа, хранение 30 дней
zfs set com.sun:auto-snapshot=true backup
# Через zfs-auto-snapshot:
apt install zfs-auto-snapshot
# Создаёт снапшоты: frequent (15 мин, 4 шт), hourly (24 шт),
# daily (31 шт), weekly (8 шт), monthly (12 шт)

Сроки восстановления: полная инфраструктура была восстановлена за 5 рабочих дней. Первый день — сеть и AD, второй — серверы приложений, третий-четвёртый — данные и 1С, пятый — тестирование и переключение пользователей.

После восстановления мы внедрили комплекс мер, чтобы атака не повторилась:

1. Замена Cisco ASA на OPNsense с IDS/IPS:

# OPNsense с Suricata IDS
# Правило блокировки RDP-брутфорса:
alert tcp $EXTERNAL_NET any -> $HOME_NET 3389 (
  msg:"ET SCAN RDP Brute Force Attempt";
  flow:to_server,established;
  threshold: type both, track by_src, count 5, seconds 60;
  sid:2024001; rev:1;
)

2. VPN вместо проброса портов:

# WireGuard VPN для удалённого доступа
# /etc/wireguard/wg0.conf (сервер)
[Interface]
Address = 10.10.0.1/24
ListenPort = 51820
PrivateKey = 

# Доступ к RDP только через VPN-туннель
[Peer]
PublicKey = 
AllowedIPs = 10.10.0.2/32

3. Парольная политика и MFA:

# PowerShell: политика паролей в AD
Set-ADDefaultDomainPasswordPolicy -Identity zavod.local \
  -MinPasswordLength 14 \
  -PasswordHistoryCount 24 \
  -LockoutThreshold 5 \
  -LockoutDuration 00:30:00 \
  -ComplexityEnabled $true

# Duo MFA для RDP через NPS
# Установка Duo Authentication Proxy → интеграция с NPS → 
# RD Gateway требует 2FA для всех подключений

4. Схема бэкапов 3-2-1:

• 3 копии: рабочие данные + локальный бэкап на TrueNAS + офлайн-копия
• 2 типа носителей: SSD (рабочие) + HDD (бэкапы)
• 1 офлайн-копия: внешний HDD подключается через умную розетку Sonoff только во время еженедельного бэкапа (воскресенье 3:00, отключение в 6:00)

# Скрипт управления офлайн-бэкапом
#!/bin/bash
# Включаем умную розетку (HDD подключится к серверу)
curl -s "http://10.0.0.50/cm?cmnd=Power%20On"
sleep 30  # ждём инициализации диска

# Монтируем и копируем
mount /dev/sdc1 /mnt/offline-backup
rsync -avz --delete /backup/veeam/ /mnt/offline-backup/veeam/
umount /mnt/offline-backup

# Отключаем розетку
curl -s "http://10.0.0.50/cm?cmnd=Power%20Off"
echo "$(date): offline backup completed" >> /var/log/offline-backup.log

Ключевые уроки из инцидента «ЗаводМеталл»:

1. Никогда не пробрасывайте RDP в интернет. Только через VPN с MFA. Это вектор #1 для ransomware
2. Единый пароль администратора на все системы — главная ошибка. LAPS (Local Administrator Password Solution) решает проблему для Windows, Vault — для серверов Linux
3. Бэкапы на том же сервере — не бэкапы. Шифровальщик уничтожил TrueNAS, потому что он был в той же сети с теми же креденшалами
4. Windows Server 2012R2 без поддержки — дыра в безопасности. Обновляйте ОС
5. Не паникуйте и не платите. Методичное восстановление из любых доступных источников эффективнее

Мы разработали для «ЗаводМеталл» план Disaster Recovery с целевыми показателями:

• RPO (допустимая потеря данных) — 4 часа (снапшоты каждые 4 часа)
• RTO (время восстановления) — 8 часов (вместо 5 дней как в первый раз)
• Ежеквартальные учения DR — восстановление из бэкапов на тестовом стенде

Стоимость инцидента для «ЗаводМеталл»: 5 дней простоя производства, наша работа по восстановлению, лицензии на инструменты ZFS-recovery, новое оборудование OPNsense — итого около 1.2 млн рублей. Выкуп стоил бы 13 млн, и без гарантии расшифровки. Если вам нужен аудит безопасности или план DR — обращайтесь в ITFresh, мы проведём проверку до того, как случится инцидент.