Исследование вектора повышения привилегий CertiSplit через WEC и WinRM

В ходе детального изучения компонентов Windows Event Collector и службы WinRM специалисты обнаружили необычный вектор повышения привилегий, получивший название CertiSplit. Данный сценарий демонстрирует, как обычный доменный пользователь с помощью легитимного сертификата может получить доступ к PowerShell-сессии локального администратора коллектора.

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

Теоретическая база и архитектура WEC

Компонент Windows Event Collector отвечает за централизованный сбор журналов с удаленных узлов инфраструктуры. В конфигурациях со сбором событий по инициативе источников (source-initiated subscription) применяется протокол WS-Management и служба WinRM, работающие поверх защищенного соединения HTTPS на порту 5986. Документация Microsoft часто рекомендует создавать локальную учетную запись на сервере-коллекторе, наделять ее правами администратора и настраивать соответствующее правило certificate mapping.

Типовое правило сопоставления связывает отпечаток издателя сертификата с локальным пользователем через параметры Issuer, Subject и URI. Если параметры Subject и URI оставляются в виде подставочных знаков (*), система начинает доверять любым субъектам и открывает доступ к расширенному спектру ресурсов WS-Management. В результате успешная проверка подлинности сертификата приводит к тому, что сеанс выполняется от имени привилегированного локального пользователя, даже если сам сертификат был выдан рядовой учетной записи.

Практическая реализация сценария

Для проверки жизнеспособности подхода исследователи развернули лабораторный стенд на базе Windows Server 2019. В качестве исходного субъекта использовался рядовой доменный пользователь.

Использование Machine-сертификатов

Первый вариант атаки опирался на стандартный лимит создания учетных записей компьютеров (MachineAccountQuota), разрешающий рядовым участникам домена регистрировать новые объекты. Запросив машинный сертификат из стандартного шаблона и экспортировав его в формат PEM, исследователи выполнили подключение к серверу сбора событий через утилиту Evil-WinRM. Анализ контекста безопасности с помощью команд whoami подтвердил наличие привилегий группы BUILTIN\Administrators и высокий уровень целостности сеанса.

Применение стандартных User-сертификатов

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

Контрольные эксперименты и проверка границ

Для понимания механизмов защиты были проведены изолированные тесты, затрагивающие фильтрацию URI и поведение удаленного контроля учетных записей (Remote UAC).

Влияние фильтрации URI

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

Поведение Remote UAC и LocalAccountTokenFilterPolicy

Эксперименты с параметром LocalAccountTokenFilterPolicy продемонстрировали неожиданный нюанс. При нулевом значении политики прямой сетевой вход под локальным администратором с использованием пароля блокируется из-за ограничений Remote UAC. Однако аутентификация посредством клиентского сертификата через службу WinRM инициализируется системным контекстом сетевой службы, что приводит к формированию полноценного повышенного токена без срабатывания блокировки.

Отзыв сертификатов и отключение учетных записей

Дополнительные проверки выделили разницу между статусом доменной учетной записи и выданным сертификатом. Отключение исходного пользователя в каталоге AD не препятствовало созданию новых WinRM-сессий с ранее полученным сертификатом. Тем не менее процедура отзыва сертификата и публикация актуального списка CRL успешно пресекали несанкционированные подключения, подтверждая работоспособность штатных механизмов проверки аннулирования.

Методы обнаружения и артефакты для SIEM

Для выявления подозрительной активности эксперты рекомендуют выстроить эшелонированную систему мониторинга на базе журналов безопасности Windows.

Аудит конфигурации WinRM

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

Правила корреляции событий

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

• Событие аутентификации с идентификатором 4624, инициированное через интерфейс Advapi от имени локального администратора с повышенным токеном.
• Событие 4672, фиксирующее назначение специфических привилегий для того же идентификатора сеанса.
• События поставщика Microsoft-Windows-WinRM с идентификатором 91, подтверждающие фактическое открытие сеанса PowerShell Remoting.

Меры противодействия и рекомендации

Минимизация рисков требует внедрения ряда защитных мер на серверах сбора событий:

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

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