У багатьох компаній склалася хибна впевненість: якщо для хмарних сервісів запроваджено багатофакторну автентифікацію (MFA), ризик викрадення облікових записів нібито різко падає. Для SaaS‑платформ це частково відповідає дійсності, але у світі Windows та Active Directory ситуація значно складніша. Зловмисники щодня успішно проникають у корпоративні мережі, використовуючи лише валідні логіни й паролі — без жодного другого фактора.
Чому багатофакторна автентифікація не закриває всі ризики у Windows
Сучасна інфраструктура більшості організацій — це гібрид хмари та локальної мережі. Хмарні постачальники ідентичності (IdP), такі як Microsoft Entra ID, Okta, Google Workspace, зазвичай добре захищають веб‑додатки та SSO‑портали за рахунок MFA та політик умовного доступу. Однак значна частина щоденних входів у доменну інфраструктуру Windows відбувається через класичні механізми Kerberos та NTLM, які напряму не взаємодіють з хмарним IdP.
Локальний вхід та автентифікація через контролери домену
Коли користувач входить на доменну робочу станцію або сервер, автентифікацію виконує on‑premises контролер домену Active Directory. Якщо не розгорнуто Windows Hello for Business, смарт‑картки або інші вбудовані схеми MFA, цей процес фактично зводиться до перевірки пароля чи його хеша. Жодні хмарні правила MFA тут не спрацьовують, оскільки запит на автентифікацію не виходить за межі домену.
У результаті, отримавши пароль користувача або NTLM‑хеш, зловмисник може легітимно автентифікуватися в домені й обійти всі хмарні механізми захисту, які чудово працюють лише для веб‑доступу.
RDP і VPN як ключові точки входу в корпоративну мережу
RDP (Remote Desktop Protocol) і VPN стабільно залишаються одними з найпопулярніших напрямків атак. Навіть якщо RDP не відкритий в Інтернет, до нього часто добираються вже після первинного зламу, використовуючи lateral movement усередині мережі. Стандартне RDP‑підключення до сервера покладається на доменні облікові дані й зазвичай не проходить через хмарний IdP, а отже — відбувається без MFA.
Щоб перекрити цю прогалину, застосовуються спеціалізовані рішення, які дозволяють нав’язати MFA саме на рівні входу в Windows, RDP та VPN і навіть захистити офлайн‑логін одноразовими кодами. У такій моделі викраденого пароля вже недостатньо для успішного доступу до системи.
Слабкі місця NTLM та Kerberos в Active Directory
NTLM та атаки типу pass-the-hash
Попри багаторічний курс Microsoft на відмову від NTLM, цей протокол досі широко використовується заради сумісності зі старими сервісами та додатками. Саме NTLM робить можливими атаки pass‑the‑hash, коли зловмиснику не потрібен пароль у відкритому вигляді — достатньо перехопити або витягнути NTLM‑хеш і «пред’явити» його системі як доказ автентичності.
У такому сценарії MFA фактично не бере участі: якщо служба приймає хеш як валідні облікові дані, другий фактор просто не запитується. Додатковий ризик полягає в тому, що NTLM часто захований у «надрах» внутрішніх сервісів та легасі‑додатків, про нього згадують лише під час аудиту або вже після інциденту.
Kerberos-білети та довготривалий несанкціонований доступ
Основний протокол автентифікації в Active Directory — це Kerberos. Тут фокус атак зміщується з паролів на Kerberos‑білети (service tickets, TGT). Отримавши доступ до пам’яті скомпрометованого хоста чи до високо привілейованого облікового запису, зловмисники можуть викрадати або підробляти ці білети (зокрема реалізовувати сценарії «golden» та «silver» ticket).
Такі атаки дозволяють надовго закріпитися в мережі та пересуватися між серверами без повторного введення паролів, що зменшує ймовірність детектування. Навіть зміна паролів не завжди допомагає, якщо початкову причину компрометації — наприклад, злам контролера домену — не усунуто.
Локальні адміністратори, SMB і сервісні облікові записи як «тихий» ризик
У багатьох організаціях досі масово використовуються локальні облікові записи адміністраторів для підтримки робочих станцій та аварійного доступу. Якщо один і той самий пароль локального адміністратора застосовується на десятках машин, компрометація одного хоста миттєво масштабується на всю мережу. Така автентифікація відбувається локально й повністю оминає MFA та політики умовного доступу в Entra ID.
Ще один постійний канал lateral movement — це SMB, який використовується для обміну файлами та віддаленого адміністрування. Маючи валідні облікові дані, атакувальники за допомогою адміністративних шар (C$, ADMIN$) та віддаленого виконання команд швидко просуваються мережею. На цьому рівні майже ніколи не застосовується MFA, адже трафік вважається «внутрішнім».
Окрему загрозу становлять сервісні облікові записи, які запускають служби, планувальники завдань та інтеграції між системами. Їхні паролі часто не змінюються роками, мають надлишкові привілеї та рідко потрапляють у фокус моніторингу. Впровадження MFA для таких облікових записів технічно складне, оскільки автентифікація відбувається автоматично, а багато легасі‑рішень не підтримують сучасні протоколи.
Практичні кроки захисту автентифікації у Windows-середі
Перший критичний крок — посилена політика паролів. Рекомендовано переходити на довгі парольні фрази (15+ символів), забороняти повторне використання старих паролів і блокувати типові шаблони. Важливо перевіряти нові паролі на збіг із уже злитими в публічні бази обліковими даними, які масово використовуються в атаках credential stuffing. Це можна робити за допомогою спеціалізованих рішень для керування парольними політиками та перевірки на «скомпрометованість».
Другий напрям — мінімізація NTLM. Потрібно провести інвентаризацію, де саме він застосовується, відключити там, де можливо, та посилити контроль у всіх залишкових сценаріях. Паралельно варто розглядати автентифікацію Windows як окрему поверхню атаки і впроваджувати MFA саме на рівні логону в ОС, RDP і VPN через профільні рішення.
Третій вектор — робота з привілейованими та сервісними обліковими записами. Необхідно вести їх повний облік, обмежувати надлишкові права, регулярно ротувати паролі, видаляти невикористовувані записи та посилено моніторити будь‑яку активність від їхнього імені. Галузеві звіти з кібербезпеки послідовно показують, що компрометація облікових даних — одна з провідних причин серйозних інцидентів, і саме такі «технічні» акаунти часто стають точкою опори для зловмисників.
Організації, які сприймають MFA не лише як «галочку» для хмарних сервісів, а системно зміцнюють автентифікацію в Windows та Active Directory — від політики паролів і контролю NTLM до MFA на рівні логону, RDP та VPN, — помітно знижують ризик успішних атак із використанням облікових даних. Варто розпочати з аудиту власної AD‑інфраструктури, виявити «сліпі зони» в автентифікації та протестувати спеціалізовані інструменти, які допомагають закрити ці прогалини на практиці.
