Команда Microsoft Defender Security Research Team опубликовала детальный разбор атак, в которых злоумышленники используют HTTP-куки для управления PHP-шеллами на Linux-серверах. Техника необычна тем, что вредоносный код на сервере не делает ровно ничего, пока не получит HTTP-запрос со строго определённым набором значений в куках. Обычный трафик проходит мимо, логи чисты, сканеры молчат.
Традиционно веб-шеллы принимают команды через GET- или POST-параметры. Это давно известно защитным решениям: WAF-ы и системы логирования фильтруют URL-строки и тела запросов. Куки же практически не попадают под такой контроль. Они легко доступны в PHP через суперглобальную переменную
Первоначальный доступ к серверу атакующие получают двумя основными путями: либо используют украденные легитимные учётные данные, либо эксплуатируют известные уязвимости. Ничего экзотического на этом этапе нет. Интереснее то, что происходит дальше. После проникновения создаётся задача cron, которая периодически запускает обфусцированный PHP-загрузчик. Если администратор находит и удаляет вредоносный файл, cron-задача пересоздаёт его заново. Microsoft описывает это как «самовосстанавливающуюся» архитектуру. Канал удалённого исполнения кода (RCE) таким образом сохраняется даже после частичной зачистки.
Microsoft выделила три разных модели реализации этих шеллов. Первая — обфусцированный PHP-загрузчик с несколькими уровнями запутывания и проверками среды выполнения. Он разбирает структурированные данные из куки и запускает закодированную вторичную нагрузку. Вторая модель — сегментированный PHP-скрипт, который разбивает данные из куки на части, восстанавливает из них рабочие компоненты (декодирование, работа с файлами), записывает вторичную нагрузку на диск и исполняет её при выполнении определённых условий. Третья — маркерный скрипт, где одно значение куки работает как простой триггер: если нужная кука есть, скрипт выполняет переданные команды или загружает файлы на сервер.
Разделение функций между механизмом управления и механизмом закрепления — пожалуй, самая неприятная черта этой техники с точки зрения обнаружения. Куки отвечают за передачу команд, cron обеспечивает постоянство. В стандартных логах приложений это почти не оставляет следов. Атакующие при этом не городят сложные цепочки эксплойтов, а пользуются штатной инфраструктурой: процессами веб-сервера, компонентами панелей управления хостингом, плановыми задачами cron. Всё выглядит легитимно.
Обфускация кода дополнительно маскирует функциональность. Даже если файл найден, его содержимое не всегда очевидно для администратора, который не занимается реверс-инжинирингом PHP каждый день. А с учётом того, что шелл активируется только при наличии конкретных кук, стандартное автоматическое сканирование файловой системы может не зафиксировать вредоносное поведение. Файл лежит на диске, но ведёт себя как обычный PHP-скрипт — до момента, когда атакующий решит его «разбудить».
Microsoft рекомендует шесть конкретных мер противодействия. Первая — включить многофакторную аутентификацию (MFA) на панелях управления хостингом, SSH-доступе и административных интерфейсах. Вторая — мониторить необычную активность при входе в систему. Третья — ограничить выполнение интерпретаторов командной строки. Четвёртая — проводить аудит cron-задач на всех веб-серверах, причём регулярно, а не от случая к случаю. Пятая — отслеживать подозрительное создание файлов в директориях веб-сервера. Шестая — ограничить возможности командной оболочки, доступные через панели управления хостингом.
Отдельно стоит обратить внимание на рекомендацию по аудиту cron. Администраторы нередко проверяют crontab текущего пользователя и на этом успокаиваются. Но задачи могут быть созданы от имени других пользователей, размещены в /etc/cron.d/ или зарегистрированы через systemd-таймеры. Регулярная проверка всех этих мест — дело муторное, но именно на этом построена «самовосстанавливающаяся» часть атаки.
Описанная Microsoft техника показательна ещё и тем, насколько мало ресурсов нужно атакующему для поддержания доступа. Один cron-job, один небольшой PHP-файл, пара значений в куках. Никаких экзотических бэкдоров, никаких руткитов на уровне ядра. Защита от подобных атак требует не столько дорогих инструментов, сколько дисциплины: контроля учётных записей, регулярного аудита и внимания к тому, что происходит на сервере за пределами стандартных логов веб-приложения.
Изображение носит иллюстративный характер
Традиционно веб-шеллы принимают команды через GET- или POST-параметры. Это давно известно защитным решениям: WAF-ы и системы логирования фильтруют URL-строки и тела запросов. Куки же практически не попадают под такой контроль. Они легко доступны в PHP через суперглобальную переменную
$_COOKIE, не требуют дополнительного парсинга и естественно присутствуют в любом HTTP-запросе к веб-серверу. Злоумышленники, по сути, прячут команды у всех на виду. Первоначальный доступ к серверу атакующие получают двумя основными путями: либо используют украденные легитимные учётные данные, либо эксплуатируют известные уязвимости. Ничего экзотического на этом этапе нет. Интереснее то, что происходит дальше. После проникновения создаётся задача cron, которая периодически запускает обфусцированный PHP-загрузчик. Если администратор находит и удаляет вредоносный файл, cron-задача пересоздаёт его заново. Microsoft описывает это как «самовосстанавливающуюся» архитектуру. Канал удалённого исполнения кода (RCE) таким образом сохраняется даже после частичной зачистки.
Microsoft выделила три разных модели реализации этих шеллов. Первая — обфусцированный PHP-загрузчик с несколькими уровнями запутывания и проверками среды выполнения. Он разбирает структурированные данные из куки и запускает закодированную вторичную нагрузку. Вторая модель — сегментированный PHP-скрипт, который разбивает данные из куки на части, восстанавливает из них рабочие компоненты (декодирование, работа с файлами), записывает вторичную нагрузку на диск и исполняет её при выполнении определённых условий. Третья — маркерный скрипт, где одно значение куки работает как простой триггер: если нужная кука есть, скрипт выполняет переданные команды или загружает файлы на сервер.
Разделение функций между механизмом управления и механизмом закрепления — пожалуй, самая неприятная черта этой техники с точки зрения обнаружения. Куки отвечают за передачу команд, cron обеспечивает постоянство. В стандартных логах приложений это почти не оставляет следов. Атакующие при этом не городят сложные цепочки эксплойтов, а пользуются штатной инфраструктурой: процессами веб-сервера, компонентами панелей управления хостингом, плановыми задачами cron. Всё выглядит легитимно.
Обфускация кода дополнительно маскирует функциональность. Даже если файл найден, его содержимое не всегда очевидно для администратора, который не занимается реверс-инжинирингом PHP каждый день. А с учётом того, что шелл активируется только при наличии конкретных кук, стандартное автоматическое сканирование файловой системы может не зафиксировать вредоносное поведение. Файл лежит на диске, но ведёт себя как обычный PHP-скрипт — до момента, когда атакующий решит его «разбудить».
Microsoft рекомендует шесть конкретных мер противодействия. Первая — включить многофакторную аутентификацию (MFA) на панелях управления хостингом, SSH-доступе и административных интерфейсах. Вторая — мониторить необычную активность при входе в систему. Третья — ограничить выполнение интерпретаторов командной строки. Четвёртая — проводить аудит cron-задач на всех веб-серверах, причём регулярно, а не от случая к случаю. Пятая — отслеживать подозрительное создание файлов в директориях веб-сервера. Шестая — ограничить возможности командной оболочки, доступные через панели управления хостингом.
Отдельно стоит обратить внимание на рекомендацию по аудиту cron. Администраторы нередко проверяют crontab текущего пользователя и на этом успокаиваются. Но задачи могут быть созданы от имени других пользователей, размещены в /etc/cron.d/ или зарегистрированы через systemd-таймеры. Регулярная проверка всех этих мест — дело муторное, но именно на этом построена «самовосстанавливающаяся» часть атаки.
Описанная Microsoft техника показательна ещё и тем, насколько мало ресурсов нужно атакующему для поддержания доступа. Один cron-job, один небольшой PHP-файл, пара значений в куках. Никаких экзотических бэкдоров, никаких руткитов на уровне ядра. Защита от подобных атак требует не столько дорогих инструментов, сколько дисциплины: контроля учётных записей, регулярного аудита и внимания к тому, что происходит на сервере за пределами стандартных логов веб-приложения.
