Подготовка к проверке Active Directory: что нужно учесть перед первой атакой

Внутренний пентест может быть скомпрометирован с самого начала. Применение знакомых техник или инструментов без понимания контекста среды Active Directory (AD) часто приводит к избыточному логированию, нарушению работы сервисов или получению результатов, которые сложно интерпретировать для заказчика. Поскольку AD связывает пользователей, серверы, аутентификацию и права доступа, подход "сначала проверим, потом разберемся" редко бывает эффективным.

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

Определение границ проверки

Поручение "проверить Active Directory" само по себе является слишком общим. Важно четко определить границы работы: включает ли она один домен или несколько? Допустимо ли взаимодействие с контроллерами домена? Разрешено ли сканирование? Какие сервисные учетные записи нельзя затрагивать? Кто со стороны заказчика должен быть уведомлен о критических уязвимостях в день их обнаружения?

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

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

Изучение карты домена перед атакой

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

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

Инвентаризация быстро выявляет области, требующие более детального изучения. Сервис, зависящий от доменной учетной записи, нельзя оценивать исключительно по ее имени. Важно понять назначение этой записи, наличие Service Principal Name (SPN) – идентификатора, связывающего сервис с учетной записью, – ее права, а также системы, с которыми она связана. Только тогда обнаружение превращается из простой записи в отчете в четко определенный риск.

Учетные записи: фокус на роли, а не на именах

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

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

Последний вопрос напрямую относится к технике AS-REP Roasting. Она применяется к учетным записям с отключенной предварительной аутентификацией. Для проведения атаки требуется логин пользователя: в ответ на специально сформированный AS-REQ запрос сервер аутентификации отправляет AS-REP, фрагмент которого можно использовать для офлайн-подбора пароля. Такие учетные записи встречаются нечасто, что делает их легко упускаемыми при беглом анализе.

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

Обе эти техники, AS-REP Roasting и Kerberoasting, ведут не просто к "интересному хэшу", а к риску получения пароля учетной записи. Начинать их применение без четкого понимания роли и назначения этой записи — нецелесообразно. Принцип "сначала контекст, потом гипотеза" здесь критичен.

Понимание Kerberos перед его проверкой

Kerberos — это протокол аутентификации, который обеспечивает пользователям доступ к доменным сервисам с помощью системы билетов. В его работе встречаются такие аббревиатуры, как AS-REQ, AS-REP, TGT, TGS, KDC и SPN. Их не обязательно запоминать по отдельности, так как все они описывают единый процесс аутентификации.

Клиент инициирует взаимодействие с KDC (Key Distribution Center) — центром распределения ключей, ответственным за аутентификацию в домене, — и получает TGT (Ticket Granting Ticket). Используя этот TGT, клиент затем запрашивает TGS (Ticket Granting Service) — билет, необходимый для доступа к конкретному целевому сервису.

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

Для пентестера недостаточно просто знать названия пакетов Kerberos. Необходимо понимать, что именно передается по сети, какие условия делают ту или иную технику применимой, какой результат будет получен и как его интерпретировать для заказчика.

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

Права доступа в AD: за пределами группового членства

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

Поэтому анализ не должен ограничиваться только составом административных групп. Ошибка в правах доступа к объекту может стать отправной точкой для цепочки повышения привилегий. DACL (Discretionary Access Control Lists) представляют собой списки прав доступа к объектам Active Directory, а делегирование определяет полномочия одного пользователя или сервиса действовать от имени другого.

Для каждого выявленного отношения прав полезно задокументировать: кто получает право, какой объект затрагивается, какое действие это право позволяет выполнить и к каким потенциальным последствиям оно может привести. Нет необходимости сразу строить обширный граф всех зависимостей в домене; главное — сохранить логику анализа.

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

Важность инфраструктуры сертификатов (AD CS)

Инфраструктура сертификатов (AD CS) часто остается вне поля зрения при начальной проверке Active Directory. Специалисты успевают проанализировать учетные записи, Kerberos и группы, но до службы сертификатов Active Directory руки обычно не доходят.

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

Здесь действует тот же принцип, что и при проверке Kerberos: сначала анализ конфигурации и ролей, затем формулирование гипотезы, и только после этого — безопасное подтверждение. В противном случае можно заметить отдельную настройку, но не понять, создает ли она реальный путь для эскалации привилегий в данной инфраструктуре.

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

Сетевые протоколы, NTLM и Relay: важность контекста

Функциональность Active Directory не исчерпывается протоколами LDAP и Kerberos. Внутри сети часто присутствуют сервисы, использующие NTLM — механизм аутентификации Windows, — а также другие механизмы, которые могут влиять на потенциальные векторы атак.

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

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

Согласование формата работ с заказчиком

Хотя пентест и Red Team могут применять схожие техники, они преследуют разные цели. Внутренний пентест направлен на выявление уязвимостей инфраструктуры и оценку связанных с ними рисков. Red Team, помимо этого, проверяет эффективность защитных мер: насколько быстро команда безопасности обнаруживает активность и какую информацию регистрируют логи.

Перед началом проекта необходимо четко согласовать с заказчиком ожидаемый результат. Для одной задачи может быть целесообразной широкая и согласованная проверка сети, тогда как для другой приоритетом будут скрытность действий и реакция систем мониторинга. Без такого согласования одна сторона может расценить работу как успешное выявление уязвимостей, а другая — как провальную проверку Центра операций безопасности (SOC).

Ведение журнала действий для достоверности результатов

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

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

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

Интеграция пунктов чек-листа в единую картину

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