HTB Vintage writeup: злоупотребление gMSA-паролем и Shadow Credentials в Active Directory

Пять мисконфигураций Active Directory, ноль CVE — и полная компрометация домена за вечер. Машина Vintage на HackTheBox категории Hard не требует ни одного эксплойта: здесь работают только злоупотребления DACL (Discretionary Access Control List — список, который определяет, кто и что может делать с объектом AD), протоколом Kerberos и механизмом gMSA. По данным CrowdStrike Global Threat Report 2025, 75% вторжений опираются на действительные учётные данные, а не на уязвимости ПО. Vintage моделирует именно такой сценарий — и если вы думаете, что «без эксплойтов = несерьёзно», эта машина быстро поменяет ваше мнение.

Карта атаки: от P.Rosa до Domain Admin

Vintage — grey box: нам сразу выдают учётные данные низкопривилегированного пользователя (P.Rosa / Rosaisbest123). Формат точно копирует реальные внутренние пентесты, где заказчик предоставляет доменный аккаунт рядового сотрудника.

Полная цепочка атаки (kill chain) — шесть звеньев, каждое опирается на отдельную мисконфигурацию:

1. P.Rosa (выданные креды) — разведка через BloodHound, поиск мисконфигураций
2. FS01$ (Pre-Windows 2000) — пароль компьютерной учётки равен имени хоста
3. GMSA01$ — чтение автоматически сгенерированного пароля сервисного аккаунта
4. SVC_SQL — активация отключённого аккаунта + Kerberoasting
5. C.Neri / C.Neri_adm — password spray + извлечение пароля через DPAPI
6. Domain Admin — RBCD-атака на контроллер домена

Ни одно звено не критично само по себе. Но вместе они выстраиваются в полный атакующий путь — и это самое интересное.

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

Прежде чем повторять шаги на машине:

• ОС: Kali Linux 2024+ (предустановлены большинство инструментов) или Parrot OS
• RAM: минимум 4 ГБ; 8 ГБ рекомендуется, если запускаете BloodHound CE в Docker параллельно
• Инструменты: NetExec (nxc), BloodHound.py (или bloodhound-ce-python), Impacket (secretsdump.py, getST.py, dpapi.py), Evil-WinRM, bloodyAD
• Сеть: активный VPN к HackTheBox, DNS направлен на IP машины
• Файл /etc/hosts: запись 10.10.11.45 dc01.vintage.htb vintage.htb
• Kerberos: настроенный /etc/krb5.conf (пример ниже)

[libdefaults]
    default_realm = VINTAGE.HTB

[realms]
    VINTAGE.HTB = {
        kdc = dc01.vintage.htb
        admin_server = dc01.vintage.htb
    }

[domain_realm]
    .vintage.htb = VINTAGE.HTB
    vintage.htb = VINTAGE.HTB

Без этого файла Kerberos-аутентификация не заработает, и большинство команд ниже вернут ошибку. Если у вас Kali и вы раньше не трогали /etc/krb5.conf — создайте его с содержимым выше.

Разведка: Kerberos-аутентификация и BloodHound

Почему NTLM не работает

Первое, что делаем с выданными кредами — проверяем их через SMB: nxc smb dc01.vintage.htb -u P.Rosa -p Rosaisbest123. Ответ — STATUS_NOT_SUPPORTED и пометка (NTLM:False).

Что произошло: на Vintage DC отключена входящая NTLM-аутентификация (политика Network Security: Restrict NTLM, RestrictReceivingNTLMTraffic=2). NTLM (NT LAN Manager) — протокол, при котором хеш пароля передаётся по сети. Отключение NTLM всё чаще встречается в production-средах — это защита от relay-атак. Решение — флаг -k, переключающий NetExec на Kerberos. Kerberos использует «билеты» вместо хешей и требует точного совпадения имени хоста с SPN (Service Principal Name — идентификатор сервиса в AD).

Подключаемся: nxc smb dc01.vintage.htb -u P.Rosa -p Rosaisbest123 -k. Ответ [+] — креды валидны. Обратите внимание: используем полное имя dc01.vintage.htb, а не IP. При обращении по IP клиент формирует SPN вида cifs/10.10.11.45, для которого в AD нет зарегистрированного принципала, и KDC возвращает KRB_AP_ERR_S_PRINCIPAL_UNKNOWN. Типичная ошибка новичков — запомните этот момент.

Проверка SMB-шар (--shares) и пользователей (--users) не даёт ничего кроме стандартных ресурсов контроллера домена. Переходим к системной разведке.

Сбор данных BloodHound

BloodHound собирает объекты AD (пользователи, группы, компьютеры, ACL) и строит граф возможных путей атаки. На любом внутреннем пентесте AD это первый инструмент после проверки кредов — без него вы будете тыкаться вслепую.

bloodhound-python -c all -d vintage.htb \
  -u P.Rosa -p 'Rosaisbest123' \
  -ns 10.10.11.45 --zip

Параметр -c all собирает всё: пользователей, группы, компьютеры, ACL, GPO. Флаг -ns 10.10.11.45 указывает DNS-сервер — в AD-средах контроллер домена обычно совмещает роль DNS. На выходе — ZIP-файл с JSON, который загружаем в BloodHound CE (или Legacy).

Результат: 16 пользователей, 58 групп, 2 компьютера (DC01 и FS01). И вот главная находка при анализе графа: компьютерная учётная запись FS01$ входит в группу Pre-Windows 2000 Compatible Access. Если вы не знаете, почему это плохо — читайте дальше.

Pre-Windows 2000 и злоупотребление gMSA password в Active Directory

Когда пароль компьютера равен имени хоста

Группа Pre-Windows 2000 Compatible Access — наследие Windows NT 4.0. Само по себе членство — индикатор, но не гарантия слабого пароля. А вот конкретная ситуация опасна: когда администратор создаёт компьютерную учётную запись с опцией «Assign this account as a pre-Windows 2000 computer» без явного указания пароля, пароль по умолчанию устанавливается равным имени компьютера в нижнем регистре без символа $. Для FS01$ это fs01. Исторически пароли LM ограничивались 14 символами, но для типичных NetBIOS-имён усечения не происходит. В современных доменах это чистая мисконфигурация, но она встречается в средах с долгой историей миграций — «так исторически сложилось, мигрировать некогда».

Проверяем: nxc ldap dc01.vintage.htb -u 'FS01$' -p fs01 -k. Ответ [+] — администратор не сменил пароль после создания учётки. Мы получили доступ от имени компьютерного объекта FS01$.

ReadGMSAPassword: чтение управляемого пароля

Сам FS01$ не имеет прямых привилегий над другими объектами. Но он входит в группу Domain Computers, которая (данные BloodHound) имеет ACE (Access Control Entry — запись в списке доступа) ReadGMSAPassword на сервисную учётную запись GMSA01$.

gMSA (Group Managed Service Account) — механизм Windows Server 2012+, автоматически генерирующий 256-символьный (Unicode) случайный пароль для сервисных аккаунтов. Пароль ротируется по умолчанию раз в 30 дней, хранится в атрибуте msDS-ManagedPassword и доступен только принципалам из msDS-GroupMSAMembership. На Vintage это вся группа Domain Computers — избыточная конфигурация, открывающая путь любому компьютерному объекту в домене. Типичное обоснование от админов: «а этим сервисам тоже нужен доступ».

Команда: nxc ldap dc01.vintage.htb -u 'FS01$' -p fs01 -k --gmsa --kdcHost dc01.vintage.htb. Если Kerberos-аутентификация под машинной учёткой не проходит (не сформирован ccache или отсутствует --kdcHost), используйте альтернативу: gMSADumper.py -u 'FS01$' -p fs01 -d vintage.htb — он парсит MSDS-MANAGEDPASSWORD_BLOB и выдаёт NT-хеш. Команда bloodyAD get object 'GMSA01$' --attr msDS-ManagedPassword возвращает raw blob, а не готовый хеш — учитывайте это. На выходе — NT-хеш и AES-ключи пароля GMSA01$. Для дальнейших действий (LDAP-модификации, S4U) применяем nxc ldap ... -H <nthash> или Kerberos с AES-ключом.

Зачем GMSA01$ интересен: в BloodHound видно, что у него есть AddSelf на группу ServiceManagers и GenericWrite на пользователя SVC_SQL. Цепочка продолжается.

Kerberoasting через злоупотребление gMSA-привилегиями

Активация отключённого аккаунта и установка SPN

Учётная запись SVC_SQL деактивирована (флаг ACCOUNTDISABLE в атрибуте userAccountControl). Право GenericWrite от GMSA01$ позволяет изменить этот атрибут и включить аккаунт. Далее устанавливаем SPN (например, MSSQLSvc/dc01.vintage.htb) — без него KDC (Key Distribution Center — сервис выдачи Kerberos-билетов на контроллере домена) не выдаст TGS-билет для аккаунта, и Kerberoasting становится невозможен.

Оба действия выполняются через bloodyAD или Impacket-скрипты с аутентификацией от имени GMSA01$.

Механика Kerberoasting

Kerberoasting (T1558.003 по MITRE ATT&CK — открытая база тактик и техник атак, где T-коды — стандартные идентификаторы, которые вы будете встречать в каждом втором отчёте и вакансии) — атака, при которой запрашивается TGS-билет для сервисного аккаунта с установленным SPN. Билет зашифрован хешем пароля этого аккаунта. Вся суть: получив билет, вы ломаете пароль offline — без взаимодействия с сервером, без блокировок, без алертов на неудачные попытки входа.

Запрос TGS через impacket-GetUserSPNs от имени GMSA01$, затем офлайн-подбор через hashcat -m 13100 или john. Результат — пароль SVC_SQL в открытом виде.

Родственная техника — AS-REP Roasting (T1558.004, Credential Access): атакует аккаунты с отключённой предварительной аутентификацией Kerberos. На Vintage она неприменима — у целевых аккаунтов pre-auth включён.

Password Spray, DPAPI и повышение привилегий в Active Directory

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

Люди ставят один пароль на сервисный и персональный аккаунты. Это не теория — это статистика. Проверяем пароль SVC_SQL по списку доменных пользователей: nxc smb dc01.vintage.htb -u users.txt -p '<пароль>' -k. Пользователь C.Neri совпал. Подключаемся через Evil-WinRM (evil-winrm -i dc01.vintage.htb -r VINTAGE.HTB) и забираем user flag.

DPAPI: извлечение паролей из Credential Manager

DPAPI (Data Protection API) — механизм Windows для шифрования сохранённых паролей, cookies, сертификатов. Ключи шифрования (master keys) привязаны к паролю пользователя и хранятся в %APPDATA%\Microsoft\Protect\<SID>\. Если вы знаете пароль пользователя — вы можете расшифровать его master key, а через него — всё, что он сохранил в Credential Manager.

У C.Neri обнаруживаются сохранённые данные аккаунта C.Neri_adm. Порядок расшифровки:

1. Скачиваем master keys из Protect\<SID>\ — несколько файлов с GUID-именами
2. Скачиваем зашифрованные credentials из %APPDATA%\Microsoft\Credentials\
3. Расшифровываем master key: impacket-dpapi masterkey -file <mk_guid> -sid <SID> -password '<пароль_C.Neri>' — на выходе ключ в hex-формате
4. Применяем master key к credential blob: impacket-dpapi credential -file <cred_blob> -key 0x<masterkey_hex> — извлекаем пароль C.Neri_adm

C.Neri_adm имеет право AddSelf на группу DelegatedAdmins. Путь к финальному этапу открыт.

RBCD: захват контроллера домена

Resource-Based Constrained Delegation (RBCD) — механизм Kerberos, при котором целевой сервер решает, каким аккаунтам разрешено имперсонировать пользователей. Конфигурация хранится в атрибуте msDS-AllowedToActOnBehalfOfOtherIdentity на объекте целевой машины.

Группа DelegatedAdmins имеет GenericWrite на объект DC01 (edge в BloodHound) — это позволяет изменять его атрибуты. C.Neri_adm может добавить себя в эту группу (ACE AddSelf). Последовательность:

1. Добавляем C.Neri_adm в группу DelegatedAdmins
2. Записываем SID контролируемой машинной учётки FS01$ в атрибут msDS-AllowedToActOnBehalfOfOtherIdentity на DC01
3. Получаем TGT для FS01$: impacket-getTGT vintage.htb/'FS01$':fs01, затем запрашиваем билет: export KRB5CCNAME=./FS01\$.ccache && impacket-getST -spn cifs/dc01.vintage.htb -impersonate Administrator -dc-ip 10.10.11.45 -k -no-pass vintage.htb/'FS01$' (протокол S4U2Self → S4U2Proxy)
4. С полученным билетом подключаемся к DC через secretsdump или WinRM

Результат — полный контроль над контроллером домена. Root flag получен.

Shadow Credentials: атака через PKINIT-аутентификацию Kerberos

На Vintage финальное повышение привилегий идёт через RBCD. Но в средах с развёрнутым AD CS (Active Directory Certificate Services — инфраструктура сертификатов в домене) при тех же DACL-мисконфигурациях применяется Shadow Credentials. Эту технику стоит знать, даже если здесь она не пригодилась.

Механика атаки

Shadow Credentials злоупотребляет атрибутом [msDS-KeyCredentialLink](https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/de61eb56-b75f-4743-b8af-e9be154b47af). Он появился в Windows Server 2016 для Windows Hello for Business (беспарольная аутентификация) и хранит публичный ключ, привязанный к учётной записи.

Если у атакующего есть GenericWrite или GenericAll на объект AD (как у GMSA01$ на SVC_SQL в Vintage), он может записать собственный публичный ключ в msDS-KeyCredentialLink цели. Дальше — аутентификация через PKINIT (Public Key Cryptography for Initial Authentication — расширение Kerberos, позволяющее аутентифицироваться сертификатом вместо пароля): KDC проверяет публичный ключ, выдаёт TGT, из которого извлекается NT-хеш аккаунта. Пароль жертвы при этом не затрагивается и не меняется — что делает атаку менее заметной.

Инструменты: certipy shadow auto на Linux или Whisker + Rubeus на Windows.

Когда что применять

На Vintage AD CS не установлен, поэтому Shadow Credentials неприменимы. Но на машинах вроде HTB Certified (тот же кластер AD-тематики) Shadow Credentials — основной вектор. Понимание обеих техник даёт возможность выбирать оптимальный путь в зависимости от конфигурации домена.

Ограничения техник и детекшн

Все описанные техники работают в контексте внутреннего пентеста с учётными данными (grey box). На внешнем периметре они неприменимы — это важно понимать.

Детекшн для blue team:

Все инструменты из цепочки (BloodHound.py, NetExec, Impacket, Evil-WinRM, certipy-ad) активно поддерживаются сообществом: свежие коммиты за 2024–2025 годы. bloodyAD — последнее обновление 2024.

Vintage на первый взгляд кажется учебной задачей, но каждое звено этой цепочки регулярно встречается на реальных проектах — по отдельности и в комбинациях. Pre-Windows 2000 — «так исторически сложилось». gMSA с избыточным ReadGMSAPassword на всю группу Domain Computers — «а этим сервисам тоже нужен доступ». RBCD без ограничений — «нам нужна гибкость». Медианное время нахождения атакующего в сети до обнаружения, по данным Mandiant M-Trends 2025, составляет 11 дней — а вся цепочка Vintage укладывается в один рабочий день. Сканер покажет «чисто», а граф DACL-злоупотреблений приведёт к полной компрометации. В 2025 году мисконфигурации AD остаются основным вектором lateral movement в корпоративных сетях, и умение читать BloodHound-графы ценится выше, чем навык запуска готовых эксплойтов. Если хочешь не повторять команды из writeup, а разобраться в фундаменте AD-безопасности — на IB Basics проходят именно это, от базовых концепций до первых задач в домене.