На сучасних Linux-хостингах фіксується зростання цілеспрямованих атак, у яких зловмисники використовують HTTP cookies як канал керування PHP web shell. За даними команди Microsoft Defender Security Research, ця техніка дозволяє підтримувати малопомітний віддалений доступ до скомпрометованих серверів і виконувати команди, майже не залишаючи характерних слідів у журналах подій.
Як працює cookie-based PHP web shell на Linux-серверах
Традиційно web shell приймають команди через параметри URL або тіло HTTP-запиту. У новому підході вся логіка керування переноситься у значення HTTP cookies. Вбудований у сайт шкідливий PHP-код зчитує дані з суперглобального масиву $_COOKIE та активує прихований функціонал лише за наявності певних значень.
Такий механізм дає зловмисникам одразу кілька переваг. По‑перше, web shell залишається «пасивним» під час звичайної роботи веб-додатку. По‑друге, запити з командами практично не відрізняються від легітимного трафіку, оскільки cookies масово використовуються для авторизації, персоналізації та аналітики, а отже рідко піддаються глибокому аналізу.
Cookie-gated execution: «заперте» виконання шкідливого коду
Дослідники визначають цю техніку як cookie-gated execution — виконання коду, «заблоковане» умовою наявності конкретних cookies. У такому режимі шкідлива логіка може бути вбудована в:
- звичайні HTTP-запити до веб-додатку;
- заплановані задачі та фонові процеси;
- background workers і системні сервіси, яким адміністратори зазвичай довіряють.
Поки у запиті відсутня «правильна» cookie, скрипт виглядає як звичайний, безпечний фрагмент коду. Щойно з’являється наперед узгоджене значення, активується повноцінний PHP web shell: запускаються системні команди, завантажується додатковий шкідливий код, змінюються конфігурації або створюються нові точки входу.
Персистентність через cron і «самовідновлюваний» PHP-loader
В одному з задокументованих інцидентів зловмисники отримали початковий доступ до Linux-хостингу через компрометовані облікові дані або відому вразливість веб-додатку. Далі вони створили cron-задачу, яка регулярно запускала оболонковий скрипт, що у свою чергу завантажував та виконував обфусцований PHP-loader.
Такий підхід дослідники називають self-healing («самоіснуючою» або «самовідновлюваною») архітектурою. Якщо адміністратор виявляє та видаляє підозрілий PHP-файл, cron при наступному спрацюванні автоматично відновлює loader. У результаті формується стійкий канал віддаленого виконання коду, який складно ліквідувати одноразовим очищенням файлів.
Варто підкреслити, що сам PHP-loader більшу частину часу залишається неактивним. Його логіка запуску жорстко прив’язана до HTTP-запитів із правильно сформованими cookies. Персистентність забезпечує cron, а керування здійснюється через cookies, що значно знижує рівень «шуму» в логах і ускладнює розслідування інциденту без глибокого аналізу заголовків.
Обфускація PHP-коду та маскування трафіку через cookies
Характерною ознакою cookie-based web shell є : зловмисники шифрують рядки, імена змінних і функцій, використовують динамічне формування та виконання коду. Це істотно ускладнює статичний аналіз і виявлення шкідливих фрагментів за сигнатурами.
Другий ключовий елемент — cookie-based gating, коли виконання небезпечних операцій суворо залежить від вмісту cookies. У журналах веб-сервера такі запити майже не виділяються на фоні легітної активності, особливо якщо заголовки HTTP cookies не зберігаються або не аналізуються засобами моніторингу.
Чому cookie-based web shell становлять підвищений ризик для Linux-інфраструктури
Web shell уже багато років залишаються одним з основних інструментів постексплуатації при атаках на веб-сервери. У сценаріях, що спостерігаються сьогодні, зловмисники не завжди будують складні ланцюжки атак, а максимально використовують стандартні механізми самого середовища:
- процеси веб-сервера (Apache, Nginx у зв’язці з PHP-FPM);
- хостинг-панелі керування та їхні агенти;
- системний планувальник завдань cron.
Це дозволяє обходити частину традиційних засобів захисту, зосереджених на виявленні експлойтів, аномальних HTTP-параметрів або підозрілих бінарних файлів. Керування через HTTP cookies додатково ускладнює роботу WAF, IDS/IPS і систем моніторингу, якщо ті не аналізують або не зберігають вміст cookies для подальшого розбору.
Рекомендації з кіберзахисту Linux-хостингів і PHP веб-серверів
Щоб мінімізувати ризики використання cookie-based PHP web shell, доцільно впроваджувати комплексний захист Linux-інфраструктури. Ключові технічні заходи включають:
- Многофакторну аутентифікацію (MFA) для хостинг-панелей, SSH-доступу, панелей адміністрування CMS і внутрішніх інтерфейсів підтримки.
- Моніторинг аномальної активності входу: авторизації з нетипових IP‑адрес, незвичних геолокацій, підозрілого часу або масових спроб входу.
- Обмеження виконання оболонки з веб-контексту: жорсткі політики PHP (disable_functions, open_basedir), заборона викликів bash/sh там, де це не є критично необхідним.
- Регулярний аудит cron-задач і scheduled tasks на веб-серверах, включно із завданнями, які автоматично створюють хостинг-панелі чи плагіни CMS.
- Сканування веб-директорій на предмет підозрілих файлів: невідомі PHP-скрипти, обфусцований код, неочікувані зміни у системних компонентах і добре відомих плагінах.
- Обмеження shell-функціоналу в панелях хостингу та, за можливості, ізоляція користувацьких облікових записів у контейнери або окремі середовища виконання.
Додатково корисно ввімкнути логування HTTP-заголовків, включно з cookies, та застосовувати WAF з поведінковими правилами, що виявляють нетипові послідовності запитів. Регулярний аудит вихідного коду веб-додатків, пошук прихованих точок віддаленого виконання та перевірка cron-задач дозволяють значно знизити ризик довготривалої компрометації. Чим раніше будуть виявлені підозрілі web shell та «самовідновлювані» PHP-loader, тим більше шансів зупинити атаку до витоку даних або повного захоплення серверної інфраструктури.
