Атаки на Active Directory: как перестать зубрить PowerView и начать понимать граф доверия

На третьем внутреннем пентесте я знал наизусть 40+ команд PowerView — и не мог объяснить заказчику, как рядовой пользователь из helpdesk становится Domain Admin за три шага. Команды выдавали данные, но в голове не складывалась картина: почему именно эта учётная запись, почему именно через этот сервер, почему цепочка работает. Перелом случился, когда я перестал копировать однострочники из чужих writeups и начал рисовать связи между объектами домена вручную — маркером на доске, потом в Neo4j. Ниже — методика, которая превращает набор разрозненных PowerView-запросов в понимание логики атак на Active Directory.

Почему зубрёжка команд PowerView — тупик для пентеста Active Directory

PowerView (модуль из набора PowerSploit для разведки в Active Directory) — отличный инструмент: умеет перечислять пользователей, группы, ACL (Access Control List — список, определяющий, кто и что может делать с конкретным объектом), делегирования и трасты. Проблема не в нём, а в подходе: если заучивать Get-DomainUser, Get-DomainGroup, Find-InterestingDomainAcl как заклинания, результат — простыня текста, из которой непонятно, куда двигаться дальше.

Типичная ошибка новичка — я через неё прошёл сам. Запускаешь Get-DomainUser -SPN (поиск учётных записей с Service Principal Name — кандидатов для атаки Kerberoasting), получаешь список из 15 сервисных аккаунтов и радостно натравливаешь Rubeus на все подряд. В половине случаев пароли оказывались 30-символьными: учётки управлялись через gMSA (Group Managed Service Account — механизм Windows, который генерирует и ротирует пароли сервисных учёток автоматически), брутфорс бесполезен. А реальный путь к Domain Admin шёл через ACL-цепочку: helpdesk-группа → WriteDACL на организационную единицу → GenericAll на сервисную учётку SQL → Kerberoasting → DCSync. Без графа эту цепочку не увидишь — каждая команда PowerView показывает лишь фрагмент.

Зачем это атакующему: ему не нужны все 15 SPN-аккаунтов. Нужен один конкретный путь от текущих прав до контроллера домена. Путь — цепочка связей между объектами, и видна она только на графе. По данным CrowdStrike Global Threat Report 2025, 75% вторжений используют действительные учётные данные, а среднее время латерального движения после первичного доступа — 62 минуты (рекорд — 51 секунда). Атакующий не тратит эти минуты на перебор команд. Он ищет путь.

Граф доверия Active Directory: узлы и рёбра вместо списка команд

Граф доверия (security graph) — способ представить домен AD как набор объектов и связей между ними. Концепция проще, чем звучит:

Узлы (nodes) — объекты домена: пользователи, группы, компьютеры, OU (Organizational Unit — контейнер для группировки объектов в AD), GPO (Group Policy Object — политика, применяемая к машинам или пользователям), центры сертификации.

Рёбра (edges) — связи и права между объектами. Именно рёбра определяют, кто чем может управлять:

Microsoft описывает это так: в security graph AD узлы — пользователи, компьютеры, группы, OU, GPO и центры сертификации, а рёбра — права и отношения между ними: членство, делегированные разрешения, владение и ссылки контроля доступа. Когда строишь такой граф, вопрос «какие атаки на Active Directory возможны» превращается в «какой кратчайший путь от текущего узла до Domain Admin через эксплуатируемые рёбра».

Пример: пользователь svc-backup → MemberOf → группа IT-Support → GenericAll → пользователь sql-admin → MemberOf → Domain Admins. Три узла, два ребра — путь к захвату домена. На бумаге это занимает полминуты. В голове без графа — не складывается вообще.

Строим граф доверия вручную: пошаговая методика изучения атак на AD

Суть методики: перед запуском BloodHound (инструмент автоматического построения графа атак — подробнее ниже) строим граф руками. Это как учить арифметику перед калькулятором — без этого шага не поймёшь, что BloodHound показывает, и не заметишь, что он чего-то не увидел.

Шаг 1 — собираем узлы: пользователи, группы, компьютеры

Предусловия: Windows-машина в домене (Windows 10/11 или Server 2016+), учётная запись обычного доменного пользователя, загруженный PowerView (. .\PowerView.ps1 в PowerShell).

Три запроса дают основные узлы графа:

# Привилегированные группы — конечные точки на графе
Get-DomainGroupMember "Domain Admins" -Recurse | Select MemberName
# В multi-domain лесах -Recurse может не развернуть FSP — проверяйте вывод на SID-строки
# Сервисные учётки с SPN — кандидаты для Kerberoasting
Get-DomainUser -SPN -Properties samaccountname,serviceprincipalname
# Компьютеры — точки латерального движения
Get-DomainComputer -Properties dnshostname,operatingsystem

Ожидаемый вывод: списки с именами учёток и их свойствами. На бумаге (или в текстовом редакторе) создаём первый слой графа — записываем каждый объект как кружок. Отдельно выделяем членов Domain Admins — это конечные точки пути.

Зачем: определяем «куда хотим попасть» (Domain Admins) и «откуда стартуем» (текущий пользователь). Всё между ними — поле для поиска рёбер.

Шаг 2 — рисуем рёбра: ACL, делегирование и сессии

Теперь ищем связи между узлами. Самый ценный шаг — рёбра определяют возможные пути атаки.

Команда Find-InterestingDomainAcl -ResolveGUIDs (PowerView) находит ACL-записи, где непривилегированные пользователи имеют потенциально опасные права над другими объектами. Параметр -ResolveGUIDs переводит нечитаемые GUID прав в понятные названия: GenericAll, WriteDACL, WriteProperty.

Что делать с выводом: для каждой строки рисуем стрелку на графе. Например, вывод IdentityReferenceName: HELPDESK-USERS | ActiveDirectoryRights: GenericAll | ObjectDN: CN=svc-sql,... означает ребро: группа HELPDESK-USERS → (GenericAll) → пользователь svc-sql.

Дополнительно ищем делегирования — настройки, позволяющие одной учётке действовать от имени другой:

• Unconstrained delegation: Get-DomainComputer -Unconstrained — эти машины хранят TGT (Ticket Granting Ticket — «мастер-ключ» Kerberos, с которым можно запрашивать доступ к любому сервису) всех пользователей, которые на них аутентифицировались. Каждая такая машина — узел с потенциально мощными рёбрами.
• Constrained delegation: Get-DomainUser -TrustedToAuth — объект может олицетворять других пользователей, но только к определённым сервисам.

И сессии: Invoke-UserHunter ищет, где в сети есть активные сессии привилегированных пользователей. Каждая сессия — ребро HasSession между компьютером и пользователем. Если на рабочей станции WS-42 обнаружена сессия Domain Admin — это критическое ребро на графе.

На этом этапе бумажный граф густеет. Это нормально — плотность связей и есть реальная поверхность атаки.

Шаг 3 — ищем путь эскалации привилегий Active Directory

Ключевой вопрос: есть ли непрерывный путь от текущего пользователя до Domain Admins по эксплуатируемым рёбрам?

На бумаге начинаем от своего узла и идём по стрелкам. Каждое ребро — конкретная техника атаки. MITRE ATT&CK — открытая база тактик и техник атак (что-то вроде энциклопедии действий злоумышленников); T-коды (T1558.003 и т.п.) — её идентификаторы, по которым удобно искать детали. Маппинг рёбер на техники:

Если непрерывный путь нашёлся — вы руками воспроизвели то, что BloodHound делает автоматически. С важным отличием: вы понимаете каждый шаг.

Как ручной граф раскрывает логику атак на Active Directory

Kerberoasting через призму графа доверия

Kerberoasting (T1558.003) как команда — Rubeus.exe kerberoast, запрос билетов, брутфорс. Через граф картина другая:

1. Текущий пользователь (аутентифицирован в домене) может запросить TGS (Ticket Granting Service — билет доступа к конкретному сервису) для любого SPN
2. TGS зашифрован хешем пароля сервисной учётки
3. Если эта учётка → MemberOf → привилегированная группа, то сбрученный пароль даёт новый узел с мощными рёбрами на графе
4. Если учётка → MemberOf → группа без интересных связей, Kerberoasting бесполезен даже при слабом пароле

Вот почему слепой запуск Rubeus на все SPN — пустая трата времени. Граф показывает, какие SPN-аккаунты атаковать: те, от которых идут рёбра к привилегированным узлам. На одном пентесте из 12 SPN-учёток реально опасной была одна — с GenericAll на OU, содержащую контроллер домена. BloodHound нарисовал путь за секунды, но я уже знал ответ по бумажному графу.

Латеральное движение в домене как обход рёбер графа

Латеральное движение (lateral movement) — перемещение атакующего между машинами в сети. На графе это траверсия рёбер HasSession и AdminTo:

1. Компрометация рабочей станции WS-01
2. На WS-01 → HasSession пользователя admin-finance
3. Дамп LSASS (процесс Windows, хранящий учётные данные в памяти) → получен NTLM-хеш
4. admin-finance → AdminTo → сервер SRV-DB
5. Pass-the-Hash (T1550.002) на SRV-DB
6. На SRV-DB → HasSession Domain Admin…

Без графа каждый шаг выглядит как отдельная атака. С графом — единый путь, где каждый шаг логически следует из предыдущего. По данным IBM X-Force 2025, атаки с действительными учётными данными выросли на 71% за год, а в dark web ежедневно появляется порядка 6 000 свежих учёток. У атакующего почти всегда есть стартовый узел в вашем графе. Вопрос — существует ли от него путь.

От бумажного графа к BloodHound — граф доверия в масштабе

BloodHound — инструмент автоматического построения графа атак на AD. Его коллектор SharpHound собирает те же данные, что мы собирали PowerView-ом вручную: пользователей, группы, ACL, сессии, делегирования, трасты (trust relationships — доверительные отношения между доменами и лесами, определяющие, какие пользователи могут аутентифицироваться в каких доменах). Разница — масштаб: SharpHound обрабатывает домен из тысяч объектов за минуты.

Но SharpHound собирает не всё. И вот тут ручной граф дополняет автоматику:

Если понимаешь, что означает каждое ребро, замечаешь отсутствие ожидаемых рёбер в BloodHound и проверяешь вручную. Без этого понимания — просто веришь тому, что нарисовано.

Трасты и делегирование Active Directory заслуживают отдельного внимания. Согласно MITRE ATT&CK (техника T1482 — Domain Trust Discovery), атакующие перечисляют трасты между доменами с помощью nltest /domain_trusts, PowerView Get-DomainTrust или LDAP-запросов. Направление траста определяет, кто кому доверяет. Атрибут trustDirection задаётся на объекте TrustedDomain (TDO) и описывает направление доверия относительно домена, в котором объект хранится. Значения: 0 (отключён), 1 (inbound — внешний домен доверяет нашему, пользователи нашего домена могут аутентифицироваться во внешнем), 2 (outbound — наш домен доверяет внешнему, пользователи внешнего домена могут аутентифицироваться у нас), 3 (bidirectional — оба домена доверяют друг другу). Если Domain A доверяет Domain B (trustDirection=1 со стороны B), пользователи Domain B могут запрашивать ресурсы Domain A — компрометация Domain B открывает путь в Domain A. На графе это ребро между доменами, и без понимания направления вы не видите вектор.

Делай раз, делай два, делай три — практический блок аудита безопасности домена Windows

Предусловия: Windows-машина в домене, учётная запись обычного доменного пользователя, загруженный PowerView. Блокнот или доска для рисования.

Делай раз — определи конечную точку и стартовую позицию:

# Конечная точка графа: кто в Domain Admins?
Get-DomainGroupMember "Domain Admins" -Recurse | Select MemberName
# Стартовая точка: в каких группах текущий пользователь?
whoami /groups

Ожидаемый вывод: список членов Domain Admins (обычно 2–8 учёток) и группы текущего пользователя. Записываем конечные точки вверху листа, стартовую — внизу. Если вывод пуст или ошибка «Access denied» — проверь, загружен ли PowerView: команда Get-DomainUser -Identity $env:USERNAME должна вернуть данные текущего пользователя.

Делай два — ищи рёбра от стартовой точки:

Запусти Find-InterestingDomainAcl -ResolveGUIDs | Where-Object {$_.IdentityReferenceName -match "ТВОЯ_ГРУППА"} — подставь имя одной из своих групп. Ожидаемый вывод: строки с ActiveDirectoryRights (GenericAll, WriteDACL, WriteProperty) и ObjectDN (объект, над которым есть права). Каждая строка — ребро на графе. Рисуем стрелки от группы к объектам. Если вывод пуст — пробуем другие группы из whoami /groups. Нулевой результат по всем группам означает: прямых ACL-рёбер нет, ищем альтернативные пути через сессии (Invoke-UserHunter) или SPN (Get-DomainUser -SPN).

Делай три — строй путь вверх:

Для каждого найденного объекта повторяем: в какие группы он входит (Get-DomainGroup -MemberIdentity "имя_объекта"), какие ACL есть на него. Поднимаемся по графу к Domain Admins. Если путь замкнулся — найдена цепочка эскалации привилегий Active Directory. Если оборвался — ищем альтернативные рёбра: HasSession через Invoke-UserHunter, делегирования через Get-DomainComputer -Unconstrained, SPN для Kerberoasting.

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

Десяток проектов я начинал с этого упражнения, даже когда SharpHound уже собирал данные в фоне. Ручной граф даёт фору: к моменту, когда BloodHound нарисует shortest paths, уже есть гипотеза и понимание, почему конкретный путь реален.

Сообщество обожает обсуждать новые инструменты — очередной форк SharpHound, ADscan, BHE — и почти не обсуждает навык графового мышления. Но инструменты сменяются каждые пару лет. PowerView уже конкурирует с ADSearch и другими альтернативами. Принцип «покажи мне граф — покажу атаку» не менялся с 2016 года, когда появился BloodHound. Я видел джунов, которые за месяц с графовым подходом обгоняли коллег с двухлетним стажем копирования однострочников. Разница не в количестве знакомых команд, а в модели принятия решений: «какой путь я ищу» вместо «какую команду запустить». Когда этот переключатель срабатывает — PowerView, Rubeus, mimikatz становятся инструментами проверки конкретных рёбер графа, а не магическими заклинаниями из чит-шита. Если разбираешься с нуля и хочешь, чтобы эту логику закладывали системно, а не урывками из случайных writeups — на IB Basics в Codeby именно так строят фундамент: через связи и пути, не через зубрёжку.