Раз в квартал я прихожу к клиентам с одним и тем же вопросом: «Давайте прямо сейчас восстановим бэкап». Не отчёт о бэкапе открою, не галочку в консоли проверю — а реально возьму файл резервной копии и попробую его развернуть. В среднем половина компаний в этот момент понимает, что резервное копирование у них существует только на бумаге.
Конкретный случай: малый бизнес, файловый сервер плюс база 1С на выделенной машине. Резервное копирование настроено, задачи в планировщике зелёные, письма об успешном завершении приходят каждую ночь. Формально — всё в порядке. По факту — при попытке восстановить случайную копию базы процесс завис на 40 минутах вместо заявленных «максимум часа», а один из архивов файлового сервера оказался повреждён и не распаковывался вовсе.
Что нашли при проверке
- Резервные копии базы 1С делались штатным средством, но никто не проверял целостность архива — часть .dt-файлов была битой из-за обрыва соединения при копировании через сеть.
- Бэкап файлового сервера лежал в соседней папке на том же RAID-массиве, что и рабочие данные — при отказе диска или шифровальщике теряется всё одновременно.
- Реальное время восстановления базы — около суток, а не часа: копия хранилась на медленном сетевом накопителе, а процесс восстановления никто не хронометрировал раньше.
- Учётная запись службы бэкапа имела права локального администратора на всех серверах — удобно для настройки, фатально при компрометации.
Чем это грозило в рублях
При остановке 1С на сутки типичный малый бизнес теряет от 150 000 до 500 000 рублей выручки и оплаты труда простаивающих сотрудников — в зависимости от оборота. Если бы дошло до шифровальщика (а с учётом прав службы бэкапа и совместного хранения копий это было бы почти гарантированно), сценарий выглядел бы так: рабочие данные зашифрованы, «резервные» копии на том же массиве зашифрованы вместе с ними, восстанавливать нечего. Дальше — либо оплата выкупа (в среднем по рынку 300 000–2 000 000 рублей для компаний такого масштаба), либо восстановление вручную из разрозненных источников на протяжении недель, что дороже выкупа в разы за счёт упущенной выручки, штрафов контрагентам за просрочку и репутационных потерь.
Как это эксплуатируется
С точки зрения атакующего резервные копии — не защита, а ещё одна цель. Классическая цепочка при атаке шифровальщиком включает поиск и уничтожение бэкапов до момента шифрования продакшена — иначе жертва просто восстановится и не заплатит.
-
Разведка сети. После получения первичного доступа (фишинг, слабый RDP, брутфорс) атакующий сканирует внутреннюю сеть на предмет файловых шар и бэкап-серверов:
nmap -p 445,139,3389,5985 --open -sV 192.168.0.0/24 Nmap scan report for 192.168.0.15 PORT STATE SERVICE VERSION 445/tcp open microsoft-ds Windows Server 2012 R2 microsoft-ds 139/tcp open netbios-ssn -
Поиск шар с бэкапами. Скрипт smb-enum-shares показывает открытые ресурсы без аутентификации или с дефолтными паролями:
Права на чтение и запись анонимному пользователю на шаре с бэкапами — практически подарок: злоумышленник может как скачать копию для последующего изучения структуры базы, так и удалить её.nmap --script smb-enum-shares -p445 192.168.0.15 Host script results: | smb-enum-shares: | \\192.168.0.15\Backup$: | Anonymous access: READ/WRITE | \\192.168.0.15\1C_Backup: | Anonymous access: READ -
Подключение и разведка содержимого.
smbclient //192.168.0.15/1C_Backup -N smb: \> ls base_2024_01_15.dt A 4823910284 Mon Jan 15 03:12:00 2024 base_2024_01_16.dt A 4823910284 Tue Jan 16 03:11:00 2024 smb: \> get base_2024_01_16.dt -
Уничтожение точек восстановления перед шифрованием. Это стандартный шаг почти в любом современном ransomware-плейбуке (Conti, LockBit, Akira и их аналоги используют схожие команды):
Если у службы, из-под которой работает вредоносный процесс, есть права локального администратора (как в описанном кейсе — у сервисной учётки бэкапа), эти команды выполняются без проблем.vssadmin delete shadows /all /quiet wmic shadowcopy delete wbadmin delete catalog -quiet -
Если бэкап-хранилище защищено паролем NAS/учётной записи, а не сегментировано сетевым доступом — в ход идёт перебор:
hydra -l admin -P rockyou.txt smb://192.168.0.15 hashcat -m 1000 ntlm_hash.txt rockyou.txt - Шифрование или удаление найденных архивов — финальный шаг. После этого у жертвы физически не остаётся откуда восстанавливаться, что резко повышает вероятность выплаты выкупа.
Полутехнические пруфы, на которые стоит смотреть
- Открытый порт 445 наружу или доступный без сегментации внутри сети — классический вектор для WannaCry-подобных и современных SMB-эксплойтов.
- Общие пароли на NAS/бэкап-сервере, не отличающиеся от заводских (admin/admin, admin/12345) — проверяются перебором за секунды.
- Служебная учётная запись бэкапа с правами Domain Admin или локального администратора на всех узлах — при компрометации любого сервера злоумышленник получает контроль над бэкапами.
- Отсутствие версионирования и WORM/immutable-флагов на хранилище — теневые копии и снапшоты удаляются одной командой.
- В логах событий Windows признак атаки — массовые события 524 (VSS) и 4688 с процессом vssadmin.exe или wmic.exe, запущенным нетипичным для сервера пользователем.
Что и почему сработало бы
Если бы описанная инфраструктура попала под реальную атаку, цепочка развивалась бы предсказуемо: первичный доступ через слабый RDP или фишинг → повышение привилегий за счёт сервисной учётки с админ-правами → латеральное перемещение на бэкап-сервер → удаление теневых копий и снапшотов → шифрование рабочих данных и одновременно найденных резервных копий → требование выкупа с угрозой публикации данных (двойное вымогательство). Ключевая причина успеха такой атаки — не отсутствие бэкапа как файла, а отсутствие изоляции бэкапа от продакшена и избыточные права сервисных аккаунтов. Именно эти два фактора превращают резервное копирование из страховки в дополнительную точку отказа.
Как закрыть
- Внедрить правило 3-2-1: минимум 3 копии данных, на 2 разных носителях, 1 копия — офлайн или в изолированном облаке без постоянного сетевого доступа.
- Изолировать бэкап-хранилище от рабочей сети отдельным VLAN и правилами firewall, разрешающими только исходящее соединение от сервера бэкапа, но не входящее с рабочих станций:
# пример правила на Linux-бэкап-сервере (iptables) iptables -A INPUT -p tcp --dport 445 -s 192.168.0.0/24 -j DROP iptables -A INPUT -p tcp --dport 22 -s 192.168.10.5 -j ACCEPT - Убрать избыточные права у сервисной учётки резервного копирования — только права на конкретные каталоги и базы, без Domain Admin и без входа в интерактивную сессию.
- Включить immutable/WORM-хранение там, где это поддерживается (S3 Object Lock, Veeam Immutability, ZFS snapshot с blockonce), чтобы удалить копию не могла даже скомпрометированная учётка администратора.
- Автоматизировать тестовое восстановление вместо ручной квартальной проверки — по крону поднимать копию базы в изолированном контейнере и проверять целостность:
Результат — код возврата и лог — автоматически пишется в журнал с таймстампом, а не проверяется «на глаз» раз в квартал.# пример проверки консистентности архива restic restic check --read-data-subset=10% # для 1С - разворачивание .dt во временную информационную базу 1cv8 CREATEINFOBASE File="C:\test_restore" /RestoreDT "base_2024_01_16.dt" - Зафиксировать регламент письменно: раз в квартал — восстановление случайного файла и одной базы целиком с замером времени и фиксацией результата в журнале. Это единственный способ узнать реальное RTO (время восстановления), а не то, что написано в документации на бумаге.
Стоимость такого регламента — несколько часов работы инженера в квартал. Стоимость его отсутствия — от сотен тысяч до нескольких миллионов рублей в случае реальной аварии или атаки, когда выясняется, что бэкап был, а восстановить из него было нечего.