Шифровальщик и «бэкап», который лежал на том же NAS

Исходное состояние

Что было на площадке

В 06:12 склад не открыл накладные: шары \files01 давали .encrypted и readme. 1С на SQL ещё дышала — её диск шифровальщик не успел. Но выгрузки, сканы договоров и общие папки отделов — нет.

На NAS висели «бэкапы». Тот же SMB, та же учётка Domain Admins, без immutability и без второй копии вне площадки. Часть репозитория уже была переименована тем же процессом. Зелёный отчёт в почте за вчера ничего не стоил.

Рамки

Ограничения и задача

• Не платить выкуп и не экспериментировать с «декрипторами с форумов» на боевом томе.
• Бухгалтерия требовала закрытие периода через 36 часов.
• Интернет на площадке нельзя было просто вырубить: терминалы ТСД ходили в облачную WMS.
• Форензика «для суда» не заказывалась — нужна была рабочая инфраструктура, не экспертиза.

Факт

Результат

• Потеря данных: около трёх часов работы склада (окно между offsite-копией и атакой), не неделя.
• 1С не восстанавливали: SQL не затронут. Общие шары — с нового сервера к утру следующего дня.
• Схема 3-2-1 стала фактической, а не слайдом: локальная копия, независимый репозиторий, offsite с отдельным секретом.

Практика

Выводы

• Backup, доступный той же учёткой, которой работает админ на файловом сервере, — это не backup, а вторая жертва.
• Зелёный job status проверяет пайплайн программы, не пригодность копии после атаки.
• Забытый offsite rsync спас больше, чем «красивый» NAS в той же подсети.