Захист облікових даних Windows

Reading time: 10 minutes

Захист облікових даних

WDigest

Протокол WDigest, представлений з Windows XP, призначений для аутентифікації через HTTP-протокол і включений за замовчуванням у Windows XP до Windows 8.0 та Windows Server 2003 до Windows Server 2012. Це налаштування за замовчуванням призводить до зберігання паролів у відкритому тексті в LSASS (Служба підсистеми локальної безпеки). Зловмисник може використовувати Mimikatz для витягування цих облікових даних, виконавши:

sekurlsa::wdigest

Щоб вимкнути або ввімкнути цю функцію, реєстрові ключі UseLogonCredential та Negotiate в HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest повинні бути встановлені на "1". Якщо ці ключі відсутні або встановлені на "0", WDigest є вимкненим:

reg query HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential

LSA Protection (PP & PPL захищені процеси)

Protected Process (PP) та Protected Process Light (PPL) є захистами на рівні ядра Windows, призначеними для запобігання несанкціонованому доступу до чутливих процесів, таких як LSASS. Впроваджений у Windows Vista, PP модель спочатку була створена для забезпечення DRM і дозволяла захищати лише бінарні файли, підписані спеціальним медіа-сертифікатом. Процес, позначений як PP, може бути доступний лише іншим процесам, які також є PP і мають однаковий або вищий рівень захисту, і навіть тоді, тільки з обмеженими правами доступу, якщо це не дозволено спеціально.

PPL, впроваджений у Windows 8.1, є більш гнучкою версією PP. Він дозволяє ширше використання (наприклад, LSASS, Defender), вводячи "рівні захисту" на основі поля EKU (Enhanced Key Usage) цифрового підпису. Рівень захисту зберігається в полі EPROCESS.Protection, яке є структурою PS_PROTECTION з:

• Тип (Protected або ProtectedLight)
• Підписувач (наприклад, WinTcb, Lsa, Antimalware тощо)

Ця структура упакована в один байт і визначає хто може отримати доступ до кого:

• Вищі значення підписувача можуть отримувати доступ до нижчих
• PPL не можуть отримувати доступ до PP
• Незахищені процеси не можуть отримувати доступ до жодного PPL/PP

Що вам потрібно знати з наступальної точки зору

• Коли LSASS працює як PPL, спроби відкрити його за допомогою OpenProcess(PROCESS_VM_READ | QUERY_INFORMATION) з нормального адміністративного контексту терплять невдачу з 0x5 (Access Denied), навіть якщо SeDebugPrivilege увімкнено.
• Ви можете перевірити рівень захисту LSASS за допомогою таких інструментів, як Process Hacker, або програмно, читаючи значення EPROCESS.Protection.
• LSASS зазвичай має PsProtectedSignerLsa-Light (0x41), до якого можна отримати доступ тільки процесам, підписаним вищим підписувачем, таким як WinTcb (0x61 або 0x62).
• PPL є обмеженням лише для користувача; код на рівні ядра може повністю його обійти.
• LSASS, будучи PPL, не запобігає витоку облікових даних, якщо ви можете виконати код ядра або використати процес з високими привілеями з належним доступом.
• Встановлення або видалення PPL вимагає перезавантаження або налаштувань Secure Boot/UEFI, які можуть зберігати налаштування PPL навіть після скасування змін реєстру.

Варіанти обходу захисту PPL:

Якщо ви хочете витягти LSASS, незважаючи на PPL, у вас є 3 основні варіанти:

1. Використовуйте підписаний драйвер ядра (наприклад, Mimikatz + mimidrv.sys), щоб видалити прапорець захисту LSASS:

2. Принесіть свій вразливий драйвер (BYOVD), щоб виконати власний код ядра та вимкнути захист. Інструменти, такі як PPLKiller, gdrv-loader або kdmapper, роблять це можливим.
3. Вкрадіть існуючу дескриптор LSASS з іншого процесу, який його відкрив (наприклад, процес AV), а потім дублюйте його у свій процес. Це є основою техніки pypykatz live lsa --method handledup.
4. Зловживайте деяким привілейованим процесом, який дозволить вам завантажити довільний код у його адресний простір або всередині іншого привілейованого процесу, ефективно обходячи обмеження PPL. Ви можете перевірити приклад цього в bypassing-lsa-protection-in-userland або https://github.com/itm4n/PPLdump.

Перевірте поточний статус захисту LSA (PPL/PP) для LSASS:

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA /v RunAsPPL

Коли ви запускаєте mimikatz privilege::debug sekurlsa::logonpasswords, це, ймовірно, завершиться з кодом помилки 0x00000005 через це.

• Для отримання додаткової інформації про це перевірте https://itm4n.github.io/lsass-runasppl/

Credential Guard

Credential Guard, функція, що є ексклюзивною для Windows 10 (Enterprise та Education editions), підвищує безпеку облікових даних машини, використовуючи Virtual Secure Mode (VSM) та Virtualization Based Security (VBS). Вона використовує розширення віртуалізації процесора для ізоляції ключових процесів у захищеному просторі пам'яті, подалі від основної операційної системи. Ця ізоляція забезпечує, що навіть ядро не може отримати доступ до пам'яті в VSM, ефективно захищаючи облікові дані від атак, таких як pass-the-hash. Local Security Authority (LSA) працює в цьому захищеному середовищі як trustlet, тоді як процес LSASS в основній ОС виконує лише роль комунікатора з LSA VSM.

За замовчуванням Credential Guard не активний і вимагає ручної активації в організації. Це критично важливо для підвищення безпеки проти інструментів, таких як Mimikatz, які обмежені у своїй здатності витягувати облікові дані. Однак вразливості все ще можуть бути використані через додавання користувацьких Security Support Providers (SSP) для захоплення облікових даних у відкритому тексті під час спроб входу.

Щоб перевірити статус активації Credential Guard, можна перевірити реєстровий ключ LsaCfgFlags під HKLM\System\CurrentControlSet\Control\LSA. Значення "1" вказує на активацію з UEFI lock, "2" без замка, а "0" означає, що він не активований. Ця перевірка реєстру, хоча і є сильним показником, не є єдиним кроком для активації Credential Guard. Докладні вказівки та скрипт PowerShell для активації цієї функції доступні онлайн.

reg query HKLM\System\CurrentControlSet\Control\LSA /v LsaCfgFlags

Для всебічного розуміння та інструкцій щодо активації Credential Guard у Windows 10 та його автоматичної активації в сумісних системах Windows 11 Enterprise та Education (версія 22H2), відвідайте документацію Microsoft.

Додаткові відомості про реалізацію користувацьких SSP для захоплення облікових даних наведені в цьому посібнику.

Режим обмеженого адміністратора RDP

Windows 8.1 та Windows Server 2012 R2 представили кілька нових функцій безпеки, включаючи Режим обмеженого адміністратора для RDP. Цей режим був розроблений для підвищення безпеки шляхом зменшення ризиків, пов'язаних з pass the hash атаками.

Традиційно, підключаючись до віддаленого комп'ютера через RDP, ваші облікові дані зберігаються на цільовій машині. Це становить значний ризик для безпеки, особливо при використанні облікових записів з підвищеними привілеями. Однак, з впровадженням Режиму обмеженого адміністратора, цей ризик суттєво зменшується.

При ініціюванні з'єднання RDP за допомогою команди mstsc.exe /RestrictedAdmin, автентифікація на віддаленому комп'ютері виконується без зберігання ваших облікових даних на ньому. Цей підхід забезпечує, що в разі зараження шкідливим ПЗ або якщо зловмисник отримує доступ до віддаленого сервера, ваші облікові дані не будуть скомпрометовані, оскільки вони не зберігаються на сервері.

Важливо зазначити, що в Режимі обмеженого адміністратора спроби доступу до мережевих ресурсів з RDP-сесії не використовуватимуть ваші особисті облікові дані; натомість використовується ідентичність машини.

Ця функція є значним кроком вперед у забезпеченні безпеки віддалених підключень до робочого столу та захисту чутливої інформації від витоку у разі порушення безпеки.

Для отримання більш детальної інформації відвідайте цей ресурс.

Кешовані облікові дані

Windows захищає облікові дані домену через Local Security Authority (LSA), підтримуючи процеси входу з безпековими протоколами, такими як Kerberos та NTLM. Ключовою функцією Windows є її здатність кешувати останні десять входів до домену, щоб забезпечити доступ користувачів до своїх комп'ютерів, навіть якщо контролер домену офлайн—це перевага для користувачів ноутбуків, які часто перебувають поза мережею своєї компанії.

Кількість кешованих входів можна налаштувати за допомогою конкретного реєстраційного ключа або групової політики. Щоб переглянути або змінити цю настройку, використовується наступна команда:

reg query "HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\WINLOGON" /v CACHEDLOGONSCOUNT

Доступ до цих кешованих облікових даних суворо контролюється, лише обліковий запис SYSTEM має необхідні дозволи для їх перегляду. Адміністратори, які потребують доступу до цієї інформації, повинні робити це з привілеями користувача SYSTEM. Облікові дані зберігаються за адресою: HKEY_LOCAL_MACHINE\SECURITY\Cache

Mimikatz може бути використаний для витягнення цих кешованих облікових даних за допомогою команди lsadump::cache.

Для отримання додаткової інформації оригінальне джерело надає всебічну інформацію.

Захищені користувачі

Членство в групі Захищені користувачі вводить кілька покращень безпеки для користувачів, забезпечуючи вищі рівні захисту від крадіжки та зловживання обліковими даними:

• Делегування облікових даних (CredSSP): Навіть якщо налаштування групової політики для Дозволити делегування стандартних облікових даних увімкнено, облікові дані захищених користувачів у відкритому тексті не будуть кешуватися.
• Windows Digest: Починаючи з Windows 8.1 та Windows Server 2012 R2, система не буде кешувати облікові дані захищених користувачів у відкритому тексті, незалежно від статусу Windows Digest.
• NTLM: Система не буде кешувати облікові дані захищених користувачів у відкритому тексті або односторонні функції NT (NTOWF).
• Kerberos: Для захищених користувачів аутентифікація Kerberos не буде генерувати DES або RC4 ключі, а також не буде кешувати облікові дані у відкритому тексті або довгострокові ключі після первинного отримання квитка на отримання квитків (TGT).
• Офлайн вхід: У захищених користувачів не буде створено кешований перевірник під час входу або розблокування, що означає, що офлайн вхід не підтримується для цих облікових записів.

Ці заходи захисту активуються в момент, коли користувач, який є членом групи Захищені користувачі, входить на пристрій. Це забезпечує наявність критичних заходів безпеки для захисту від різних методів компрометації облікових даних.

Для отримання більш детальної інформації зверніться до офіційної документації.

Таблиця з документів.