Анализ руткита веб-сервера PHP

Компания SophosLabs недавно обнаружила Linux-имплант, связанный с скомпрометированными средами управления политиками доступа (APM) BIG-IP, использующими компоненты Apache и PHP. Вредоносная программа демонстрирует передовые методы, включая загрузку пользовательских ELF-файлов, перехват функций и патчинг кода во время выполнения, чтобы избежать обнаружения, сохраняя при этом постоянный доступ через скрытые веб-оболочки.

Этот имплант обеспечивает привычный результат — выполнение серверного кода по запросу, обычно ассоциируемое с веб-оболочками, — но реализует его с использованием более сложных методов, специфичных для Linux и Apache.

Вредоносная программа нацелена на развертывания, использующие Apache, libphp, загрузку модулей APR, компоненты веб-интерфейса BIG-IP APM и рабочие процессы обновления BIG-IP, что указывает на ее разработку для конкретных сред. F5 связывает активность c05d5254 с системами BIG-IP APM, затронутыми уязвимостью CVE-2025-53521, представляющей собой уязвимость удаленного выполнения кода без аутентификации в BIG-IP APM при настройке политики доступа на виртуальном сервере. Если вы считаете, что используете или использовали затронутые версии BIG-IP APM, следуйте рекомендациям F5 по устранению уязвимостей и оценке компрометации, прежде чем применять общие рекомендации по усилению защиты Apache или PHP.

Наш анализ показывает, что рассматриваемый здесь образец представляет собой полезную нагрузку второго этапа; при параллельном анализе связанного образца umount мы обнаружили отдельный компонент установщика/распространения, ответственный за заражение /usr/sbin/httpd , сохранение активности в образах обновления BIG-IP, изменение конфигураций SELinux и развертывание полезной нагрузки, анализируемой в этой статье. Загрузчик первого этапа ищет рабочие процессы обновления/установки образов BIG-IP, например, в /mnt/tm_install . Примечательно, что размер вредоносного префикса, используемого зараженным httpd (0x5430), совпадает с размером полезной нагрузки, встроенной в образец umount , что убедительно свидетельствует о том, что последний отвечает за развертывание первого.

Второй этап атаки скрывает ключевые операционные строки с помощью RC4, получает доступ к выполнению до вызова функции main() хост-приложения, перехватывая __libc_start_main , атакует модуль PHP Apache, перехватывая загрузчик модулей Apache Portable Runtime (APR) ( apr_dso_load ), и внедряет веб-оболочку PHP в память. Последнее достигается путем манипулирования поведением mmap внутри libphp во время выполнения — таким образом, вредоносное содержимое видит только зараженный процесс, и ничто не затрагивает диск.

Помимо доступа через веб-интерфейс, имплант также создает локальный сокет домена UNIX и может перенаправлять соединение в /bin/bash , обеспечивая интерактивный доступ без открытия TCP-порта для прослушивания.

Судя по текущим публичным сообщениям и нашему анализу, наблюдаемая целевая аудитория сосредоточена на средах BIG-IP APM webtop, а не на стандартных развертываниях Apache/PHP или распространенных CMS.

Примечание: В ходе данного исследования нам стало известно, что исследователи из ESET провели анализ этого вредоносного ПО, которое они назвали «PoisonedRefresh». Наш анализ, проведенный независимо, выявил сходное поведение и предоставляет дополнительные подробности.

SHA256 образца: 26bd5b0722d1dbab5db749a063c49bc8638653ac2addfead7a9cb3d6d57bccc9

Почему это дело важно

Когда специалисты по кибербезопасности слышат «веб-оболочку», они обычно представляют себе небольшой серверный скрипт, часто написанный на PHP, JSP или ASP, размещенный в доступном через веб каталоге для обеспечения постоянного удаленного выполнения кода посредством обычных HTTP-запросов. Скрипт существует в виде файла на диске, возможно, зашифрованного или скрытого среди легитимного контента, но тем не менее обнаруживаемого.

Это предположение определяло логику обнаружения на протяжении многих лет. Аналитики ищут подозрительные скрипты в корневых каталогах веб-сайтов, ищут характерные имена параметров в HTTP-запросах и полагаются на мониторинг целостности файлов для выявления неожиданных изменений.

Некоторые семейства веб-оболочек стали печально известны именно потому, что продемонстрировали, насколько мощной может быть эта простая модель атаки. Например, China Chopper — это хорошо известная веб-оболочка, которую MITRE описывает как предоставляющую доступ через веб-серверы и поддерживающую такие действия, как выполнение команд HTTP POST, операции с файлами и доступ к командному терминалу.

Данный пример ставит под сомнение традиционную модель тремя способами:

• Доставка веб-оболочки без файлов: возможность использования веб-оболочки по-прежнему существует, но больше не привязана к статическому скриптовому файлу на диске. Вместо этого имплант перехватывает загрузку определенных PHP-файлов и добавляет веб-оболочку к их представлению в памяти во время выполнения функции mmap().
• Компромисс на уровне процесса , а не только на уровне приложения: имплант перенаправляет выбранные вызовы функций libc и libphp внутрь рабочих процессов Apache, поэтому каждый компонент на основе PHP, выполняющийся в этом процессе — плагины, сканеры, локальные скрипты — работает в управляемой среде выполнения.
• Двойной канал доступа: злоумышленники могут использовать как PHP-код, работающий по протоколу HTTP, так и локальный бэкдор UNIX-сокета, предоставляющий им интерактивную оболочку без прослушиваемого TCP-порта.

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

Хотя у нас нет достаточных доказательств, чтобы отнести это вредоносное ПО к конкретному злоумышленнику, его целевая направленность и способ реализации указывают на высокую оперативную изощренность.

Веб-оболочка в двух словах

На концептуальном уровне пример объединяет три идеи:

1. Запускается на ранней стадии жизненного цикла процесса. Внедрение выполняется до выполнения обычной логики хост-приложения, перехватывая последовательность запуска libc через __libc_start_main .
2. Действовать следует только при наличии PHP. Перехватывая функции Apache Portable Runtime (APR), в частности apr_dso_load , имплант ожидает, пока Apache загрузит модуль PHP ( libphp ), прежде чем изменять поведение процесса.
3. Предоставьте несколько путей доступа. Веб-оболочка PHP внедряется в представление конкретных PHP-файлов в памяти посредством перехвата функции mmap() внутри libphp , а локальный сокет домена UNIX после аутентификации перенаправляет потоки ввода, вывода и ошибок в /bin/bash , обеспечивая интерактивный доступ к оболочке без использования сетевого слушателя.

Каждый из этих методов сам по себе относительно прост; сложность заключается в том, как они объединены в согласованный, стабильный механизм доступа, специально предназначенный для развертывания на Apache/PHP.

Наш анализ

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

Вместо того чтобы начинать с импорта, мы сосредоточились на следующем:

• Изменение схемы управления потоком выполнения, особенно на этапе запуска процесса.
• Подпрограммы расшифровки строк во время выполнения
• Логика разрешения символов и установки хуков
• Использование интроспекции процессов Linux через /proc
• Точки перехода, где зашифрованные или непрозрачные данные становятся открытым текстом и исполняемыми.

Этот стиль анализа приобретает все большее значение, поскольку вредоносное ПО для Linux все больше отходит от простых имплантаций на диске и переходит к использованию пользовательских загрузчиков, генерации кода во время выполнения, выполнения в оперативной памяти и манипулирования процессами.

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

Этот пример хорошо иллюстрирует ситуацию: вместо того, чтобы обычным способом внедрять обычную веб-оболочку, он изменяет способ представления конкретных PHP-файлов запущенному процессу во время выполнения. Хотя возможности, предоставляемые злоумышленнику, схожи с возможностями традиционной веб-оболочки, реализация устраняет многие артефакты, на которые обычно полагаются защитники. Это подчеркивает важность многоуровневой защиты, которая объединяет видимость файловой системы, памяти, процессов и поведения.

Строки RC4: Следуя по хлебным крошкам

Одной из первых трудностей в понимании этого примера стало широкое использование расшифровки строк во время выполнения. Многие из наиболее важных строк хранятся в зашифрованном виде в разделе .rodata и расшифровываются только по мере необходимости с помощью компактной процедуры RC4.

Вредоносная программа использует потоковый шифр RC4 с жестко закодированным 16-байтовым ключом: TrswBWIl90Z5e38n .

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

После расшифровки во время выполнения программы эти строки раскрывают истинный масштаб и предназначение импланта:

• /proc/self/exe и /proc/self/maps используются для самоинспекции процессов.
• __libc_start_main — подпрограмма запуска libc.
• apr_dso_load и apr_time_now — функции автоматического распознавания количества событий (APR) внутри Apache.
• libphp — модуль PHP, используемый внутри процесса Apache.
• API для работы с файлами и памятью, такие как open , close и mmap.
• Примитивы многопоточности, такие как pthread_create и pthread_detach

Отдельно взятые из этих строк ни одна из них не представляет особого интереса, но вместе они создают картину примера, который понимает внутреннее устройство процессов Linux, среду выполнения Apache и модель выполнения PHP.

Совет для защитников: В этом примере RC4, по-видимому, функционирует в основном как механизм обфускации: он скрывает операционные строки от прямого статического извлечения и откладывает анализ до момента выполнения. Стоит отметить, что, как и в случае с любым образцом, кажущиеся безобидными строковые выходные данные не обязательно означают, что бинарный файл безопасен. При исследовании серверов Linux все чаще встречаются расшифровка строк во время выполнения, динамическое разрешение API и отложенное раскрытие данных конфигурации в более совершенных семействах вредоносных программ для Linux.

Главный заезд гонки для исполнения.

В Linux большинство программ не вызывают функцию main напрямую. Выполнение проходит через код инициализации libc , который подготавливает среду процесса, а затем вызывает main . Критически важным компонентом этой последовательности является __libc_start_main , который выполняет инициализацию и вызывает точку входа программы.

Обычные ELF-файлы Linux следуют проторенной схеме: ядро загружает бинарный файл, динамический компоновщик ( ld.so ) разрешает зависимости, а затем код запуска libc подготавливает окружение и вызывает функцию main . Многие инструменты безопасности и мониторинга используют эту последовательность для получения информации о запуске процессов.

Наш пример отличается от этого пути двумя способами. Во-первых, в точке входа он напрямую переходит к пользовательской подпрограмме загрузчика, а не вызывает __libc_start_main обычным способом. Вместо простого выполнения дополнительного кода, загрузчик повторно открывает свой собственный образ через /proc/self/exe , переходит к смещению, где начинается сохраненный исходный исполняемый файл, и вручную загружает этот встроенный ELF-файл в память.

Рисунок 1: Типичная процедура _start из урезанного, статически скомпилированного 32-битного ELF-файла. Даже без символов точка входа имеет знакомое поведение запуска среды выполнения C: выравнивание стека, настройка аргументов запуска и вызов процедуры запуска libc . Это выделяло зараженную точку входа httpd , поскольку вместо следования этому шаблону она передавала необработанный стек непосредственно в пользовательский загрузчик и останавливалась, если эта процедура возвращала управление.

Рисунок 2: Точка входа программы ( _start ) передает выполнение непосредственно пользовательской подпрограмме загрузчика. В обычном исполняемом файле Linux _start обычно переходит к __libc_start_main , которая в конечном итоге вызывает main() . Отсутствие этой привычной последовательности запуска сразу бросилось в глаза во время анализа и привело к обнаружению пользовательской логики загрузки ELF-файлов и перехвата запуска импланта.

Затем загрузчик анализирует встроенный ELF-файл, проходит по его сегментам PT_LOAD, отображает новую область памяти, копирует содержимое сегментов на нужное место, применяет соответствующие средства защиты памяти, обрабатывает исходный интерпретатор там, где это необходимо, и перенаправляет выполнение через свою собственную оболочку __libc_start_main .

Рисунок 3: Имплант расшифровывает и разрешает __libc_start_main , сохраняет исходную процедуру запуска libc и перезаписывает ее оберткой (подключенной к __libc_start_main ), так что код импланта выполняется до реальной основной программы.

На практике такой подход, когда «принеси свой собственный погрузчик», предоставляет злоумышленнику ряд преимуществ:

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

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

В примере явно используется библиотека __libc_start_main , которая заменяется функцией-оберткой. Концептуально поток выполнения меняется:

_start -> __libc_start_main(main, …) -> main()

к:

_start -> пользовательский загрузчик -> реальный __libc_start_main(wrapper, …) -> wrapper() -> реальный main() wrapper() запускает инициализацию импланта, а затем wrapper() вызывает реальный main

Это обеспечивает вредоносной программе раннее и надежное окно выполнения до того, как основное приложение начнет выполнять значимую работу. Кроме того, это обеспечивает стабильную точку опоры независимо от поведения остальной части приложения, позволяя вредоносной программе инициализироваться один раз, а затем слиться с легитимным процессом.

Перехват логики запуска таким образом также предоставляет злоумышленнику следующие возможности:

• Стабильная единая точка выполнения
• Возможность разрешать API-запросы и устанавливать обработчики событий до начала работы потоков приложения.
• Способ сделать так, чтобы последующие вредоносные действия выглядели как неотъемлемая часть процесса.

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

Совет от Defender: Необычное поведение на самых ранних этапах жизненного цикла процесса, например, доступ к /proc или изменение разрешений доступа к памяти, может быть более информативным, чем активность на более поздних этапах.

Нацеливание на Apache через APR

Получив ранний доступ к выполнению, имплант не пытается немедленно манипулировать всем процессом. Вместо этого он ожидает выполнения определенного условия: загрузки Apache модуля PHP ( libphp ).

APR предоставляет API для динамической загрузки модулей, включая apr_dso_load , которая загружает разделяемые объекты во время выполнения. Перехват этой функции обеспечивает вредоносной программе естественную точку наблюдения за инициализацией модулей, без необходимости гадать или жестко задавать порядок загрузки. Вместо того чтобы без разбора модифицировать каждый процесс Apache, вредоносная программа может дождаться появления целевой среды, прежде чем активироваться.

Наш пример использует механизм apr_dso_load и проверяет пути к загружаемым модулям. Когда вредоносная программа обнаруживает libphp , она изменяет поведение внутри этого модуля.

Рисунок 4: Имплант перехватывает функцию apr_dso_load из APR и явно ограничивает ее поведение модулем PHP, возвращая управление немедленно, если не загружается libphp .

В то же время, в примере используется функция apr_time_now , отвечающая за отображение текущего времени в Apache. Этот API кажется безобидным, но часто вызывается в работающем процессе Apache.

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

Такой подход свидетельствует об операционной зрелости в следующих аспектах:

• Область применения имплантата ограничивается той средой, для которой он предназначен.
• Это позволяет избежать дестабилизации услуг за счет слишком ранних или слишком масштабных действий.
• Он использует собственные абстракции среды выполнения целевой платформы, а не борется с ними.

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

Совет от Defender: В процессах Apache следует исследовать изменения защиты памяти или модификации исполняемых страниц, происходящие вскоре после загрузки libphp.

Поиск библиотеки libphp в памяти

После загрузки PHP импланту необходимо знать, где он находится в памяти процесса. Linux предоставляет эту информацию через /proc/self/maps , который перечисляет все отображения памяти вместе с диапазонами их адресов и файлами-источниками.

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

чтение /proc/self/maps -> найти libphp -> mprotect RWX -> внести изменения в перемещения -> mprotect RX

Чтение файла /proc/self/maps само по себе не является вредоносным. Отладчики, профилировщики и инструменты управления памятью могут законно проверять отображения процессов. Однако это становится гораздо более подозрительным, если за этим сразу же следуют изменения прав доступа к памяти, исправления перемещений и запись в исполняемые области целевой разделяемой библиотеки.

Эта последовательность действий особенно аномальна в рабочих процессах Apache, где у рабочих процессов мало оснований проверять собственные отображения памяти, а затем немедленно изменять исполняемые страницы.

Совет от Defender: Доступ к /proc/self/maps с последующим использованием mprotect() , изменением местоположения или записью в исполняемые области памяти — это важные действия, заслуживающие внимания, особенно в рабочих процессах Apache.

Перенаправление выполнения внутри libphp

Многие специалисты по кибербезопасности знакомы с перехватом вредоносных программ через LD_PRELOAD или изменением записей PLT/GOT . Наш пример использует более точечный подход, сочетая перехват на основе перемещений с прямой перезаписью целевых вызовов внутри libphp , так что выбранные операции сначала перенаправляются в код, управляемый имплантом.

Перед применением этих изменений имплант временно изменяет защиту памяти в целевом отображении libphp , исправляет выбранные цели перемещения и вызовов, а затем восстанавливает исходную защиту.

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

В контексте модуля PHP пример незаметно перенаправляет вызовы, которые обычно обращаются к API файлов и памяти, таким как open , close , mmap и __fxstat , и, следовательно, получает контроль над тем, как PHP открывает, определяет размер, отображает и в конечном итоге выполняет целевые скриптовые файлы. Эти хуки составляют основу для механизма доставки веб-оболочки в память, описанного далее. Это также дает злоумышленнику еще одно преимущество: ему не нужно внедрять новую разделяемую библиотеку в обычный путь загрузчика.

Доставка веб-оболочки посредством отображения в память.

На наш взгляд, это была наиболее отличительная особенность образца. Встроенный модуль перехватывает попытки PHP открыть три конкретных скриптовых файла:

• apm_css.php3
• full_wt.php3
• webtop_popup_css.php3

Эти имена файлов, вероятно, были выбраны из-за их наличия в целевой среде BIG-IP APM webtop, и поэтому вряд ли вызовут подозрения.

Когда PHP открывает один из этих файлов, имплант записывает дескриптор файла. Когда этот файл впоследствии отображается в память, имплант создает измененное представление в памяти, содержащее как встроенную веб-оболочку, так и исходное содержимое скрипта.

Файл на диске вовсе не обязательно должен содержать окончательное содержимое веб-оболочки; выполнение происходит на основе модифицированного представления в памяти, созданного имплантом во время выполнения.

Рисунок 5: Хук mmap() проверяет, принадлежит ли сопоставление отслеживаемому дескриптору файла PHP-скрипта. Если да, то он вызывает исходный mmap() и добавляет встроенную веб-оболочку PHP к сопоставленному содержимому в памяти, оставляя файл на диске без изменений.

Встроенная PHP-память ведёт себя как классическая веб-оболочка, но с несколькими примечательными особенностями:

• Считывает необработанные байты запроса из php://input
• Проверяет наличие короткого магического префикса (BSOHAzPB) в начале тела запроса.
• Расшифровывает оставшуюся часть с помощью небольшого потокового шифра.
• Выполняет расшифрованное содержимое с помощью функции eval.
• Возвращает HTTP-статус 201 и устанавливает Content-Type: text/css; charset=utf-8 для интеграции с обычными запросами ресурсов.

Полезная нагрузка имеет шаблонный характер, при этом ключевые строки перезаписываются во время выполнения, что еще больше усложняет сопоставление статических подписей. В нашем примере маркер запроса (BSOHAzPB) и ключ веб-оболочки (wSLjN1beuR) были добавлены в PHP во время выполнения, а не сохранены непосредственно в их окончательном виде.

Совет от Defender: механизмы обнаружения веб-оболочек должны включать анализ поведения во время выполнения и проверку памяти, а не только сканирование файлов. Для этого класса угроз вполне возможно, что PHP-файл на диске может выглядеть безобидным, в то время как отображение в памяти содержит вредоносный код.

Отложенная активация через apr_time_now

Вместо того чтобы запускать потоки или ресурсоемкие процедуры на ранних этапах запуска, имплант использует свой обработчик события apr_time_now в качестве отложенного триггера.

Когда процесс Apache начинает выполнять обычные вызовы таймера, имплант запускает и отключает рабочий поток, ответственный за создание локального бэкдора UNIX-сокета. Такой подход минимизирует риск дестабилизации сервиса и помогает импланту интегрироваться в нормальное поведение во время выполнения. Он также усложняет работу динамических аналитических сред, которые наблюдают за процессом лишь в течение короткого промежутка времени после его запуска.

Помимо веб-оболочки, работающей по протоколу HTTP, имплант также устанавливает локальный сокет AF_UNIX по адресу /run/bigtlog.pipe, вместо того чтобы предоставлять традиционный TCP-слушатель.

В 32-битных системах Linux операции с сокетами обычно мультиплексируются с помощью исторического системного вызова socketcall , который обрабатывает такие операции, как socket , bind , listen и accept . Встроенный модуль использует этот интерфейс, соответствующий средам x86-32.

После короткой проверки подлинности на основе токена Kzwd6jM5, имплант перенаправляет стандартные потоки ввода, вывода и ошибок в сокет и запускает /bin/bash , что обеспечивает интерактивный доступ к оболочке без открытия TCP-порта для прослушивания, что затрудняет его обнаружение с помощью одного лишь сетевого мониторинга. После успешной аутентификации слушатель остается активным, используя функцию fork() для создания отдельного процесса оболочки, продолжая при этом принимать дополнительные соединения.

Примечательно, что нам не удалось обнаружить никакого встроенного механизма, который позволил бы злоумышленнику подключиться к сокету. Отсутствовал код клиентской части сокета, а также дополнительные упоминания токена аутентификации, что говорит о том, что два метода (веб-оболочка и сокет) представляют собой отдельные возможности. Возможно, злоумышленник может взаимодействовать с сокетом через веб-оболочку, но на данный момент у нас нет доказательств, подтверждающих или опровергающих это.

Рисунок 6: Встроенный модуль передает локальное сокетное соединение непосредственно в /bin/bash , перенаправляя стандартные потоки и выполняя исполняемый файл оболочки.

Совет от Defender: Локальные точки межпроцессного взаимодействия, особенно в каталоге /run , заслуживают пристального внимания при попытках компрометации на стороне сервера.

Защита и оборона

Sophos обнаруживает эту угрозу как Linux/Agnt-IC.

Поиск угроз

Эти действия следует рассматривать как зацепки для расследования и сопоставлять с данными о целостности файлов, процессах, памяти и специфическими для BIG-IP доказательствами, а не использовать в качестве самостоятельного подтверждения.

Сигналы веб-уровня

Проверьте наличие:

• Запросы к указанным выше конечным точкам .php3 , особенно если они редко встречаются в вашей среде.
• PHP-эндпоинты возвращают HTTP 201 , утверждая, что это CSS ( Content-Type: text/css; charset=utf-8 ).
• Повторяющиеся POST-запросы с неизменной структурой или необычными размерами тела к PHP-путям, похожим на CSS.

Сигналы на уровне хоста

Проверьте наличие:

• Рабочие процессы Apache читают /proc/self/maps .
• Временные изменения в правах доступа к памяти при сопоставлении модулей PHP (RWX с последующим RX) в отношении libphp .
• Создание сокета домена UNIX по адресу /run/bigtlog.pipe .
• Процессы Apache lineage перенаправляют стандартный ввод-вывод и выполняют /bin/bash .

Руководство для защитников

Руководство по реагированию на инциденты

При подозрении на наличие этого имплантата:

1. Сначала соберите взрывоопасные улики:
2. Предположим, что доступ возможен с двух сторон:
3. Одного лишь перезапуска службы недостаточно для гарантии:

Укрепление и обнаружение

Хотя каждая среда уникальна, существует несколько общих мер, которые могут снизить воздействие внешних факторов или улучшить видимость:

уменьшение площади атаки

• Если выполнение .php3 не требуется в вашей среде, рассмотрите возможность его отключения после внесения изменений и анализа влияния на приложение. Не применяйте это как повсеместное решение для систем BIG-IP APM без соблюдения рекомендаций F5.
• По возможности отдавайте приоритет конфигурациям, которые минимизируют длительные пути выполнения PHP-кода.
• Ограничьте использование ptrace (это может уменьшить некоторые возможности межпроцессного анализа и внедрения, но не обязательно решит проблему поведения загрузчика и патчера в процессе работы):

echo 1 > /proc/sys/kernel/yama/ptrace_scope

• Добавить в конфигурацию Apache:

Require all denied

• Сведите к минимуму ненужные функции выполнения PHP-кода и, при необходимости, оцените влияние ограничения опасных функций на работу системы.

Мониторинг поведения

• Предупреждение о необычных сочетаниях активности, например, о рабочих процессах Apache:
  • Чтение /proc/self/maps
  • Изменение защиты памяти в libphp
  • Привязка UNIX-сокетов в каталоге /run
  • Запуск /bin/bash
• Ответы HTTP 201 + text/css от PHP-интерфейсов следует рассматривать как подозрительные, если они не являются частью нормального поведения приложения.
• Планируйте реакцию с учетом особенностей памяти:
  • Включите сбор данных из оперативной памяти процессов и сравнение содержимого модулей на диске и в оперативной памяти в сценарии реагирования на инциденты для критически важных веб-серверов.

Заключение

Этот имплант демонстрирует, как современное вредоносное ПО для Linux может предоставлять знакомые злоумышленникам возможности с помощью сложных механизмов доставки. Хотя встроенный PHP в конечном итоге ведет себя как традиционная веб-оболочка, окружающая инфраструктура значительно более продвинута: пользовательская загрузка ELF-файлов, перехват на ранних этапах запуска, мониторинг модулей с учетом APR, исправление перемещений и доставка полезной нагрузки только в память.

На основе анализа связанных с этим образцов umount и зараженного httpd мы пришли к выводу, что эта кампания использует поэтапную архитектуру. Компонент установщика, по-видимому, отвечает за развертывание, поддержание и распространение, в то время как зараженный компонент httpd сосредоточен на возможностях выполнения, манипулировании процессами, доставке веб-оболочки и интерактивном доступе.

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

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

Читать полностью на источнике