Методы защиты от mimikatz в домене Windows

Конец июня 2017 года запомнился IT сообществу по массовому заражению множества крупнейших компаний и госучреждений России, Украины и других стран новым вирусом-шифровальщиком Petya (NotPetya). В большинстве случаев, после проникновения внутрь корпоративной сети, Petya молниеносно распространялся по всем компьютерам и серверам домена, парализуя до 70-100% всей Windows-инфраструктуры. И хотя, одним из методов распространения Пети между компьютерами сети было использование эксплоита EternalBlue (как и в случае с WannaCry), это был не основной канал распространения вымогателя. В отличии от WCry, который распространялся исключительно благодаря уязвимости в SMBv1, NotPetya были изначально заточен под корпоративные сети. После заражения системы, шифровальщик с помощью общедоступной утилиты Mimikatz, получал учетные данные (пароли, хэши) пользователей компьютера и использовал их для дальнейшего распространения по сети с помощью WMI и PsExec, вплоть до полного контроля над доменом. Соответственно, для защиты всех систем не достаточно было установить обновление MS17-010.

В этой статье мы рассмотрим основные методики защиты Windows систем в домене Active Directory от атак посредством Mimikatz–like инструментов.

Утилита Mimikatz с помощью модуля sekurlsa позволяет извлечь пароли и хэши авторизованных пользователей, хранящиеся в памяти системного процесса LSASS.EXE (Local Security Subsystem Service ). У нас уже была статья с примером использования mimikatz для получения в паролей пользователей в открытом виде (из WDigest, LiveSSP и SSP).

Предотвращение возможности получения debug

В статье по ссылке выше видно, как использование привилегии debug, позволяет Mimikatz получить доступ к системному процессу LSASS и извлечь из него пароли.

По умолчанию, права на использование режима debug предоставляются локальной группе администраторов (BUILTIN\Administrators). Хотя в 99% случаях эта привилегия абсолютно не используется администраторами (нужна она как правило системным программистам), соответственно, в целях безопасности возможность использования привелегии SeDebugPrivilege лучше отключить. Делается это через групповую политику (локальную или доменную). Перейдите в раздел Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment и включите политику Debug Program. В нее нужно добавить доменную группу пользователей, которым могут понадобится права debug (как правило, разработчики), либо оставить эту группу пустой, чтобы данного права не было не у кого.

Теперь, если попробовать получить debug через mimikatz появится ошибка:

EROOR kuhl_m_privilege_simple ; RtlAdjustPrivilege (20) c0000061

Отключение WDigest

Протокол WDigest появился в Windows XP и использовался для выполнения HTTP дайджест-аутентификации (HTTP Digest Authentication), особенностью которой являлось использование пароля пользователя в открытом виде. В Windows 8.1 and Server 2012 R2 добавилась возможность полного запрета хранения паролей в открытом виде в LSASS. Для запрета хранения WDigest в памяти, в этих ОС в ветке реестра HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest уже имеется DWORD32 параметр с именем UseLogonCredential и значением 0.

Если же нужно полностью отключить метод аутентификации WDigest, в этой же ветке (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest) установите значение ключа Negotiate в 0.

Для поддержки этой возможности в Windows 7, 8 и Windows Server 2008 R2 / 2012 необходимо установить специальное обновление — KB2871997, а потом выставить эти же ключи реестра. В доменной среде параметры реестра проще всего распространить с помощью групповой политики.

Защита LSA от подключения сторонних модулей

В Windows 8.1 и Windows Server 2012 R2 появилась возможность включения защиты LSA, обеспечивающей защиту памяти LSA и предотвращаю возможность подключения к ней из незащищённых процессов. Для включения этой защиты, необходимо в ветке реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA создать параметр RunAsPPL со значением 1.

После применения этого параметра атакующий не сможет получить доступ к памяти LSA, а mimikatz на команду securlsa::logonpassword, выдаст ошибку

ERROR kuhl_m_securlsa_acquireLSA : Handle on memory (0x00000005).

Отключение LM и NTLM

Устаревший протокол LM аутентификации и, соответственно, хранение LM хэшей нужно обязательно отключить с помощью групповой политики Network Security: Do Not Store LAN Manager Hash Value On Next Password Change (на уровне Default Domain Policy).

Далее нужно отказаться от использования как минимум протокола NTLMv1 (политика в разделе Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options — Network Security: Restrict NTLM: NTLM authentication in this domain), а как максимум и NTLMv2

И если отказ от NTLMv1 как правило проходит безболезненно, то при отказе от NTLMv2 придется потрудиться. В больших инфраструктурах, как правило, приходят к сценарию максимального ограничения использования NTLMv2. Т.е. везде, где возможно должна использоваться Kerberos аутентификация (как правило придется уделить дополнительное время настройке Kerberos аутентификации на IIS и SQL), а на оставшихся системах — NTLMv2.

Запрет использования обратимого шифрования

Следует явно запретить хранить пароли пользователей в AD в текстовом виде. Для этого следует включить доменную политику Store password using reversible encryption for all users in the domain в разделе Computer Configuration -> Windows Settings ->Security Settings -> Account Policies -> Password Policy, выставив ее значание на Disabled.

Использование группы Protected Users

При использовании функционального уровня домена Windows Server 2012 R2, для защиты привилегированных пользователей возможно использовать специальную защищенную группу Protected Users. В частности, защита этих учеток от компрометации выполняется за счет того, что члены этой группы могут авторизоваться только через Kerberos (никаких NTLM, WDigest и CredSSP) и т.д. (подробности по ссылке выше). Желательно добавить в эту группу учетные записи администраторов домена, серверов и пр. Этот функционал работает на серверах будет работать на Windows Server 2012 R2 (для Windows Server 2008 R2 нужно ставить упомянутое выше дополнительное обновление KB2871997)

Запрет использования сохранённых паролей

Можно запретить пользователям домена сохранять свои пароли для доступа к сетевым ресурсам в Credential Manager.

Для этого включите политику Network access: Do not allow storage of passwords and credentials for network authentication в разделе Computer Configuration -> Windows Settings ->Security Settings ->Local Policies ->Security Options.

Запрет кэширования учетных данных

Одной из возможностей mimikats – получения хэша паролей пользователей из ветки реестра HKEY_LOCAL_MACHINE\SECURITY\Cache, в которую сохраняются хэши паролей последних 10 (по-умолчанию) доменных пользователей, врошедших в систему. Эти хэши в обычном случае могут использоваться для авторизации пользователей в системе при недоступности контроллера домена.

Желательно запретить использование сохранения кэшированных данных пользователя для входа с помощью включения политики Interactive Logon: Number of previous logons to cache (in case domain controller is not available) в разделе Computer Configuration -> Windows Settings -> Local Policy -> Security Options, изменив значение ее параметра на 0.

Кроме того, чтобы ускорить очистку памяти процесса lsass от учётных записей пользователей, завершивших сеанс, нужно в в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa нужно создать ключ типа DWORD с именем TokenLeakDetectDelaySecs и значением 30. Т.е. память будет очищаться через 30 секунд после логофа пользователя. В Windows 7, 8/ Server 2008R2, 2012 чтобы этот ключ заработал, нужно установить уже упоминавшееся ранее обновление KB2871997.

Credential Guard

В Windows 10 Enterprise, Windows Server 2016 появился новый компонент Credential Guard, позволяющий изолировать и защитить системный процесс LSASS от несанкционированного доступа. Подробности здесь.

Выводы

Рассмотренные выше меры позволят существенно снизить возможности mimikatz и ей подобных утилит для получения паролей и хэшей администраторов из процесса LSASS и системного реестра. В любом случае, при принятии решения о внедрения этих политик и методик, их нужно вводить поэтапно с обязательным тестированием.

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