Специалисты из команды Microsoft Defender Security Research Team обнаружили тревожную тенденцию: злоумышленники всё чаще используют обычные HTTP-куки (cookie) в качестве канала управления для PHP-веб-шеллов на Linux-серверах. Такой подход позволяет хакерам удалённо выполнять код на взломанных машинах, оставаясь практически незамеченными.
В чём суть метода? Вместо того чтобы передавать команды через параметры URL или тело запроса (что легко отследить), вредоносные программы-шеллы полагаются на значения, которые злоумышленник подкладывает в cookie. По сути, куки становятся ключом-активатором: если в запросе есть определённое значение — шелл просыпается и выполняет команды. Нет нужной cookie — шелл молчит и никак себя не выдает.
Этот подход даёт злоумышленникам мощное преимущество в скрытности. Вредоносный код остаётся в спящем режиме во время нормальной работы веб-приложения и активируется только тогда, когда в запросе появляются специальные значения cookie. Причём Microsoft подчёркивает, что такая логика работает не только для веб-запросов, но и для запланированных задач (cron), а также для доверенных фоновых обработчиков.
Секрет кроется в том, что значения cookie доступны во время выполнения PHP-скрипта через суперглобальную переменную $_COOKIE. Злоумышленнику не нужно изобретать сложные механизмы парсинга — переменная уже готова к употреблению. Более того, куки выглядят как совершенно обычный элемент веб-трафика: браузеры постоянно их отправляют, серверы их принимают. На фоне тысяч легитимных запросов несколько «странных» cookie просто теряются в общем потоке. Системы мониторинга и журналы доступа не поднимают тревогу — ведь формально нет ничего подозрительного.
Исследователи Microsoft выделили три основные разновидности такой атаки.
Первый вариант: многослойный загрузчик с обфускацией
Злоумышленник размещает на сервере PHP-загрузчик (loader). Этот код сильно запутан (обфусцирован), содержит несколько слоёв проверок. Только после того, как скрипт убедится, что пришедшие cookie содержат правильное «секретное» значение, он приступает к парсингу структурированных данных из cookie. Затем загрузчик извлекает и выполняет закодированную вторичную полезную нагрузку (второй этап атаки).
Второй вариант: сегментированный скрипт-конструктор
В этом случае PHP-скрипт принимает структурированные данные из cookie, разбивает их на сегменты и из этих сегментов «на лету» восстанавливает рабочие компоненты: функции для работы с файлами, функции декодирования и так далее. После сборки скрипт условно (при определённых условиях) записывает на диск вторую вредоносную нагрузку и тут же её выполняет.
Третий вариант: cookie как маркер-триггер
Самый простой, но не менее опасный вариант. Одно единственное значение в cookie служит маркером-пускателем. Если маркер совпадает с ожидаемым — шелл активирует действия, контролируемые злоумышленником: выполняет переданные команды или загружает файлы на сервер.
Особо хитрый механизм: самовосстанавливающийся шелл через cron
В как минимум одном из исследованных случаев злоумышленники действовали по следующей схеме. Сначала они получали начальный доступ к среде Linux жертвы — либо через украденные легитимные учётные данные, либо через эксплуатацию известной уязвимости. Затем хакеры настраивали задание в планировщике cron. Это задание периодически (например, раз в минуту или час) запускало рутину, которая выполняла запутанный PHP-загрузчик.
В чём гениальность этого метода для злоумышленника? Архитектура получилась «самолечащейся» (self-healing). Даже если администратор обнаружит вредоносный PHP-файл и удалит его в рамках очистки сервера, запланированное задание cron снова создаст этот файл из резервной копии или заново скачает его. Получается надёжный и устойчивый канал для удалённого выполнения кода. Администратор может удалять шелл хоть десять раз — cron будет его восстанавливать снова и снова, пока не будет удалено само задание.
После того как PHP-загрузчик развёрнут, он ведёт себя тихо: во время обычного трафика он спит и не подаёт признаков жизни. Но как только приходит HTTP-запрос с определёнными значениями cookie — шелл мгновенно просыпается и выполняет команды хакера.
Почему это сложно обнаружить стандартными средствами
Microsoft подводит итог: перенося управление выполнением в cookie, веб-шелл может оставаться скрытым в обычном трафике, активируясь только при целенаправленных взаимодействиях злоумышленника. А разделив две задачи — сохранение персистентности (через cron-восстановление) и управление активацией (через cookie-пускатель) — хакеры значительно снизили операционный шум и ограничили количество наблюдаемых индикаторов в обычных журналах приложений.
Общая черта всех трёх описанных реализаций — использование обфускации (запутывания кода) для сокрытия чувствительной функциональности и активация через cookie для запуска вредоносных действий. При этом интерактивный след (то, что обычно оставляют хакеры при ручном управлении) минимален.
Чтобы противостоять этой угрозе, Microsoft рекомендует внедрить следующие меры защиты:
Включите многофакторную аутентификацию (MFA) для панелей управления хостингом, SSH-доступа и всех административных интерфейсов. Это значительно усложнит получение начального доступа.
Отслеживайте необычную активность при входе в систему — подозрительные логины в нерабочее время, с необычных IP-адресов или после нескольких неудачных попыток.
Ограничьте выполнение интерпретаторов команд (shell-интерпретаторов, таких как bash, sh) из веб-окружения. По возможности запретите веб-серверу вызывать shell-команды.
Регулярно проверяйте задания cron и запланированные задачи на всех веб-серверах. Ищите подозрительные записи, которые вызывают PHP-скрипты из нестандартных мест.
Мониторьте создание подозрительных файлов в веб-директориях. Обращайте внимание на недавно созданные PHP-файлы с запутанным (обфусцированным) содержимым.
Ограничьте возможности shell-команд в панелях управления хостингом — отключите выполнение системных команд там, где это не требуется.
Microsoft подчёркивает, что последовательное использование cookie в качестве механизма управления говорит о том, что злоумышленники повторно используют устоявшиеся методы веб-шеллов из своего арсенала. Перенося логику управления в куки, атакующие получают возможность долговременного персистентного доступа после взлома, который может обойти многие традиционные системы обнаружения и логирования.
Особенно неприятно то, что хакеры не полагаются на сложные цепочки эксплойтов. Вместо этого они используют легитимные пути выполнения, уже присутствующие в среде: процессы веб-сервера, компоненты панелей управления и инфраструктуру cron — чтобы разместить и сохранить вредоносный код.
Чтобы комментировать, зарегистрируйтесь или авторизуйтесь
Компания Cisco выпустила срочные обновления безопасности, закрывающие критическую уязвимость в собственном контроллере Integrated Management Controller (IMC). Если бы злоумышленник смог воспользоваться этой брешью, он получил бы возможность удалённо, без ввода логина и пароля, обойти систему аутентификации и войти в устройство с максимальными привилегиями.
Компания Google выпустила срочное обновление безопасности для своего веб-обозревателя Chrome. В свежем релизе закрыто 21 уязвимость, и одна из них особенно тревожна — разработчики подтвердили, что ею уже активно пользуются злоумышленники в реальных атаках.
Масштабная атака на браузерные расширения вскрыла уязвимость, о которой пользователи даже не подозревали. Популярный инструмент «Save Image as Type» (Сохранить изображение как), который помогал миллионам людей конвертировать WebP-картинки в привычные форматы, оказался в руках злоумышленников. Результат: более миллиона пользователей Chrome по всему миру стали жертвами скрытой махинации.