В расследовании атаки на корпоративную сеть исследователи увидели редкую для таких инцидентов картину: злоумышленники сидели в инфраструктуре жертвы не меньше 18 месяцев. Группа UNC5221, которую также называют VerdantBamboo, использовала бэкдор Brickstorm и новые загрузки Plenet и AgentPSD, чтобы не потерять доступ даже после частичной очистки сети.

Атака затронула не только среду Microsoft 365, но и управляемого поставщика услуг жертвы. Такой сценарий опасен тем, что одна компрометация тянет за собой другую: сначала заражают подрядчика, потом через него заходят в основную сеть. О похожем длинном «хвосте» атаки мы уже писали в разборе инцидента с SolarWinds Serv-U.

Что произошло и почему это важно

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

Главная проблема таких атак — не громкий взлом, а тихое присутствие. Злоумышленники стараются сливаться с обычным трафиком, обходить стандартные политики доступа и закрепляться в системах, которые редко проверяют вручную.

Чем отличаются Brickstorm, Plenet и AgentPSD

Brickstorm — это основной бэкдор, который исследователи называют продвинутым вредоносным имплантом. Сначала его писали на Golang, а новые варианты появились уже на Rust. Такой переход обычно говорит о развитии инструмента и попытке сделать его гибче и незаметнее.

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

AgentPSD — более простой Python-инструмент, который, по оценке Volexity, служил запасным механизмом закрепления. Если основной канал сломается, такой «резерв» позволяет злоумышленникам не потерять контроль над системой.

Какую схему использовали атакующие

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

Отдельный риск — связка основной компании и MSP, то есть поставщика управляемых ИТ-услуг. Если подрядчик уже заражён, атака на него превращается в короткую дорогу к нескольким клиентским средам сразу. Для администраторов это повод ещё раз проверить не только серверы, но и цепочку доверия между сервисами.

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

Кому какой подход к защите нужен

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

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

Если вы часто подключаетесь к открытым Wi-Fi в аэропорту, кафе или поезде, стоит добавить ещё один слой защиты трафика. В таких случаях пригодится сервис для приватного доступа в дороге — как дополнительная мера, а не замена базовой гигиене безопасности.

Рекомендация

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

Если у вас есть Microsoft 365, удалённый доступ и внешний подрядчик, проверьте, кто и когда подключался к системе, какие учётные записи давно не использовались и где остались включённые сервисы. Именно такие «мелочи» чаще всего и удерживают злоумышленников в сети месяцами.

Практический чек-лист

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