30 июля 2025 года на сайте «Орион Телекома» появилось сообщение о возможной утечке персональных данных после кибератаки, случившейся еще 12 июня. К тому моменту компания уже успела оказаться в центре редкого для рынка сюжета: новый режим штрафов за крупные утечки только заработал, а суды начали разбирать первые дела.

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

1. История инцидента

Судебные решения, вынесенные в конце апреля — начале мая 2026 года, раскрыли детали расследования, которое проводило ООО «Бизон». Картина получилась неприятная для оператора связи: атакующие вошли в инфраструктуру через учетную запись уволенного сотрудника, а пароль к ней не меняли с момента создания в 2019 году.

Дальше цепочка только ухудшалась. Первый хост, с которого шло подключение, работал на ПО с критической уязвимостью. Затем злоумышленники перешли на другой сервер, где эксперты нашли сразу несколько опасных дыр. Вишенка на торте — некорректная настройка прав, позволявшая повышать привилегии до root без ввода пароля.

То есть речь шла не о сложной многоходовке против сильной защиты, а о наборе ошибок, которые обычно начинают с самых простых вещей: инвентаризации учетных записей, обновлений и контроля прав доступа. Подобные провалы хорошо знакомы и по другим инцидентам, например по кейсам из разборов взлома внутренних репозиториев GitHub или атак на цепочки поставок вроде истории с уязвимостями в Windows 11.

2. Что пошло не так в защите

Главная проблема — не одна, а сразу несколько.

Во-первых, компания не закрыла доступ уволенного сотрудника. Это базовая ошибка: учетная запись, которая больше не нужна, не должна жить годами и тем более сохранять пароль, не менявшийся с 2019 года.

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

В-третьих, провайдер не навел порядок с повышением привилегий. Если пользователь может стать root без пароля, то контроль доступа фактически отсутствует. Это не тонкая настройка, а фундаментальная дыра в администрировании.

Наконец, компания слишком поздно заметила саму атаку. По материалам дела, один из серверов был скомпрометирован 30 мая 2025 года, а обнаружили инцидент только 12 июня. За почти две недели злоумышленники успели закрепиться в системе.

3. Уроки для читателя

Этот кейс полезен не только юристам и специалистам по ИБ. Он показывает, что утечки редко начинаются с чего-то экзотического. Чаще всего все ломается на рутине: старый пароль, забытая учетная запись, не поставленное обновление, слишком широкие права.

Для бизнеса вывод прямой: инвентаризация доступов нужна не раз в год, а постоянно. Уход сотрудника должен запускать автоматическую проверку всех его учеток, ключей и прав. Серверы и рабочие станции надо обновлять по графику, а не по настроению администратора.

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

4. Практические выводы и чек-лист

История «Ориона» — это не про один злополучный сервер. Это про культуру, в которой безопасность считают второстепенной задачей, пока не приходит проверка, суд и утечка на десятки тысяч записей.

Компании стоит держать в голове простую логику: если уволенный сотрудник все еще может войти в систему, если root можно получить без пароля, если критические уязвимости месяцами лежат без патча — утечка почти неизбежна. А дальше уже вступают в дело не только техники, но и юристы.

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