Как уязвимость в PHP и AD CS приводит к захвату домена

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

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

Что произошло

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

Ключевой эпизод — эксплуатация CVE-2024-4577, уязвимости в PHP CGI на Windows. Она позволяет подменять параметры запуска интерпретатора и добиваться выполнения кода на сервере через веб-запрос.

Как это сделано

Сначала атакующий провел разведку и увидел, что узел живет в доменной среде: на нем доступны Kerberos, LDAP, SMB, RDP и WinRM. Отдельно выделялся веб-сервис на порту 8888 — именно он и стал первой точкой входа.

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

После закрепления начался сбор учетных данных и артефактов аутентификации. Тут уже сработал не один эксплойт, а вся логика компрометации: доступ к системе, поиск секретов, исследование доменной среды и анализ AD CS.

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

Кого затронуло и какие последствия

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

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

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

Что делать читателю прямо сейчас

Если у вас на периметре есть PHP, XAMPP, Windows-хосты или AD CS, не откладывайте базовую проверку. Сценарии вроде этого чаще всего бьют не по экзотике, а по забытым сервисам и кривым настройкам.

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

• Проверьте, не торчит ли наружу старый XAMPP, PHP CGI или другой забытый веб-стек.
• Обновите PHP и закрывающие его компоненты до версий, где CVE-2024-4577 уже устранена.
• Ограничьте доступ к AD CS и пересмотрите его шаблоны, роли и права выпуска сертификатов.
• Проверьте, не хранятся ли на сервере учетные данные в скриптах, конфигурациях и журналах.
• Включите многофакторную аутентификацию для админов и сервисных учетных записей.
• Сверьте внешнюю поверхность с внутренней: все, что не нужно снаружи, должно быть закрыто.
• Проверьте журналы на аномальные запросы к PHP CGI и подозрительную аутентификацию в домене.