RANSOMWARE ДАВНО ПЕРЕСТАЛ БЫТЬ ИСКЛЮЧИТЕЛЬНО ТЕХНИЧЕСКОЙ ПРОБЛЕМОЙ. ДЛЯ БИЗНЕСА ЭТО РИСК ПРОСТОЯ, ПРЯМЫХ ФИНАНСОВЫХ ПОТЕРЬ И УПРАВЛЕНЧЕСКИХ РЕШЕНИЙ ПОД ДАВЛЕНИЕМ ВРЕМЕНИ.
Почему ransomware в 2025 - это кризис управления. Реальный кейс взлома критической инфраструктуры
1. Вступление
Ransomware давно перестал быть исключительно технической проблемой. Для бизнеса это риск простоя, прямых финансовых потерь и управленческих решений под давлением времени.
По нашему опыту, большинство успешных атак 2024–2025 годов — это не случайность, а результат цепочки недооценённых рисков: периметра, мониторинга, резервного копирования и готовности к инцидентам.
В этом лонгриде команда RTEAM разбирает реальный кейс взлома критической инфраструктуры и объясняет, почему даже зрелые организации оказываются не готовы к таким сценариям.
2. Ransomware сейчас
Ransomware — это не «программа-шифровальщик», а целевая операция, которая обычно развивается в три этапа:
Проникновение в инфраструктуру.
Захват контроля: учётные записи, привилегии, перемещение по сети.
Шифрование и вымогательство, часто с параллельной кражей данных.
Снаружи всё выглядит просто — «зашифровали и попросили деньги». На практике почти всегда есть разведка, подготовка и работа по инфраструктуре как по карте.
Опасность ransomware заключается не только в шифровании:
Давление временем. Чем дороже простой, тем выше риск принять плохое решение.
Целевой подход. Атакуют тех, где ущерб и выкуп максимальны.
Отсутствие «плана Б». Всё чаще атаки направлены на бэкапы, виртуализацию и AD.
По нашим наблюдениям за инцидентами 2024–2025 годов:
количество ransomware-инцидентов выросло примерно на 30%+,
более половины компаний в итоге платят выкуп,
около половины атак приходятся на критическую инфраструктуру,
средний размер выкупа достигает $1 млн.
Даже оплата не даёт гарантий: ключ может не сработать, данные могут утечь, а компания часто становится повторной целью.
В зоне повышенного риска — критическая инфраструктура, где простой дороже любых формальных мер безопасности: производство, здравоохранение, энергетика, финансы и транспорт.
3. Реальный кейс: как мы расследовали взлом критической инфраструктуры
Теория и статистика важны, но реальную картину ransomware-атак показывает только практика. Ниже — кейс из расследования, которое команда RTEAM проводила по инциденту в критической инфраструктуре.
Все системы отключены от электропитания для предотвращения распространения
Полностью парализована работа всех критических сервисов и бизнес-процессов
Хост не находился на мониторинге ни в каком SOC
Для анализа были предоставлены:
Логи NGFW (сетевого межсетевого экрана)
Артефакты с единственного скомпрометированного и незашифрованного хоста
Схемы сетевой архитектуры и список опубликованных NAT-ресурсов
Первые гипотезы и противоречия
На начальном этапе анализа у нас были две основные версии:
Гипотеза 1: Компрометация веб-сервера компании через известную уязвимость
Гипотеза 2: Утечка креденшалов одного из VPN-пользователей с последующим использованием для входа в систему
Однако при анализе артефактов картина стала ясна достаточно быстро.
Неожиданные находки в логах
В логах NGFW мы обнаружили прямые сетевые взаимодействия из интернета с одним из серверов инфраструктуры. Это было странно, потому что:
Клиент утверждал, что этот хост никогда не был опубликован в интернет
Хост отсутствовал в списке опубликованных ресурсов
На схеме сети он находился глубоко в инфраструктуре, якобы защищённый внутренними слоями
В логах Windows мы также увидели успешные аутентификации с внешнего IP-адреса через административные порты (RDP).
Вывод: хост был доступен из интернета, хотя клиент этого не знал.
4. Углубленный анализ: полная картина атаки
Когда мы начали копать глубже, стало понятно, что это была скоординированная, многоэтапная атака, подготовленная под конкретную инфраструктуру.
Этап 1: Точка входа RDP (T1110.001 Bruteforce: Password Guessing)
Предоставленные логи не охватывали события до момента получения удаленного доступа по RDP, исходя из того что пароль локальной учетной записи администратора (Administrator) был словарным (Password123) предполагаемый способ получения доступа был перебор пароля внешнего сервиса.
Этап 2: Компрометация критического хоста (T1021.001 RDP)
Злоумышленник тем самым получил прямой доступ к серверу Veeam Backup & Replication под учётной записью локального администратора с полными привилегиями (Privelege Escalation TA0004).
Veeam — это решение для резервного копирования и disaster recovery, которое используется в большинстве корпоративных инфраструктур. Для админа это мощный инструмент, но для злоумышленника — золотая жила, так как этот сервер имеет:
Полный доступ ко всей виртуальной инфраструктуре
Креденшалы для доступа к vCenter (управление всеми VM)
Доступ ко всем хранилищам с резервными копиями
Часто — доменные привилегированные учётные записи
Этап 3: Разведка и подготовка (TA0007 Discovery)
Проверка сетевой доступности и сервисов Windows/SMB, тестирование портов:
Проверка доступности внешнего S3-ресурса (возможный канал доставки полезной нагрузки)
certutil -url https://s3.akz.redacted.io
Подготовка инструментов для NFS и сетевых тестов (iPerf)
Install-WindowsFeature NFS-Client, RSAT-NFS-Admin
Сбор сведений о шарах и правах доступа. запуск PowerShell из процесса Veeam.Backup.Manager.exe.Разведка SAN/FC/iSCSI, обращения к WMI-классам семейства MSFC_*:
- Load: Veeam.Backup.Common.dll (собственная библиотека Veeam)
- Call: [ProtectedData]::Unprotect (стандартный .NET DPAPI)
- De-obfuscate: методы шифрования Veeam для финальной расшифровки
- Result: открытые пароли всех сохранённых учётных данных
Это означает, что локальный административный доступ + легитимная библиотека = полная компрометация всех секретов, которые когда-либо были введены в Veeam.
Шаг 3 — Exploitation (lateral movement)
Получив все креденшалы, злоумышленник использовал инструмент nxc.exe (NetExec) для:
SMB Spray — проверка полученных паролей на других хостах
Lsass Dump — получение NTLM-хешей для pass-the-hash атак
Вот где приём злоумышленников показал глубокое понимание архитектуры VMware:
Вместо того чтобы шифровать ВМ с уровня гостевой ОС (что может быть заметно и остановлено системой защиты), он произвёл шифрование на уровне хранилища:
Целевой объект: виртуальные диски (VMDK файлы)
Уровень атаки: хранилище (LUN), минуя ОС гостя
Результат: все 99% инфраструктуры зашифрованы
Побочный эффект: включены ВСЕ резервные копии на этом же LUN
Критический момент: Veeam всегда хранит резервные копии на том же хранилище, где работает infrastructure (обычно в одном LUN с высокими правами доступа). Поэтому резервные копии тоже оказались зашифрованы.
Он указал внешний IP-адрес в числе целевых хостов. При проверке в Shodan выяснилось, что:
Этот адрес принадлежит казахстанской сети
Это IP партнёрской компании (интегратора/поставщика услуг)
На этом адресе была опубликована служба RPC
В сервисе была указана информация о хостнейме — название соответствует серверу компании
Всего было открыто более 10 портов в Shodan
Вывод: точка входа была именно здесь. Через неправильно сконфигурированный Windows сервер с открытыми портами RDP, RPC, SMB, Veeam и др.
Kill Chain атаки: полная цепочка действий
Реконструированная цепочка действий выглядела так:
1. Интернет → Сервер партнёра (Казахстан)
2. Scouting → Shodan выявил RPC с информацией о целевой системе
3. Network traversal → Через партнёра доступ к хосту жертвы (Veeam)
4. Initial Access → RDP с административными правами
5. Privilege Escalation → Уже под админом (не требовалась)
6. Persistence → Установка RAT (AnyDesk)
7. Reconnaissance → Анализ сети, поиск критических систем
8. Credential Dumping → Дамп Veeam, получение vCenter, доменных учёток
9. Lateral Movement → SMB Spraying, распространение по сети
10. Impact → Шифрование на уровне хранилища (99% инфры)
11. Extortion → Требование выкупа
5. Как SOC помог бы предотвратить эту атаку
Если бы инфраструктура находилась под мониторингом SOC, атака была бы заметна на нескольких этапах подряд — задолго до шифрования.
Ключевые сигналы по этапам атаки:
Брутфорс RDP с публичного IP Детект по множественным попыткам входа
Успешный вход с публичного IP Аномальная локация и контекст входа
Отключение антивируса Изменение политики безопасности на хосте
PowerShell с обфускацией Детект по сигнатурам и поведению
Использование certutil для загрузки ПО Детект LOLBins
Установка AnyDesk Детект удалённого доступа / RAT
Дамп учётных данных из Veeam Специальное правило на эту технику
SMB spraying Детект активности pass-the-hash
Доступ к LSASS Детект попыток дампа памяти
Итого: порядка 9 критических алертов отработало бы на разных этапах атаки.
Даже перехват части из них позволил бы остановить атаку или существенно сократить ущерб.
6. Распространённые ошибки которые усиливают ущерб
В этом кейсе мы увидели типовые ошибки, которые регулярно встречаются при ransomware-инцидентах:
1. Компании не знают насколько уязвим внешний периметр
Критичные сервисы доступны извне, не задокументированы и не контролируются
2. Нет плана реагирования
Решения принимаются в панике, а время — главный ресурс атакующего.
3. Обесточивание вместо изоляции
Потеря данных памяти и следов атаки усложняет расследование и восстановление.
4. Плоская сеть
Компрометация одного узла быстро становится компрометацией всей инфраструктуры.
5. Бэкапы существуют формально
Хранятся рядом с production и не спасают в момент атаки.
Каждая ошибка критична и все вместе сформировали неизбежный сценарий катастрофы.
7. Правильные действия при обнаружении инцидента
Если инцидент уже произошёл, ключевые приоритеты выглядят так:
изолировать инфраструктуру, а не отключать питание
зафиксировать следы атаки до разрушения данных
быстро собрать команду принятия решений
оценить состояние резервных копий
восстановление начинать только после понимания точки входа
8. Выводы
Ransomware — это управляемая операция, а не случайный инцидент.
Зрелость компании не гарантирует защиту без мониторинга и контроля периметра.
SOC — это способ лишить атакующего времени.
Бэкапы без изоляции — иллюзия защиты.
IR-план должен существовать до атаки, а не во время неё.
Постоянный контроль внешнего периметра (Attack Surface Management)