PowerShell и ADWS: скрытая разведка в Active Directory

В Active Directory обнаружен существенный пробел в механизмах выявления разведывательной активности, связанной с PowerShell. Как следует из отчета, злоумышленники могут использовать архитектуру Active Directory Web Services (ADWS) для обхода традиционных систем мониторинга и сокрытия источника своих запросов.

Почему стандартные средства мониторинга не видят угрозу

Обычно средства обнаружения ориентируются на фиксацию LDAP-запросов, проходящих через порты 389 или 636. Однако в случае взаимодействия PowerShell с ADWS эта логика не работает: сервис использует порт 9389 и передает данные по зашифрованному SOAP/XML.

Ключевая проблема состоит в том, что при выполнении команд, таких как Get-ADComputer, PowerShell не устанавливает прямое сетевое соединение по LDAP. Вместо этого запросы обрабатываются через ADWS на самом контроллере домена, а в журналах они выглядят как исходящие с localhost. В результате реальный IP-адрес злоумышленника остается скрытым.

Почему журналы могут вводить в заблуждение

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

«Без дополнительного контекста из событий 1138 и 1139 журналы становятся вводящими в заблуждение», — следует из содержания отчета.

Попытки сокрытия и их ограничения

Отдельное внимание в материале уделено попыткам злоумышленников запутать свои команды. В частности, отмечается, что даже такие приемы, как изменение регистра, не влияют на LDAP-запросы, генерируемые PowerShell, поскольку язык не чувствителен к регистру.

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

Признаки, на которые стоит обращать внимание

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

• событие 1644 — фиксирует сам LDAP-запрос;
• события 1138 и 1139 — помогают определить исходный сеанс;
• корреляция этих событий — ключ к более точному выявлению подозрительной активности.

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

Архитектурная проблема ADWS

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

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

Вывод

Главный вывод материала заключается в том, что для эффективного обнаружения угроз в среде Active Directory недостаточно полагаться только на сетевые сигналы и традиционные правила для LDAP. Необходим всесторонний контроль взаимодействий PowerShell с доменной инфраструктурой, а также корреляция событий, позволяющая определить истинный источник запроса.

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