Служба каталогов Active Directory остается одной из самых популярных целей как среди злоумышленников, так и среди специалистов по Red Teaming и пентестеров. С выходом новых версий операционных систем семейства Windows продолжают появляться новые векторы атак на AD, например атаки на Delegated Managed Service Accounts (dMSA) в 2025-м.

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

Меня зовут Степан Ляхов, я работаю старшим инженером SOC в «Лаборатории Касперского». В этой статье я хочу рассмотреть один из самых популярных инструментов для сбора информации о домене Active Directory, разобрать, какие следы он оставляет в журналах и как обнаружить его активность.

Инструменты сбора информации в домене Active Directory

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

• PowerView — инструмент из состава известного фреймворка PowerSploit, который позволяет автоматизировать сбор информации и постэксплуатацию в Active Directory с помощью PowerShell. Несмотря на обилие возможностей его обнаружения с помощью решений классов SIEM и EPP/EDR, данный инструмент продолжает пользоваться популярностью.

• ADRecon — созданный приблизительно в 2017 году, этот инструмент не теряет актуальности. Изначально придуманный для аудита конфигурации Active Directory, он выполняет десятки проверок и собирает большое количество информации о ее объектах, благодаря чему получил популярность не только у специалистов Blue Team.

• PingCastle — еще один инструмент, изначально созданный для аудита безопасности Active Directory в 2016 году. Быстрое сканирование, поиск типовых уязвимостей и мисконфигураций, отсутствие необходимости в установке, а на выходе — отчет с оценкой рисков. И это лишь часть функционала данного инструмента, используемая администраторами Active Directory, но при этом ставшая популярной у злоумышленников и специалистов по тестированию на проникновение.

• Impacket — фреймворк, первоначально созданный как набор Python-классов для взаимодействия с сетевыми протоколами ОС Windows, которые не поддерживались Linux-системами. Это повлекло за собой его использование в различном ПО, однако наиболее известным он стал как инструмент, покрывающий практически все этапы атак на Active Directory, от сбора информации до постэксплуатации.

Однако одним из стандартов среди инструментов для сбора информации об объектах Active Directory является BloodHound, названный так в честь древней породы гончих, родом из Бельгии.

Гончая в атаке

BloodHound был создан в 2016 году для облегчения поиска кратчайшего пути получения привилегий доменного администратора с помощью представления взаимосвязей между объектами целевой Active Directory в виде графа.
Несмотря на солидный возраст, упоминания о его использовании в атаках регулярно фигурируют в отчетах «Лаборатории Касперского».

В обзоре тактик техник и процедур азиатских APT-группировок за 2022 г. наша команда Threat Intelligence писала об использовании BloodHound вместе с вышеупомянутыми инструментами для сбора информации о доверительных отношениях (Domain Trusts) и уязвимостях в Active Directory.

В отчете об основных тенденциях и событиях, связанных с ransomware, за 2023 г. указывается, что в некоторых случаях APT-группы, применяющие в своей работе ransomware, также используют BloodHound для получения информации о целевой инфраструктуре.

В Записках цифрового ревизора от нашей команды Threat Intelligence и аналитическом отчете нашего сервиса MDR за 2024 г. также упоминается, что BloodHound используется для сбора информации о связах между объектами Active Directory и о домене в целом, а также о доверительных отношениях между разными доменами.

В отчете о ландшафте киберугроз за 2025 г. BloodHound вновь фигурирует в качестве инструмента разведки в целевой инфраструктуре. Вместе с тем отмечается, что в редких случаях (1% от всех инцидентов) коллектор SharpHound.exe использовался злоумышленниками в качестве инструмента для сбора информации.

Таким образом, несмотря на десятилетнюю историю и широкую известность, данный фреймворк до сих пор используется злоумышленниками разного уровня при атаках на свои цели. Поэтому мы в команде SOC Consulting разобрали, какую информацию позволяют собрать коллекторы BloodHound и как это увидеть в логах ОС Windows через призму SIEM-системы (мы, разумеется, используем нашу KUMA).

Профиль ищейки: режимы сбора данных

В 2023 году разработчики из SpecterOps разделили BloodHound на две версии: BloodHound Enterprise и BloodHound Community Edition. BloodHound Enterprise представляет собой SaaS-решение для управления рисками реализации атак на Active Directory с возможностью периодического сбора и проверки данных, выявления уязвимостей в конфигурации, предоставления рекомендаций по их устранению, а также с круглосуточной технической поддержкой.

Для красных команд используется вариант BloodHound Community Edition (BloodHound CE), позиционируемый как решение для тестирования безопасности и валидации риска атаки по найденному пути. Нам интересен именно BloodHound CE, без дополнительных сервисов и поддержки, который чаще всего используется и злоумышленниками, и специалистами по тестированию на проникновение.

Основные следы BloodHound оставляет из-за своих коллекторов. Официально для сбора информации о сущностях домена Active Directory предоставляются два коллектора: SharpHound в виде исполняемого файла и PowerShell-скрипта, а также AzureHound — коллектор для сбора информации из Azure Active Directory и AzureRM.
При этом неофициально был разработан BloodHound.py — вариация фреймворка на Python 3, позволяющая запускать его на Linux и MacOS без привязки к операционной системе Windows. Основанный на Impacket, он имеет разные ветки для совместимости с разными версиями BloodHound. Коллектор BloodHound.py (bloodhound-python) для legacy-версий BloodHound предустановлен в Kali Linux и позволяет собирать информацию о целевой системе и выводить информацию в формате, совместимом с оригинальным.

Далее фокус будет на информационные системы on-premise, поэтому остановимся на коллекторах SharpHound и BloodHound.py более подробно.

Данные коллекторы различаются по реализации функционала, но имеют довольно много общего, несмотря на разное количество режимов сбора данных: коллектор SharpHound имеет 21 режим, а BloodHound.py — 14. Под спойлером — сравнительная таблица, в которой перечислены данные, собираемые каждым коллектором.

Как можно заметить даже по названиям, SharpHound включает в себя все режимы сбора, поддерживаемые BloodHound.py. Однако разница видна даже по описаниям режимов в мануале каждого из коллекторов. Также разница в реализации ставит вопрос о том, насколько похожи будут следы данных коллекторов в журналах Windows. Давайте детальнее рассмотрим каждый режим сбора и проверим, есть ли разница в поведении коллекторов BloodHound и, если есть, насколько явно она отражается в журналах событий ОС Windows?

Откуда уши растут: поиск следов в журналах Windows

Рассмотрим подробнее каждый из режимов работы коллекторов. В рамках тестирования будет использован следующий стенд:

• win-uujsd1kdqli — контроллер домена на Windows Server 2025;

• vulnerable — клиентская машина на Windows 11 с заведомо уязвимыми настройками, с нее будет запускаться коллектор SharpHound;

• Kali linux — машина с установленной одноименной операционной системой для запуска коллектора bloodhound.py.

Журналы событий с vulnerable и контроллера домена направляются в лабораторную инсталляцию SIEM-системы KUMA. Упрощенная схема стенда представлена ниже:

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

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

Для сбора информации о домене Active Directory на тестовом стенде будет использоваться SharpHound версии 2.9.0:

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

Альтернативой ему будет bloodhound-python версии 1.8.0:

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

Пример «По умолчанию»

Для демонстрации поиска следов в журналах событий взят режим сбора Default, доступный в обоих коллекторах. Он аналогичен запуску коллектора без указания режима, однако есть нюанс: если BloodHound.py в таком случае соберет только информацию о членах групп безопасности, доверительных отношениях, локальных администраторах и пользовательских сессиях, то в SharpHound добавит сведения о правах доступа различных объектов AD, включая объекты AD CS, древо organization units, ссылки групповой политики, ряд свойств объектов AD и локальные группы доменных машин.

Что происходит в журналах событий? Так как требуется учетная запись, а также домен (можно даже указать конкретный контроллер домена), логично ожидать события авторизации. Запустим SharpHound, посмотрим, что произойдет:

sharphound.exe -c Default -d windomain.local --ldapusername lsa --ldappassword **** --domaincontroller win-uujsd1kdqli.windomain.local -v 1

Генерируются множественные события авторизации:

При этом, если присмотреться, то можно заметить кое-что интересное. Во-первых, авторизации выполнялись разными пользователями. Во-вторых, каждый вход генерирует уникальный Target Logon ID, под которым могли выполняться еще какие-то действия. Это происходит из-за наследования контекста безопасности дочерним процессом и использования им прав текущего пользователя, в том числе для аутентификации на контроллере домена с помощью протоколов NTLM и Kerberos, что будет показано в следующем разделе.

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

Для иллюстрации модифицируем наш поисковой запрос, чтобы можно было увидеть количество уникальных пользователей и количество уникальных Target Logon ID:

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

Анализ событий по данным Logon ID показывает, что дополнительные манипуляции выполнялись в сессии с Logon ID '0x1f91aeeb7'. Мы видим следующие события в порядке их поступления:

• 4799: A security-enabled local group membership was enumerated — 29 событий

• 4661: A handle to an object was requested — 7 событий

• 4658: The handle to an object was closed — 7 событий

• 5145: A network share object was checked to see whether client can be granted desired access — 3 события

• 4624: An account was successfully logged on — 1 событие

• 4672: Special privileges assigned to new logon — 1 событие

• 5140: A network share object was accessed — 1 событие

Note. Для настройки аудита событий безопасности рекомендуется использовать официальное руководства от Microsoft. Ссылки для каждого из событий:
4799 – Audit Security Group Management;
4661 – Audit Directory Service Access и Audit SAM;
4658 – Audit File System, Audit Handle Manipulation, Audit Kernel Object, Audit Registry и Audit Removable Storage;
5145 – Audit Detailed File Share;
4672 – Audit Special Logon;
5140 – Audit File Share.

В случае события 4799 были перечислены группы безопасности контроллера домена, а события 4661 и 4658 — старт и начало процесса перечисления ряда групп. Для событий 5145 характерно наличие подключения к именованным каналам SAMR и SRVSVC с маской доступа 0x12019f и к именованному каналу DAV RPC SERVICE с маской доступа 0x2100080. Тесты SharpHound в версии .ps1 показали, что он ведет себя аналогичным образом.

BloodHound.py ведет себя схожим образом, однако есть существенные различия:

bloodhound-python -u lsa -d windomain.local -c Default -vv -dc win-uujsd1kdqli.windomain.local

Всего 3 события авторизации, и все под пользователем, указанным в запущенной команде:

При этом снова видны разные Target Logon ID, и все это снова в пределах секунды.

Просмотрев каждый из них, можно увидеть, что BloodHound.py начал обращаться к разным хостам, среди которых есть и наш контроллер домена, целевой идентификатор сессии '0x1f9631b8e'. Здесь видна существенно меньшая активность:

• 4799: A security-enabled local group membership was enumerated — 1 событие

• 4661: A handle to an object was requested — 7 событий

• 4658: The handle to an object was closed — 2 события

• 5145: A network share object was checked to see whether client can be granted desired access — 3 события

• 4624: An account was successfully logged on — 1 событие

• 4672: Special privileges assigned to new logon — 1 событие

• 5140: A network share object was accessed — 3 события

Также замечено существенное отличие в части сбора информации о группах безопасности: была перечислена только группа Builtin/Administrators, о чем свидетельствует единственное событие 4799.

Кроме того, видна разница в количестве событий 5145:

BloodHound.py получает доступ к именованным каналам SAMR, SRVSVC и LSARPC с маской доступа 0x3 (0x1 — Read, 0x2 — Write).

С помощью такой методики мы проанализировали все режимы сбора информации обоих коллекторов вместе с вариантом SharpHound на PowerShell. Ниже в двух таблицах представлены результаты анализа одноименных режимов для обоих коллекторов и режимов, характерных только для SharpHound. Обе таблицы содержат Event ID, генерируемые для каждого режима сбора, и особенности каждого из них.

Вынесем пару моментов за таблицу, так как они имеют отношение ко всем рассматриваемым режимам сбора:

• Все генерируемые события авторизации на контроллере домена относятся к сетевому типу входа (logon type 3).

• При запуске команды без указания протокола аутентификации будут генерироваться попытки аутентификации по протоколам NTLM и Kerberos, если указать конкретный протокол — будут попытки использовать указанный протокол.

• Вместе с нижеперечисленными событиями также генерируются и другие события, такие как 4661, 4658, 5140, 4672, но они не несут никакой дополнительной информации, и для детектирования на них можно не опираться.

А если не 5145?

Несмотря на повсеместное использование данного события для разработки правил корреляции как у разных вендоров и провайдеров услуг, так и в In-house SOC организаций, иногда имеет смысл обратить внимание на другие варианты.

В качестве альтернативы событиям с идентификатором 5145 можно использовать события 5712 «A Remote Procedure Call (RPC) was attempted»:

В нем виден хост, с которого выполнялось подключение, имя пользователя, в контексте безопасности которого оно было произведено, информация о процессе, к которому получен доступ, хост, к которому выполнялось подключение, именованный канал, информация о параметрах аутентификации, интерфейсе и OpNum (Operation Number — это индекс в таблице функций RPC-сервера, по которому запрашивается конкретная функция). В отличие от событий ETW, например провайдера Microsoft-Windows-RPC-Audit, это события журнала Security, что позволяет не настраивать дополнительные механизмы сбора событий. Однако на контроллере домена такие события генерируются в большом количестве, поэтому стоит проявлять осторожность при включении их записи в журнал.

Для того чтобы эти события стали записываться в журнал, необходимо создать RPC-фильтр. Наиболее простой способ его создать — через стандартную утилиту netsh:

netsh rpc filter add rule layer=um actiontype=permit audit=enable
netsh rpc filter add condition field=protocol matchtype=equal data=ncacn_np
netsh rpc filter add filter

Коротко о содержимом фильтра:

• layer=um — user mode, пользовательский режим.

• actiontype=permit — действие, которое будет выполняться данным фильтром. У нас нет задачи запретить подключения ко всем папкам и именованным каналам, поэтому разрешаем подключения.

• audit=enable — включение аудита.

• field=protocol — поле для сопоставления в условии созданного правила. Сопоставлять будем по этому полю.

• matchtype=equal — оператор сравнения, используемый условием. Мы будем использовать прямое сопоставление.

• data=ncacn_np — значение, с которым происходит сопоставление. ncan_np — наименование подключений к именованным каналам, то, что нас интересует.

ВАЖНО! Microsoft декларирует возможность создания условий фильтрации по IP-адресам, однако данное поле не принимает в качестве значения адреса IPv4.

Этот фильтр можно импортировать в виде файла с уже готовой конфигурацией, что упрощает его настройку. Таким образом, есть возможность вместо событий 5145 использовать события 5712, которые также будут записываться в журнал Security.

Полное обнаружение

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

Но есть еще один источник событий, который до этого мы не упоминали. Это события 1644 «LDAP Search». Коллекторы отправляют их контроллеру домена именно по протоколам LDAP или LDAPS по 389 или 636 TCP-портам соответственно.

Не во всех инфраструктурах администраторы включают журналы Directory Service на контроллерах домена ввиду их большого количества, что может создавать проблемы в работе контроллеров домена. Аналогичные проблемы могут возникнуть и при сборе данных событий.

Note. Для того чтобы избежать проблем с производительностью контроллеров домена при анализе LDAP-запросов, рекомендуется ограничить дорогие и неэффективные LDAP-запросы в реестре контроллера домена по количеству, а также по времени выполнения каждого запроса. Описание включения событий 1644 и методики оценки эффективности обработки LDAP-запросов доступно по ссылке.

Различные режимы сбора информации SharpHound и BloodHound.py генерируют от нескольких единиц до сотен LDAP-запросов. Пример метода All и метода DCOM в SharpHound это наглядно демонстрирует:

Стоит напомнить, что SharpHound использует 21 режим работы, а BloodHound.py — 14, и следы работы коллекторов в событиях «LDAP Search» выглядят так, что найти в них что-либо особенное, кроме количества LDAP-запросов, в данной ситуации довольно сложно.

Однако в ходе тестов удалось установить, что режимы сбора имеют характерные LDAP-фильтры и набор запрашиваемых атрибутов, как на этом примере:

(objectClass=*) — LDAP-фильтр для сбора объектов всех классов.
[all_with_list]nTSecurityDescriptor — атрибуты, хранящие набор DACL, SACL объекта, информацию о владельце и основной группе объекта, с указанием возвращать все значения атрибута и включить в ответ список запрошенных атрибутов.

Некоторые имеют конкретную комбинацию LDAP-фильтров и набор запрашиваемых атрибутов, характерные только для них:

|  (sAMAccountType=268435456) (sAMAccountType=268435457) (sAMAccountType=536870912) (sAMAccountType=536870913) ) 

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

objectSid,distinguishedName,objectGUID,isDeleted,userAccountControl,sAMAccountType,objectClass,sAMAccountName,msDS-GroupMSAMembership,flags,member,cn,primaryGroupID,dNSHostName

— набор атрибутов, содержащий уникальный идентификатор пользователя, полное уникальное имя в каталоге, глобальный уникальный идентификатор объекта в формате xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, общее имя объекта, имя пользователя для входа в формате SAM, битовую маску флагов состояния учетной записи, идентификатор основной группы пользователя, тип учетной записи, список членов группы, расширенный механизм членства в группах для MSA (Managed Service Accounts), флаг, указывающий, что объект помечен как удаленный, служебный атрибут с битовыми флагами для различных операций, имя хоста для компьютеров и контроллеров домена и класс объекта в схеме Active Directory.

В случае метода Default при запуске SharpHound также будет характерен запрос атрибута msDS-AllowedToDelegateTo, содержащий информацию о делегировании. Сам факт запроса о делегировании является редкой активностью, характерной для поиска учетных записей с такими возможностями.

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

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

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

В качестве альтернативы событиям 1644 «LDAP Search» можно использовать события 4662, которые также могут содержать LDAP-фильтры, однако это потребует тонкой настройки SACL.

Варианты обнаружения

В продуктивных инфраструктурах события, необходимые для обнаружения коллекторов BloodHound, генерируются в большом количестве. Для их детектирования стоит обращать внимание на следующие моменты:

• Последовательность входа и обращения к характерным пайпам с конкретной маской доступа во время одной сессии в течение нескольких секунд. В некоторых случаях эта последовательность дополняется перебором одной или нескольких групп безопасности.

• Набор LDAP-запросов или выполнения операций над объектом с конкретными комбинациями LDAP-фильтров и свойств запрашиваемого объекта также в течение нескольких секунд.

Вместо заключения

Мы в «Лаборатории Касперского» учли вышеописанные нюансы и добавили новый пакет правил корреляции для обнаружения обоих коллекторов как с помощью событий ОС Windows из журнала Security, так и с помощью журналов LDAP-запросов. Эти правила уже доступны для пользователей KUMA. Резюмируя все вышесказанное, можно сделать несколько выводов:

• SharpHound и BloodHound.py из коробки собирают немного разную информацию, однако между собой у них много общего.

• Во время работы оба коллектора оставляют разное количество следов в журналах Security и Directory Service.

• В качестве альтернативы событиям 5145 для отслеживания обоих коллекторов можно использовать события 5712.

• Обнаружить работу обоих коллекторов можно с помощью журналов 1644 «LDAP-Search», при этом обнаружение будет эффективным вне зависимости от режимов сбора, указанных в командах их запуска, в отличие от событий из журнала Security. В качестве альтернативы можно использовать события 4662.

Успешной охоты, будьте внимательны.