Impacket secretsdump через NTLM relay: дамп хэшей AD без доступа к контроллеру домена

На внутреннем пентесте банковской инфраструктуры прямой доступ к контроллеру домена (DC) был наглухо закрыт сетевым сегментированием — ни одного открытого порта с нашего VLAN. Хэши доменных учёток получили за 40 минут через relay-цепочку: Responder перехватил NTLM-аутентификацию, ntlmrelayx переслал её на рабочую станцию с отключённым SMB Signing, а impacket secretsdump вытянул локальную SAM-базу. Ни одного агента на целевой машине, ни одного обращения к DC напрямую. Дальше — pass-the-hash и горизонтальное перемещение по сети. Разбираю весь процесс пошагово, с объяснением каждой строки вывода secretsdump и честным описанием ситуаций, когда цепочка ломается.

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

По данным CrowdStrike Global Threat Report 2025, 75% вторжений за 2024 год использовали действительные учётные данные. IBM X-Force фиксирует рост таких атак на 71% год к году. Кража хэшей — не экзотика, а стандартная задача на каждом этапе внутреннего пентеста.

MITRE ATT&CK — открытая база тактик и техник атак; T-коды вроде T1003 — её идентификаторы. Извлечение хэшей классифицируется как техника T1003 OS Credential Dumping, тактика Credential Access. Зачем это атакующему: получить NTLM-хэши (числовой «отпечаток» пароля), чтобы аутентифицироваться на других машинах без знания самого пароля. Это и есть pass-the-hash — атака, которая открывает lateral movement (горизонтальное перемещение по сети).

Relay-цепочка встраивается в полную цепочку атаки внутреннего пентеста так:

1. Initial Access / Foothold — атакующий попадает во внутреннюю сеть (VPN, физический доступ, скомпрометированный хост)
2. Network Position — Responder отравляет broadcast-запросы, перехватывает NTLM-аутентификацию
3. Credential Access (T1003) — ntlmrelayx пересылает перехваченную аутентификацию на целевую машину, secretsdump извлекает хэши из SAM и LSA
4. Lateral Movement — pass-the-hash с полученными хэшами на другие хосты
5. Privilege Escalation — повторение цикла до получения доменных привилегий или прямого доступа к DC

Ключевой момент: без прямого доступа к DC мы не можем выполнить DCSync — атаку, имитирующую репликацию контроллеров домена для получения всех хэшей. Но relay-цепочка позволяет вытаскивать локальные хэши с рабочих станций и серверов, а среди них регулярно находятся пароли сервисных или привилегированных учётных записей.

Контекст применения: техника работает только на внутреннем пентесте или при assumed breach (атакующий уже внутри сети). Для внешнего периметра relay-атаки неприменимы — нужен Layer 2 доступ к целевому сегменту.

Как работает NTLM relay атака

NTLM (NT LAN Manager) — протокол аутентификации в Windows, работающий по схеме «запрос-ответ». Если коротко: клиент не передаёт пароль по сети. Сервер отправляет случайный challenge (8-байтный одноразовый код), клиент вычисляет ответ на основе своего хэша пароля и этого challenge, сервер проверяет ответ.

Уязвимость здесь в том, что NTLM не гарантирует подлинность сервера. Атакующий встаёт «посередине»: принимает аутентификацию от жертвы и ретранслирует (relay) её на другой сервер, получая на нём доступ от имени жертвы. Жертва думает, что аутентифицируется на легитимном ресурсе, а её credentials уходят на машину, которую выбрал атакующий.

По данным TrustedSec, NTLM relay остаётся одним из самых частых векторов на внутренних пентестах. Протоколу лет больше, чем некоторым пентестерам, но техника рабочая — Kerberos до сих пор не заменяет NTLM полностью, и многие функции Windows по-прежнему от него зависят.

Предусловия: когда relay + impacket secretsdump сработает

Relay-атака — не волшебная кнопка. Есть жёсткие предусловия, без которых цепочка не соберётся.

SMB Signing отключен на целевых хостах

SMB Signing — механизм цифровой подписи пакетов протокола SMB (Server Message Block), гарантирующий целостность данных при передаче. Если SMB Signing включён и требуется (enforced), relay-атака на SMB невозможна: подпись привязана к оригинальному challenge, и подмена адресата ломает криптографическую цепочку.

Реальность: по умолчанию SMB Signing enforced только на контроллерах домена. Рабочие станции и рядовые серверы Windows идут с параметром «enabled but not required» — подпись поддерживается, но не требуется. Это и делает их relay-целями.

Для проверки используется CrackMapExec (проект архивирован, активный наследник — NetExec/nxc): команда nxc smb 10.0.0.0/24 --gen-relay-list targets.txt сканирует подсеть и сохраняет в файл хосты, где SMB Signing не required. На выходе — готовый список целей для ntlmrelayx.

Работает если: SMB Signing отключен или не enforced на целевом хосте (Windows Workstation, Member Server по умолчанию). Не работает если: SMB Signing enforced через GPO на всех хостах домена (на DC включено всегда).

LLMNR и NBT-NS включены в сети

LLMNR (Link-Local Multicast Name Resolution) и NBT-NS (NetBIOS Name Service) — протоколы разрешения имён, к которым Windows обращается, когда DNS не возвращает ответ. Работают через мультикаст и широковещательные запросы в локальном сегменте сети. Responder отравляет эти запросы: когда пользователь обращается к несуществующему или недоступному сетевому ресурсу (опечатка в пути, отключённый сервер), Responder отвечает «это я» и получает NTLM-аутентификацию.

Проверить наличие broadcast-трафика можно запуском Responder в режиме анализа: sudo responder -I eth0 -A. Флаг -A включает режим «только слушать, не отравлять». Если в консоли появляются запросы LLMNR и NBT-NS — предусловие выполнено.

Альтернатива broadcast-отравлению. Если LLMNR/NBT-NS отключены через GPO (что бывает в зрелых инфраструктурах), аутентификацию можно принудительно спровоцировать через coercion-инструменты: PetitPotam, PrinterBug, DFSCoerce. Они заставляют целевую машину инициировать NTLM-аутентификацию на указанный адрес без broadcast-протоколов. Для этого обычно нужны валидные доменные credentials — grey box сценарий, когда пентест проводится с выданными учётными данными.

Привилегии релейного аккаунта

Условие, о котором часто забывают: учётная запись, чью аутентификацию мы перехватываем, должна иметь права локального администратора на целевой машине. Иначе ntlmrelayx не сможет обратиться к SAM-базе. Из TrustedSec: «if an attacker is able to relay authentication of a user to a system that has SMB Signing turned off and that user happens to be a local admin on that system, the default behavior of NTLM relay is to dump the SAM database».

Если перехваченный аккаунт не имеет админ-прав, relay всё равно создаёт аутентифицированную SMB-сессию. Через неё можно, например, перечислить доменных пользователей (GuidePoint Security описывают эту технику с использованием lookupsid.py через SOCKS-прокси ntlmrelayx), но дамп хэшей не получится.

Relay-цепочка от перехвата до извлечения хэшей: пошаговая инструкция

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

• ОС: Kali Linux 2024.x+ (рекомендуется) или любой Linux с Python 3.8+
• RAM: минимум 2 ГБ — relay-инструменты нетребовательны к ресурсам
• Сеть: прямой Layer 2 доступ к целевому VLAN, без NAT между атакующим и целями
• Инструменты: Impacket (pip install impacket>=0.12.0 — версии до 0.12.0 затронуты уязвимостью path traversal GHSA-mj63-64×7-57xf, исправленной в 0.12.0.post1; поддерживается Fortra, репозиторий github.com/fortra/impacket, активная разработка), Responder (github.com/lgandx/Responder), NetExec (nxc, наследник CrackMapExec)
• Права: root на атакующей машине (Responder слушает на привилегированных портах)

Шаг 1: Разведка — находим цели без SMB Signing

Запускаем nxc smb 10.0.0.0/24 --gen-relay-list targets.txt. На современных Windows (11 24H2+) анонимный SMB negotiate может быть заблокирован, и команда вернёт signing: Unknown или ошибку. Тогда используйте валидные креденшелы: nxc smb 10.0.0.0/24 -u user -p pass --gen-relay-list targets.txt. В выводе напротив каждого хоста будет пометка signing: True/False. Файл targets.txt автоматически заполнится адресами с signing: False. Ожидаемый результат: DC показывает signing: True, рабочие станции и серверы — signing: False.

Если ВСЕ хосты показывают signing: True — организация включила SMB Signing через групповую политику, и SMB-relay на эти хосты невозможен. Стоит рассмотреть relay на другие протоколы: LDAP, HTTP, MSSQL (ntlmrelayx поддерживает их через URI-формат таргетов).

Шаг 2: Настраиваем Responder

Перед запуском откройте Responder.conf и отключите встроенные SMB- и HTTP-серверы: SMB = Off, HTTP = Off. Зачем: ntlmrelayx сам поднимает эти серверы для приёма аутентификации. Два конкурирующих сервера на одном порту — конфликт и потерянные хэши.

Запуск: sudo responder -I eth0 -wv. Здесь -I eth0 — сетевой интерфейс в целевом VLAN, -w — WPAD rogue proxy, -v — подробный вывод. Флаг -d (DHCP poisoning) — агрессивный режим, потенциально деструктивный для сети; применять только после отдельного согласования в scope. Ожидаемый результат: в консоли появляются строки [*] [LLMNR] Poisoned answer sent to... при каждом перехваченном запросе.

Шаг 3: Запускаем ntlmrelayx с автоматическим дампом

В параллельном терминале: impacket-ntlmrelayx -tf targets.txt -smb2support. Флаг -tf указывает файл с целями, -smb2support включает поддержку SMBv2 (без него современные Windows-клиенты не подключатся). По умолчанию ntlmrelayx при успешном relay с правами локального администратора выполняет полный дамп через встроенную реализацию secretsdump: SAM, LSA Secrets и cached credentials (DCC2). Результаты сохраняются в текущем каталоге и выводятся в консоль. Режим -socks полезен, когда нужно вручную запускать другие инструменты Impacket через ту же relay-сессию.

Шаг 4: Ждём аутентификацию и получаем хэши

Как только пользователь в целевом VLAN обратится к несуществующему сетевому ресурсу (опечатка в Explorer, автоматический поиск WPAD-прокси, запрос к отключённому серверу), произойдёт следующее:

1. Windows отправит LLMNR/NBT-NS запрос в сеть
2. Responder ответит «ресурс здесь, подключайся ко мне»
3. Клиент начнёт NTLM-аутентификацию с Responder
4. ntlmrelayx перехватит эту аутентификацию и перенаправит на хост из targets.txt
5. Если учётная запись — локальный админ на целевой машине, ntlmrelayx выполнит secretsdump

В консоли ntlmrelayx это выглядит так: строка Authenticating against smb://10.0.0.50 as DOMAIN/username SUCCEED, за которой следует дамп SAM-хэшей.

Альтернативный вариант: SOCKS-прокси для ручного запуска

Для более гибкого подхода ntlmrelayx запускается с флагом -socks: impacket-ntlmrelayx -tf targets.txt -smb2support -socks. В этом режиме ntlmrelayx не выполняет автоматических действий, а сохраняет каждую успешную relay-сессию как SOCKS-прокси на порту 1080. После этого через proxychains можно запустить secretsdump вручную: proxychains -q impacket-secretsdump -no-pass DOMAIN/username@10.0.0.50 (предварительно убедитесь, что в /etc/proxychains.conf указано: socks4 127.0.0.1 1080; доступные relay-сессии можно проверить командой socks в консоли ntlmrelayx). Этот метод полезен, когда нужно прицельно работать с конкретной сессией или использовать другие инструменты Impacket через ту же relay-сессию (например, smbclient.py для просмотра файлов).

Разбираем вывод impacket secretsdump по полочкам

Самая ценная часть — понять, что именно вы получили. Вывод secretsdump содержит несколько блоков, каждый — отдельный тип секретов.

SAM-записи: локальные учётные записи

SAM (Security Account Manager) — база данных на каждой Windows-машине, хранящая хэши паролей локальных учётных записей. В выводе secretsdump SAM-записи выглядят так:

Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
svc_backup:1001:aad3b435b51404eeaad3b435b51404ee:a4f49c406510bdcab6824ee7c30fd852:::

Формат: username:RID:LM_hash:NT_hash:::. Разберём каждое поле:

• username — имя локальной учётной записи
• RID (Relative Identifier) — числовой идентификатор учётки. 500 — всегда встроенный Administrator, 501 — Guest, 1001+ — созданные вручную
• LM_hash — устаревший хэш LAN Manager. Значение aad3b435b51404eeaad3b435b51404ee — LM-хэш пустой строки, placeholder, когда LM-хэш не хранится (начиная с Windows Vista LM отключён политикой NoLMHash)
• NT_hash — NTLM-хэш. То, что нужно для pass-the-hash. Значение 31d6cfe0d16ae931b73c59d7e0c089c0 — хэш пустого пароля (если видите его — учётка без пароля или отключена)
• ::: — пустые завершающие поля (для совместимости формата)

Хэш a4f49c406510bdcab6824ee7c30fd852 у svc_backup — рабочий NT-хэш, который можно использовать для pass-the-hash.

LSA Secrets: пароли сервисов и ключи DPAPI

LSA (Local Security Authority) — подсистема Windows, управляющая политиками безопасности. В LSA Secrets хранятся данные, которые часто ценнее SAM-хэшей:

• $MACHINE.ACC — пароль машинного аккаунта в домене (secretsdump выводит из него NTLM- и AES-ключи). Пригоден для Silver Ticket на службы этого хоста (CIFS, HOST) или для запросов к LDAP от имени компьютера
• DPAPI_SYSTEM — системный pre-key (machine key + user key) для расшифровки SYSTEM-level DPAPI master keys из C:\Windows\System32\Microsoft\Protect\S-1-5-18. С ним и master key файлами можно расшифровать Wi-Fi профили, scheduled tasks credentials, сохранённые пароли системных сервисов
• _SC_ServiceName — пароли сервисных учётных записей в открытом виде. Если служба запускается от доменной учётки, здесь будет её пароль. Золотая жила: сервисные учётки часто имеют завышенные привилегии в домене

Synacktiv (публикация LSA Secrets: revisiting secretsdump) подробно описали внутреннюю механику: secretsdump сначала включает службу RemoteRegistry (если отключена), вычисляет bootkey из реестра, сохраняет ветки SAM и SECURITY во временный каталог, читает их через SMB-шару ADMIN$, затем удаляет временные файлы и возвращает службу в исходное состояние.

Cached Domain Credentials: хэши из кеша

Если на машине ранее входили доменные пользователи, их хэши кешируются локально (MsCache/DCC2). Количество кешированных записей определяется значением реестра CachedLogonsCount — по умолчанию 10 последних входов. Эти хэши отображаются в блоке [*] Dumping cached domain logon information и имеют формат, отличный от SAM: алгоритм DCC2/MsCacheV2 (PBKDF2-HMAC-SHA1 с 10240 итерациями поверх MD4). Для pass-the-hash они НЕ подходят. Но их можно попробовать сбрутить офлайн — hashcat mode 2100; для legacy MsCacheV1 — mode 1100.

NetNTLM vs NTLM: различие, которое нужно понять сразу

Это то место, где новички путаются чаще всего. Responder перехватывает NetNTLMv2-хэши — результат challenge-response при сетевой аутентификации. Они пригодны ТОЛЬКО для relay-атаки (что мы и делаем) или офлайн-брутфорса (hashcat mode 5600). Использовать NetNTLMv2 для pass-the-hash нельзя.

Secretsdump извлекает NTLM-хэши (NT-хэши) из SAM-базы. Это статические хэши паролей, которые можно напрямую использовать в pass-the-hash. Разница — как между одноразовым кодом (NetNTLM) и мастер-ключом (NTLM).

Что дальше: pass-the-hash и lateral movement в Active Directory

Получив NT-хэш локального администратора, следующий шаг — проверить, используется ли тот же пароль на других машинах. Распространённая ошибка администраторов: единый пароль локального админа на всех рабочих станциях. Команда nxc smb 10.0.0.0/24 -u Administrator -H a4f49c406510bdcab6824ee7c30fd852 --local-auth проверит хэш против всех хостов подсети. Каждый хост с ответом Pwn3d! — новая цель для secretsdump.

На каждой новой машине secretsdump может вытянуть другие сервисные учётки из LSA Secrets. Один из реальных сценариев: на третьей по счёту рабочей станции в LSA обнаружился пароль сервисной учётки с правами Domain Admin. С этого момента — прямой путь к DCSync и полному дампу NTDS.dit.

Ограничения техники и что видит защита

Когда relay-атака НЕ работает

Детект: что фиксирует защита

Secretsdump через relay оставляет заметные следы. В репозитории SigmaHQ по тегу T1003 (OS Credential Dumping) — 156 правил, покрывающих все под-техники (LSASS dump, Mimikatz и др.); из них непосредственно к secretsdump-цепочке относятся единицы — правила на RemoteRegistry service creation, SAM/SECURITY hive save, ADMIN$ access.

Конкретно: — Взаимодействие со svcctl named pipe (запуск/остановка RemoteRegistry) — детектируется Sysmon Event ID 18 (PipeConnected) и Windows Security Log Event 7045 (новая служба) — Сохранение ветки реестра SAM/SECURITY во временный каталог — файловые операции в C:\Windows\Temp с расширением .tmp фиксированного размера — Подключение к ADMIN$ share — SMB Event ID 5140/5145

По вендорам: CrowdStrike Falcon детектирует secretsdump по паттернам обращения к named pipes и аномальным registry query (SAM/SECURITY hives). SentinelOne фиксирует запуск RemoteRegistry как подозрительное событие в контексте chain-of-events. Kaspersky EDR Expert (актуально для российских инфраструктур) детектирует сохранение ветвей реестра через ASEP-мониторинг.

Synacktiv в той же публикации описали альтернативный подход — regsecrets.py, который использует флаг REG_OPTION_BACKUP_RESTORE при открытии ключей реестра, обходя ACL-проверки и не сохраняя hive на диск. Заметность снижается, но детект на уровне взаимодействия с RemoteRegistry остаётся.

D3FEND (knowledge graph защитных техник от MITRE) для T1003 рекомендует: Process Lineage Analysis (D3-PLA), Process Spawn Analysis (D3-PSA) и File Analysis (D3-FA) — все три направлены на отслеживание цепочки процессов и файловых операций, связанных с дампом.

Чеклист защиты от NTLM relay атак

Готовый список для передачи сисадмину или включения в отчёт по пентесту:

1. Включить SMB Signing на всех хостах — GPO: Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options → Microsoft network server: Digitally sign communications (always) = Enabled
2. Отключить LLMNR — GPO: Computer Configuration → Administrative Templates → Network → DNS Client → Turn off multicast name resolution = Enabled
3. Отключить NBT-NS — на каждом сетевом адаптере: Properties → TCP/IPv4 → Advanced → WINS → Disable NetBIOS over TCP/IP. Либо централизованно через PowerShell-скрипт (Set-ItemProperty на NetbiosOptions=2 для всех интерфейсов)
4. Развернуть LAPS (Local Administrator Password Solution) — уникальный пароль локального админа на каждой машине, ротация каждые 30 дней
5. Включить LDAP Signing и Channel Binding на DC — реестр: LdapEnforceChannelBinding = 2, GPO: Domain controller: LDAP server signing requirements = Require signing
6. Включить EPA для веб-сервисов (Exchange, AD CS) — Extended Protection for Authentication через IIS Configuration
7. Мониторинг — добавить Sigma-правила для T1003 в SIEM, отслеживать запуск/остановку RemoteRegistry и подключения к ADMIN$
8. Сегментация — ограничить lateral movement между рабочими станциями (станция не должна иметь SMB-доступ к другой станции)

Relay-атака с impacket secretsdump выглядит сложной в описании, но на практике собирается за три команды в трёх терминалах. Именно простота делает её опасной: порог входа для атакующего минимален, а дефолтные настройки Windows играют на его стороне. Из десятков внутренних пентестов за последние два года SMB Signing был enforced на всех хостах ровно в двух случаях. В остальных — открытые ворота для relay.

Защита от relay — не rocket science. Восемь пунктов чеклиста выше закрывают все описанные векторы. Проблема не в сложности мер, а в том, что их внедрение «ломает» легаси-приложения, и администраторы откладывают. Пока откладывают — secretsdump работает. По моему опыту, самый эффективный аргумент для IT-отдела — показать дамп их собственных хэшей в отчёте. После этого SMB Signing включают за неделю. Если хочешь системно разобраться в таких атаках и защите от них — на IB Basics как раз строят фундамент от сетевых протоколов до первых задач в blue/red team, без академического тона.