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