Как именно лег «Аэрофлот»

Привет, %username%! Далее будет небольшой разбор нашумевшей истории о сбое информационных систем компании «Аэрофлот».

28 июля 2025 года около 4:30 утра карта сети «Аэрофлота» начала «гаснуть»: рабочие станции перезагружались и превращались в кирпичи, отвалился корпоративный домен, перестали работать SAP ERP, документооборот и ITSM. Хакеры, имея права администратора в AD, разлили через GPO задачу на стирание данных и удар по домену, после чего единственным способом остановить разрушение стало физически рубить каналы связи и электричество целыми этажами.

На бизнесе это отразилось сразу: более сотни отменённых рейсов, десятки задержанных, очереди в Шереметьево, невозможность переоформить билеты и вернуть деньги. В публичных каналах это аккуратно назвали «сбоем в работе информационных систем», но украинская Silent Crow и белорусские «Киберпартизаны» почти сразу объявили, что это результат их совместной операции, которую они вели около года внутри сети перевозчика.

Жизнь авиакомпании в ручном режиме

Интересная деталь — как именно вытаскивали операционку «с толкача». Пассажирские данные дублировались в «Сирена-Трэвел», и когда стало понятно, что стационарные рабочие станции «мертвые», сотрудники начали работать с ноутбуков вне домена, подключаясь напрямую к бронировочной системе и по сути отправляя рейсы вручную.

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

Подрядчик как входная дверь

Ключевой сюжет статьи — роль относительно небольшой компании «Бакка Софт», которая делала для «Аэрофлота» веб‑приложения и ряд внутренних систем и имела удалённый доступ в инфраструктуру авиакомпании. В январе 2025-го ИБ‑команда зафиксировала подозрительную активность и характерные утилиты и в сети «Аэрофлота», и в сети подрядчика, атаку тогда формально отбили, но, судя по всему, инфраструктуру «Бакка Софт» не дочистили и не пересмотрели модель доверия.

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

Как была устроена защита

ИБ «Аэрофлота» к моменту атаки — это пазл из нескольких вертикалей и вендоров. Есть служба ИБ под security-блоком, есть ИТ‑блок, у каждого свои бюджеты, свои подрядчики (Бастион, Solar, BI.ZONE, «Лаборатория Касперского» и др.), которые делили зоны влияния и проекты. Внутри это выливалось в «войну кошек с собаками» и отсутствие единого владельца ИБ, который отвечает за весь ландшафт end‑to‑end.

Отдельная пикантная деталь — объём мониторинга. В одном из тендеров на SOC‑мониторинг был заложен лимит по событиям, которого хватало примерно на 3% инфраструктуры: что-то вроде сигнализации только на входной двери у огромного дома. На таком фоне «экономия на лицензиях» превращается в прямой системный риск: low‑and‑slow атака, растянутая на год, вполне может жить мимо тех участков, которые видно из SOC.

Техника атаки без магии

С технической точки зрения атака не была чем-то принципиально новым, и в этом, пожалуй, самый неприятный вывод. Использовались модифицированные легитимные админские утилиты для сбора информации и дампов памяти, кастомные модули управления для C2, открытые прокси и туннели вроде Ghost Proxy и HAProxy, чтобы маскировать трафик под нормальную активность.

Часть заявлений хакеров — откровенный PR (истории про «7000 уничтоженных серверов» и «полную базу всех перелётов» выглядят завышенными и до конца не подтверждены). Но факт глубокого компромета и паралича критичных бизнес‑процессов никто не опровергает: Генпрокуратура квалифицировала инцидент как хакерскую атаку, заведено уголовное дело по неправомерному доступу, плюс идёт проверка на халатность ответственных лиц.

Человеческий фактор и политика доступов

Отдельная линия — дисциплина паролей и исключения для топ‑менеджмента. В политике «Аэрофлота» предусмотрена регулярная смена паролей раз в три месяца, но, по данным источников, правило могли снять для гендиректора «не царское это дело», чем хакеры и воспользовались.

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

Что можно вынести для своей практики

Если вытащить из этой истории уроки для SRE/DevOps/DevSecOps, получается очень практичный чек‑лист:

Подрядчик с доступом в прод — это часть твоей инфраструктуры, а не «чужой периметр»: Zero Trust, нормальный мониторинг его активности, регулярные аудиты и право выключить доступ до полной зачистки.
SOC, который видит 3% сети, — это не экономия, а иллюзия контроля: телеметрия должна покрывать не только «красивые» узлы, но и прикладные системы, через которые тихо двигаются злоумышленники.
Исключения для руководителей по паролям и 2FA в итоге аукнутся инженерам и on‑call’ам, которые будут ночами спасать бизнес «из Excel».
Playbook’и инцидентов должны включать сценарии физического отключения и изоляции, с понятным балансом между «сейчас всё рубим» и «даём системе умереть ещё чуть-чуть».
Резервное копирование — это не только про наличие бэкапов, но и про стратегию восстановления: из какой точки, какие доверенные снапшоты, как не вернуть в прод уже скомпрометированные артефакты.

Как тебе эта история теперь, когда разложена чуть глубже? Что для тебя выглядит самым критичным: подрядчики и VPN, слабый мониторинг, организационная «война вертикалей» или человеческий фактор с паролями? Какие изменения ты бы первым делом сделал у себя: расширил покрытие SOC, пересобрал модель доверия к вендорам, устроил IR‑учения с реальным сценарием «всё гаснет», или начал с жёсткого наведения порядка в доступах для руководства?

Если у тебя есть вопросы, комментарии и/или замечания – заходи в чат, а так же подписывайся на канал.

О способах отблагодарить автора можно почитать на странице “Донаты”.