Az - Cloud Kerberos Trust
Цей пост є підсумком https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/, де можна знайти додаткову інформацію про атаку. Цю техніку також обговорено в https://www.youtube.com/watch?v=AFay_58QubY.
Основна інформація
Довіра
Коли встановлюється довіра з Azure AD, в AD створюється Read Only Domain Controller (RODC). Обліковий запис комп'ютера RODC називається AzureADKerberos$
. Також створюється додатковий обліковий запис krbtgt
з назвою krbtgt_AzureAD
. Цей обліковий запис містить ключі Kerberos, які використовуються для квитків, які створює Azure AD.
Отже, якщо цей обліковий запис буде скомпрометований, можливо підробити будь-якого користувача... хоча це не зовсім правда, оскільки цей обліковий запис не може створювати квитки для будь-якої звичайної привілейованої групи AD, таких як Domain Admins, Enterprise Admins, Administrators...
Однак у реальному сценарії будуть привілейовані користувачі, які не належать до цих груп. Тому новий обліковий запис krbtgt, якщо скомпрометований, може бути використаний для підробки їх.
Kerberos TGT
Крім того, коли користувач аутентифікується в Windows за допомогою гібридного ідентифікатора Azure AD, Azure AD видаватиме частковий квиток Kerberos разом з PRT. TGT є частковим, оскільки AzureAD має обмежену інформацію про користувача в AD на місці (наприклад, ідентифікатор безпеки (SID) та ім'я).
Після цього Windows може обміняти цей частковий TGT на повний TGT, запитуючи квиток для служби krbtgt
.
NTLM
Оскільки можуть існувати служби, які не підтримують аутентифікацію Kerberos, а лише NTLM, можливо запросити частковий TGT, підписаний за допомогою додаткового krbtgt
ключа, включаючи поле KERB-KEY-LIST-REQ
в частині PADATA запиту, а потім отримати повний TGT, підписаний основним ключем krbtgt
, включаючи NT hash у відповіді.
Зловживанням Cloud Kerberos Trust для отримання Domain Admin
Коли AzureAD генерує частковий TGT, він використовуватиме дані, які має про користувача. Тому, якщо Глобальний адміністратор може змінювати дані, такі як ідентифікатор безпеки та ім'я користувача в AzureAD, при запиті TGT для цього користувача ідентифікатор безпеки буде іншим.
Це неможливо зробити через Microsoft Graph або Azure AD Graph, але можна використовувати API Active Directory Connect, яке використовується для створення та оновлення синхронізованих користувачів, що може бути використано Глобальними адміністраторами для зміни імені SAM та SID будь-якого гібридного користувача, і потім, якщо ми аутентифікуємося, ми отримаємо частковий TGT, що містить змінений SID.
Зауважте, що це можливо зробити за допомогою AADInternals та оновлення синхронізованих користувачів через Set-AADIntAzureADObject cmdlet.
Вимоги до атаки
Успішне виконання атаки та отримання привілеїв Domain Admin залежать від виконання певних передумов:
Ключовим є можливість змінювати облікові записи через API синхронізації. Це можливо завдяки ролі Глобального адміністратора або наявності облікового запису синхронізації AD Connect. Також підійде роль Адміністратора гібридного ідентифікатора, оскільки вона надає можливість керувати AD Connect та створювати нові облікові записи синхронізації.
Наявність гібридного облікового запису є обов'язковою. Цей обліковий запис повинен бути піддається змінам з даними облікового запису жертви та також повинен бути доступний для аутентифікації.
Необхідно визначити цільовий обліковий запис жертви в Active Directory. Хоча атаку можна виконати на будь-якому вже синхронізованому обліковому запису, тенант Azure AD не повинен мати реплікованих ідентифікаторів безпеки на місці, що вимагає модифікації несинхронізованого облікового запису для отримання квитка.
Крім того, цей обліковий запис повинен мати привілеї еквівалентні Domain Admin, але не повинен бути членом типових груп адміністраторів AD, щоб уникнути створення недійсних TGT AzureAD RODC.
Найбільш підходящою цільовою метою є обліковий запис Active Directory, який використовується службою синхронізації AD Connect. Цей обліковий запис не синхронізується з Azure AD, залишаючи його SID як потенційну мету, і він має привілеї еквівалентні Domain Admin завдяки своїй ролі в синхронізації хешів паролів (за умови, що активовано синхронізацію хешів паролів). Для доменів з експрес-встановленням цей обліковий запис починається з MSOL_. Для інших випадків обліковий запис можна визначити, перераховуючи всі облікові записи, які мають привілеї реплікації каталогу на об'єкт домену.
Повна атака
Перевірте це в оригінальному пості: https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/
Last updated