Linux rootkit инжектира злонамерен PHP код без файлове в компрометирани сървъри на F5 BIG-IP

Скрит Linux rootkit дава на атакуващите нов начин да поддържат контрол върху компрометирани сървъри F5 BIG-IP Access Policy Manager.

Вместо да оставя очевиден злонамерен PHP файл, той поставя злонамерен код (web shell) само в паметта, използвана от работещия сървърен процес. Дейността е свързана с среди на BIG-IP APM webtop, работещи с Apache и PHP.

F5 свързва тази дейност с CVE-2025-53521 – експлоатирана уязвимост за отдалечено изпълнение на код без автентификация, риск, който вече бе подчертан в материали за уязвими устройства BIG-IP APM.

Анализатори от Sophos идентифицираха импланта по време на преглед на компрометирани системи. Изследователите посочват, че неговата конструкция загатва за целеви злонамерен код от втори етап, а не за широка атака срещу обикновени инсталации на Apache или системи за управление на съдържанието, като отбелязват, че няма достатъчно доказателства за приписването му на конкретен автор на заплахата.

Въздействието е сериозно, тъй като традиционните проверки на файлове могат да показват чисти PHP скриптове, докато Apache изпълнява модифицирани версии в паметта.

За бизнес, който използва BIG-IP APM за осигуряване на отдалечен достъп, този пропуск може да осигури на нападателя траен контрол от страна на сървъра и незабележим път към защитената инфраструктура.

От Sophos заявяват в доклад, споделен с Cyber Security News (CSN), че имплантът комбинира персонализиран зареждащ модул (loader), прихващане на процеси (process hooks) и динамично коригиране на код в реално време, за да скрие своята работа.

Linux rootkit инжектира злонамерен PHP код без файлове

Зловредният софтуер се стартира преди основната програма да достигне нормалната си функция main. Той отваря собствения си образ, ръчно зарежда оригиналния изпълним файл и прихваща основна стартираща рутина на Linux.

Това ранно установяване му позволява да постави капани, преди да започне нормалната дейност на Apache, и прави конвенционалния мониторинг при стартиране по-малко надежден. След това той следи модулния зареждащ компонент на Apache и се активира само когато се появи PHP компонентът, libphp.

Имплантът променя избрани файлови операции и операции с паметта в този компонент, което му позволява да контролира начина, по който се отварят и картографират конкретни скриптове. Това селективно поведение обяснява защо той може да остане скрит в рамките на легитимна уеб услуга.

Цел са три скрипта на APM webtop. Когато PHP картографира един от тях в паметта, rootkit-ът изгражда модифицирано копие, което съдържа оригиналното съдържание плюс злонамерения код.

Файлът на диска остава непроменен, така че проверките, базирани само на файлове в основната уеб директория, могат да пропуснат пробива за разлика от моделите, наблюдавани при предишни RCE атаки срещу BIG-IP. Инжектираният код приема специално формирани заявки, декриптира тяхното съдържание и ги изпълнява на сървъра.

Той връща отговор HTTP 201, докато се представя като CSS ресурс – необичайна комбинация, която може да се слива с обичайния трафик на ресурси. Това прави уеб логовете, заглавните части на отговорите и моделите на заявките важни доказателства наред с проверките на файловата система.

Задна врата чрез сокет увеличава залозите за реакция

Имплантът също така създава локален Unix сокет и може да прехвърли автентифицирана връзка към Bash shell. Тъй като този канал не отваря нормален слушащ TCP порт, мониторингът само на мрежово ниво може да не го засече.

Констатацията добавя контекст към докладите за киберпрестъпници, използващи устройство BIG-IP за SSH достъп и придвижващи се по-дълбоко в корпоративните мрежи.

Изследователите вярват, че rootkit-ът е част от поетапна операция. Свързан компонент от инсталатора изглежда инфектира бинарния файл на HTTP сървъра, запазва достъпа през изображения за обновяване на BIG-IP, променя настройките на SELinux и внедрява зловредния код по време на работа.

Следователно само рестартирането на услугата не е надеждна стъпка за възстановяване, тъй като може да не премахне по-ранния механизъм за персистентност.

Организациите, които се съмняват в компрометиране, трябва да запазят оперативните доказателства (в оперативната памет), преди да променят хоста, включително паметта на процесите и подробности за работещите процеси.

Те трябва да разследват процесите на Apache, четящи карти на паметта, временни промени за писане и изпълнение около libphp, неочаквани локални сокети и дъщерни процеси, стартиращи Bash.

Администраторите трябва да следват указанията на F5 за отстраняване и оценка на компрометирането за засегнатите версии на APM, преди да прилагат общи промени в Apache или PHP.

Където е оперативно безопасно и прегледано, деактивирането на ненужното наследено изпълнение на PHP може да намали излагането на риск. Екипите трябва също да сравняват съдържанието на диска и паметта, да проверяват PHP крайните точки, връщащи 201 отговори с етикет CSS, и да използват най-новите указания за корекции за сигурност на BIG-IP, за да подредят по приоритет дейностите по отстраняване.

Те трябва също така да потвърдят изображенията за обновяване и да прегледат промените в SELinux, тъй като персистентността извън активния процес на Apache може да преживее рутинно рестартиране на услугата.

Индикатори за компрометиране (IoCs):-

Забележка: IP адресите и домейните са нарочно деактивирани (напр. [.]), за да се предотврати случайно решаване на домейни или последване на връзки. Активирайте ги отново само в контролирани платформи за разузнаване на заплахи като MISP, VirusTotal или вашата SIEM система.