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

После Initial Access фазы атакующий будет стремиться повысить привилегии и двигаться дальше по сети. Дамп памяти lsass.exe — самый прямой и часто самый простой способ достичь этих целей, поскольку при отсутствии защиты атакующий очень легко извлекает оттуда данные для проведения атак Pass-the-hash и Pass-the-ticket. В то же время, для атаки на незащищенный lsass.exe, нужно сравнительно немного: права локального администратора и Mimikatz. Таким образом, защиту этого процесса, по моему мнению, нужно внести в базовый набор мероприятий для любой инфраструктуры с Windows-машинами. 

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

Введение. Тривиальные методы защиты и нападения

Дамп процесса lsass.exe — желанная цель для злоумышленников. Получить этот дамп можно с помощью различных инструментов. 

Во-первых, любой пользователь с правами локального администратора может сделать дамп через Диспетчер задач: найти процесс lsass.exe, кликнуть по нему правой кнопкой мыши и выбрать «Дамп процесса». 

Второй метод — использовать утилиту Procdump из набора Sysinternals. 

Третий — модуль sekurlsa::logonpasswords из Mimikatz. 

Четвертый — вызов comsvcs.dll через rundll32.exe следующим образом: 

rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump (Get-Process lsass).Id C:\lsass.dmp full

Эти четыре метода — наиболее примитивные способы получить дамп lsass для дальнейшего исследования и извлечения аутентификационных данных. На сегодняшний день выполнение любого из способов выше более-менее успешно детектируется всеми актуальными средствами антивирусной защиты. К примеру, KES при создании дампа «занулит» его, то есть дамп будет присутствовать на системе, но его размер будет равен 0 байтам (и он не будет содержать ничего чувствительного). Включенный Windows Defender выдаст соответствующий алерт (см. картинку ниже) и удалит дамп. 

Таким образом, если мы говорим  о простых защитных мерах, то первое, что можно рекомендовать по защите процесса lsass.exe — обновить и включить на эндпоинте антивирус. Второе  — регулярно обновлять операционную системы и ее компоненты до актуальных версий. Звучит довольно скучно, да? Это две базовые рекомендации, которые выдаются практически в любых случаях. Задача по защите lsass не исключение, и вот почему. 

Антивирус может быть отключен злоумышленником, изначально отсутствовать на системе или не сработать на конкретный случай (вероятность ненулевая, особенно если атакующие используют living off the land техники). Для большей уверенности надо полагаться не только на наложенные средства защиты, но и на соответствующие настройки безопасности непосредственно в ОС. 

До релиза Windows 8.1 и Server 2012 R2 борьба с хищением данных из lsass на уровне ОС строилась на таких рекомендациях:

1. Отзыв SeDebugPrivilege у непривилегированных пользователей, поскольку lsass.exe разрешает чтение памяти процессам, имеющим эту привилегию. 

2. Отключение WDigest с помощью записи в 

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest

Значения

UseLogonCredential=0

Как известно, WDigest — устаревший протокол, использовавшийся в ОС Windows для HTTP/LDAP аутентификации. Проблема безопасности протокола заключается в том, что он хранит учетные данные в lsass в открытом виде. Если выставить UseLogonCredential в ноль, то WDigest не будет сохранять пароли в памяти. Начиная с Windows 8.1/2012 R2, Microsoft по умолчанию отключила сохранение паролей для WDigest (UseLogonCredential=0). Однако эта настройка никак не защищает от извлечения данных NTLM и Kerberos.  

3. Настройка параметра реестра TokenLeakDetectDelaySecs. Этот параметр уже упоминался в прошлой статье про защиту AD. Пожалуй, стоит рассказать о нем чуть подробнее. Он находится по пути

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\TokenLeakDetectDelaySecs

и принудительно очищает lsass от учетных данных пользователей, вышедших из системы. В приведенной выше статье я рекомендовал задать значение 10 для этого параметра, сам Майкрософт рекомендует 30, но даже десяти секунд между циклами очистки может быть достаточно для кражи данных.

4. Отключение LM и NTLM. Такие устаревшие протоколы целесообразно отключать в пользу Kerberos, однако даже в этом случае lsass все равно остается целью для атаки — система генерирует и хранит хэш NTLM для совместимости и для интерактивного входа на самом компьютере.

5. Использование группы Protected Users. Такое решение ограничивает хранение аутентификационных данных в памяти. Для членов группы отключена аутентификация по устаревшим протоколам (LM, NTLM, Digest, CredSSP), установлено короткое время жизни билетов Kerberos, а также запрещено кэширование паролей в памяти lsass. Однако на практике эта защитная мера применяется ограниченно — никто не запихивает в эту группу всех пользователей домена. Да, целесообразно завести отдельные учетные записи администраторов в Protected Users, чтобы усложнить атакующим доступ к привилегированным учетным данным, но не более. Применение для обычных пользователей часто непрактично из-за ограничения на кэширование билетов Kerberos, что ломает работу офлайн (например, ноутбуков вне сети).

В чем проблема всех вышеперечисленных мер? Субъективно список ощущается как набор методов паллиативной помощи, если так можно выразиться. Как будто бы заплатки для архитектурно уязвимой системы. Вы настроите очистку памяти? 30 секунд — вечность для автоматизированного инструмента. Отключите NTLM? Система все равно любезно подготовит для атакующего ваш NTLM-хэш. Возможно, когда-то давно эти меры действительно были эффективны сами по себе, но точно не сегодня. 

RunAsPPL — защита на уровне процесса

Расцвет атак на lsass начался после 2012 года, когда был опубликован исходный код Mimikatz, и в 2013 защитники выкатили свой контраргумент. Начиная с Windows 8.1 и Windows Server 2012 R2, Microsoft предложила более фундаментальный механизм — запуск lsass в режиме Protected Process Light (PPL). В нем доступ к памяти lsass ограничен: только доверенные и подписанные Microsoft компоненты могут загружаться в его адресное пространство. Это резко снижает риск извлечения учётных данных примитивными методами (Task Manager, Procdump, Mimikatz в лоб и т. п.). Надо отметить, что формулировка «доверенные и подписанные» не означает обычную Authenticode-подпись. 

Обычная Authenticode подпись — стандартная цифровая подпись, которой Microsoft или другой вендор подписывает исполняемые файлы и драйверы, подтверждая их подлинность и целостность. Но для Protected Process Light этого недостаточно. RunAsPPL требует специального атрибута подписи, называемого Windows Protected Process Light (PPL) signing level. Это внутренний механизм Windows Code Integrity, который делит двоичные файлы на уровни доверия.

Как видно на картинке, уровни подписи бывают разными, но общий смысл такой. Для работы с защищенным процессом другому процессу потребуется уровень подписи не ниже, чем у защищенного. Простая Authenticode-подпись (например, драйвер легитимного производителя железа или стороннего софта) не даёт права внедряться в защищенный lsass. Поэтому большинство утилит сторонних разработчиков (в том числе легитимных) оказываются «за бортом» — доступ к lsass им закрыт.

Это объясняет, почему в некоторых случаях программы не могут корректно работать при включённом RunAsPPL, пока их вендоры не получили у Microsoft соответствующие права. Чтобы избежать таких сценариев, целесообразно перед включением провести аудит по инструкции. В противном случае можно получить проблемы в таком духе.  

После аудита можно включать RunAsPPL для lsass (LSA Protection) по инструкции. При включении LSA Protection атакующий не сможет сдампить процесс «в лоб». 

Если параметр RunAsPPL в реестре был выставлен в 1, то при включенном на хосте Secure Boot применяется UEFI Lock. Это означает, что даже если атакующий получит права на редактирование реестра, то отключить LSA Protection указанным способом не получится — изменения реестра не применятся. 

Звучит уже лучше. Тем не менее RunAsPPL для lsass — не панацея. Он отметает простые методы атак, но при наличии высоких привилегий (локальный администратор, SYSTEM) остаются сценарии, в которых атакующий может обойти защиту. Например, метод с mimidrv.sys, описанный здесь, или техника BYOVD (Bring Your Own Vulnerable Driver), когда вместо явного вредоносного драйвера используется легитимный, но уязвимый. Антивирусы в таком случае часто не реагируют, ведь файл подписан и доверен. Атакующий с административными правами загружает драйвер, получает доступ к памяти ядра и обходит RunAsPPL. Именно поэтому патч-менеджмент и контроль драйверов становятся неотъемлемой частью защиты. Да даже защищенный lsass по-прежнему уязвим к атакам со стороны ядра. В качестве смягчающей меры атак такого рода можно выполнить включение в инфраструктуре HVCI (Hypervisor-Protected Code Integrity), как механизм защиты целостности ядра. 

Credential Guard

Чтобы устранить фундаментальный недостаток (доступ ядра к памяти lsass), компания Microsoft внедрила Credential Guard. Решение основано на VBS (Virtualization-Based Security) и изолирует секреты в защищённой виртуальной среде (LSA Isolated, в Task Manager это выглядит как процесс LsaIso.exe), которая существует «под гипервизором» и недоступна даже коду в ядре. При включённом Credential Guard секреты всё ещё присутствуют в памяти основного lsass.exe, но в зашифрованном виде. Ключи для их расшифровки находятся в изолированном процессе LsaIso.exe, работающем в среде VBS. Таким образом, обычный дамп lsass не позволяет напрямую извлечь учётные данные. Да, дамп снять можно, но содержимое окажется непригодным без доступа к LsaIso.

Однако внедрение CG несет определенные сложности: 

1. Есть конкретные аппаратные требования, не позволяющие развертывать решение в старых инфраструктурах. Это виртуализация, TPM 2.0, Secure Boot. 

2. Можно столкнуться со сложностями в виртуализованной среде — поскольку Credential Guard базируется на VBS, то есть на изолированном с помощью Hyper-V окружении, то для работы на виртуальных машинах требуется режим вложенной виртуализации (nested virtualization). Вложенная виртуализация может не поддерживаться старыми версиями гипервизоров или даже актуальными импортозамещенными решениями. 

3. Виртуальные TPM (vTPM) тоже поддерживаются не везде. 

Короче говоря, идея массового включения Credential Guard в виртуальных средах требует тщательной оценки.

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

Выводы

Защита процесса lsass.exe от кражи учетных данных эволюционировала от набора разрозненных и легко обходимых настроек к многоуровневой архитектуре безопасности, встроенной непосредственно в операционную систему.

Исторически сложившиеся методы, такие как отключение устаревших протоколов (WDigest, NTLM), принудительная очистка памяти и использование группы Protected Users, хоть и несут определенную пользу, все же не могут эффективно противостоять атаке. Их главный недостаток — архитектурный: они не устраняют фундаментальную уязвимость. Критически важные секреты хранятся в памяти основного процесса lsass, доступного для чтения широким перечнем процедур.

Безусловно, значительный шаг вперед — внедрение технологии Protected Process Light (RunAsPPL/LSA Protection). Запуская lsass в защищенном режиме, система серьезно ограничивает круг процессов, которым разрешено взаимодействовать с его памятью, эффективно блокируя простые методы дампа. Однако и эта защита уязвима для атак, исходящих из самого ядра системы, таких как использование уязвимых/скомпрометированных драйверов (BYOVD). Тем не менее LSA Protection точно можно рекомендовать как базовый уровень защиты lsass, который должен быть внедрен во всех средах.

Credential Guard обеспечивает наивысший уровень защиты на сегодняшний день. Его ключевое преимущество — архитектурное: он основан на виртуализации (VBS) и изолирует секреты в отдельном, аппаратно защищенном процессе (LsaIso.exe), который недоступен даже для кода с привилегиями ядра ОС. Да, внедрить его непросто из-за требований к оборудованию и потенциальных проблем с совместимостью. Но хотя методы его обхода описаны, они настолько сложные, шумные и требуют такого высокого уровня привилегий, что Credential Guard становится золотым стандартом защиты учетных данных в памяти. 

Напоследок, отдавая дань моде, можно привести чек-лист по защите процесса: 

НЛО прилетело и оставило здесь промокод для читателей нашего блога:
-15% на заказ любого VDS (кроме тарифа Прогрев) — HABRFIRSTVDS.