Источник: Microsoft Security Blog — https://www.microsoft.com/en-us/security/blog/2026/05/22/from-edge-appliance-to-enterprise-compromise-multi-stage-linux-intrusion-via-f5-and-confluence/
Разбор Microsoft полезен тем, что первый заметный шаг атаки не был экзотикой. Открытое наружу edge‑устройство F5 BIG-IP стало путем к Linux‑хосту, а дальше атака пошла через внутреннюю разведку, SaaS, приложения и злоупотребление идентичностью.
В этом и есть практический смысл истории. Edge‑устройство больше не просто граница сети. Во многих корпоративных средах оно хранит или может достать учетные данные, сертификаты, сессионные материалы, токены аутентификации, интеграции с каталогами, связи с облаком и доверие провайдера идентичности. После компрометации такого устройства атакующий не просто «внутри сети». Он может оказаться внутри графа доверия.
Microsoft описывает многоэтапное вторжение в Linux, которое началось с доступного из интернета firewall appliance, затем перешло на внутренний Linux‑хост по SSH, после чего затронуло уязвимый Atlassian Confluence и использовало учетные данные для relay‑атак против Active Directory. Источник не раскрывает все детали эксплуатации в сохраненном материале, и это важно. Главный урок не в одной «магической» CVE. Главный урок — в цепочке.
Что изменилось#
В центре кейса Microsoft — балансировщик F5 BIG-IP, определенный как Azure‑устройство на BIG-IP Virtual Edition версии 15.1.201000. Microsoft отмечает, что срок поддержки этой версии закончился 31 декабря 2024 года.
Это не мелкая деталь. Edge‑инфраструктура с истекшим сроком поддержки — ценная точка входа: она остается открытой наружу, но теряет запас безопасности, который дают актуальная поддержка и поток исправлений. Окна обслуживания, заморозки изменений, расхождение шаблонов и инерция облачных развертываний приводят к одной практической ошибке: доверенное устройство продолжает работать после того, как его риск уже изменился.
В инциденте атакующий получил SSH‑доступ к Linux‑серверу с F5‑устройства, используя привилегированную учетную запись. Microsoft пишет, что этот уровень доступа сохранялся на протяжении наблюдаемой активности без явной настройки persistence. Это сильный сигнал. Если чрезмерно привилегированная учетная запись уже дает стабильный sudo‑доступ, атакующему может не понадобиться шумный механизм закрепления.
Затем началась широкая разведка. Microsoft описывает перебор файлов, сканирование внутренних подсетей, обнаружение сервисов и использование скриптового Nmap. Схема сканирования сначала была горизонтальной, затем вертикальной: найти связанные активы, потом изучить открытые сервисы на них.
Атакующий также использовал gowitness для просмотра HTTP и HTTPS‑сервисов, найденных при сканировании, включая снимки экранов и фильтрацию сервисов. Там, где находились Windows‑серверы, он пробовал типичные техники lateral movement на базе NTLM с open-source инструментами. Microsoft пишет, что эти первые попытки не удались.
После этого атакующий скачал собственный инструмент сканирования с внешнего IP‑адреса, указанного в разборе Microsoft, и применил его для разведки web‑инфраструктуры. Судя по описанию, инструмент взаимодействовал с приложениями и мобильными сервисами организации, вероятно чтобы понять механизмы доступа и достижимые системы.
Во время внутренней разведки атакующий, по сводке Microsoft, нашел сервер Confluence с неустановленными исправлениями. Сохраненный исходный текст обрывается до полной секции про Confluence, поэтому читать его нужно аккуратно: Microsoft связывает путь от appliance к Linux с дальнейшей компрометацией SaaS/приложений и злоупотреблением учетными данными, но в этом фрагменте не сохранен каждый шаг.
Почему этот кейс важен#
Самый сильный урок — про перекос в мониторинге. Edge‑устройства открыты наружу, им доверяют, но их часто мониторят слабее, чем рабочие станции и серверы. Linux‑системы и сетевые устройства могут находиться вне самой полной зоны EDR. SaaS‑платформы и системы идентичности могут логироваться, но не всегда жестко коррелируют с активностью appliance.
Этот разрыв дает атакующему пространство для движения между доменами. Firewall или балансировщик становится первичной точкой опоры. Linux‑хост — рабочей платформой. Confluence — источником учетных данных. Active Directory — зоной последствий.
Поэтому фраза «edge‑устройство» занижает риск. Такие устройства часто стоят на пересечении сетевого доступа, доставки приложений, работы с сертификатами, поведения VPN или proxy и интеграции с идентичностью. Они по замыслу упрощают эксплуатацию инфраструктуры. Эти же сокращения превращаются в маршруты атаки, когда ломаются поддержка, учетные данные или видимость.
Кейс также ослабляет привычное защитное предположение: если lateral movement не сработал, значит сдерживание работает. Microsoft отмечает, что первые попытки на базе NTLM не удались, но атакующий продолжил работу. Он сканировал дальше, менял инструменты и искал слабости в web‑инфраструктуре и приложениях. Заблокированная техника не означает остановленное вторжение, если оператор все еще имеет привилегированный доступ к Linux.
Именно эту часть командам security operations стоит воспринимать серьезно. Атаке не понадобилась одна прямая линия от периметра до компрометации домена. Она использовала доступное доверие. Поэтому ее сложнее увидеть средствами, которые смотрят только на один слой.
Что проверить до активных действий#
Начинайте с инвентаризации, а не с паники. Практический вопрос простой: актуален ли ваш парк открытых edge‑устройств, поддерживается ли он, мониторится ли он и сопоставлены ли идентичности, которые он может использовать или до которых может дотянуться.
Если F5 актуален для вашей среды, проверьте следующее:
- Найдите все доступные из интернета развертывания BIG-IP и BIG-IP VE.
- Подтвердите версии и статус поддержки, особенно для облачных образов, созданных из старых ARM templates, Terraform modules или скопированных шаблонов развертывания.
- Проверьте, не работает ли какой-либо BIG-IP на ПО с истекшим сроком поддержки.
- Проверьте exposure management‑доступа, SSH‑пути и административные учетные записи.
- Убедитесь, что логи appliance сохраняются и доступны для поиска в том же процессе, что и endpoint‑, identity‑ и cloud‑логи.
Затем проверьте граф доверия вокруг appliance:
- Какие привилегированные учетные записи могут аутентифицироваться с него?
- Хранит ли он или использует ли сертификаты, токены, сервисные учетные данные или интеграции с каталогом?
- Может ли он достигать внутренних Linux‑хостов, management‑сетей, Confluence, CI/CD‑систем или сервисов идентичности?
- Узкие и обоснованные ли sudo‑права на достижимых Linux‑системах?
- Считаются ли события аутентификации с edge‑устройств сильным сигналом или воспринимаются как обычный шум?
Для Linux‑хостов ищите признаки, совпадающие с поведением, а не только известный вредоносный файл. Источник Microsoft выделяет hands-on-keyboard SSH‑доступ, скриптовое сканирование Nmap, использование gowitness, загрузки через wget с внешней инфраструктуры и разведку web‑сервисов. Это операционные действия. Они могут быть важнее одного хеша файла.
Для Confluence и похожих внутренних приложений статус исправлений — только часть проверки. Смотрите доступность из внутренних Linux‑систем, хранение учетных данных, сервисные учетные записи, риск плагинов и логи необычной аутентификации или enumeration. Если внутреннее приложение может стать мостом между доступом к хосту и компрометацией идентичности, его нужно расследовать в той же цепочке, что и edge‑устройство.
Чего не стоит утверждать сверх фактов#
Не сводите инцидент к формуле «F5 был уязвим» или «Confluence был уязвим». Рамка Microsoft шире: доступные из интернета edge‑устройства все чаще используются как точки начального доступа, а компрометация может каскадом пройти через Linux‑хосты, SaaS‑приложения, cloud workloads и системы идентичности.
Не стоит также считать, что сохраненный фрагмент доказывает конкретный путь эксплуатации на каждом этапе. В нем названы версия F5 BIG-IP VE и ее end-of-life статус, описан SSH‑доступ с устройства, а также разведка и дальнейшее злоупотребление приложениями и идентичностью. Но фрагмент не сохраняет все технические детали из полного поста Microsoft.
Есть еще одна граница, которую важно держать. В активности встречаются open-source инструменты, включая Nmap и gowitness, а Microsoft упоминает типичные инструменты lateral movement через NTLM. Это не делает open source проблемой. Операционная проблема в другом: распространенные инструменты смешиваются с реальной админской средой, если security operations не умеют привязывать их использование к контексту — кто запустил, откуда, после какой аутентификации и против каких активов.
Это различие важно и для безопасности open source. Полезная реакция — не считать публичные инструменты подозрительными по умолчанию. Полезная реакция — сделать security artifacts пригодными для эксплуатации: инвентаризация, версии, provenance, логирование и повторяемые проверки. Мы разбирали тот же принцип в материалах про сигналы OpenSSF и покрытие пакетов тестами: artifacts помогают только тогда, когда команды могут действовать по ним в production. См. также: https://gigatap.top/en/articles/openssfs-april-signal-make-security-artifacts-operational и https://gigatap.top/en/articles/100-package-test-coverage-is-the-point-not-the-slogan
Практический вывод#
Рассматривайте каждое открытое наружу edge‑устройство одновременно как инфраструктурный риск и как риск для идентичности. Если ему доверяют маршрутизацию трафика, завершение сессий, хранение сертификатов или доступ к внутренним сервисам, его нужно мониторить как одну из ключевых систем.
Минимальные операционные проверки понятны: поддерживаемые версии, жестко ограниченный административный доступ, searchable логи, сопоставленные trust relationships, ограниченные sudo‑пути, актуальные исправления внутренних приложений и identity telemetry, которая может проследить цепочку через сеть, Linux, SaaS и Active Directory.
Путь атакующего, описанный Microsoft, опасен не потому, что он редкий и сложный. Он опасен потому, что использует предприятие таким, каким оно уже построено.