Как защитить LSASS от credential dumping в Windows 10/11

Если вы администрируете парк машин или отвечаете за безопасность, рано или поздно вы упрётесь в тему LSASS. И это хорошо — значит, вы не ждёте, пока кто-то вытащит пароли из памяти вашего контроллера домена. Разберёмся, что именно атакуют, как это работает и — главное — что с этим делать на практике.

Что такое LSASS и почему на него нападают

LSASS (Local Security Authority Subsystem Service) — это системный процесс Windows, который отвечает за аутентификацию, смену паролей, создание токенов доступа и работу с политиками безопасности. Он крутится на каждой машине, и по умолчанию хранит в оперативной памяти данные, достаточные для входа в систему: NTLM-хэши, Kerberos-билеты, а в старых конфигурациях — и пароли в открытом виде.

Credential dumping через LSASS — это когда злоумышленник получает доступ к памяти этого процесса и вытягивает оттуда учётные данные. Инструменты вроде Mimikatz, ProcDump, встроенные возможности Metasploit делают это за секунды. После получения хэша администратора домена игра заканчивается — у атакующего полный контроль над инфраструктурой.

Ключевой момент: для дампа памяти LSASS нужны права администратора (или SYSTEM). Значит, первая линия обороны — не допустить получения этих прав. Но если атакующий всё-таки их получил, нужны дополнительные слои защиты.

Включение LSA Protection (RunAsPPL)

Начинать нужно отсюда. LSA Protection делает процесс LSASS защищённым процессом (Protected Process Light). После включения Windows не позволит неподписанным процессам читать память LSASS и внедрять в него код.

Включить можно через реестр или через групповые политики:

1. Откройте редактор реестра на целевой машине.
2. Перейдите в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.
3. Создайте или измените параметр RunAsPPL типа DWORD, установите значение 1.
4. Перезагрузите машину.

Для массового развёртывания через GPO: Computer Configuration → Administrative Templates → System → Local Security Authority → Configure LSA to run as a protected process. Включите и выберите режим «Enabled with UEFI Lock» — это жёстче, но передумать потом сложнее.

Что даёт: после включения обычный Mimikatz при попытке дампа получит ошибку «access denied». Это не панацея — существуют обходы через драйверы уровня ядра, но базовая защита уже работает.

Важный нюанс: некоторые легитимные программы (например, определённые агенты мониторинга или антивирусы старых версий) пытаются обращаться к памяти LSASS и начинают падать. Проверяйте на пилотной группе перед массовым включением.

Credential Guard — следующий уровень

Credential Guard использует виртуализацию на основе гипервизора (VBS) для изоляции секретов. По сути, NTLM-хэши и Kerberos-билеты хранятся в изолированной среде, недоступной даже для SYSTEM.

Требования для Windows 10/11:

• Процессор с поддержкой VT-x или AMD-V.
• Включённая аппаратная виртуализация в BIOS/UEFI.
• Secure Boot (рекомендуется).
• Windows 10 Enterprise/Education или Windows 11 Enterprise/Education — для Pro версии Credential Guard тоже доступен, но с ограничениями.

Включение через реестр:

1. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard — создайте DWORD EnableVirtualizationBasedSecurity = 1.
2. В том же разделе создайте DWORD RequirePlatformSecurityFeatures = 1 (или 3 для Secure Boot и DMA Protection).
3. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA — DWORD LsaCfgFlags = 2.
4. Перезагрузите.

Через GPO путь такой: Computer Configuration → Administrative Templates → System → Device Guard → Turn on Virtualization Based Security. Там же можно выбрать уровень защиты и включить блокировку для доменных учётных данных.

Что реально меняет: даже если атакующий получил SYSTEM и пытается достать хэши через Mimikatz — он получит мусор. Хэши хранятся в LSAIso (LSA Isolated), и из обычного ядра их не прочитать.

Подвох: Credential Guard может сломать некоторые сценарии аутентификации. В частности, NTLMv1, Kerberos unconstrained delegation, интеграция с некоторыми старыми системами прикладного уровня. Тестируйте перед включением на контроллерах домена — там особенно чувствительно.

Защита через WDAC — блокировка инструментов атаки

Даже с включённым Credential Guard стоит заблокировать сами инструменты, которые используются для атаки на LSASS. Windows Defender Application Control (WDAC) позволяет создать белый список разрешённых исполняемых файлов.

Что блокировать в первую очередь:

• Mimikatz и его модификации (mimikatz.exe, mimidrv.sys).
• ProcDump от Sysinternals (procdump.exe, procdump64.exe) — легитимный инструмент, но его используют для создания дампа LSASS.
• Comsvcs.dll через rundll32 (минидамп через MiniDump export).
• Task Manager на машинах, где он не нужен администраторам.
• Нестандартные утилиты, обращающиеся к lsass.exe через OpenProcess с флагом PROCESS_VM_READ.

Пример настройки WDAC через политику:

1. Создайте базовую политику в режиме Audit сначала — посмотрите, что заблокируется.
2. Добавьте правила блокировки по хешам известных инструментов атаки.
3. Разрешите подписанный софт от доверенных издателей (Microsoft, ваш вендор безопасности).
4. Переведите политику в Enforce на пилотной группе.

WDAC — это не разовая настройка. Политику нужно обновлять при установке нового ПО. Но если вы уже используете Intune или SCCM, развёртывание через них вполне штатное.

Настройка аудита доступа к LSASS

Пока вы разворачиваете защиту, неплохо бы понимать, кто и когда пытается лезть в память LSASS. Встроенными средствами Windows можно включить аудит вызовов OpenProcess к lsass.exe.

Для этого используйте Sysmon. Скачайте его с Sysinternals и установите конфигурацию, которая логирует обращения к LSASS. Минимально полезный набор правил в конфиге Sysmon:

Событие, на которое нужно смотреть — Event ID 10 (ProcessAccess), где TargetImage заканчивается на \lsass.exe и GrantedMask содержит флаги вроде 0x1010 (PROCESS_VM_READ | PROCESS_QUERY_INFORMATION) или 0x1410.

Настройте сбор этих логов в SIEM или хотя бы в централизованный лог-сервер. Настройте алерт: если к LSASS обращается процесс, не входящий в белый список (lsass.exe сам, svchost, wininit, ваш EDR-агент) — это повод для расследования.

Сравнение методов защиты

Правила Attack Surface Reduction (ASR)

В Microsoft Defender есть правило, которое напрямую блокирует кражу учётных данных из LSASS: «Block credential stealing from the Windows local security authority subsystem (lsass.exe)». Найдёте его в настройках ASR по ID: 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2.

Включить можно через:

• Group Policy: Computer Configuration → Administrative Templates → Windows Components → Microsoft Defender Antivirus → Microsoft Defender Exploit Guard → Attack Surface Reduction.
• PowerShell: Set-MpPreference -AttackSurfaceReductionRules_Ids 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 -AttackSurfaceReductionRules_Actions Enabled.
• Intune: конфигурационный профиль Endpoint Protection.

Сначала включите в режиме Audit — посмотрите в журнале событий (Microsoft-Windows-Windows Defender/Operational), что бы заблокировалось. Потом Enforce.

Что делать в зависимости от вашей ситуации

У вас малый бизнес, нет домена, 5–20 машин: Включите LSA Protection и ASR-правило на всех машинах. Это займёт час и даст базовую защиту. Если используете Intune — настройте через него. Если нет — скрипт через реестр и GPO на локальном уровне.

У вас доменная инфраструктура, Windows Server 2019+: Включайте Credential Guard на рабочих станциях и рядовых серверах. На контроллерах домена — с осторожностью, сначала проверьте, не сломается ли репликация и аутентификация. Обязательно включите Sysmon и настройте сбор логов.

У вас Enterprise с EDR и SIEM: Комбинируйте все слои. Credential Guard + WDAC + ASR + Sysmon + EDR-политики. Настройте детектирование аномальных обращений к LSASS в SIEM. Проводите регулярные тесты на проникновение — убедитесь, что защита реально работает.

У вас смешанная среда с legacy-системами: Credential Guard может конфликтовать со старыми системами. Начните с LSA Protection и ASR. Постепенно модернизируйте инфраструктуру, чтобы можно было включить Credential Guard без последствий.

Частые ошибки при защите LSASS

Включили Credential Guard и забыли про тестирование. Это самая распространённая проблема. Включили на всех машинах, через неделю пользователи не могут войти в старое приложение, которое использует NTLMv1. Всё откатывают и говорят, что «эта защита не работает». Решение: пилотная группа, мониторинг, только потом масштабирование.

Включили RunAsPPL и остановились. LSA Protection — это первый слой, а не всё решение. Атакующий с драйвером уровня ядра (Bring Your Own Vulnerable Driver) обходит его без проблем. Нужно минимум два слоя защиты.

Не настроили мониторинг. Вы включили защиту, но не знаете, пытались ли атаковать ваши машины. Без логов и алертов вы узнаете о взломе постфактум. Sysmon + SIEM или хотя бы централизованный Event Log — обязательны.

Забыли про контроллеры домена. На КД LSASS хранит базу SAM домена. Но Credential Guard на КД работает иначе — он защищает ключи и учётные данные, но не изолирует всю базу. Уточняйте в документации Microsoft поведение для вашей версии Windows Server.

Блокируют всё подряд через WDAC без белого списка. Машины перестают запускать даже обновления Windows. Начинайте с Audit Mode, собирайте данные, потом постепенно закрывайте пробелы.

Практические рекомендации

1. Начните с инвентаризации. Поймите, какие машины у вас есть, какие версии Windows, какие роли. Без этого вы будете настраивать защиту вслепую.
2. Включите LSA Protection везде. Это минимальная мера, которая не требует аппаратной поддержки и почти ничего не ломает.
3. Включите ASR-правило для LSASS. Делается одной командой, работает сразу.
4. Развёрните Sysmon с мониторингом доступа к LSASS. Без видимости вы не узнаете об атаках.
5. Планируйте Credential Guard на рабочих станциях. Это самый сильный слой защиты учётных данных на сегодня.
6. Тестируйте перед масштабированием. Пилотная группа из 10–20 машин с разными ролями и ПО. Неделя наблюдений — и только потом развёртывание на всех.
7. Документируйте изменения. Когда через месяц что-то сломается, вы должны точно знать, что изменили и почему.

Итог

Защита LSASS от credential dumping — это не одна кнопка, а комбинация слоёв. Минимальный набор, который должен быть на каждой машине: LSA Protection + ASR-правило + мониторинг через Sysmon. Если хотите серьёзной защиты — добавляйте Credential Guard и WDAC. Главное — не включать всё сразу без тестирования и не забывать про видимость: без логов и алертов вы будете защищены, но слепы.

Начните с малого: включите LSA Protection и ASR на пилотной группе машин сегодня. Проверьте, что всё работает. Завтра добавьте Sysmon. Через неделю — планируйте Credential Guard. Такой подход даст реальную защиту без авралов и откатов.