Зупиніть крадіжку облікових даних: налаштування Windows, яке ніхто не вмикає

February 20, 2026 • February 20, 2026 • Читання: 4 хв • Views: 0

Було корисно?

Більшість крадіжок облікових даних у Windows — це не магія. Це інженерія. Зловмисникам не потрібні голлівудські «зломи», коли ваші кінцеві точки тихо зберігають повторно використовувані секрети в місцях, створених для зручності, а не для роботи в умовах ворожих мереж.

Налаштування, яке змінює економіку для нападників, — це Windows Defender Credential Guard. Воно не нове. Воно не екзотичне. Просто… його рідко включають послідовно. І саме тому воно постійно з’являється в звітах після інцидентів, як відсутній датчик диму: ви помічаєте його лише після пожежі.

Налаштування: Credential Guard (і що воно насправді робить)

Credential Guard — це спроба Microsoft припинити перетворення Windows на шведський стіл повторно використовуваних секретів. Конкретно воно використовує Virtualization-Based Security (VBS) для ізоляції секретів так, щоб навіть якщо зловмисник отримає адміністраторські права на машині, «головні цінності» було складніше витягнути та відтворити.

Без Credential Guard служба Local Security Authority Subsystem Service (LSASS) виступає і як швейцар, і як бар. Вона аутентифікує користувачів і також зберігає матеріали облікових даних у процесі. Якщо загарбник може зняти дамп пам’яті LSASS (або змусити його через підписані драйвери, привілеї відладки чи маніпуляції токенами), він часто може зібрати:

NTLM-хеші (паливо для Pass-the-Hash)
Kerberos Ticket Granting Tickets (паливо для Pass-the-Ticket)
Кешовані доменні облікові дані (паливо для офлайн-клацання)
Інколи навіть відкриті секрети, залежно від конфігурації та старих компонентів аутентифікації

З Credential Guard чутливі дані переміщуються в захищене середовище (ізольований режим користувача), підкріплене гіпервізором. LSASS все ще може запитувати операції аутентифікації, але воно не зберігає коронні коштовності в легкодоступній формі, яку просто зішкрібнути.

Чи є Credential Guard досконалим? Ні. Нічого ідеального не буває. Це контроль, який підвищує вартість атаки та зменшує радіус ураження. У продукційній безпеці саме це й потрібно.

Чого Credential Guard не робить

Воно не виправляє слабкі паролі, надмірні привілеї облікових записів або «Domain Admin скрізь».
Воно не зупиняє фішинг, який може захопити облікові дані до того, як вони потраплять на вашу машину.
Воно не запобігає діям залогіненого зловмисника, який діє від імені цього користувача.
Воно не робить застарілу аутентифікацію безпечною; часто вона просто ламає її (що є функцією, а не багом).

Чому його ніхто не вмикає (і чому це слабкий привід)

Credential Guard ігнорують з трьох причин: страх, інерція та «сумісність». У більшості організацій є хоча б один застарілий бізнес-додаток, один клієнт VPN від вендора або один «особливий» модуль аутентифікації, що востаннє оновлювався, коли ще сперечалися, чи прижиться Wi‑Fi.

Тому команди роблять те, що роблять команди під тиском доставки: уникають змін, які можуть спричинити тікети. Вони утримують поверхню облікових даних відкритою, бо «так завжди працювало».

Тим часом зловмисники автоматизують крадіжки облікових даних. Їм не потрібен ваш графік служби підтримки. Вони працюють на швидкості машин.

Ось неприємна правда: сумісність — це вирішувана проблема; крадіжка облікових даних у масштабі — це проблема, що може знищити бізнес. Ваша мета — знайти невелику кількість кінцевих точок та робочих процесів, які дійсно не можуть працювати з Credential Guard, ізолювати їх і припинити вдавати, що все підприємство має залишатися незахищеним заради їхньої зручності.

Жарт №1: Якщо ваша стратегія безпеки базується на «ніколи не буде локального адміністратора», у мене є міст на продаж — оплату приймаю в NTLM-хешах.

Що ви фактично зупиняєте: LSASS, хеші, квитки та відтворення

Credential Guard орієнтоване на дуже специфічний і дуже поширений сегмент ланцюжка атак: відтворення облікових даних після компрометації та латеральний рух. Схема виглядає так:

Початковий доступ (фішинг, експлойт в браузері, вкрадені VPN-облікові дані, відкритий RDP, шкідлива макрокоманда — обирайте отруту).
Локальне підвищення привілеїв або крадіжка токена для отримання високого рівня довіри.
Знімання облікових даних з LSASS (або примус отримати матеріал аутентифікації) і повторне їх використання.
Латеральний рух до файлових серверів, RDP на робочі станції, атака AD, збір ще більше облікових даних, ескалація до доменного домінування.

Credential Guard робить крок 3 суттєво складнішим, ізолюючи секрети, обмежуючи те, що LSASS може показувати, і зменшуючи цінність інструментів «зняв і поїхав».

Варто виділити частини, що постійно фігурують у інцидентах:

Pass-the-Hash (PtH)

NTLM-хеші повторно використовуються у надто багатьох місцях. Якщо ви можете зібрати хеш привілейованого облікового запису, часто можна аутентифікуватися, ніколи не знаючи пароля. Credential Guard зменшує доступність таких хешів у LSASS.

Pass-the-Ticket (PtT)

Kerberos-квитки можна відтворити. Якщо нападники можуть витягнути матеріали квитків, вони можуть видавати себе за користувачів і сервіси. Credential Guard зменшує експозицію секретів, що видають квитки.

WDigest та застарілі постачальники облікових даних

Windows зберегла поведінки старої аутентифікації для сумісності. Деякі з них по суті «зберігають секрети так, як зручно для нападників». Ви хочете від них позбутися.

Експозиція облікових даних через RDP

RDP не зло. Але дозволяти користувачам з високими привілеями RDP на невисоконадійні кінцеві точки — це як віддавати адміністраторські креденшіали першому зразку шкідливого ПЗ, якому пощастило. Credential Guard допомагає, але також потрібні Remote Credential Guard і розумна архітектура робочих станцій адміністраторів.

Факти та історія, що пояснюють сучасний безлад

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

LSASS довгий час був цінною ціллю, бо там відбувається Windows-аутентифікація і кумулюються матеріали облікових даних під час нормального використання.
«Pass-the-Hash» став широко відомий у кінці 2000-х, і він залишався релевантним, бо NTLM лишався в підприємствах як незакритий принтер: завжди поруч, тихо критичний.
WDigest створювали для сумісності зі старими схемами аутентифікації; проблема в тому, що сумісність іноді означає «зручніше обробляти відкриті паролі». Сучасні версії Windows посилили значення за замовчуванням, але оновлення і дрейф політик підтримують ризик.
Credential Guard з’явився в еру Windows 10 Enterprise / Windows Server 2016, пов’язаний із VBS та ізоляцією гіпервізора — безпека, вбудована в платформу, а не прикручена зверху.
Віртуалізація стала межою безпеки, бо класичний ОС-перегородок не витримував при роботі з драйверами ядра, правами адміністратора та скрейпінгом пам’яті; гіпервізор складніше підробити, ніж процес користувача.
Інструменти атак професіоналізувалися: те, що колись було нішевим вмінням, стало доступне у вигляді «натисни кнопку» фреймворків, які швидко та тихо витягують облікові дані.
«Захист LSASS» (RunAsPPL) з’явився раніше за масове впровадження Credential Guard; багато організацій увімкнули PPL, але не завершили роботу, залишивши інші матеріали облікових даних доступними.
Сучасні рекомендації Microsoft частіше базуються на принципі «припускай компрометацію», зосереджуючись на мінімізації експозиції облікових даних, а не на запевненнях, що кінцеві точки ніколи не будуть скомпрометовані.

Швидкий план діагностики

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

1) Перевірте спочатку: чи Credential Guard дійсно увімкнено?

Перегляньте статус VBS та стан виконання Credential Guard.
Якщо воно «сконфігуровано», але не «працює», у вас проблема з платформою/передумовами (прошивка, віртуалізація, політика, конфлікти драйверів).

2) Перевірте далі: чи ви все ще просочуєте облікові дані через застарілі налаштування?

WDigest, використання NTLM, кешовані входи та «зручні» налаштування делегування.
Якщо ви досі дозволяєте NTLM повсюдно, Credential Guard допомагає, але ви лишаєте бічні двері відкритими.

3) Третя перевірка: чи адміністратори входять у невірні місця?

Привілейовані облікові записи на робочих станціях користувачів — це інцидент, що чекає на запрошення в календарі.
Виправте робочі процеси: робочі станції для адміністраторів (PAW/SAW), Remote Credential Guard і чіткий розподіл ролей.

4) Четверта перевірка: чи блокуєте ви звичайні техніки знімання пам’яті?

LSASS PPL, правила Attack Surface Reduction (ASR), контроль драйверів і захист від підробки EDR.
Якщо ви не можете зупинити завантаження підписаного вразливого драйвера, ваша історія ізоляції слабша, ніж виглядає.

Практичні завдання: 12+ перевірок із командами, виводом, рішеннями

Це завдання «зробіть на машині». Кожне містить реалістичну команду, що означає вивід і яке рішення ухвалювати далі. Виконуйте їх у підвищеній сесії PowerShell, якщо не вказано інше. Підказки в блоках залишаються без змін за задумом.

Завдання 1: Перевірити, чи Credential Guard працює (WMI)

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Select-Object -ExpandProperty SecurityServicesRunning"
1
2

Що це означає: Числовий масив перераховує сервіси безпеки, що зараз працюють під Device Guard/VBS. Зазвичай 1 вказує на Credential Guard, а 2 — на Hypervisor-protected Code Integrity (HVCI), хоча точні відповідності можуть відрізнятися за збіркою.

Рішення: Якщо ви не бачите очікуваних значень, Credential Guard не працює. Перейдіть до перевірки передумов і політик (Завдання 2–4).

Завдання 2: Перевірити, чи увімкнено VBS (WMI)

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Select-Object VirtualizationBasedSecurityStatus, RequiredSecurityProperties, AvailableSecurityProperties | Format-List"
VirtualizationBasedSecurityStatus : 2
RequiredSecurityProperties       : {1}
AvailableSecurityProperties      : {0, 1, 2, 3}

Що це означає: VirtualizationBasedSecurityStatus зазвичай: 0=вимкнено, 1=сконфігуровано але не працює, 2=працює. Поля Required/Available підказують, чи підтримує апарат/прошивка модель безпеки.

Рішення: Якщо статус 1, ймовірно потрібен перезавантаження, увімкнення віртуалізації в прошивці або усунення конфліктних драйверів. Якщо 0, політика не застосована.

Завдання 3: Перевірити наявність гіпервізора Hyper-V (system info)

cr0x@server:~$ powershell -NoProfile -Command "systeminfo | Select-String -Pattern 'Hyper-V Requirements|A hypervisor has been detected|Virtualization' -Context 0,1"
Hyper-V Requirements:      VM Monitor Mode Extensions: Yes
                           Virtualization Enabled In Firmware: Yes
                           Second Level Address Translation: Yes
                           Data Execution Prevention Available: Yes

Що це означає: Для багатьох сценаріїв VBS потрібні апаратна віртуалізація і SLAT. Якщо «Virtualization Enabled In Firmware: No», ви без шансів.

Рішення: Якщо віртуалізація вимкнена, заплануйте зміну в BIOS/UEFI та вікно обслуговування. Якщо відсутній SLAT, таке обладнання не підійде для VBS.

Завдання 4: Підтвердити політику Credential Guard у реєстрі

cr0x@server:~$ powershell -NoProfile -Command "reg query 'HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard' /v EnableVirtualizationBasedSecurity & reg query 'HKLM\SYSTEM\CurrentControlSet\Control\Lsa' /v LsaCfgFlags"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard
    EnableVirtualizationBasedSecurity    REG_DWORD    0x1

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
    LsaCfgFlags    REG_DWORD    0x1

Що це означає: Ці значення часто відображають конфігурацію VBS і Credential Guard. Значення LsaCfgFlags можуть вказувати на вимкнення/увімкнення з UEFI lock або без нього залежно від вибору організації.

Рішення: Якщо політика встановлена, але WMI показує «не працює», усуньте проблеми з передумовами (драйвери, стан гіпервізора, Secure Boot, потреба в перезавантаженні).

Завдання 5: Перевірити, чи LSASS працює як Protected Process Light (PPL)

cr0x@server:~$ powershell -NoProfile -Command "Get-Process -Name lsass | Select-Object Name,Id,Path | Format-List"
Name : lsass
Id   : 628
Path : C:\Windows\System32\lsass.exe

Що це означає: PowerShell безпосередньо не показує PPL. Це завдання підтверджує шлях процесу й базову цілісність перед перевіркою реєстру і подій у наступному кроці.

Рішення: Якщо lsass не знаходиться за очікуваним шляхом, ставте це під підозру і негайно розслідуйте.

Завдання 6: Підтвердити налаштування «RunAsPPL» для LSASS

cr0x@server:~$ powershell -NoProfile -Command "reg query 'HKLM\SYSTEM\CurrentControlSet\Control\Lsa' /v RunAsPPL"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
    RunAsPPL    REG_DWORD    0x1

Що це означає: RunAsPPL=1 увімктає LSASS як protected process light, що блокує багато технік знімання пам’яті в просторі користувача, якщо лише нападник не має трюків на рівні ядра.

Рішення: Якщо значення 0 або відсутнє, додайте його до базової конфігурації. Credential Guard і PPL доповнюють одне одного; не обирайте лише одне і вважайте роботу завершеною.

Завдання 7: Перевірити використання WDigest (ризик відкритого тексту)

cr0x@server:~$ powershell -NoProfile -Command "reg query 'HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' /v UseLogonCredential"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest
    UseLogonCredential    REG_DWORD    0x0

Що це означає: 0 загалом означає, що WDigest не кешує облікові дані в спосіб, що відкриває відкриті паролі. 1 — червоний прапорець, якщо тільки у вас немає дуже специфічної спадщини потреби.

Рішення: Якщо 1, виправте політикою і аудитом, які додатки це змушують. Якщо хтось «потребував» цього, нехай доведе це і ізолюйте ту систему.

Завдання 8: Виявити використання NTLM на кінцевій точці (локальні події)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 30 | Where-Object {$_.Properties[10].Value -like 'NTLM*'} | Select-Object -First 5 | ForEach-Object { $_.Properties[5].Value + ' ' + $_.Properties[10].Value }"
jdoe NTLMv2
svc_backup NTLMv2
jdoe NTLMv2

Що це означає: Показуються недавні входи з використанням NTLM. Розбір подій варіюється; суть — знайти, чи NTLM все ще активний у робочих процесах.

Рішення: Якщо NTLM поширений для адміністраторських облікових записів або доступу до серверів, у вас є прискорювач латерального руху. Плануйте обмеження NTLM і перенос сервісів на Kerberos де можливо.

Завдання 9: Перевірити кількість кешованих логонів (експозиція кешу офлайн)

cr0x@server:~$ powershell -NoProfile -Command "reg query 'HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon' /v CachedLogonsCount"
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
    CachedLogonsCount    REG_SZ    10

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

Рішення: Зменшіть його там, де бізнес дозволяє (особливо для привілейованих користувачів), і поєднуйте з BitLocker і жорсткими контролями пристроїв. Не ламайте роботу мобільних співробітників без пілоту.

Завдання 10: Перевірити готовність Remote Credential Guard (RDP клієнт/сервер)

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name SecurityLayer,UserAuthentication | Format-List"
SecurityLayer      : 2
UserAuthentication : 1

Що це означає: Налаштування вказують на переговори безпеки RDP та NLA. Це не повна перевірка Remote Credential Guard, але швидкий сигнал, що ви не працюєте повністю беззахисно по RDP.

Рішення: Якщо NLA вимкнено, увімкніть його. Потім спроектуйте доступ адміністраторів з використанням Remote Credential Guard або еквівалентних захищених jump host.

Завдання 11: Підтвердити стан Secure Boot (часто потрібний для зафіксованих режимів)

cr0x@server:~$ powershell -NoProfile -Command "Confirm-SecureBootUEFI"
True

Що це означає: Secure Boot увімкнено. Деякі режими розгортання Credential Guard (особливо з UEFI lock) припускають Secure Boot для підвищення захисту від підробки.

Рішення: Якщо false, вирішіть, чи погоджуєтесь прийняти «сконфігуровано, але легше підробити», або заплануйте увімкнення Secure Boot. Для привілейованих кінцевих точок плануйте Secure Boot.

Завдання 12: Перевірити, чи ви віртуалізовані (і чи VBS підтримується там)

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_ComputerSystem | Select-Object Model,Manufacturer"
Model        Manufacturer
-----        ------------
Virtual Machine Microsoft Corporation

Що це означає: Цей хост віртуалізовано. Підтримка VBS/Credential Guard у віртуальних машинах залежить від вашого гіпервізора, його версії та можливостей (nested virtualization, vTPM тощо).

Рішення: Якщо критичні сервери — ВМ, перевірте, чи ваш гіпервізор підтримує потрібні можливості. Не вимагайте VBS, а потім розгорніть на платформі, яка його не підтримує.

Завдання 13: Виявити потенційно небезпечні налаштування делегування облікових записів (запит AD з хоста адміністратора)

cr0x@server:~$ powershell -NoProfile -Command "Get-ADUser -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation | Select-Object SamAccountName,TrustedForDelegation | Sort-Object SamAccountName | Select-Object -First 5"
SamAccountName TrustedForDelegation
------------- --------------------
svc_app01     True
svc_legacy02  True

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

Рішення: Проведіть аудит причин існування кожного з них. Віддавайте перевагу обмеженому делегуванню та сучасним паттернам аутентифікації. Якщо ви не знаєте, навіщо воно є — це ваша відповідь.

Завдання 14: Підтвердити стан правил ASR, що стосуються крадіжки облікових даних (Defender)

cr0x@server:~$ powershell -NoProfile -Command "Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Ids | Select-Object -First 5"
D4F940AB-401B-4EFC-AADC-AD5F3C50688A
9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2

Що це означає: Правила ASR налаштовані. Потрібно зіставити GUIDи з намірами правил у вашому стандарті, але це показує, чи кінцева точка навіть «у грі».

Рішення: Якщо ASR не використовується, Credential Guard сам по собі залишає інші шляхи крадіжки облікових даних відкритими (скриптове знімання, підозрілі процеси). Плануйте застосування ASR у режимі аудиту, потім — в режимі примусового виконання.

Завдання 15: Підтвердити налаштування дампів при збоях (щоб уникнути «ми випадково записали LSASS на диск»)

cr0x@server:~$ powershell -NoProfile -Command "reg query 'HKLM\SYSTEM\CurrentControlSet\Control\CrashControl' /v CrashDumpEnabled & reg query 'HKLM\SYSTEM\CurrentControlSet\Control\CrashControl' /v DumpFile"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl
    CrashDumpEnabled    REG_DWORD    0x2

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl
    DumpFile    REG_EXPAND_SZ    %SystemRoot%\MEMORY.DMP

Що це означає: Кернел/дампи пам’яті можуть містити чутливі матеріали залежно від контексту збою та інструментів. Це не означає автоматично, що Credential Guard вимкнено, але це ризик обробки даних.

Рішення: Забезпечте захист дампів (ACL, шифрування на диску, обмежений доступ) і розглядайте дампи як високочутливі під час інциденту.

Три корпоративні міні-історії з реального світу

Міні-історія 1: Інцидент, спричинений хибним припущенням

Середня компанія мала сильний EDR і гордий графік патчування. Їхнє припущення було просте: «Якщо Defender і EDR встановлені скрізь, крадіжку облікових даних буде виявлено». Вони розглядали крадіжку облікових даних як проблему виявлення, а не проблему експозиції.

Фішингова кампанія потрапила на робочу станцію фінансів. Початкове шкідливе ПЗ нічого особливого не робило. Воно чекало на локальний адміністративний токен (хтось із ІТ підключився віддалено, щоб «полагодити Outlook»), потім використало ці привілеї, щоб спробувати доступ до LSASS. EDR заблокував один відомий метод знімання пам’яті. Усі зітхнули. Тікет закрито.

Два дні потому файловий сервер показав дивні шаблони доступу. Потім — контролер домену. Нападник не мусив «гучно» знімати LSASS. Він використовував альтернативні шляхи: імітацію токенів, зібрані кешовані матеріали та відтворення облікових даних через вбудовані механізми Windows. Вони не були швидші за команду оборони. Вони були просто терплячішими.

Постмортем був болісним, бо контрзаходи «були», але секрети все ще були досяжні. Credential Guard не увімкнули через «воно ламає деякі VPN». Це було правдою для кількох кінцевих точок, але не для 18 000.

Виправлення не було героїчним. Вони впровадили Credential Guard для стандартних користувачів спочатку, потім для ІТ, потім для ретельно спроектованого рівня робочих станцій адміністраторів. Найбільшою зміною була культура: адміністраторські акаунти припинили входити на випадкові кінцеві точки. Улюблений хід нападника — взяти привілейований хеш з робочої станції — перестав бути надійним.

Міні-історія 2: Оптимізація, що відбилася боком

Глобальна компанія була одержима продуктивністю. Вони оптимізували час завантаження і віддалений доступ у масштабі. Частина цієї оптимізації включала щедре кешування облікових даних («користувачі подорожують»), широке дозволення NTLM («спадкові шари») і кілька зручних політик, що зменшували кількість звернень у службу підтримки.

Потім вони включили Credential Guard для пілотної групи розробників. Невеликий набір віддалених робочих процесів сповільнився. Деякі старі аутентифікаційні обміни зламалися. Голосно зробили висновок: «Credential Guard спричиняє проблеми». Тихою реальністю було: «Ми покладалися на незахищені обхідні шляхи як оптимізацію продуктивності».

Замість усунення залежностей вони відкотили зміни. Через шість місяців нападник потрапив на робочу станцію розробника, зішкреб що міг і використав латеральний рух на основі NTLM, щоб дістатися до сервера збірки. Звідти він підмінив артефакти, і реакція на інцидент стала проблемою ланцюга постачання програмного забезпечення — дорога, репутаційна, повільна у вирішенні.

Після цього «оптимізацію» перейменували на те, чим вона була: інструмент технічного боргу з відсотками. Credential Guard повернули, але цього разу разом з ремедіацією: міграція конкретних сервісів на Kerberos, звуження області NTLM і використання захищених jump host для адміністративних шляхів. Продуктивність була в порядку. Небезпечний обхід виявився справжнім вузьким місцем — просто не тим, який вимірювали на дашбордах.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Одна медична організація дотримувалась суворої базової конфігурації кінцевих точок. Це не було гламурно. Це була купа групових політик, VBS там, де можливо, Credential Guard, застосований на більшості кінцевих точок, і жорстке правило: привілейовані облікові записи заходять тільки з привілейованих робочих станцій. Вони також мали невеликий список виключень для систем, що не підтримують VBS, і ті системи були ізольовані як радіоактивні елементи.

Їх усе одно вразило шкідливе ПЗ. Таке буває. Різниця була в тому, що шкідливе ПЗ не могло зробити. Воно потрапило на ПК у палаті, отримало рівень користувача і спробувало рухатися латерально. Воно майже нічого не могло повторно використати. Адмін-креденшіали були відсутні. Матеріали для аутентифікації були менш доступні. Очевидні шляхи PtH та PtT були ненадійні.

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

Післяінцидентний розбір був майже нудним: «Базова конфігурація спрацювала як проектувалося». Ось цього й треба прагнути. Надійність — це не феєрверк; це відсутність сюрпризів.

Чеклісти / покроковий план (розгортання, що не зруйнує службу підтримки)

Credential Guard — це не просто чекбокс. Це розгортання. Робіть його як інженер з надійності (SRE): поетапно, вимірювано, з можливістю відкату там, де це потрібно, і з короткими зворотними зв’язками.

Крок 1: Інвентаризація та сегментація кінцевих точок (не варіть океан)

Модель Tier 0/1/2: контролери домену та інфраструктура ідентичності; серверні рівні; кінцеві точки користувачів.
Визначте кінцеві точки, що мають підтримувати застарілу автентифікацію (системи вендорів, старі VPN-клієнти, спеціальне апаратне забезпечення з драйверами).
Створіть «кільце винятків» з компенсуючими контролями (мережева ізоляція, обмежені адміністраторські входи, посилені політики EDR).

Крок 2: Чисте увімкнення передумов

Увімкнена апаратна віртуалізація в прошивці.
Secure Boot увімкнено там, де можливо (особливо на привілейованих кінцевих точках).
Гігієна драйверів: видаляйте або оновлюйте несумісні драйвери ядра.

Крок 3: Пілот у кільцях

Кільце 0: ноутбуки команди безпеки ІТ і кілька дружніх просунутих користувачів.
Кільце 1: стандартні користувачі.
Кільце 2: робочі станції розробників (часто найбрудніша аутентифікаційна стек).
Кільце 3: привілейовані робочі станції та jump host для адміністраторів.

Крок 4: Поєднуйте з нудними контролями, які роблять його стійким

Увімкніть LSASS PPL (RunAsPPL), де підтримується.
Вимкніть кешування WDigest у відкритому вигляді (перевіряйте, що воно лишається вимкненим).
Використовуйте правила Attack Surface Reduction (почніть у режимі аудиту, потім примусово включайте).
Зменшуйте слід NTLM; обмежуйте його там, де можливо.
Розділяйте адміністраторські ідентичності і обмежуйте, де вони можуть входити.

Крок 5: Моніторинг та примусове виконання

Звітуйте про стани «сконфігуровано, але не працює».
Відстежуйте пристрої з винятками і періодично підтверджуйте їхнє виправдання.
Налаштуйте оповіщення про підозрілі спроби доступу до LSASS і матеріалів облікових даних.

Крок 6: Документуйте типові збої, що повідомлятимуть користувачі

Старі VPN-клієнти, що намагаються підключати провайдерів аутентифікації.
Застарілі плагіни SSO.
ПЗ для смарт-карт або проміжні модулі безпеки з застарілими драйверами.

Жарт №2: Єдина річ більш постійна, ніж тимчасове виняток — це тимчасове виняток, яке «ще потребує одного кварталу».

Поширені помилки: симптом → корінна причина → виправлення

1) «Credential Guard увімкнено політикою, але не працює.»

Симптом: WMI показує статус VBS «сконфігуровано» або «вимкнено», а SecurityServicesRunning порожній.

Корінна причина: Відсутня апаратна віртуалізація, невідповідність стану Secure Boot, несумісні драйвери або відсутній перезавантаження після увімкнення.

Виправлення: Перевірте апаратну віртуалізацію (Завдання 3), Secure Boot (Завдання 11) і усуньте конфлікт драйверів. Перезавантажтеся. Якщо це ВМ — підтвердьте підтримку гіпервізора (Завдання 12).

2) «Після увімкнення VPN/SSO зламалося.»

Симптом: Циклічні підказки аутентифікації, SSO не працює або клієнт не підключається.

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

Виправлення: Оновіть клієнта, перейдіть на підтримуваний метод аутентифікації або ізолюйте робочий процес до захищених jump host. Не відкатуйте глобально — створіть кільце винятків із компенсуючими контролями.

3) «RDP на сервери тепер просить облікові дані інакше / автоматизація зламалася.»

Симптом: Скрипти, що покладаються на збережені креденшіали, не працюють; адміністратор скаржиться на додаткові підказки.

Корінна причина: Ви покладалися на патерни делегування облікових даних, що є ризикованими за своєю суттю.

Виправлення: Використовуйте Remote Credential Guard там, де доречно, переносіть автоматизацію на керовані ідентичності/сервісні учасники і припиніть вкладати повторно використовувані секрети в скрипти.

4) «EDR каже, що доступ до LSASS заблоковано; користувачі повідомляють про випадкові збої додатків.»

Симптом: Інструмент безпеки блокує процес, що читає LSASS; «менеджер паролів» або агент моніторингу скаржиться.

Корінна причина: Легітимний (або не зовсім легітимний) інструмент намагається отримати доступ до облікових даних у спосіб, який неможливо відрізнити від знімання.

Виправлення: Видаліть інструмент або отримайте версію від вендора, яка не потребує скрейпінгу LSASS. Розглядайте «потребує читання LSASS» як проєктний дефект, а не як вимогу.

5) «Ми увімкнули Credential Guard, але нападники все одно рухалися латерально.»

Симптом: Латеральний рух відбувся через SMB/RDP/WinRM.

Корінна причина: Credential Guard зменшує певні шляхи крадіжки облікових даних; воно не виправляє погану поведінку адміністраторів, надмірні привілеї, розповсюдження NTLM або фішинг облікових даних.

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

6) «Служба підтримки відключила його на кількох машинах, щоб виправити тікет — і забула.»

Симптом: Дрейф: деякі кінцеві точки більше не запускають VBS/Credential Guard.

Корінна причина: Відсутній цикл примусового виконання/звітності; винятки не відстежуються як операційний борг.

Виправлення: Централізовано моніторьте стан виконання (Завдання 1–2), застосовуйте політику і вимагайте обмежених у часі винятків з регулярним переглядом.

Цитата, яку варто тримати на стіні

Парафразована ідея — Вернер Фогельс: ви будуєте системи, припускаючи, що щось зазнає відмови, і робите їх стійкими за дизайном, а не сподіваючись на краще.

Чого уникати: «театральна» версія цього контролю

Credential Guard часто впроваджують так, що гарно виглядає на слайді, але мало дає на практиці:

Увімкнено лише на частині кінцевих точок без вимірювання фактичного «стану виконання».
Адміністратори все ще входять скрізь, тож привілейовані креденшіали все ще опиняються на ненадійних машинах.
NTLM залишається повсюдно, а винятки множаться непомітно.
Немає плану для застарілих додатків, тож команди відкочують налаштування при першому скарзі.

Не робіть так. Якщо ви берете на себе політичні та операційні навантаження через посилення аутентифікації, отримайте від цього реальну вигоду для безпеки.

Як Credential Guard змінює математику для нападника (практично)

У розслідуванні інцидентів ви постійно ставите питання: «Якщо в них був адмін на робочій станції, чи могли вони захопити домен?» Credential Guard робить це питання менш страшним, бо зменшує ймовірність, що одна скомпрометована кінцева точка стане джерелом облікових даних.

Але воно працює тільки як частина стратегії стримування ідентичності:

Зменшити присутність облікових даних: не входьте привілейованими обліками на ненадійні пристрої.
Зменшити повторне використання облікових даних: менше спільних локальних паролів, менше сервісних акаунтів з широкими правами.
Зменшити застарілу автентифікацію: звузьте NTLM, видаліть старі провайдери.
Зменшити екстракцію: Credential Guard + LSASS PPL + EDR/ASR + контроль драйверів.

Це погляд SRE на безпеку: контролюйте радіус ураження, усувайте одиночні точки катастрофічної відмови і вимірюйте контрзаходи як працюючі системи, а не наміри.

Поширені питання

1) Чи Credential Guard те саме, що «захист LSASS»?

Ні. Захист LSASS (RunAsPPL) ускладнює процесам читання LSASS. Credential Guard використовує VBS, щоб ізолювати секрети так, щоб вони не знаходились у пам’яті LSASS взагалі. Використовуйте обидва, де можливо.

2) Чи зупинить Credential Guard Mimikatz?

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

3) Чому кажуть «воно ламає речі»?

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

4) Чи потрібен Windows Enterprise?

Credential Guard зазвичай орієнтований на видання Enterprise/Education і керовані середовища. На практиці те, що ви зможете увімкнути, залежить від видання ОС, збірки та підходу до управління. Перевірте на вашому парку перед обіцянками.

5) Чи можна увімкнути його на серверах?

Так, у багатьох сценаріях, але розглядайте сервери як виробничу інфраструктуру: тестуйте сумісність драйверів, інструментів безпеки і робочих процесів віддаленого управління. Деякі сервери (особливо старі або спеціалізовані) можуть вимагати винятків з ізоляцією.

6) Якщо я використовую смарт-карти або Windows Hello for Business, чи все ще треба це?

Так. Сильніша користувацька автентифікація допомагає, але Credential Guard захищає похідні матеріали облікових даних і зменшує можливості їхнього відтворення на скомпрометованих кінцевих точках.

7) Як довести аудиторам, що воно дійсно увімкнено?

Не доводьте «політика встановлена». Доведіть «воно працює». Використовуйте сигнали WMI (Завдання 1–2), збирані централізовано, і звітуйте про дрейф. Аудитори люблять докази; нападники люблять дрейф.

8) Яка найпоширеніша причина, чому це не окупається?

Поведінка адміністраторів. Якщо привілейовані обліки все ще заходять на робочі станції користувачів, ви все одно можете втратити домен через альтернативні шляхи. Credential Guard зменшує один великий вектор; воно не виправдовує погану гігієну ідентичності.

9) Чи слід вимкнути NTLM після увімкнення Credential Guard?

Не проводьте це як «великий вибух». Спочатку виміряйте використання NTLM, потім обмежуйте його вибірково. Мета — скоротити NTLM там, де він не потрібен, і локалізувати його там, де уникнути неможливо.

10) Чи варто це робити, якщо у мене вже є EDR?

Так. EDR — це виявлення та реагування. Credential Guard — це зменшення експозиції. Потрібні обидва: менше секретів, доступних для крадіжки, і кращі шанси впіймати нападника, якщо щось піде не так.

Наступні кроки, які ви можете зробити цього тижня

Якщо ви хочете, щоб це стало реальністю — а не політичною презентацією PowerPoint — виконайте ці практичні кроки:

Виміряйте реальність: Запустіть Завдання 1–2 на репрезентативній вибірці. Порахуйтe «працює» проти «сконфігуровано» проти «вимкнено».
Знайдіть блокери: Для систем, що не працюють, зберіть стан апаратної віртуалізації (Завдання 3) та Secure Boot (Завдання 11). Визначте конфліктні драйвери та агенти вендорів.
Викоріньте очевидну спадщину: Переконайтеся, що WDigest вимкнено (Завдання 7) і увімкніть LSASS PPL там, де підтримується (Завдання 6).
Виправте шляхи адміністраторів: Припиніть входи привілейованих користувачів на випадкові десктопи. Побудуйте робочі станції для привілейованого доступу / jump host.
Розпочніть реєстр винятків: Кожний пристрій, що не може запускати Credential Guard, потрапляє в список з власником бізнесу, обґрунтуванням, компенсуючими контролями та датою перегляду.
Розгорніть у кільцях: Пілотуйте, вимірюйте типи тікетів, виправляйте, розширюйте. Не перетворюйте це на п’ятничний сюрприз.

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