Разведка в Active Directory — LDAP-запросы к группам, service principal names, учётным записям admin — выглядит как рутинный трафик рядового пользователя и обычно не срабатывает ни на одно правило SIEM. Именно на этом этапе, до самого перемещения по сети, CrowdStrike научил ML-модель ловить атакующего: система вычленяет вредоносные LDAP-запросы из легитимного шума и поднимает сигнал прежде, чем разведка перерастёт в захват учётных данных и движение к домен-контроллеру.
Что произошло
По данным CrowdStrike, в одном из расследований злоумышленник получил root-доступ к Linux-серверу Tomcat через известную уязвимость, а затем начал перечислять сетевые ресурсы через LDAP-запросы — классическая разведка в стиле SharpHound. Дальше атакующий похитил учётные данные из служб безопасности Windows, перешёл на Windows-хосты и скомпрометировал аккаунты с повышенными привилегиями. Параллельно вторая инфраструктура C2 атаковала облако: через AWS Systems Manager злоумышленник обращался к панели управления напрямую, минуя контроль на уровне endpoint, создавал новые учётные записи и развернул резервный «break glass»-инстанс на случай потери доступа.
Активность зафиксировали охотники за угрозами CrowdStrike OverWatch, а связку идентичности, endpoint и облака сопоставила Falcon Identity Protection — по данным вендора, платформа распознала действия атакующего даже с неуправляемых устройств. Компанию оповестили в реальном времени, атака была локализована до того, как злоумышленник получил полный контроль над каталогом.
Кейс показателен не столько масштабом, сколько тем, где именно сработала детекция: не на этапе шифрования или эксфильтрации, а на этапе разведки и первичного бокового перемещения — там, где у защитников есть время среагировать без экстренного реагирования на уже случившийся инцидент.
Как это работает
В основе детектора — методология «слабого контроля» (weak supervision): модель сопоставляет подозрительные LDAP-запросы с высокоуверенными детектами на endpoint от того же пользователя в узком временном окне и на этой связке учится обобщать новые вредоносные паттерны, а не просто запоминать сигнатуры известных инструментов. Задача усложняется тем, что LDAP по умолчанию разрешает обычному пользователю домена читать директорию без повышенных прав — поэтому чисто сигнатурные правила почти бесполезны.
Модель ищет запросы, нацеленные на чувствительные группы, аккаунты доменных администраторов и service principal names — то, что делают инструменты вроде SharpHound и Rubeus, а также самописные скрипты разведки. Ложные срабатывания отсекаются перекрёстной валидацией и статистическими тестами с контролем частоты ошибок по семействам паттернов. В результате детектируются не только известные тулкиты, но и модифицированный трафик, ad-hoc-перечисление и ранее не встречавшиеся атаки — то есть именно тот момент атаки, когда её ещё дёшево остановить.
Для SOC это означает смещение точки обнаружения на один-два шага раньше в цепочке атаки: не «атакующий уже собирает NTDS.dit», а «кто-то из домена только начал искать, где лежат привилегированные аккаунты». Разница в цене реагирования на этих двух этапах — на порядки.
Что внедрить у себя
- Включите мониторинг LDAP-запросов к AD как отдельный источник телеметрии, а не побочный лог — большинство SIEM его недооценивают.
- Сопоставляйте сигналы идентичности и endpoint в одном временном окне: аномальный LDAP-запрос от пользователя, у которого в тот же час зафиксирован подозрительный процесс, — куда более сильный сигнал, чем каждое событие по отдельности.
- Настройте алертинг на запросы к группам Domain Admins, Enterprise Admins и к service principal names — это типичная цель BloodHound-подобной разведки.
- Ограничьте read-доступ к директории для сервисных и рядовых учётных записей там, где это не критично для бизнес-процессов — это сузит легитимный шум, на фоне которого прячется разведка.
- Проверьте, что у SOC есть автоматический плейбук на изоляцию хоста и отзыв сессии сразу при подтверждённой разведке в AD — счёт идёт на минуты до эскалации к домен-контроллеру.
- Регулярно прогоняйте red team сценарии с SharpHound и Rubeus, чтобы убедиться, что детекторы ловят именно ваш трафик, а не только эталонные сигнатуры вендора.
Похожая логика — сопоставление слабых сигналов идентичности и endpoint в реальном времени — лежит и в основе UEBA-детекции аномального входа с нового устройства, и в сценариях, где автономный ответ блокирует сканирование сети до того, как оно перерастёт в атаку. Если для вас критична скорость реакции именно на ранней стадии — до кражи данных, — посмотрите также разбор того, как AI ловит аномальную выгрузку данных инсайдером и как self-learning AI детектирует ransomware без сигнатур.
Источники: CrowdStrike, блог «Cross-Domain Attack Defense with Intel-Led Threat Hunting»; CrowdStrike, блог «Inside CrowdStrike’s ML-Powered LDAP Reconnaissance Detections».
