Экспертный пентест Active Directory: от разведки до компрометации леса

Архитектура безопасности Active Directory и методология глубокой разведки

В 2021 году в ходе одного из крупнейших инцидентов безопасности злоумышленники получили доступ к контроллеру домена через цепочку, которая началась с забытого сервисного аккаунта с избыточными правами на чтение контейнера Configuration. Многие системные администраторы полагают, что Active Directory (AD) защищена по умолчанию, пока в ней нет явных дыр вроде пустых паролей. Однако для эксперта по пентесту AD — это не просто база данных пользователей, а сложнейший граф взаимосвязей, где легитимные функции протоколов становятся инструментами компрометации. Понимание того, как именно структурированы объекты и как работает репликация, позволяет атакующему «видеть сквозь стены» корпоративной сети еще до того, как будет отправлен первый эксплойт.

Фундамент безопасности: логическая структура и границы доверия

Прежде чем переходить к инструментам разведки, необходимо переосмыслить архитектуру AD с точки зрения атакующего. В классическом администрировании лес (Forest) считается границей безопасности. В пентесте это утверждение принимается как аксиома: если вы скомпрометировали корень леса, вы владеете всеми доменами внутри. Однако обратное не всегда верно — компрометация дочернего домена не всегда ведет к мгновенному захвату леса, если не эксплуатируются специфические механизмы вроде SID History.

Критически важным элементом является раздел каталога Configuration. Он реплицируется между всеми контроллерами домена в лесу. Для пентестера это «золотая жила»: здесь хранятся данные о сайтах, подсетях и, что более важно, о сервисах, интегрированных с AD (например, Exchange или SCCM). Если вы видите в конфигурации следы Exchange, вы автоматически расширяете поверхность атаки на специфические группы доступа вроде Exchange Windows Permissions, которые исторически имеют опасные привилегии (WriteDACL) на объект домена.

Второй столп — это Global Catalog (GC). Это частичная копия всех объектов леса, доступная для поиска. При разведке пентестер использует запросы к GC (порт 3268/3269) для поиска пользователей и групп в других доменах того же леса без необходимости устанавливать прямое соединение с их контроллерами. Это позволяет оставаться вне поля зрения некоторых систем мониторинга, настроенных на отслеживание аномальных запросов к локальным DC.

Модель безопасности объектов и дескрипторы доступа

В основе безопасности AD лежит модель управления доступом (Windows Access Control Model). Каждый объект в AD имеет дескриптор безопасности (Security Descriptor), который содержит списки управления доступом (ACL).

Для экспертного пентеста критически важно различать два типа списков:

DACL (Discretionary Access Control List): определяет, кто и что может делать с объектом.

SACL (System Access Control List): определяет, какие действия над объектом будут логироваться.

Большинство администраторов фокусируются на членстве в группах (Domain Admins, Enterprise Admins), но упускают из виду атомарные права доступа (ACE — Access Control Entries). Например, право GenericAll на объект пользователя позволяет злоумышленнику сбросить ему пароль или изменить его ServicePrincipalName (SPN), что ведет к атакам типа Kerberoasting.

Особое внимание стоит уделить наследованию. В AD объекты в организационных юнитах (OU) наследуют права от родительских контейнеров. Атакующий ищет «разрывы» в этой логике или избыточные права, делегированные на уровне OU. Если учетная запись обычного специалиста техподдержки имеет право WriteProperty на OU с серверами, он может изменить атрибуты компьютерных объектов, что в конечном итоге позволит выполнить код на этих серверах.

Методология глубокой разведки: от пассивного сбора к графам

Разведка в Active Directory делится на два этапа: перечисление (Enumeration) и анализ связей. На экспертном уровне мы не просто запускаем скрипты, а имитируем поведение легитимных приложений, использующих протокол LDAP.

LDAP как основной инструмент разведки

LDAP (Lightweight Directory Access Protocol) — это язык, на котором говорит AD. Большинство инструментов (BloodHound, SharpHound, adPEAS) являются лишь обертками над LDAP-запросами. Глубокая разведка начинается с понимания фильтров поиска.

Пример сложного фильтра для поиска учетных записей, которые не требуют предварительной аутентификации Kerberos (уязвимы к AS-REP Roasting): (&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=4194304))

Здесь используется идентификатор 1.2.840.113556.1.4.803, известный как LDAP_MATCHING_RULE_BIT_AND. Это позволяет выполнять побитовое сравнение атрибута userAccountControl (UAC). Число 4194304 соответствует флагу DONT_REQ_PREAUTH. Умение составлять такие запросы вручную позволяет пентестеру обходить ограничения автоматизированных утилит и искать нестандартные векторы.

Использование BloodHound и теория графов

BloodHound произвел революцию в пентесте AD, переведя анализ из плоскости списков в плоскость графов. Он визуализирует пути атаки, которые невозможно заметить глазом. Например: * Пользователь А входит в группу Б. * Группа Б имеет право GenericWrite на объект компьютера В. * На компьютере В активна сессия администратора домена.

Для эксперта BloodHound — это не «нажми кнопку, получи результат», а база данных на языке Cypher. Профессионалы пишут собственные запросы к базе Neo4j, чтобы найти уникальные аномалии. Например, поиск всех пользователей, которые имеют права на изменение GPO, примененных к контроллерам домена:

Такой подход позволяет выявить критические цепочки еще на этапе разведки, не совершая ни одного агрессивного действия в сети.

Анализ протоколов аутентификации и их слабых мест

Разведка не ограничивается объектами в базе LDAP. Необходимо понимать, как именно происходит общение между клиентом и сервером. В современных сетях сосуществуют Kerberos и NTLM, и каждый из них предоставляет свои возможности для сбора данных.

Нюансы Kerberos в разведке

Kerberos — основной протокол аутентификации в AD. С точки зрения разведки он интересен процессом запроса билетов. Когда мы запрашиваем Service Ticket для определенного SPN (Service Principal Name), контроллер домена не проверяет, есть ли у нас права на доступ к этому сервису — он просто выдает зашифрованный билет, если учетная запись сервиса существует.

Это позволяет проводить «сканирование портов без сканирования портов». Вместо того чтобы стучаться на каждый сервер по порту 1433 (MSSQL), мы можем запросить у DC список всех SPN, начинающихся на MSSQLSvc/. DC сам отдаст нам список всех SQL-серверов в организации. Это абсолютно легитимный трафик, который крайне сложно отличить от работы обычного приложения.

NTLM и его роль в современном AD

Несмотря на попытки Microsoft отказаться от NTLM, он остается в сетях для обеспечения совместимости. Разведка NTLM-трафика позволяет выявить:

Использование протокола LLMNR/NBT-NS: если сеть не настроена должным образом, узлы будут рассылать широковещательные запросы для поиска имен. Это первый шаг к атакам типа Relay.

Версии ОС: через NTLM-челлендж можно получить точную версию сборки Windows, что критично для выбора эксплойтов.

Скрытая разведка: обход механизмов обнаружения

На экспертном уровне критически важно минимизировать «шум». Современные решения класса EDR (Endpoint Detection and Response) и приманки (Honeytokens) настроены на поиск типичных действий пентестера.

Борьба с Honeytokens

Honeytokens — это поддельные объекты в AD (например, пользователь sql_admin_svc), которые не используются в реальности. Любое обращение к такому объекту (запрос SPN или попытка чтения атрибутов) вызывает мгновенное оповещение службы безопасности. Как их вычислить? * Анализ атрибута whenCreated: часто приманки создаются пачками в одно время. * Отсутствие активности: у реального пользователя заполнено поле lastLogon, есть членство в группах, описание. Приманки часто выглядят слишком «стерильно». * Анализ badPwdCount: если у пользователя 0 неудачных попыток входа за 5 лет — это подозрительно.

Ограничение скорости запросов (Throttling)

Массированный запрос всех данных через SharpHound создает огромный объем трафика к контроллеру домена по порту 389/636. Эксперты используют модульные инструменты (например, ldapsearch с задержками) или настраивают BloodHound на сбор только определенных типов данных (например, только Group, исключая LoggedOn), чтобы снизить вероятность обнаружения.

Анализ доверительных отношений (Trusts)

Разведка в крупных инфраструктурах неизбежно сталкивается с понятием леса и доверия. Существует несколько типов доверительных отношений: * Parent-Child: автоматическое двустороннее доверие внутри леса. * External Trust: доверие между доменами в разных лесах (обычно не транзитивное). * Forest Trust: доверие между двумя лесами.

Для пентестера важно определить направление доверия (Direction) и его транзитивность. Если домен А доверяет домену Б (Direction: Bi-directional), это означает, что пользователи из Б могут аутентифицироваться в А. Разведка через Get-DomainTrust (PowerView) позволяет построить карту экспансии. Особое внимание уделяется атрибуту Selective Authentication. Если он включен, то простого наличия доверия недостаточно для доступа — необходимо явное разрешение на конкретных ресурсах.

Инвентаризация групповых политик (GPO)

GPO — это не только способ настройки системы, но и мощнейший вектор атаки. Разведка GPO на начальном этапе позволяет понять:

Где отключен антивирус или EDR.

На каких серверах добавлены локальные администраторы через Restricted Groups или Preferences.

Есть ли в файлах конфигурации (находящихся в папке SYSVOL) зашифрованные пароли (cpassword). Хотя Microsoft выпустила патч, закрывающий эту уязвимость в 2014 году, в реальных сетях до сих пор встречаются старые GPO с забытыми учетными данными.

Чтение SYSVOL — это пассивное действие. Любой аутентифицированный пользователь имеет право читать содержимое этой папки. Анализ .xml и .ini файлов внутри SYSVOL может дать информацию о запланированных задачах (Scheduled Tasks), которые запускаются от имени привилегированных пользователей.

Работа с контейнером Managed Service Accounts (MSA)

Современные версии AD используют MSA и gMSA (Group Managed Service Accounts) для автоматизации управления паролями сервисов. С точки зрения безопасности это хорошо, так как пароли длинные и сложные. Однако разведка может выявить, какие компьютеры имеют право запрашивать пароль для конкретной gMSA. Если вы скомпрометировали такой компьютер, вы можете извлечь пароль gMSA и действовать от имени сервиса в сети. Поиск таких связей через атрибут msDS-AllowedToRetrieveManagedPassword — обязательный пункт в чек-листе глубокой разведки.

Логика построения цепочки атаки на основе разведки

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

Рассмотрим сценарий:

Через LDAP-запрос найден пользователь с установленным SPN (кандидат на Kerberoasting).

Анализ BloodHound показывает, что этот пользователь имеет право GenericWrite на объект GPO.

Этот GPO применяется к OU "IT_Admins".

В OU "IT_Admins" находятся рабочие станции системных администраторов.

Логический вывод: вместо того чтобы пытаться брутфорсить пароль сервиса (что шумно и долго), можно попробовать изменить GPO, чтобы внедрить свой скрипт на машины администраторов при следующем обновлении политик. Это и есть экспертный подход: использование архитектурных особенностей AD для построения путей с минимальным сопротивлением.

Разведка — это непрерывный процесс. Даже после получения прав локального администратора на первой захваченной машине, цикл разведки повторяется, но уже с использованием новых инструментов (например, чтение памяти процесса lsass.exe или поиск токенов доступа), что позволяет двигаться дальше по графу сети.

Вся мощь Active Directory кроется в её связности. И именно эту связность мы будем использовать в следующих главах для реализации атак на протоколы аутентификации и механизмы делегирования.

Атаки на протоколы аутентификации: эксплуатация уязвимостей NTLM и Kerberos

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

В современной инфраструктуре Active Directory сосуществуют два гиганта: Kerberos, как основной и более защищенный протокол, и NTLM, сохраняемый для обратной совместимости. Понимание их внутренней механики — это не просто теоретический базис, а прикладной инструмент, позволяющий пентестеру находить бреши там, где патчи безопасности бессильны.

Анатомия Kerberos и векторы «жарки» билетов

Протокол Kerberos строится на доверии к третьей стороне — Key Distribution Center (KDC), роль которого в AD выполняет контроллер домена. Процесс аутентификации разбит на этапы, и именно на стыке этих этапов возникают возможности для атак типа «Roasting».

Когда пользователь хочет войти в систему, он отправляет запрос AS-REQ к KDC. Чтобы доказать, что он — это он, пользователь шифрует временную метку (timestamp) своим секретом (хешем пароля). Если на учетной записи отключена проверка предварительной аутентификации (Do not require Kerberos preauthentication), KDC ответит на запрос AS-REQ сообщением AS-REP, содержащим зашифрованную часть, даже если отправитель не предоставил доказательств владения паролем.

Эксплуатация AS-REP Roasting

Данная атака нацелена на учетные записи, у которых в атрибуте userAccountControl установлен флаг DONT_REQ_PREAUTH. Это часто встречается в старых системах или при специфических настройках интеграции с Unix-сервисами.

Процесс эксплуатации выглядит следующим образом:

Пентестер запрашивает билет TGT для целевого пользователя.

KDC возвращает AS-REP, где часть данных зашифрована хешем пароля пользователя.

Атакующий извлекает этот зашифрованный блок и перебирает его в оффлайне с помощью Hashcat или John the Ripper.

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

Механика Kerberoasting: атака на сервисные учетные записи

Kerberoasting — это более универсальный вектор, так как он не требует специфических флагов в настройках аккаунта. Он эксплуатирует тот факт, что любой аутентифицированный пользователь домена может запросить сервисный билет (TGS) для любого сервиса, у которого зарегистрирован Service Principal Name (SPN).

Когда вы запрашиваете TGS для сервиса, KDC шифрует часть билета хешем пароля той учетной записи, под которой запущен этот сервис. Если сервис запущен от имени обычной доменной учетной записи (а не LocalSystem или Managed Service Account), мы получаем зашифрованный блок, пригодный для оффлайн-брутфорса.

Математическая модель безопасности здесь упирается в энтропию пароля. Если пароль сервисного аккаунта составляет 8 символов, он будет взломан за считанные минуты. > Kerberoasting остается одной из самых эффективных техник, так как она не требует привилегий администратора и генерирует минимальное количество подозрительных логов (событие 4769 в журнале Windows часто игнорируется из-за его массовости).

Уязвимости NTLM: от перехвата до Relay-атак

Несмотря на то что Microsoft продвигает Kerberos, NTLM (NT LAN Manager) остается «живым мертвецом» в сетях AD. Главная проблема NTLM — это отсутствие взаимной аутентификации и уязвимость к атакам типа «человек посередине» (MITM).

Протокол Challenge-Response и его слабости

В NTLM v2 процесс выглядит так:

Клиент отправляет запрос на аутентификацию (NEGOTIATE).

Сервер отвечает случайным числом — «челленджем» (CHALLENGE).

Клиент смешивает свой хеш пароля с этим числом и отправляет результат обратно (RESPONSE).

Если атакующий может заставить клиента инициировать соединение с подконтрольным узлом, он перехватит этот Response. Это не сам NTLM-хеш (который хранится в базе SAM или NTDS.dit), а Net-NTLMv2 хеш. Его нельзя использовать для атак Pass-the-Hash, но можно попытаться взломать или — что гораздо эффективнее — транслировать (Relay) на другой сервер.

NTLM Relay: искусство перенаправления

Суть Relay-атаки заключается в том, что атакующий выступает посредником. Когда жертва пытается аутентифицироваться на машине атакующего, тот в реальном времени пересылает эти учетные данные на целевой сервер. Если у жертвы есть права администратора на целевом сервере, атакующий получает полный контроль над ним.

Ключевые условия для успешного Relay:

Отсутствие SMB Signing: Если на целевом сервере подпись SMB не является обязательной (Required), атакующий может модифицировать трафик или просто успешно завершить аутентификацию. На рабочих станциях Windows по умолчанию подпись включена, но не обязательна. На контроллерах домена — обязательна.

Протоколы принуждения (Coercion): Чтобы атака сработала, нужно заставить жертву «постучаться» к нам. Для этого используются техники LLMNR/NBT-NS Poisoning (инструмент Responder) или более продвинутые методы, такие как использование RPC-вызовов (MS-EFSRPC, известный как PetitPotam, или MS-RPRN — PrintNightmare).

Рассмотрим сценарий с использованием PetitPotam. Атакующий вызывает API-метод на контроллере домена, который заставляет сервер аутентифицироваться на машине атакующего через протокол HTTP или SMB. Если атакующий перенаправит этот запрос на Active Directory Certificate Services (AD CS), он может получить сертификат администратора домена, что приведет к мгновенной компрометации всего леса.

Сравнительный анализ векторов эксплуатации

Для выбора стратегии атаки важно понимать различия в требованиях и результатах:

| Характеристика | Kerberoasting | NTLM Relay | AS-REP Roasting | | :--- | :--- | :--- | :--- | | Требуемые права | Любой пользователь домена | Сетевой доступ (MITM) | Не требуются (при знании логина) | | Тип атаки | Оффлайн брутфорс | Онлайн эксплуатация | Оффлайн брутфорс | | Цель | Хеш сервисного аккаунта | Сессия администратора | Хеш пользователя | | Зависимость от конфигурации | Наличие SPN у аккаунтов | Отсутствие SMB Signing / HTTP | Флаг DONT_REQ_PREAUTH | | Скрытность | Высокая | Средняя (шум в сети) | Высокая |

Глубокое погружение в Silver и Golden Tickets

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

Golden Ticket (Золотой билет)

Это поддельный TGT (Ticket Granting Ticket). Для его создания необходимо владеть хешем учетной записи krbtgt — секретного ключа службы KDC. Обладая этим хешем, атакующий может выписать себе билет от имени любого пользователя (даже несуществующего) с любыми группами (например, Domain Admins) и любым сроком действия (по умолчанию 10 лет).

Математически это выглядит так:

Где включает в себя идентификатор пользователя (RID) и его членство в группах. Поскольку мы знаем , мы полностью контролируем содержимое билета. Контроллер домена доверяет этому билету безоговорочно, так как он зашифрован его собственным ключом.

Silver Ticket (Серебряный билет)

В отличие от золотого, серебряный билет — это поддельный TGS (Ticket Granting Service). Для его создания не нужен доступ к контроллеру домена или хешу krbtgt. Достаточно иметь хеш пароля конкретного сервисного аккаунта (например, учетной записи компьютера, на котором запущен MSSQL).

С помощью Silver Ticket атакующий может создать билет для доступа к конкретному сервису на конкретном сервере. Это менее мощный инструмент, чем Golden Ticket, но его гораздо сложнее обнаружить, так как при использовании Silver Ticket обращение к контроллеру домена вообще не происходит — сервис сам проверяет билет своим хешем.

Особенности эксплуатации в сложных топологиях

В крупных инфраструктурах часто встречаются «прыжки» между протоколами. Например, атака NTLM to Kerberos (Shadow Credentials). Если мы можем выполнить NTLM Relay на объект компьютера в AD, мы можем изменить его атрибут msDS-KeyCredentialLink. Это позволит нам аутентифицироваться от имени этого компьютера через Kerberos, используя PKINIT (сертификаты), даже если NTLM в сети планируют отключать.

Другой важный нюанс — работа с AES-шифрованием. По умолчанию современные системы используют AES-256 для Kerberos. Однако, если в ходе Kerberoasting вы видите хеши типа 23$*, это означает использование старого и слабого алгоритма RC4. Взлом RC4-хеша происходит в десятки раз быстрее, чем AES. Иногда пентестеры намеренно пытаются «понизить» тип шифрования (Downgrade Attack), заставляя клиента использовать RC4, если это разрешено в настройках домена.

Практические нюансы и обход защиты

Современные системы защиты, такие как Microsoft Defender for Identity или продвинутые SIEM-решения, обучены искать аномалии в Kerberos-трафике.

Обход обнаружения Kerberoasting: Вместо того чтобы запрашивать TGS для всех SPN в домене сразу (что вызовет срабатывание алерта на массовые запросы 4769), опытный атакующий делает это точечно, выбирая только наиболее ценные аккаунты (например, с именами sql, admin, backup) и распределяя запросы во времени.

Honeytokens: Как упоминалось в предыдущей главе, в домене могут быть расставлены ловушки. SPN, привязанный к аккаунту, который никогда не используется, — классический Honeytoken. Запрос билета для него мгновенно выдает присутствие атакующего. Проверка даты последнего изменения пароля или времени последнего входа (LastLogon) помогает отсеять такие ловушки.

Борьба с NTLM Relay: Если включен механизм EPA (Extended Protection for Authentication), Relay на такие сервисы, как AD CS или IIS, становится невозможным, так как протокол связывает уровень TLS с процессом аутентификации.

Логика атакующего: от входа до доминирования

Рассмотрим цельную цепочку атаки, объединяющую изученные методы:

Точка входа: Получен доступ к непривилегированной сессии на рабочей станции (например, через фишинг).

Разведка: Запуск BloodHound и поиск пользователей с отключенной пре-аутентификацией.

AS-REP Roasting: Обнаружен пользователь svc_backup с флагом DONT_REQ_PREAUTH. Извлечен хеш, взломан оффлайн. Пароль оказался Backup123!.

Lateral Movement: С учетными данными svc_backup мы заходим на сервер резервного копирования. Там мы обнаруживаем, что запущена служба под учетной записью с правами локального администратора.

NTLM Relay: Используя Responder, мы перехватываем запрос от администратора сети, который опечатался в адресе сетевого диска. Транслируем этот запрос на соседний сервер, где подпись SMB отключена, и выполняем там код через smbexec.

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

Persistence: Найдя хеш krbtgt в памяти контроллера домена (после эскалации привилегий), мы создаем Golden Ticket, обеспечивая себе доступ к лесу на годы вперед.

Эта цепочка демонстрирует, что безопасность AD — это не крепость с одной стеной, а сложная экосистема, где слабость одного протокола (NTLM) или небрежность в настройке другого (Kerberos) создает мостик для захвата всей структуры. Экспертный уровень пентеста заключается не в знании команд инструментов, а в понимании того, какой именно бит в пакете аутентификации позволяет вам обойти волю системного администратора.

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