В два часа ночи злоумышленники получили доступ к управлению крупным хостингом. В 02:30 запустили программу уничтожения данных. В 02:55 серверы отключили от сети. Двадцати пяти минут оказалось достаточно, чтобы тысячи сайтов и сервисов столкнулись с катастрофой.
В ночь на 2 ноября 2026 года российский хостинг-провайдер Beget подвергся разрушительной кибератаке.
Это был не обычный DDoS, когда серверы перегружают запросами. И не классический ransomware, когда файлы шифруют ради выкупа.
Злоумышленники получили доступ к управляющему контуру инфраструктуры и запустили вредоносное ПО, предназначенное для удаления данных.
Beget официально подтвердил этот сценарий.
Хроника двадцати пяти минут
По опубликованной компанией хронологии:
- 02:00 — предполагаемое начало атаки и получение доступа к управляющим серверам.
- 02:30 — запуск программы уничтожения данных.
- 02:40 — обнаружение несанкционированного доступа.
- 02:55 — отключение серверов от сети для остановки распространения атаки.
В 03:00 начались расследование и восстановительные работы.
К этому моменту повреждения уже были нанесены.
Инцидент затронул виртуальный хостинг, облачные серверы, хранилища, DNS и почтовую инфраструктуру.
Среди пострадавших сервисов оказался каршеринг BelkaCar. Возникли проблемы с доступом к информационному порталу «Честного знака», хотя сама система маркировки, по заявлению её оператора, продолжала работать.
Beget обслуживает более 200 тысяч клиентов. А по данным октябрьского исследования рынка, с компанией были связаны около 14,7% доменов зоны .RU, включая парковочные домены и перенаправления.
Это не означает, что каждый седьмой российский сайт перестал работать. Но показывает масштаб зависимости интернет-проектов от одного провайдера.
Как можно уничтожить облако за 25 минут?
Представьте огромный склад с тысячами помещений.
У каждого помещения своя дверь и замок. Но где-то существует центральный пульт, позволяющий одновременно открыть, закрыть или перепланировать весь комплекс.
В серверной инфраструктуре подобную роль играет Control Plane, управляющий контур.
Через него автоматизированные системы могут создавать виртуальные машины, выделять диски, менять сетевые настройки, управлять хранилищами и удалять ресурсы.
Если злоумышленник получает достаточно высокие полномочия, ему не обязательно взламывать каждую виртуальную машину отдельно.
Он может воздействовать на инфраструктуру централизованно.
При этом уничтожение огромных объёмов данных не всегда требует физически перезаписывать каждый байт.
В зависимости от устройства хранилища достаточно удалить виртуальные диски, повредить критические метаданные или уничтожить информацию, необходимую для доступа к данным.
Система перестаёт видеть содержимое, хотя физические накопители продолжают существовать.
Это техническое объяснение возможного механизма, а не установленная схема действий атакующих Beget. Компания пока не раскрыла конкретные инструменты и способ первоначального проникновения.
Самая страшная потеря — резервные копии
3 ноября Beget сообщил об утрате данных в облачной инфраструктуре VPS, S3 и Kubernetes.
Бинарные резервные копии VPS также были потеряны.
При этом файловые резервные копии сохранились, что оставило возможность частичного восстановления.
Разница принципиальная.
Бинарная копия виртуального сервера позволяет восстановить целый образ машины. Файловая копия содержит отдельные файлы, но не обязательно всю структуру дисков, состояние работающих сервисов и необходимые конфигурации.
Поэтому наличие файлового архива ещё не означает, что сервер можно вернуть к жизни одной кнопкой.
5 ноября Beget сообщил, что большая часть файловых резервных копий VPS сохранилась и ведётся подготовка к их выдаче клиентам.
Вот здесь и находится главная инженерная проблема.
Если рабочие данные и система резервного копирования зависят от одного управляющего контура, компрометация этого контура может одновременно уничтожить и оригинал, и путь к восстановлению.
Три копии на трёх дисках не спасут, если все три можно удалить одними административными полномочиями.
Миллион изменений маршрутов: что происходило с сетью?
У атаки обнаружился ещё один необычный признак.
По данным «Коммерсанта» со ссылкой на RIPEstat, в течение одного часа в маршрутизации сетей Beget наблюдалось почти миллион изменений анонсов. Для сравнения: прежний максимум за 90 дней не превышал 20 тысяч.
Это колоссальная аномалия.
BGP — протокол, с помощью которого автономные сети обмениваются информацией о доступных маршрутах интернета.
Резкие изменения маршрутизации могут сопровождать отключение сетевых узлов, аварийную переконфигурацию или нарушение работы маршрутизаторов.
Могли ли атакующие воздействовать на сетевое оборудование? Теоретически да.
Могли ли сами инженеры вызвать всплеск маршрутов, пытаясь изолировать инфраструктуру? Такой сценарий тоже возможен.
Но опубликованные данные пока не позволяют установить причину.
Аномалия BGP заслуживает отдельного исследования. Приписывать её действиям злоумышленников без доказательств было бы преждевременно.
А если причиной стала октябрьская уязвимость PHP?
В октябре мы уже разбирали опасные уязвимости серверного программного обеспечения и AI-шлюзов.
Возникает закономерный вопрос: не использовали ли атакующие аналогичный путь для проникновения в Beget?
Возможных точек входа множество: административные панели, украденные токены, уязвимые сервисы, рабочие станции сотрудников, системы удалённого доступа.
Но Beget не назвал первоначальный вектор атаки.
Поэтому связывать ноябрьское уничтожение инфраструктуры с конкретной PHP-уязвимостью сейчас нельзя.
Главный подтверждённый факт другой: атакующие получили доступ к управлению инфраструктурой. Каким способом — пока неизвестно.
Как защитить собственный сервер от подобной катастрофы?
Для небольшого проекта не нужны три дата-центра и миллионный бюджет.
Нужна архитектура, которая не позволяет одному инциденту уничтожить всё.
Первое. Независимые резервные копии.
Базы данных, конфигурации, ключи восстановления и файлы необходимо регулярно копировать за пределы основного хостинг-провайдера.
Второе. Защита от удаления.
Для резервных копий полезны хранилища с Object Lock и режимом неизменяемости. Например, S3 Object Lock Compliance запрещает удаление защищённой версии объекта до окончания установленного срока хранения даже администратору аккаунта.
Но такая защита требует правильной настройки и не заменяет отдельные учётные данные и контроль доступа.
Третье. Независимое управление DNS.
Если сайт, почта, DNS и резервные копии находятся у одного поставщика, его авария способна парализовать весь проект.
Возможность быстро перенаправить домен на резервную площадку должна сохраняться независимо от основного сервера.
Четвёртое. Проверенное восстановление.
Архив, который никто никогда не пробовал восстановить, — лишь надежда.
Нужно периодически разворачивать тестовый сервер из резервной копии и проверять, запускаются ли приложения, открываются ли базы данных и работают ли необходимые сервисы.
Пятое. Ограничение административных полномочий.
Массовое удаление инфраструктуры не должно зависеть от одного токена или одной учётной записи. Для критических операций необходимы разделение полномочий, независимое подтверждение и аварийная блокировка доступа.
Почему это касается каждого владельца VPN и AI-сервиса?
Представьте, что у вас есть VPN-сервер с сотнями клиентов.
На нём хранятся конфигурации, ключи доступа, настройки маршрутизации и данные биллинга.
Одна разрушительная атака на инфраструктуру провайдера — и сервер исчезает.
Если резервная копия находится там же, исчезает и возможность быстро восстановить работу.
Для AI-шлюза ситуация аналогичная: потеря конфигураций, секретов, базы пользователей и истории платежей может остановить весь сервис.
Поэтому независимость — это не только возможность выбрать другого облачного провайдера.
Настоящая независимость начинается с возможности уйти от текущего провайдера вместе со своими данными и восстановить работу без его участия.
Что произошло после атаки?
Восстановление Beget продолжалось несколько дней.
К 5 ноября компания сообщила о запуске 60% виртуального хостинга и 40% выделенных серверов под собственным администрированием.
Для клиентов пострадавших сервисов списания на время недоступности были приостановлены.
Компания продолжила проверку серверов и восстановление резервных копий.
Это тяжёлая работа: после компрометации управляющего контура нельзя просто включить оборудование обратно, не убедившись, что вредоносный код и чужие полномочия устранены.
Главный вывод
В предыдущих расследованиях «Стеклянного моста» мы изучали уязвимости Linux, AI-шлюзов и компрометацию официальных программных обновлений.
Beget показал следующий уровень угрозы.
Иногда злоумышленнику не нужно атаковать отдельный сервер.
Достаточно получить управление системой, от которой зависят тысячи серверов.
Двадцать пять минут могут уничтожить инфраструктуру, которую строили годами.
И потому главный вопрос владельца любого цифрового бизнеса должен звучать не «насколько известен мой хостинг?».
А гораздо конкретнее:
«Смогу ли я завтра восстановить весь свой проект, если сегодня этот хостинг исчезнет?»
Если ответ неизвестен, самое время провести проверку. Пока это ещё учебная тревога, а не реальная катастрофа.
Стеклянный мост | 6 ноября 2026 года
Источники
- Beget — официальная хронология кибератаки и восстановления: https://beget.ru/ru/security
- Beget Official — сообщения о потере облачных данных и сохранности файловых резервных копий: https://t.me/s/beget_official
- «Коммерсантъ», 2 ноября 2026 — масштаб сбоя и аномалии BGP: https://www.kommersant.ru/doc/9079245
- AWS — документация по S3 Object Lock: https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html