Раньше подобные атаки считали редкой историей для плохо защищённых сайтов. Теперь исследователи видят совсем другую картину: злоумышленники быстро добираются до секретов входа, а затем подключают ИИ-агентов для разведки и закрепления в сети.

Какую проблему решаем

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

По данным Palo Alto Networks Unit 42, одна из атак затронула европейскую госорганизацию. В течение двух часов после первичного проникновения злоумышленники уже получили доступ к хешам паролей и секретам 2FA, а затем попытались развернуть NTLM-ретрансляцию в Active Directory и повысить привилегии до Domain Admin.

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

Что подготовить

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

Полезно заранее проверить, где включён upload progress, какие версии PHP стоят на боевых системах и где хранятся секреты аутентификации. Отдельно стоит знать, какие приложения используют session_start() и unserialize(), потому что именно такие сценарии могут попасть в зону риска.

Пошаговые действия

один. Проверьте, где у вас живёт PHP

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

два. Обновите PHP на хостах

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

три. Ищите следы пробного сканирования

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

Обратите внимание на POST-запросы с ошибкой 500, сообщения PHP о нехватке памяти, сбоях кучи и падение рабочего процесса Apache. Если такие артефакты идут подряд, это уже повод для разбора инцидента.

четыре. Проверьте секреты входа и доменную инфраструктуру

После проникновения атакующие ищут хеши паролей, секреты 2FA, LDAP-данные и сервисные учётные записи. Если у вас есть следы доступа к таким данным, меняйте секреты по цепочке: сначала чувствительные ключи, затем сервисные аккаунты, потом админские учётки.

Здесь полезно свериться с логами на Linux-серверах: иногда именно журналы выдают попытку перебора каталогов, анонимные LDAP-запросы или нетипичные curl-обращения к контроллеру домена.

пять. Усильте мониторинг на стороне Active Directory

Исследователи зафиксировали попытки разведки домена, поиска администраторской учётки и перечисления привилегированных групп. Это уже не просто проверка на проникновение, а движение к контролю над всей инфраструктурой.

Если у вас есть SOC или хотя бы централизованный сбор событий, настройте отдельные правила на аномальные LDAP-запросы, всплеск запросов к контроллеру домена и попытки ретрансляции NTLM. В похожих сценариях ИИ-агенты помогают злоумышленникам быстро прогонять большие наборы команд, поэтому скорость реакции важнее, чем красивый отчёт задним числом.

шесть. Не откладывайте разбор инцидента

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

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

Как проверить себя

Самый простой тест звучит так: если злоумышленник получит доступ к одному PHP-хосту, сможет ли он уйти дальше по сети? Если ответ «да», у вас проблемы не только с патчами, но и с сегментацией, секретами и правами учётных записей.

Посмотрите на три признака. Первый — устаревшие версии PHP на внешних или внутренних сервисах. Второй — секреты, которые хранятся рядом с приложением или живут слишком долго. Третий — отсутствие понятных логов по цепочке «запрос — ошибка — падение процесса — подозрительная активность в домене».

Что делать, если не получилось

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

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

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

Практический чек-лист

  • Составьте список всех серверов и приложений на PHP.
  • Проверьте версии PHP и установите актуальные обновления.
  • Найдите приложения с session_start(), unserialize() и upload progress.
  • Просмотрите логи на цепочку: POST-запрос, ошибка 500, сбой PHP, падение Apache.
  • Смените секреты 2FA, хеши и сервисные учётные записи, если есть признаки компрометации.
  • Проверьте аномалии в Active Directory и LDAP-запросах.
  • Ограничьте права учётных записей, которые не нужны для ежедневной работы.
  • Подготовьте план изоляции сервера на случай повторного инцидента.
Поделиться: