Az - Cloud Kerberos Trust

Reading time: 7 minutes

Ця публікація є підсумком https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/ яка може бути перевірена для отримання додаткової інформації про атаку. Цю техніку також коментують у https://www.youtube.com/watch?v=AFay_58QubY.

Огляд відносин довіри Kerberos

Cloud Kerberos Trust (Entra ID -> AD) -- Ця функція (частина Windows Hello for Business) встановлює односторонню довіру, де on-prem AD довіряє Entra ID для видачі квитків Kerberos для AD. Увімкнення цієї функції створює об'єкт комп'ютера AzureADKerberos$ в AD (який з'являється як контролер домену тільки для читання) та пов'язаний обліковий запис krbtgt_AzureAD (додатковий KRBTGT). Entra ID зберігає ключі для цих облікових записів і може видавати "часткові" TGT Kerberos для користувачів AD. Контролери домену AD визнають ці квитки, але з обмеженнями, подібними до RODC: за замовчуванням групи з високими привілеями (Domain Admins, Enterprise Admins тощо) заборонені, а звичайним користувачам дозволено. Це запобігає Entra ID від автентифікації доменних адміністраторів через довіру за звичайних умов. Однак, як ми побачимо, зловмисник з достатніми привілеями Entra ID може зловживати цим дизайном довіри.

Переходження з Entra ID до On-Prem AD

Сценарій: Цільова організація має Cloud Kerberos Trust увімкненим для безпарольної автентифікації. Зловмисник отримав Global Administrator привілеї в Entra ID (Azure AD), але ще не контролює on-prem AD. Зловмисник також має доступ до мережі контролера домену (через VPN або Azure VM в гібридній мережі). Використовуючи довіру в хмарі, зловмисник може скористатися контролем Azure AD, щоб отримати Domain Admin-рівень доступу в AD.

Передумови:

• Cloud Kerberos Trust налаштовано в гібридному середовищі (індикатор: обліковий запис AzureADKerberos$ RODC існує в AD).

• Зловмисник має права Global Admin (або Hybrid Identity Admin) в орендарі Entra ID (ці ролі можуть використовувати API синхронізації AD Connect для зміни користувачів Azure AD).

• Принаймні один гібридний обліковий запис користувача (існує в AD та AAD), під яким зловмисник може автентифікуватися. Це може бути отримано, знаючи або скидаючи його облікові дані або призначаючи безпарольний метод (наприклад, Тимчасовий доступний пропуск) для генерації первинного токена оновлення (PRT) для нього.

• Обліковий запис цільового on-prem AD з високими привілеями, який не входить до стандартної політики "заборони" RODC. На практиці, чудовою метою є обліковий запис синхронізації AD Connect (часто називається MSOL_*), який має права DCSync (реплікації) в AD, але зазвичай не є членом вбудованих адміністративних груп. Цей обліковий запис зазвичай не синхронізується з Entra ID, що робить його SID доступним для підробки без конфлікту.

Кроки атаки:

1. Отримати доступ до API синхронізації Azure AD: Використовуючи обліковий запис Global Admin, отримайте токен доступу для Provisioning (sync) API Azure AD. Це можна зробити за допомогою інструментів, таких як ROADtools або AADInternals. Наприклад, з ROADtools (roadtx):

# Using roadtx to get an Azure AD Graph token (no MFA)
roadtx gettokens -u <GlobalAdminUPN> -p <Password> --resource aadgraph

(Альтернативно, можна використовувати Connect-AADInt від AADInternals для автентифікації як Global Admin.)

2. Змінити атрибути гібридного користувача на локальному рівні: Використовуйте Azure AD API синхронізації для встановлення вибраного гібридного користувача onPremises Security Identifier (SID) та onPremises SAMAccountName так, щоб вони відповідали цільовому обліковому запису AD. Це ефективно повідомляє Azure AD, що хмарний користувач відповідає локальному обліковому запису, який ми хочемо видати за себе. Використовуючи відкритий набір інструментів ROADtools Hybrid:

# Example: modify a hybrid user to impersonate the MSOL account
python3 modifyuser.py -u <GlobalAdminUPN> -p <Password>\
--sourceanchor <ImmutableID_of_User>\
--sid <TargetAD_SID> --sam <TargetAD_SAMName>

sourceAnchor (незмінний ID) користувача потрібен для ідентифікації об'єкта Azure AD, який потрібно змінити. Інструмент встановлює SID та ім'я облікового запису SAM гібридного користувача на значення цільового (наприклад, SID та SAM облікового запису MSOL_xxxx). Azure AD зазвичай не дозволяє змінювати ці атрибути через Graph (вони є тільки для читання), але API служби синхронізації це дозволяє, і Глобальні адміністратори можуть викликати цю функціональність синхронізації.

3. Отримати частковий TGT з Azure AD: Після зміни, автентифікуйтеся як гібридний користувач в Azure AD (наприклад, отримавши PRT на пристрої або використовуючи їхні облікові дані). Коли користувач входить в систему (особливо на пристрої, приєднаному до домену або Entra), Azure AD видасть частковий Kerberos TGT (TGT_AD) для цього облікового запису, оскільки активовано Cloud Kerberos Trust. Цей частковий TGT зашифрований за допомогою ключа AzureADKerberos$ RODC і включає цільовий SID, який ми встановили. Ми можемо змоделювати це, запитавши PRT для користувача через ROADtools:

roadtx getprt -u <HybridUserUPN> -p <Password> -d <DeviceID_or_Cert>

Це виводить файл .prt, що містить частковий TGT та ключ сесії. Якщо обліковий запис був лише хмарним паролем, Azure AD все ще включає TGT_AD у відповіді PRT.

4. Обмін часткового TGT на повний TGT (на AD): Частковий TGT тепер можна представити локальному контролеру домену, щоб отримати повний TGT для цільового облікового запису. Ми робимо це, виконуючи запит TGS для служби krbtgt (основна служба TGT домену) -- по суті, оновлюючи квиток до нормального TGT з повним PAC. Інструменти доступні для автоматизації цього обміну. Наприклад, використовуючи скрипт ROADtools Hybrid:

# Use the partial TGT from the PRT file to get a full TGT and NTLM hash
python3 partialtofulltgt.py -p roadtx.prt -o full_tgt.ccache --extract-hash

Цей скрипт (або еквіваленти Impacket) зв'яжеться з Контролером Домену та отримає дійсний TGT для цільового облікового запису AD, включаючи NTLM хеш облікового запису, якщо використовується спеціальне розширення Kerberos. Розширення KERB-KEY-LIST-REQ автоматично включається, щоб попросити DC повернути NTLM хеш цільового облікового запису в зашифрованій відповіді. Результатом є кеш облікових даних (full_tgt.ccache) для цільового облікового запису або відновлений NTLM хеш пароля.

5. Вдавання за ціль та підвищення до адміністратора домену: Тепер атакуючий ефективно контролює цільовий обліковий запис AD. Наприклад, якщо ціллю був обліковий запис AD Connect MSOL, він має права на реплікацію в каталозі. Атакуючий може виконати атаку DCSync, використовуючи облікові дані цього облікового запису або Kerberos TGT, щоб скинути хеші паролів з AD (включаючи обліковий запис домену KRBTGT). Наприклад:

# Using impacket's secretsdump to DCSync as the MSOL account (using NTLM hash)
secretsdump.py 'AD_DOMAIN/<TargetSAM>$@<DC_IP>' -hashes :<NTLM_hash> LOCAL

Це вивантажує всі хеші паролів користувачів AD, надаючи зловмиснику хеш KRBTGT (дозволяючи йому підробляти квитки Kerberos домену на свій розсуд) і фактично привілеї адміністратора домену над AD. Якщо цільовий обліковий запис був би іншим привілейованим користувачем, зловмисник міг би використовувати повний TGT для доступу до будь-якого доменного ресурсу як цей користувач.

6. Очищення: За бажанням, зловмисник може відновити оригінальний onPremisesSAMAccountName та SID модифікованого користувача Azure AD через той же API або просто видалити будь-якого тимчасового користувача, створеного раніше. У багатьох випадках наступний цикл синхронізації Azure AD Connect автоматично скасує несанкціоновані зміни в синхронізованих атрибутах. (Однак на цьому етапі шкода вже завдана -- зловмисник має привілеї DA.)

Посилання

• Отримання адміністратора домену з Azure AD через хмарну довіру Kerberos