Клиент обратился не после взлома, а «для профилактики»: захотели независимый аудит инфраструктуры перед сезоном отчётности. Задача была рутинная — посмотреть на сеть, права доступа, патчи. Про бэкапы никто отдельно не спрашивал: они считались решённым вопросом. Задания стояли в расписании, диск с копиями подключался каждую ночь, в почту падали отчёты. На бумаге — всё в порядке.
Первое, что бросилось в глаза при осмотре сервера: NAS с резервными копиями стоит в той же серверной стойке, подключён к тому же коммутатору и виден в сети под тем же доменом, что и продакшн. Второе — в почтовом ящике администратора накопилось 47 писем с темой «Backup completed with warnings», ни одно не открыто. Третье — журнала тестовых восстановлений просто не существовало: копии никогда не поднимали, только создавали.
Что показала проверка
Попытка восстановить случайную базу 1С из последней ночной копии закончилась ошибкой контрольной суммы. Откатились на копию недельной давности — сработала, но с потерей индексов и половины движений за последние дни. Копии за два месяца до этого физически лежали на том же RAID-массиве, что и рабочие данные — просто в другой папке. Формально «резервная копия» существовала. Функционально — это была ещё одна копия того же файла, которая ломается вместе с оригиналом при любом серьёзном инциденте: пожаре, скачке напряжения, шифровальщике или банальном выходе из строя контроллера.
Чем это грозило в рублях
У клиента база 1С весом около 40 ГБ обслуживает closing месяца, зарплату и расчёты с полусотней контрагентов. Если бы в момент реальной аварии оказалось, что восстановить нечего, компания получила бы не абстрактный «риск», а конкретные цифры:
- простой бухгалтерии и логистики на 5–10 рабочих дней — упущенная выручка и штрафы контрагентам за срыв сроков;
- восстановление данных вручную по бумажным документам и выпискам банка — по опыту таких историй это 300–600 тысяч рублей услуг сторонних специалистов и переработок штата;
- если инцидент вызван шифровальщиком — требование выкупа, которое для базы такого объёма и профиля бизнеса обычно стартует от 1–3 млн рублей, при этом гарантии расшифровки никто не даёт;
- репутационные потери и штрафы, если утечка затронула персональные данные сотрудников или клиентов.
Как это эксплуатируется
Схема «бэкап рядом с продакшеном под одной учёткой» — это не абстрактный риск, а рабочий сценарий для любого шифровальщика или целенаправленной атаки. Показываем, как это разворачивается технически, чтобы было понятно, почему «копия лежит в соседней папке» — это фактически отсутствие копии.
Шаг 1. Разведка сети
Первое, что делает атакующий, получив любой плацдарм в сети (фишинговое письмо, скомпрометированный RDP, уязвимый VPN), — сканирует сегмент на наличие файловых шар и NAS:
nmap -p 139,445,3389,5985 --script smb-enum-shares,smb-os-discovery 10.0.0.0/24
Nmap scan report for 10.0.0.15
PORT STATE SERVICE
445/tcp open microsoft-ds
| smb-enum-shares:
| \\10.0.0.15\BACKUPS$
| Type: STYPE_DISKTREE
| Comment: Ежедневные копии 1С
| \\10.0.0.15\1C_BASE$
| Type: STYPE_DISKTREEУже на этом этапе видно главную проблему: шара с бэкапами и рабочая база 1С отвечают с одного IP, одного сервера, часто под одной учётной записью службы.
Шаг 2. Проверка доступа
Дальше проверяется, под какими правами доступна шара с копиями — часто там сидит та же служебная учётка, что и на проде, с избыточными правами записи/удаления:
crackmapexec smb 10.0.0.15 -u users.txt -p passwords.txt --shares
SMB 10.0.0.15 445 SRV-1C [+] DOMAIN\svc_backup:P@ssw0rd2019 (Pwn3d!)
SMB 10.0.0.15 445 SRV-1C [+] BACKUPS$ READ,WRITEУчётка сервиса резервного копирования почти всегда даёт полный доступ на запись — иначе задания не смогут писать новые копии. Именно эта учётка и становится точкой входа для уничтожения архивов.
Шаг 3. Проверка целостности «до»
Атакующему даже не нужно ничего ломать специально — часто копии уже нерабочие, что подтверждается стандартными средствами верификации:
7z t backup_1C_2024-06-14.7z
Testing archive: backup_1C_2024-06-14.7z
ERROR: CRC Failed : 1cv8.dt
Sub items Errors: 1Это ровно тот случай, который поймали у клиента: копия существует, занимает место на диске, регулярно перезаписывается — но при попытке распаковки или восстановления рассыпается.
Шаг 4. Уничтожение бэкапов перед шифрованием
Если атака доходит до стадии шифровальщика, первым делом убираются теневые копии и любые доступные по сети архивы — это стандартный шаг практически во всех современных семействах вымогателей:
vssadmin delete shadows /all /quiet
wmic shadowcopy delete
wbadmin delete catalog -quietА затем шифровальщик обходит все доступные сетевые шары, включая ту самую \\10.0.0.15\BACKUPS$, и шифрует или удаляет её содержимое вместе с продакшеном. Если бэкап физически находится в той же локальной сети без изоляции — он гибнет вместе с оригиналом за минуты.
Что и почему сработало бы дальше
Даже если компания не платит выкуп, а пытается восстановиться сама, сценарий предсказуем: администратор идёт к последней «рабочей» копии, обнаруживает ошибку CRC или несовпадение версии базы, откатывается на более старую — теряет данные за недели. Параллельно современные группировки практикуют double extortion: перед шифрованием данные выгружаются наружу (через rclone на облачное хранилище или обычный FTP), и даже при наличии рабочего бэкапа компания получает шантаж утечкой персональных данных сотрудников и контрагентов.
Ключевая причина, почему это работает раз за разом: резервное копирование настраивается один раз при внедрении и потом годами не тестируется. Предупреждения в логах игнорируются, потому что задание формально «завершилось», а на человеческую проверку результата никто не закладывает время.
Как закрыли
Решение не требовало новой инфраструктуры — только дисциплины и правильной архитектуры хранения.
- Физическая и сетевая изоляция копий. Резервное хранилище вынесли в отдельный VLAN без прямого доступа из пользовательской сети, доступ — только с сервера бэкапа по расписанию, входящие подключения к хранилищу с продакшн-сервера закрыты правилом firewall.
- Отдельная учётка с минимальными правами — сервис бэкапа пишет копии, но не может их читать или удалять после записи (write-once логика на уровне прав NTFS/ACL).
- Иммутабельность копий. Для облачной части подключили S3-совместимое хранилище с object lock:
Даже если атакующий получит учётку с полными правами, удалить или перезаписать копию раньше срока хранения физически невозможно.aws s3api put-object-lock-configuration \ --bucket backups-1c-prod \ --object-lock-configuration '{ "ObjectLockEnabled": "Enabled", "Rule": {"DefaultRetention": {"Mode": "COMPLIANCE","Days": 35}} }' - Регламент тестового восстановления. Раз в квартал — восстановление случайного файла и полное поднятие базы 1С на отдельном тестовом сервере, замер времени (RTO) и фиксация результата в журнале:
restic restore latest --target /restore_test --path "/1C_BASE" restic check --read-data - Мониторинг вместо игнорируемых писем. Настроили алерт в Telegram/почту не на «job completed», а на конкретные коды ошибок и отсутствие подтверждения успешной верификации архива, чтобы предупреждение физически нельзя было пропустить.
После внедрения регламента первый же тестовый прогон вскрыл ещё одну проблему — расписание архивации не совпадало с окном блокировки базы, из-за чего часть копий делалась «на живую» и содержала неконсистентные данные. Без квартальной проверки это всплыло бы только в момент реальной аварии — как и произошло бы изначально.