Методи захисту від 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
  • відключення WDigest
  • Захист LSA від підключення сторонніх модулів
  • Відключення LM і NTLM
  • Заборона використання оборотного шифрування
  • Використання групи Protected Users
  • Заборона використання збережених паролів
  • Заборона кешування облікових даних
  • Credential Guard
  • висновки

Запобігання можливості отримання 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, а потім виставити ці ж ключі реєстру. У доменній середовищі параметри реєстру найпростіше поширити за допомогою групової політики.

Порада. При відмові від зберігання WDigest в пам'яті, в першу чергу варто протестувати коректність авторизації користувачів і додатків на IIS серверах.

Захист 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 від подібних атак. Слідкуйте за оновленнями!