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 створюється контролер домену тільки для читання (RODC). Обліковий запис комп'ютера RODC, названий AzureADKerberos$. Також створюється додатковий обліковий запис krbtgt з назвою krbtgt_AzureAD. Цей обліковий запис містить ключі Kerberos, які використовуються для квитків, які створює Azure AD.
Отже, якщо цей обліковий запис буде скомпрометований, можливо видача заступництва будь-якому користувачеві... хоча це не зовсім правда, оскільки цей обліковий запис не може створювати квитки для будь-якої звичайної привілейованої групи AD, таких як Адміністратори домену, Адміністратори підприємства, Адміністратори...
Однак у реальному сценарії будуть привілейовані користувачі, які не належать до цих груп. Таким чином, новий обліковий запис 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 хеш у відповіді.
Зловживанням хмарним довірянням Kerberos для отримання прав адміністратора домену
Коли AzureAD генерує частковий TGT, він буде використовувати деталі, які він знає про користувача. Таким чином, якщо Глобальний адміністратор може змінити дані, такі як ідентифікатор безпеки та ім'я користувача в AzureAD, при запиті TGT для цього користувача ідентифікатор безпеки буде іншим.
Це неможливо зробити через Microsoft Graph або Azure AD Graph, але можна використовувати API Active Directory Connect, яке використовується для створення та оновлення синхронізованих користувачів, що може бути використано Глобальними адміністраторами для зміни імені SAM та SID будь-якого гібридного користувача, і потім, якщо ми аутентифікуємося, ми отримаємо частковий TGT, що містить змінений SID.
Зауважте, що це можна зробити за допомогою AADInternals та оновлення синхронізованих користувачів через Set-AADIntAzureADObject cmdlet.
Передумови атаки
Успішне виконання атаки та отримання привілеїв адміністратора домену залежить від виконання певних передумов:
Ключовим є можливість змінювати облікові записи через API синхронізації. Це можливо завдяки ролі Глобального адміністратора або наявності облікового запису синхронізації AD Connect. Також підійде роль Адміністратора гібридного ідентифікатора, оскільки вона надає можливість керувати AD Connect та створювати нові облікові записи синхронізації.
Наявність гібридного облікового запису є обов'язковою. Цей обліковий запис повинен бути піддається змінам з даними облікового запису жертви та також повинен бути доступний для аутентифікації.
Необхідно ідентифікувати цільовий обліковий запис жертви в Active Directory. Хоча атаку можна виконати на будь-якому вже синхронізованому обліковому записі, тенант Azure AD не повинен мати реплікованих ідентифікаторів безпеки на місці, що вимагає модифікації несинхронізованого облікового запису для отримання квитка.
Крім того, цей обліковий запис повинен мати привілеї еквівалентні адміністратору домену, але не повинен бути членом типових груп адміністраторів AD, щоб уникнути створення недійсних TGT AzureAD RODC.
Найбільш підходящою цільовою метою є обліковий запис Active Directory, який використовується службою синхронізації AD Connect. Цей обліковий запис не синхронізується з Azure AD, залишаючи його SID як потенційну мету, і він має привілеї еквівалентні адміністратору домену через його роль у синхронізації хешів паролів (за умови активного синхронізації хешів паролів). Для доменів з експрес-встановленням цей обліковий запис починається з MSOL_. Для інших випадків обліковий запис можна визначити, перераховуючи всі облікові записи, які мають привілеї реплікації каталогу на об'єкт домену.
Повна атака
Перевірте це в оригінальному пості: https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/
Last updated