Перейти к содержанию
Обсудить задачу →
Новости

Кибератака на Beget: хронология, потеря данных и ход восстановления

Опубликовано 10.11.2026
Что произошло 2 ноября, когда Beget предупредил клиентов, какие данные потеряны и что удалось вернуть к 10 ноября. Подробная хронология, изменения обещаний и подтверждённые границы расследования.
Концептуальная иллюстрация восстановления облачной инфраструктуры: специалист у серверных стоек

Концептуальная иллюстрация. Не фотография инфраструктуры Beget.

Кибератака на Beget в ночь на 2 ноября 2026 года привела к многодневному восстановлению сервисов и потере данных облачной платформы. Провайдер признал, что вернуть все данные VPS невозможно, а сохранившиеся файловые копии, по оценке от 6 ноября, будут доступны лишь примерно половине пользователей VPS. Вечером 10 ноября Beget заявил о восстановлении за день более 18 тысяч сайтов виртуального хостинга; ранее компания сообщила о выкладке около 25 тысяч файловых бэкапов VPS. Это ещё не означает восстановления всех клиентских проектов.

Актуальность материала — 10 ноября 2026 года. Общая хронология на сайте Beget по-прежнему датирована 9 ноября, 16:00 МСК; дополнительно учтены официальные сообщения от 10 ноября, включая вечерний статус в 20:31 МСК. Ниже отдельно указаны заявления компании, опубликованные планы и выводы редакции. Проверка отдельных клиентских аккаунтов, содержимого бэкапов и внутренних систем Beget не проводилась.

10 ноября, 20:31 МСК: Beget сообщил о восстановлении более 18 тысяч сайтов

В вечернем сообщении от 10 ноября провайдер заявил, что за день вернул в работу более 18 тысяч сайтов виртуального хостинга. По его данным, в системе восстановления находятся 66 серверов. Это число серверов, участвующих в процессе, а не количество уже полностью восстановленных машин. Общая доля возвращённых сайтов и срок завершения работ не названы.

Компания пояснила последовательность работ: подготовка сервера и сети, установка окружения, перенос данных из резервных копий, восстановление конфигураций сайтов и привязок доменов. Ответ на ping появляется уже на первом этапе и не подтверждает доступность сайтов. Теперь запуск отдельных сайтов начинается по мере поступления их данных, пока копирование остальных продолжается.

Число работающих сайтов приведено со слов Beget: независимой проверки этих проектов редакция не проводила. Сообщение относится к виртуальному хостингу и не подтверждает восстановление утраченных дисков VPS, содержимого S3 или кластеров Kubernetes. Новых сведений о первоначальной точке проникновения и причинах атаки в нём нет.

Обновление от 10 ноября: первые сайты из бэкапов и около 25 тысяч копий VPS

В статусе от 10 ноября, 12:36 МСК Beget сообщил о запуске первых сайтов виртуального хостинга из резервных копий. Файлы и базы возвращаются на аккаунты; работы продолжаются. Компания также сообщила, что развернула примерно половину серверов из оставшейся к восстановлению группы. Это не половина всего хостинга и не доля полностью восстановленных проектов.

В панели выложено около 25 тысяч файловых копий VPS, выкладка продолжается. Индивидуальная ссылка приходит на почту аккаунта после заявки. В продолжении сообщения компания объявила восстановление продления международных доменов.

Это заявления провайдера о достигнутых этапах. Число копий нельзя приравнивать к числу клиентов или работающих серверов. Проверку конкретных архивов и сайтов редакция не проводила. Первоначальная точка проникновения в этом обновлении не раскрыта.

Что произошло: удаление данных после взлома управляющей инфраструктуры

В разборе инцидента Beget сообщил о доступе злоумышленников к управляющему контуру и запуске обнуляющих скриптов. Это описание разрушительной атаки, а не только перегрузки публичных сайтов запросами. Восстанавливать пришлось сами сервисы, пользовательские данные и внутренние сведения об услугах.

Важно различать три уровня последствий. Недоступность сервера означает, что приложение не отвечает. Потеря рабочего диска означает необходимость переноса данных из другой копии. Утрата пригодной резервной копии может сделать возвращение проекта к прежнему состоянию невозможным. В случае Beget публичные сообщения последовательно затронули все три уровня.

При этом формулировка «Beget полностью перестал существовать и ничего не восстановил» не соответствует опубликованным сведениям. Часть услуг запустили, для других потребовалось развёртывание заново. Самая тяжёлая часть истории — невозможность восстановить все данные облачных клиентов, а не отсутствие любых результатов восстановительных работ.

Сколько Beget молчал и когда сообщил о масштабе проблемы

Для ответа есть конкретная отправная точка — официальная хронология Beget. В ней начало атаки обозначено как предположительное время, а не результат независимой экспертизы. Все часы в этом материале приведены по Москве.

От предполагаемого начала атаки до первого сообщения2 ч 50 мин02:00 → 04:50 МСК, 2 ноября
От обнаружения до первого сообщения2 ч 10 мин02:40 → 04:50 МСК, 2 ноября

Это расчёт по времени, опубликованному самим провайдером. Первый пост сообщал о крупном инциденте и работах, но ещё не давал клиентам картины потерь. В следующих коротких обновлениях компания говорила о расследовании, комплексной проблеме и ручной настройке оборудования в дата-центрах. В сообщениях, собранных Хабром, затем появилось официальное признание кибератаки и предупреждение об отсутствии точного общего срока восстановления.

Поэтому считать всё время до 6 ноября «полным молчанием» некорректно: обновления выходили. Но и приравнивать первый короткий пост к раскрытию масштаба аварии нельзя. Уже 3 ноября публично сообщалось о потере облачных данных; 6 ноября появилась значительно более тяжёлая оценка доступности файловых копий VPS.

По открытым публикациям нельзя установить, когда именно внутри Beget узнали о каждой категории утраченных данных. Время обнаружения взлома, время оценки ущерба и время сообщения клиентам — разные события. Доказательств, позволяющих назвать точную продолжительность намеренного сокрытия информации, в изученных материалах нет.

Хронология: от атаки до выдачи резервных копий

Ниже — основные отметки официальной страницы восстановления. Время первых событий у Beget указано как предварительное. Завершённые этапы и начало работ приведены раздельно.

  1. Предполагаемое начало атаки. Получение доступа к управляющим серверам.
  2. Запуск вредоносного ПО. Его назначение — удаление серверных данных.
  3. Обнаружение взлома. Предварительная отметка компании.
  4. Изоляция и начало восстановления. Отключение серверов от сети, расследование.
  5. Первое уведомление клиентов. Публикация в официальном Telegram-канале.
  6. Выделенные серверы без администрирования / NS. Заявлено восстановление этих направлений.
  7. Почта, домены, хостинг. Возвращение почтовых протоколов и Webmail; начало восстановления хостинга; отдельное управление доменами.
  8. Первые сайты. Запуск на восстановленных серверах виртуального хостинга.
  9. Панель управления. Запуск с ограниченными возможностями.
  10. Копии VPS. Объявлена возможность скачивания через панель.
  11. Статус восстановления. Объявлены первые сайты из копий и выкладка около 25 тысяч файловых бэкапов VPS.
  12. Вечерний результат восстановления. Beget заявил о возвращении в работу более 18 тысяч сайтов за день; в системе восстановления — 66 серверов. Полное завершение работ не объявлено.

Источник временных отметок: официальный сайт Beget. Это сведения провайдера, а не результаты нашего мониторинга.

Что было утрачено

Первый подробный разбор Beget называл потерю данных в VPS, S3 и Kubernetes, а также бинарных резервных копий VPS; отдельно упоминались утраченные настройки CDN и IP. Файловые копии VPS рассматривались как оставшийся путь восстановления. Позднее компания уточнила, что доступные копии покрывают не всех пользователей. Источник — сообщение провайдера.

Рабочие данные облака

Для проекта это может означать утрату содержимого дисков, объектов или состояния приложения. Конкретный состав нужно проверять по услуге и собственным копиям: открытого реестра пострадавших ресурсов нет.

Часть резервных копий

Наличие прежней функции резервирования не гарантировало выдачу полного образа каждому клиенту после атаки. Сохранившийся файловый архив и готовый к запуску сервер — разные результаты.

Внутренние сведения об услугах

По сообщению от 6 ноября, часть актуальных связей между аккаунтами и услугами потеряна. Их восстановление требовалось в том числе для сопоставления клиента и его копий.

«Ведомости» 6 ноября передали заявление компании: восстановить все данные VPS невозможно, файловые копии будут доступны лишь половине пользователей; облачную инфраструктуру строят заново. Это оценка провайдера на конкретную дату. Её нельзя превращать в утверждение, что ровно половина всех клиентов Beget потеряла абсолютно всё: речь шла о пользователях VPS и доступности определённого вида копий.

В изученных сообщениях нет полного перечня потерянных дисков и объектов, объёма потерь в терабайтах, списка всех пострадавших клиентов и единой даты последних пригодных копий. Поэтому точный масштаб необратимой потери для всего бизнеса клиентов сейчас не посчитан в этом материале.

Как менялись заявления о бэкапах

Эта часть истории особенно важна. В ранних сообщениях сохранность файловых копий описывалась широко. Т—Ж 3 ноября зафиксировал заявление о сохранённых файловых бэкапах хостинга и облака при отсутствии доступа к ним. Уже 6 ноября публичная оценка для VPS сузилась до примерно половины пользователей.

Разница существенна: сначала клиент мог рассчитывать на выдачу копии после восстановления доступа, затем оказалось, что сама доступность копии зависит от конкретного аккаунта. На основании публикаций нельзя установить, связано ли уточнение с завершением инвентаризации, повреждением дополнительных ресурсов или иными обстоятельствами. Это должен объяснить подробный технический отчёт компании.

Что именно нужно получить клиенту, тоже имеет значение. Файлы приложения без актуального дампа базы могут не содержать последние заказы и изменения. Архив пользовательского каталога не обязан включать системную конфигурацию, секреты, сертификаты и настройки внешних сервисов. Это общие технические различия, а не утверждение о составе конкретной копии Beget.

Сообщение от 9 ноября о скачивании копий подтверждает объявленный способ доступа. Оно само по себе не подтверждает, что архив есть у каждого пользователя, скачивается без ошибок, содержит нужную дату и позволяет запустить приложение. Эти четыре проверки выполняются отдельно.

Что восстановилось по опубликованным данным

Проценты ниже относятся к указанным датам и группам серверов. Их нельзя читать как актуальную доступность всех проектов на 10 ноября или как долю полностью восстановленных пользовательских данных.

НаправлениеЧто сообщалосьЧто это не подтверждает
Выделенные серверы без администрированияЗаявлен полный запуск 2 ноября.Работоспособность каждого приложения заказчика.
NS и доменыВозврат NS и отдельного управления записями.Наличие данных сайта по адресу, указанному в DNS.
Виртуальный хостинг35% серверов 4 ноября; 60% — 5 ноября; 6 ноября — более 60%. 10 ноября — объявлен запуск первых сайтов из бэкапов; вечером провайдер сообщил о более 18 тысячах восстановленных за день сайтов и 66 серверах в процессе восстановления.Завершение возврата остальных сайтов и их баз.
Выделенные серверы с администрированием15% — 4 ноября; 40% — 5 ноября.Тот же статус для VPS: это другая услуга.
Почтовые серверыВ обновлении от 5 ноября — 99%, доступен Webmail.Доставку каждого сообщения и сохранность всех ящиков.
ПанельС 7 ноября — ограниченный функционал.Полное управление всеми услугами.
VPSС 9 ноября объявлено скачивание сохранившихся копий. По сообщению от 10 ноября выложено около 25 тысяч файловых бэкапов.Возврат прежней облачной платформы и всех дисков.

Источники: хронология Beget, обновление от 5 ноября и публикация от 6 ноября. Для оценки конкретной услуги требуется её проверка в аккаунте.

Что Beget видел внутри инфраструктуры и чего публично не показал

Из официальных объяснений можно выделить три наблюдения компании: доступ к управляющим системам, выполнение средств удаления и повреждение не только клиентских ресурсов, но и собственной служебной информации. Ручные проверки требовались, чтобы оценить состояние узлов перед запуском. Это сведения самого провайдера; независимого подтверждения по журналам у нас нет.

Публично не представлены полная последовательность команд атакующих, перечень скомпрометированных учётных записей, схема распространения доступа и доказанный путь к каждому хранилищу копий. Поэтому мы можем описать заявленные последствия и этапы реагирования, но не восстановить всю внутреннюю картину атаки с точностью экспертизы.

Что компания предпринимала

По сообщениям Beget, работы включали изоляцию инфраструктуры, ручную проверку серверов, очистку от вредоносных механизмов и проверку данных. Для повреждённых узлов требовалось заново готовить окружение. Затем восстанавливали инфраструктуру резервирования, сопоставление копий с аккаунтами и функции панели. В обновлении от 6 ноября обычный перезапуск уже не рассматривался как достаточное решение. Официальный канал.

Это объясняет, почему возврат отдельных страниц не равен завершению аварии. Запуск аппаратного узла, восстановление платформы, получение клиентом архива и проверка его приложения — самостоятельные этапы. Сайт может открываться, но ещё не принимать заказы; панель может показывать услугу, но не позволять управлять ею. Такие варианты нужно проверять, а не объявлять установленными для всех клиентов.

РБК также сообщал о последствиях для BelkaCar: компания связала перебои со сбоем Beget и впоследствии восстановила доступ через альтернативного подрядчика. Это пример восстановления клиентского сервиса другим способом, а не доказательство возвращения всей платформы хостера.

Что обещали восстановить и какие сроки нельзя считать гарантией

В сообщении от 6 ноября компания ставила целью восстановление проектов виртуального хостинга из резервных копий. Облако предполагалось разворачивать заново; первые серверы планировали подключить за один-два дня, после чего проводить интеграцию и тестирование. Также обещали поэтапный возврат функций панели. Эти планы описывали разные этапы, а не одну дату полного восстановления. Сводка заявления компании.

В раннем разборе фигурировал и ориентир ограниченной панели в течение 24 часов. В официальной хронологии её запуск указан 7 ноября в 03:00 МСК. Это показывает расхождение раннего ожидания с опубликованной датой запуска; точную длительность задержки без датированного первоначального обещания мы не рассчитываем.

К 10 ноября в проверенных нами источниках не найдено подтверждения завершения всех этих работ и возврата всех пользовательских проектов. Поэтому мы не подменяем объявления о запуске первых узлов сообщением «облако полностью восстановлено». Аналогично заявленная цель стопроцентного восстановления хостинга не является отчётом о её достижении.

Для пострадавшего бизнеса полезнее запросить отдельные ответы: существует ли копия именно его ресурса, какого она времени, как получить её сейчас, что в неё входит и какие функции инфраструктуры ещё недоступны. Общий процент поднятых серверов этих вопросов не закрывает.

Домены: ограничения регистрации и защита от удаления

Последствия затронули и работу регистратора. Координационный центр сообщил, что аккредитация ООО «Бегет» приостановлена с 3 ноября. По описанию КЦ, это временные ограничения на новые регистрации .RU/.РФ и приём доменов от других регистраторов; поддержку уже зарегистрированных имён регистратор обязан продолжать. Это не равнозначно аннулированию всех доменов клиентов.

Первоначальные экстренные меры защищали часть истекающих доменов от удаления до 9 ноября. 9 ноября КЦ объявил продление моратория до 18 ноября 2026 года для доменов, подпадающих под условия сообщения. Применимость к конкретному имени нужно сверять с регистратором. Переносить это правило автоматически на все международные зоны нельзя. Сообщение от 3 ноября, продление от 9 ноября.

Редактирование DNS, продление регистрации и перенос домена — разные операции. Возможность изменить A-запись помогает направить сайт на новую площадку, но не возвращает его файлы и базу. Доступность операций и срок регистрации проверяйте отдельно, особенно если почта администратора домена также размещалась в пострадавшем сервисе.

Что стало причиной: известный механизм и неизвестная точка входа

Публично описанный механизм: компрометация управляющей инфраструктуры и запуск средств удаления данных. Первоначальная причина проникновения: в изученных официальных сообщениях не раскрыта. Не названы подтверждённая конкретная уязвимость, первоначально скомпрометированная учётная запись или полная цепочка действий атакующих.

Доступ к управляющему контуру объясняет масштаб полномочий, которыми могли воспользоваться злоумышленники. Но это ещё не ответ на вопрос, каким способом они туда попали и почему последствия распространились на системы с копиями. Для такого вывода нужны результаты расследования, журналы, границы доступа и подтверждённая архитектура резервирования.

Мы не утверждаем, что причиной были ранее обсуждавшиеся уязвимости PHP, определённая панель виртуализации или действия конкретной группы. Открытого подтверждения такой связи в проверенных источниках не найдено. Утрату облачной инфраструктуры также нельзя без дополнительных данных описывать как физическое уничтожение серверов.

Что известно об утечке и смене доступов

В раннем разборе Beget сообщал, что по имевшимся тогда данным не видел попыток скачивания пользовательской информации, и рекомендовал сменить пароли и ключи, которые могли храниться на серверах. Это предварительная оценка провайдера, а не независимое заключение об отсутствии утечки. Удаление информации и её возможное копирование — разные вопросы расследования.

Рекомендация редакции: после возвращения управления инвентаризировать SSH-ключи, пароли СУБД, токены внешних API, почтовые учётные данные и доступы автоматизации. Ротацию проводить с чистого доверенного устройства, с учётом зависимостей приложений. Не отправлять секреты в открытый чат поддержки и не переносить старые административные доступы на новую площадку без проверки.

Как клиенту понять, что восстановился именно его проект

Следующий порядок — рекомендации редакции, а не дополнительное заявление Beget о готовности услуг.

  1. Зафиксировать ресурс. Аккаунт, идентификатор услуги, домен, прежние адреса и время последней успешной операции. Сохранить переписку и уведомления.
  2. Проверить копию. Дату, состав и возможность распаковки. Сохранить полученный оригинал отдельно; восстановление выполнять на рабочей копии в изолированном окружении.
  3. Сопоставить данные. Файлы, базу, вложения, настройки и секреты. Для магазина проверить последние заказы и платежные статусы; для корпоративного портала — документы и изменения пользователей.
  4. Поднять безопасное окружение. Обновлённое ПО, ограниченные административные доступы, новые ключи. Не считать ранее скомпрометированный образ автоматически доверенным.
  5. Проверить бизнес-операцию. Не только главную страницу, но и вход, форму, заказ, отправку письма или обмен с учётной системой — в зависимости от проекта.
  6. Согласовать переключение. Предотвратить параллельную запись в старую и новую базы, дублирование заданий, уведомлений и платежных запросов.
  7. Создать независимую копию. Вне прежней административной зоны доступа и с проверкой восстановления.

Отдельно зафиксируйте фактическую потерю изменений: между последней пригодной копией и остановкой работы могли появиться заказы, документы или файлы. Возвращение сервиса и восстановление этой части истории требуют разных действий.

Что инцидент показывает бизнесу

Технический вывод редакции: резервирование инфраструктуры и независимое восстановление проекта — разные задачи. Несколько экземпляров данных внутри одного управления могут разделять общий риск. Проверять нужно не только число копий, но и отдельные права доступа, срок хранения, защиту от удаления и возможность получить данные без основной панели.

Независимая копия должна быть пригодна для использования: нужен описанный состав, доступные ключи расшифрования, подтверждённая дата и проверенный порядок развёртывания. Полезно заранее определить допустимую потерю изменений и время возврата работы. Эти критерии помогают отличить обещанную функцию резервирования от фактически проверенного восстановления.

Эта история не доказывает ненадёжность любого облака. Она показывает цену зависимости от одного провайдера сразу по нескольким направлениям: рабочая площадка, бэкапы, DNS, почта администратора и панель управления. Решение — проверяемый план выхода из аварии, соответствующий последствиям простоя для конкретного бизнеса.

Каких ответов пока не хватает

  • Полной подтверждённой цепочки первоначального проникновения.
  • Окончательного перечня утраченных рабочих ресурсов и пригодных копий.
  • Проверенного объёма возможного несанкционированного копирования данных.
  • Единого отчёта о завершении восстановления каждого направления.
  • Объяснения, почему ранняя оценка сохранности бэкапов изменилась.
  • Подробного описания мер, исключающих повторение аналогичного сценария.

До появления технического отчёта и окончательных статусов эти пробелы нельзя заполнять предположениями. При этом подтверждённых сведений уже достаточно, чтобы владельцы пострадавших проектов проверяли свои копии и готовность к восстановлению, не ожидая одной общей формулировки «всё работает».

Источники и границы проверки

Материал подготовлен 10 ноября 2026 года. Основные первичные источники: официальная хронология Beget, официальный канал, сообщения Координационного центра от 3 ноября, о приостановке аккредитации и о продлении моратория. Страницы КЦ проверены по доступному поисковому представлению: прямое открытие возвращало 403.

Для сопоставления дат публичных сообщений и последствий использованы Хабр, Т—Ж, «Ведомости» и РБК. Они не заменяют проверку конкретной услуги. Доступа к внутреннему расследованию, журналам и клиентским копиям у редакции нет.