Відкликані паролі RDP Microsoft залишаються активними: тривала вразливість

Автор: Джейн Сміт – 15 червня 2025 року

ЦЕ ФУНКЦІЯ, А НЕ ПОМИЛКА

Протокол віддаленого робочого столу Windows (RDP) продовжує приймати відкликані паролі облікових записів Microsoft і Azure для віддалених входів, навіть після їх зміни користувачами. Незалежні дослідники та експерти з безпеки застерігають, що така поведінка є прихованим «заднім входом», що обходить перевірку в хмарі, багатофакторну автентифікацію та політики умовного доступу.

Як працює кешування паролів RDP

Основна причина полягає в кешуванні облікових даних на локальному комп’ютері. Коли користувач вперше входить через RDP з обліковим записом Microsoft або Azure AD, Windows виконує онлайн-верифікацію пароля. Після підтвердження система зберігає перевірник — криптографічно захищений обліковий запис — у сховищі секретів Локальної служби безпеки (LSA). При наступних входах введений пароль порівнюється з цим локальним кешем, без звернення до Azure AD або Entra ID.

• Перша онлайн-верифікація: RDP викликає Advapi32::LogonUserExExW для автентифікації через Azure AD.
• Зберігання кешу: секрети LSA містять NT-хеш та сіль, зашифровані за допомогою основного ключа DPAPI системи.
• Офлайн-верифікація: вхід через RDP перевіряє локально збережений NT-хеш за допомогою пакетів автентифікації MSV1_0.

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

Висновки дослідників і реакція Microsoft

8 квітня 2025 року дослідник Деніел Уейд подав детальний звіт до Центру реагування на безпеку Microsoft (MSRC), в якому продемонстрував:

• Старі паролі надають доступ до RDP з нових, раніше не використовуваних пристроїв.
• Відсутність сповіщень у Microsoft Defender, журналах входу Azure AD або політиках умовного доступу.
• Нові паролі іноді не працюють, тоді як старі продовжують бути дійсними.
• Відсутність інструментів для користувачів для анулювання кешованих облікових даних.

Microsoft класифікувала цю поведінку як «дизайнерське рішення», щоб забезпечити можливість входу хоча б з одного облікового запису, якщо машина тривалий час працює офлайн. Компанія оновила свою документацію 2 травня 2025 року, але не надала рекомендацій щодо пом’якшення ситуації, окрім зауваження про кешування.

Останнє попередження від органів кібербезпеки

1 червня 2025 року Агентство з кібербезпеки та захисту інфраструктури (CISA) випустило CSA 25-164, попереджаючи адміністраторів підприємств переглянути конфігурації кешування RDP. У попередженні рекомендується:

• Аудит сховищ секретів LSA на предмет застарілих облікових записів.
• Впровадження безперервної SSO Azure AD з Windows Hello для бізнесу для уникнення кешування паролів.
• Використання доступу Just-In-Time (JIT) в Azure Privileged Identity Management (PIM).

Технічний аналіз: механіка LSA та DPAPI

Windows використовує API захисту даних (DPAPI) для шифрування секретів LSA. Кожен секрет захищений загальним основним ключем машини, що зберігається в %SystemRoot%System32MicrosoftProtectMachineKeys. Коли пароль встановлюється або змінюється:

• Оновлення сховища LSA: Локальний вхід оновлює секрети LSA, якщо працює офлайн; вхід через RDP цього не робить.
• Ротація основного ключа: Windows змінює основні ключі DPAPI лише при повторному налаштуванні ОС машини або видаленні профілю користувача.
• Анулювання кешу: Немає вбудованого механізму, який пов’язує оновлення секретів з подіями зміни паролів Azure AD.

Ця прогалина означає, що будь-який пароль, який коли-небудь успішно використовувався через RDP, залишається дійсним, поки секрет LSA не буде вручну видалено або машина не буде повторно налаштована.

Стратегії пом’якшення та найкращі практики

Фахівці з безпеки рекомендують кілька заходів:

• Вимкнути CacheCredentials через групову політику (Конфігурація комп'ютераНалаштування WindowsНалаштування безпекиЛокальні політикиПараметри безпеки).
• Забезпечити NTLMMinClientSec та NTLMMinServerSec для вимоги підписування сесій та шифрування.
• Впровадити політики умовного доступу Azure AD, які блокують застарілу автентифікацію та вимагають MFA для всіх сесій RDP через проксі-застосунок Azure AD.
• Регулярно змінювати основні ключі DPAPI на рівні машини, повторно приєднуючи до домену або відновлюючи ОС хоста.
• Використовувати Windows Hello для бізнесу або ключі безпеки FIDO2 для усунення входів на основі паролів.

Вплив на галузь та перспективи

Тривалість дії відкликаних паролів у RDP ставить під сумнів основні припущення безпеки щодо обробки облікових даних. Оскільки підприємства прискорюють впровадження гібридної роботи, ігноровані локальні механізми кешування підривають захисти хмарної ідентичності. Microsoft не планує виправлення коду, посилаючись на зворотну сумісність із застарілими застосунками, такими як Citrix та сторонні VPN, які покладаються на локальну автентифікацію NTLM.

У майбутньому експерти галузі прогнозують:

• Розширення рамок Zero Trust для включення анулювання локального кешу.
• Зростання кількості альтернатив RDP від третіх сторін, що пропонують реальну перевірку в хмарі (наприклад, RustDesk, Parsec).
• Посилення вимог до аудиту в рамках стандартів відповідності (PCI DSS, HIPAA) для управління кешем облікових даних.

Висновок

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