Современные кибератаки всё чаще начинаются не с фишинговых писем, а с компрометации пограничных сетевых устройств - межсетевых экранов, VPN-шлюзов и балансировщиков нагрузки. Эти системы традиционно считаются элементами защиты, но из-за постоянного выявления критических уязвимостей они превращаются в удобную точку входа. Злоумышленники получают закрепление на устройстве, которое имеет высокий уровень доверия внутри корпоративной сети, и при этом зачастую слабо мониторится. В недавно зафиксированном инциденте атакующие использовали именно такой сценарий, начав с устаревшего облачного экземпляра F5 BIG-IP и завершив попытками захвата контроллера домена.
Описание
Событие разворачивалось в гибридной среде, где часть инфраструктуры размещалась в облаке Azure. Первоначальный доступ злоумышленники получили через межсетевой экран F5 BIG-IP Virtual Edition версии 15.1.201000. Эта версия больше не поддерживается производителем: она достигла конца жизненного цикла (EOL) ещё 31 декабря 2024 года. Устройство работало в облаке и, очевидно, не получало обновлений безопасности. Как только атакующие установили SSH-соединение (протокол защищённого доступа к командной оболочке) с этим балансировщиком, они сразу перешли на внутренний Linux-сервер, используя привилегированную учётную запись. Примечательно, что для последующего закрепления они не применяли никаких дополнительных механизмов - доступ оставался активным на протяжении всей атаки, поскольку учётная запись обладала правами суперпользователя.
Попав на Linux-хост, злоумышленники провели активную разведку. Они запустили Nmap (сканирование сети для обнаружения активных хостов и открытых портов) как по горизонтали - для выявления всех подключенных устройств, так и по вертикали - для детального изучения сервисов на найденных серверах. Для снятия скриншотов веб-интерфейсов они использовали утилиту gowitness, а затем проанализировали HTTP- и HTTPS-сервисы. На этом этапе атакующие попытались применить стандартные техники бокового перемещения к Windows-серверам с помощью таких инструментов, как enum4linux, netexec, smbclient, responder и других. Однако эти попытки не удались: целевые Windows-системы оказались достаточно хорошо защищены. Как сообщается в аналитическом материале, описывающем инцидент, тогда злоумышленники сменили тактику и загрузили с удалённого сервера 206.189.27[.]39 специализированный инструмент сканирования, который антивирус детектировал как вредоносный (HackTool:Linux/MalPack.B). Эта программа изучала веб-приложения и мобильные сервисы организации, с которыми взаимодействовал скомпрометированный Linux-сервер, - скорее всего, для выявления слабых мест в контроле доступа.
Следующей целью стал внутренний сервер Atlassian Confluence. Хотя этот сервер не был доступен из интернета, после получения доступа к локальной сети атакующие обнаружили на нём неисправленные уязвимости. Они попытались выполнить код удалённо, но первоначальные попытки сброса полезной нагрузки блокировались - предположительно, на сетевом уровне. Тогда злоумышленники организовали собственный FTP-сервер (протокол передачи файлов) на первом Linux-хосте с помощью модуля Python ftplib и через него передали инструмент сканирования на Confluence. После успешной эксплуатации сервера они извлекли учётные данные из конфигурационных файлов Confluence: server.xml и confluence.cfg.xml. Эти логины и пароли, принадлежавшие учётной записи Jira-сервиса, они затем использовали для аутентификации в Windows-среде. Началась вторая волна бокового перемещения, нацеленная уже на контроллер домена.
Получив доступ от имени Jiraservices, атакующие провели ретрансляционные атаки на протокол аутентификации Kerberos (система проверки подлинности в сетях Windows) и применили эксплуатацию уязвимости CVE-2025-33073. Они вручную выполнили команды с инструментами nxc, dnstool и скриптом для CVE-2025-33073, пытаясь принудительно аутентифицировать контроллер домена через PetitPotam и изменить DNS-записи. Параллельно они проверяли SSL/TLS-соединения на предмет слабых настроек, которые могли бы позволить понизить уровень шифрования. Вся эта активность велась вручную (hands-on keyboard), что свидетельствует о целенаправленном и настойчивом характере атаки.
Этот инцидент наглядно демонстрирует, как единственная уязвимость в пограничном устройстве может запустить цепочку событий, пересекающую платформенные и доверительные границы. Даже при хорошей защите Windows-систем, недостаточный мониторинг Linux-серверов и задержки с установкой обновлений привели к тому, что атакующие смогли украсть учётные данные из внутреннего веб-приложения и использовать их для атак на каталог Active Directory. Устаревший межсетевой экран стал входной дверью, а слабо защищённый внутренний Confluence - источником критических паролей. Злоумышленники не применяли сложных техник, но их систематичность и время, потраченное на разведку, позволили им продвигаться всё глубже, пока не возникла реальная угроза компрометации всего домена.
Для предотвращения подобных сценариев организациям необходимо пересмотреть отношение к пограничным устройствам. Каждый межсетевой экран, VPN-концентратор или балансировщик нагрузки следует считать активом нулевого уровня доверия: контролировать срок его поддержки, своевременно устанавливать патчи, а если обновление невозможно - ограничивать доступ к панелям управления и усиливать мониторинг необычной административной активности. Столь же пристального внимания требуют внутренние веб-приложения. Confluence, как и другие серверы совместной работы, часто содержат конфиденциальные данные и учётные записи, но при этом не считаются первоочередными целями для патчинга. Атака показала: наличие сетевого периметра не спасает, если внутри остаются неисправленные сервисы. Наконец, критически важно внедрять защиту от ретрансляционных атак: отключать NTLM там, где это возможно, включать подпись SMB, шифрование LDAP и расширенную защиту аутентификации. Комбинация этих мер, вместе с сегментацией административных учётных записей, способна разорвать цепочку, по которой одна украденная пара логин-пароль ведёт к захвату всего домена.
Индикаторы компрометации
IPv4
- 206.189.27.39
SHA256
- 4a927d031919fd6bd88d3c8a917214b54bca00f8ddc80ecfe4d230663dda7465
- 57b3188e24782c27fdf72493ce599537efd3187d03b80f8afe733c72d68c5517
- 710a9d2653c8bd3689e451778dab9daec0de4c4c75f900788ccf23ef254b122a
- b4592cea69699b2c0737d4e19cff7dca17b5baf5a238cd6da950a37e9986f216
- bdd5da81ac34d9faa2a5118d4ed8f492239734be02146cd24a0e34270a48a455
