8 ноября 2026 года у хостинг-провайдера ESTT (e-Style Telecom) остановились клиентские сервисы, а на следующий день компания
сообщила о кибератаке с использованием шифровальщика. Это второй крупный инцидент с российским хостингом за неделю: незадолго до этого атаке подвергся Beget. Разбираем, что известно об атаке на ESTT, чем похожи оба случая и что делать компаниям, которые размещают сервисы у провайдера или сами управляют виртуализацией.
Главное об атаке на ESTT
-
8 ноября около 4:00 по Москве клиенты ESTT начали жаловаться на недоступность сервисов;
-
по заявлению компании, шифровальщик затронул кластеры виртуализации и системы управления облачной инфраструктурой, выделенные физические серверы продолжили работать;
-
к 9 ноября ESTT восстановила около 90% клиентских виртуальных серверов, позже сообщила о завершении восстановления и вернула панель управления SmartCore;
-
признаков утечки клиентских данных, по словам компании, нет, однако независимого подтверждения пока не было;
-
11 ноября внешний доступ к SmartCore снова временно ограничили из-за дополнительных технических работ, облако при этом продолжило работать.
Два хостера за неделю
В начале ноября атаке подвергся Beget. По данным провайдера, злоумышленники добрались до управляющего контура облака и запустили скрипты, которые уничтожили облачную инфраструктуру. Резервные копии VPS, по оценке компании, будут доступны только половине пользователей, а работу с доменами в зонах .ru, .рф и .su пришлось временно ограничить.
У Beget данные уничтожили, у ESTT зашифровали, но в обоих случаях удар пришелся по системам управления облаком. Получив доступ к гипервизорам и консоли управления, атакующий может остановить множество клиентских машин сразу, не взламывая каждую по отдельности.
Почему шифрование замечают слишком поздно?
Само шифрование занимает от нескольких минут до нескольких часов, а подготовка к нему обычно растягивается на дни и недели. За это время атакующим нужно получить учетные данные администраторов, найти консоль управления виртуализацией, добраться до гипервизоров и, как правило, вывести из строя резервное копирование.
Антивирус и EDR внутри клиентских виртуальных машин этот этап почти не замечают: атакующий действует на уровне платформы, через штатные консоли и под учетными записями администраторов. Журналы на захваченных узлах он может стереть, но подключения к гипервизорам, консоли управления и серверам резервного копирования все равно проходят через сеть, и их копию можно анализировать отдельно от захваченных систем.
Как заметить шифровальщика до начала шифрования
Здесь помогают системы анализа сетевого трафика класса NTA и NDR. Сенсор получает копию трафика с коммутатора, в том числе из сегмента управления, и еще на этапе подготовки атаки может показать:
-
подключения к консоли управления виртуализацией и API облака с узлов, которые раньше туда не обращались;
-
SSH-сессии к гипервизорам, если в штатной работе SSH на них выключен;
-
подключения администраторов по RDP и SMB в нетипичное время или с непривычных рабочих мест;
-
сканирование сегмента управления и перебор паролей;
-
обращения к серверам резервного копирования с посторонних узлов;
-
выгрузку больших объемов данных наружу, которая часто предшествует шифрованию;
-
связь с внешними управляющими серверами, в том числе через туннели.
UDV NTA разбирает SMB, Kerberos и DCE/RPC до уровня полей: видно, какая учетная запись, с какого узла и к какому сервису обращается. По зашифрованным RDP, SSH и HTTPS-консолям содержимое сессий не видно, зато видно, кто, откуда, когда и в каком объеме подключался, а этого достаточно, чтобы заметить нетипичный доступ. На карте сетевых взаимодействий видно, кто и когда подключается к сегменту управления, а данные UDV Threat Intelligence о вредоносной инфраструктуре помогают отделить обращения к серверам атакующих от фонового шума.
Чтобы такой контроль работал, сенсор должен видеть трафик внутри сегмента управления, а не только на периметре. При этом доступ к самому NTA тоже нужно защитить: интерфейсы управления и консоль лучше держать в выделенной сети управления, а учетные записи для входа не связывать с основным доменом. Тогда атакующий, захвативший управление облаком, не сможет зайти в NTA и стереть собранные данные. Как проверить, что атакующих не осталось в сети после взлома виртуализации, мы разбирали в статье «Взлом системы виртуализации: как понять, остались ли атакующие в инфраструктуре?».
Как защититься от шифровальщика в облаке
Если ваши сервисы размещены у провайдера
-
Хранить резервные копии критичных систем вне площадки провайдера и регулярно проверять восстановление из них.
-
Заранее подготовить план переезда на другую площадку: после атаки на Beget как минимум один крупный сервис восстановил работу только через другого подрядчика.
-
Спросить провайдера, как он отделяет сеть управления облаком от клиентских сетей и кто контролирует доступ к ней.
-
Контролировать сетевую активность собственных виртуальных машин. Если провайдер позволяет зеркалировать трафик или клиент сам маршрутизирует его через свой узел, обращения к неизвестной инфраструктуре и необычные выгрузки данных видны и на стороне клиента.
Если вы управляете виртуализацией сами
-
Вынести управление виртуализацией и резервное копирование в отдельные сегменты с доступом только с выделенных рабочих мест администраторов.
-
Включить многофакторную аутентификацию для консолей управления, VPN и удаленного доступа, а SSH на гипервизорах держать выключенным, пока он не нужен для обслуживания.
-
Хранить неизменяемые резервные копии вне домена и вне сети управления.
-
Поставить сенсор NTA на трафик сегментов управления и резервного копирования.
Когда проверить сеть нужно срочно, поможет российский программно-аппаратный комплекс для анализа сетевого трафика UDV NTA 2.0:
-
комплекс уже настроен и готов к работе: инсталляция занимает пару часов, тонкая настройка проходит после 7 дней эксплуатации;
-
сверяет трафик с данными UDV Threat Intelligence о вредоносной инфраструктуре;
-
помогает быстрее разбирать события с AI-ассистентом UDV AI Platform, который работает внутри контура компании;
-
включает поддержку специалистов Лаборатории кибербезопасности UDV Group.
Если предложение актуально для вас, напишите нам на zapros@udv.group или через форму обратной связи на сайте!
Михаил Пырьев
Менеджер продукта UDV NTA
Лидер продуктовой практики UDV NTA.
