Внутренний пентест легко испортить в первые же минуты. Достаточно увидеть знакомую технику, запустить инструмент без контекста — и получить шум в логах, затронутый сервис или результат, который невозможно объяснить заказчику. С Active Directory это особенно заметно: домен связывает пользователей, серверы, аутентификацию и права доступа. Подход «проверим, а потом разберёмся» здесь редко приводит к хорошему результату.
До первой активной проверки нужно собрать картину среды. Не идеальную — это часто невозможно, — но достаточную, чтобы понимать, на что вы смотрите, какой риск подтверждаете и что может измениться после вашего действия.
Проверка начинается с границ
Фраза «проверьте Active Directory» сама по себе почти ничего не говорит. Что входит в область работ: один домен или несколько? Можно ли обращаться к контроллерам домена? Разрешено ли сканирование? Какие сервисные учётные записи трогать нельзя? Кто на стороне заказчика должен узнать о критичной находке в день её обнаружения?
Пентест AD без понимания последствий может создать компании реальные проблемы. Поэтому до начала работ стоит зафиксировать не только цель, но и правила игры.
В рабочем документе должны появиться разрешённые сегменты, запрещённые действия, порядок эскалации критичных находок и способ фиксировать результаты. Тогда не придётся решать на ходу, допустимо ли обращаться к конкретному сервису или проверять выбранную гипотезу.
Где разобрать этот подход на практике
Подготовка к проверке AD быстро упирается в вопрос практики: прочитать про Kerberos недостаточно, нужно увидеть, как отдельные настройки меняют сценарий. Для этого в «Красном сентябре» доступна демо-версия курса «Атаки на Active Directory».
Курс посвящён уязвимостям внутренней инфраструктуры на базе Microsoft AD: Kerberos и NTLM, Roasting-атакам, DACL, Relay, делегированию и инфраструктуре сертификатов.
Рядом собраны другие материалы Red-направления: вебинары, практикумы, консультации с экспертами и практические задания в CyberED Labs.
Не атаковать домен, пока не понятна его карта
После согласования границ нужно выяснить, из чего состоит область проверки. Сколько доменов доступно? Где находятся контроллеры домена? Какие серверы завязаны на доменную аутентификацию? Есть ли отдельные сегменты или доверительные отношения?
Это не попытка собрать всё подряд. Пентестеру нужна рабочая карта: она помогает отделить важные объекты от фонового шума. Обычная учётная запись, сервисная учётная запись и администратор домена могут выглядеть похожими в выгрузке, но последствия компрометации у них разные.
Во время инвентаризации быстро становится видно, где нужно остановиться и посмотреть внимательнее. Сервис, который зависит от доменной учётной записи, нельзя оценивать только по её имени. Важно понять, для чего эта запись используется, есть ли у неё Service Principal Name — идентификатор, связывающий сервис с учётной записью, — какие у неё права и с какими системами она связана. Тогда находка превращается из строчки в отчёте в понятный риск.
Учётные записи: смотреть не на названия, а на роль
В AD почти всегда много технических объектов: пользователи, сервисные записи, администраторы, учётные записи для интеграций. Ошибка — воспринимать их как один список.
Перед активной проверкой их стоит разложить по назначению. Какие принадлежат пользователям? Какие запускают сервисы? Какие обладают расширенными правами? Какие доступны из интересующего сегмента? У каких настроена предварительная аутентификация Kerberos, а у каких — нет?
Последний вопрос напрямую связан с AS-REP Roasting. Эта техника направлена на учётные записи с отключённой предварительной аутентификацией. Для атаки нужен логин пользователя: после специального AS-REQ сервер аутентификации возвращает AS-REP, часть которого можно использовать для офлайн-подбора пароля. Такие записи встречаются редко, но именно поэтому их легко не заметить при поверхностной ревизии.
AS-REQ Roasting устроен иначе. Здесь нужен доступ к аутентификационному трафику между клиентом и сервером аутентификации либо дамп этого трафика. В сообщении AS-REQ содержится зашифрованная метка времени; при определённых условиях её можно извлечь и попытаться подобрать пароль офлайн.
Обе техники заканчиваются не «интересным хешем», а риском получить пароль учётной записи. Но начинать их проверку без понимания того, чья это запись и зачем она нужна, — плохая идея. Сначала контекст, потом гипотеза.
Kerberos нужно понимать до того, как его проверять
Kerberos — это протокол аутентификации, который позволяет пользователю получать доступ к сервисам домена через систему билетов. В его работе часто встречаются сокращения AS-REQ, AS-REP, TGT, TGS, KDC и SPN. Запоминать их по отдельности не нужно: они описывают один процесс.
Клиент обращается к KDC — центру распределения ключей, который отвечает за аутентификацию в домене, — и получает TGT, билет на выдачу билетов. Затем с помощью TGT он запрашивает TGS, билет для доступа к нужному сервису.
Предварительная аутентификация подтверждает, что клиент владеет секретом, связанным с паролем пользователя. При включённой предварительной аутентификации клиент отправляет зашифрованную метку времени. Если она отключена для учётной записи, появляется другой сценарий обработки запроса — именно этим пользуется AS-REP Roasting.
Пентестеру недостаточно знать названия пакетов. Нужно понимать, что именно передаётся в сети, какие условия делают технику применимой, какой результат получится и что он означает для заказчика.
Если в домене применяются современные алгоритмы шифрования, если учётная запись не обладает интересными правами или если для проверки нет согласованного доступа к трафику, это меняет план работ. Техника не существует отдельно от среды.
Права в AD часто важнее очевидного членства в группах
Права администратора домена заметны сразу. Гораздо интереснее ситуации, когда учётная запись не выглядит привилегированной, но может изменить важный объект, вступить в группу, управлять настройкой или действовать от имени другого пользователя.
Поэтому стоит смотреть не только на состав административных групп. Ошибка в правах на объект может стать первым звеном цепочки, которая приведёт к повышению привилегий. DACL — это списки прав доступа к объектам AD, а делегирование определяет, какие действия один пользователь или сервис может выполнять от имени другого.
Для каждой найденной связи полезно записать: кто получает право, на какой объект, какое действие это право позволяет выполнить и к чему оно может привести. Не нужно сразу строить большой граф всех отношений в домене. Главное — не потерять логику.
Если пользователь может менять объект, который влияет на доступ другого пользователя, это повод изучить путь внимательнее. Если право не даёт практического результата в согласованной области проверки, его не стоит выдавать за критичную находку. Техническая точность важнее эффектной формулировки.
Сертификаты нельзя оставлять на потом
Инфраструктура сертификатов часто остаётся за пределами первой проверки AD. Команда успевает посмотреть на учётные записи, Kerberos и группы, но до AD CS — службы сертификатов Active Directory — руки не доходят.
Если в домене используется инфраструктура сертификатов, нужно выяснить, кто управляет ею, какие шаблоны доступны, как выдаются сертификаты и какие права связаны с этим процессом. Недостаточно просто отметить наличие AD CS — важно понять его место в общей схеме привилегий.
Здесь работает та же последовательность, что и при проверке Kerberos: сначала конфигурация и роли, затем гипотеза, после — безопасное подтверждение. Иначе можно увидеть отдельную настройку, но не понять, создаёт ли она путь к эскалации в конкретной инфраструктуре.
Связка «учётная запись — право — шаблон — сертификат — доступ» на первый взгляд кажется набором терминов. Она становится понятнее, когда разбираешь её как единый путь, а не как несколько несвязанных тем. Именно поэтому сертификаты стоит включить в первоначальный чек-лист, а не оставлять на финальную часть проекта.
Сеть, NTLM и Relay: не вырывать из контекста
Active Directory не ограничивается LDAP и Kerberos. Внутри сети встречаются сервисы, использующие NTLM — механизм аутентификации Windows, — а также другие механизмы, влияющие на возможные пути атаки.
При подготовке к проверке нужно понять, какие протоколы реально используются в интересующем сегменте и какие сервисы участвуют в аутентификации. Само знакомство с техникой не делает её уместной: сначала проверяют условия её применимости, затем выбирают способ подтверждения.
Инструмент может показать ответ сервиса или подтвердить, что узел доступен. Но он не объяснит, насколько действие допустимо в текущем проекте и что произойдёт дальше. За это отвечает пентестер.
Согласовать формат работ с заказчиком
Пентест и Red Team могут использовать похожие техники, но решают разные задачи. Во внутреннем пентесте ищут уязвимости инфраструктуры и подтверждают их риск. В Red Team дополнительно проверяют реакцию защиты: насколько быстро команда замечает действия и что видит в логах.
Перед стартом нужно договориться, какой результат ждёт заказчик. Для одной задачи может быть уместна согласованная широкая проверка сети. Для другой важны незаметность действий и реакция мониторинга. Без этого одна сторона посчитает работу успешной находкой уязвимости, а другая — неудачной проверкой SOC.
Журнал действий спасает от спорных результатов
Каждое действие в пентесте должно быть воспроизводимым. Если специалист нашёл проблему, но не может описать, что именно сделал, при каких условиях и почему получил такой результат, заказчику будет трудно устранить риск. Команде — перепроверить исправление.
Достаточно вести аккуратный журнал: время, целевой объект, использованная учётная запись, проверяемая гипотеза, результат и возможные изменения. Если действие способно повлиять на конфигурацию, заранее нужен план отката и способ убедиться, что среда вернулась в исходное состояние.
Эта привычка отличает специалиста, который понимает технику, от человека, который умеет запустить утилиту. На собеседованиях по пентесту часто спрашивают не только название инструмента, но и то, как он работает, что пытается получить и какие последствия его применение может вызвать.
Свяжите пункты чек-листа в единую картину
Список проверок полезен, только если за каждым пунктом стоит понимание: что происходит в домене, какие условия нужны для техники и какие последствия она может иметь. Иначе Active Directory быстро превращается в набор команд, которые срабатывают только в знакомом примере.
В демо-версии курса «Атаки на Active Directory» можно последовательно разобрать эти связи: от учётных записей и Kerberos до прав, сертификатов и других путей атаки. Это поможет подготовиться к согласованной проверке инфраструктуры до того, как применять техники в рабочем проекте.
