Rootkit F5 BIG-IP научился прятать веб-шелл там, где его сложнее всего заметить: не в файлах, а прямо в памяти Apache. Вредоносный модуль атакует среды BIG-IP APM, перехватывает загрузку PHP-файлов и подмешивает код на лету, не оставляя измененных скриптов на диске. Для команд ИБ и администраторов это неприятный сценарий: привычная проверка файловой системы может показать чистую картину, пока сервер уже выполняет команды злоумышленников.
О кампании сообщает BleepingComputer со ссылкой на исследование Sophos. По данным исследователей, вредонос выглядит как полезная нагрузка второго этапа: сначала атакующие, вероятно, получали доступ через CVE-2025-53521, критическую уязвимость удаленного выполнения кода в F5 BIG-IP APM. Интересная деталь: F5 в марте переклассифицировала эту проблему из DoS в RCE, то есть из «может уронить сервис» она превратилась в «может дать выполнение кода». Разница для эксплуатации, мягко говоря, не косметическая.
Sophos изучила образец, который ESET отдельно отслеживает под названием PoisonedRefresh. По описанию исследователей, это не обычный веб-шелл, брошенный в каталог сайта с надеждой, что его не заметят. Установщик заражал Apache-бинарь /usr/sbin/httpd на BIG-IP APM, менял настройки SELinux и добивался сохранения после обновления образов BIG-IP. То есть операторы думали не только о первичном запуске, но и о жизни после патча, перезагрузки и планового обслуживания.
Технически rootkit F5 BIG-IP работает на уровне, который ближе к системному импланту, чем к типичной PHP-закладке. Он скрывает рабочие строки с помощью RC4, получает управление еще до вызова main() у хостового приложения через перехват __libc_start_main, а затем цепляется за загрузчик модулей Apache Portable Runtime через apr_dso_load. Цель — PHP-модуль Apache: когда сервер обрабатывает легитимные PHP-скрипты, имплант меняет их копии в памяти и внедряет туда веб-шелл.
На диске при этом скрипты остаются прежними. Sophos упоминает несколько файлов, которые, вероятно, выбраны из-за их роли в BIG-IP APM webtop-средах: apm_css.php3, full_wt.php3 и webtop_popup_css.php3. Они выглядят как нормальная часть инфраструктуры удаленного доступа и портала, поэтому реже вызывают подозрения. Для атакующих это удобно: меньше следов в файловых контрольных суммах, меньше шума в классических проверках целостности, больше шансов пережить поверхностный аудит.
Встроенный веб-шелл реагирует не на любой запрос, а на специально сформированные «магические» обращения. Содержимое таких запросов расшифровывается, выполняется через PHP-функцию eval(), а ответ возвращается как HTTP 201 с типом text/css. Маскировка под CSS выглядит почти грубо, но в больших логах такие вещи часто тонут: кто будет вручную читать каждую отдачу статики с пограничного устройства, особенно если сервис не падает и пользователи не жалуются?
Еще одна деталь показывает аккуратность операторов. При старте Apache имплант не сразу создает локальный бэкдор, а ждет рутинных вызовов времени. Затем он запускает отдельный worker-поток и создает защищенный паролем UNIX-сокет. Через него можно поднять интерактивный Bash, не открывая TCP-порт наружу. Снаружи такой канал напрямую не виден, но для его использования атакующим нужен другой foothold на устройстве. Sophos не определила компонент, который взаимодействует с этим сокетом.
Для защитников список сигналов выглядит вполне конкретно. Подозрение должны вызывать Apache-процессы, которые читают /proc/self/maps, меняют права памяти у libphp, создают /run/bigtlog.pipe или запускают /bin/bash. В сетевых логах стоит искать необычные POST-запросы к упомянутым .php3-эндпоинтам, а также странную пару: HTTP 201 и text/css в PHP-ответе. Это не серебряная пуля, но хороший набор индикаторов для охоты по событиям, EDR-телеметрии и SIEM-корреляциям.
Масштаб риска тоже не абстрактный. ShadowServer Foundation, которая отслеживает доступные из интернета F5 BIG-IP APM с CVE-2025-53521, сообщала о 795 exposed endpoints накануне публикации материала. Для глобального интернета число не выглядит огромным, но BIG-IP APM обычно стоит не на витринном лендинге стартапа, а на периметре компаний, где через него проходят удаленный доступ, корпоративные приложения и аутентификация. Один такой узел может быть ценнее десятков случайных веб-серверов.
История с PoisonedRefresh хорошо ложится в общий тренд: атакующие все меньше полагаются на файлы, которые можно найти, и все чаще живут в памяти, в легитимных процессах и в странностях runtime-поведения. Для бизнеса вывод неприятный, но практичный: патчить F5 нужно быстро, однако патч сам по себе не доказывает, что устройство не было взломано до обновления. После RCE на периметре нужен отдельный постинцидентный разбор: процессы, память, логи Apache, SELinux-изменения, сохранность образов и любые следы локальных сокетов. Следующий рубеж защиты для таких устройств — не только закрыть CVE, а научиться видеть, что происходит внутри уже запущенного сервиса.