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, створюється контролер домену тільки для читання (RODC) в AD. Обліковий запис комп'ютера RODC, названий AzureADKerberos$. Також, вторинний обліковий запис krbtgt, названий krbtgt_AzureAD. Цей обліковий запис містить ключі Kerberos, які використовуються для квитків, що створює Azure AD.
Отже, якщо цей обліковий запис буде скомпрометовано, може бути можливим видавати себе за будь-якого користувача... хоча це не зовсім вірно, оскільки цьому обліковому запису заборонено створювати квитки для будь-якої загальної привілейованої групи AD, такої як Domain Admins, Enterprise Admins, Administrators...
Однак у реальному сценарії будуть привілейовані користувачі, які не входять до цих груп. Тому новий обліковий запис krbtgt, якщо буде скомпрометовано, може бути використаний для видавання себе за них.
Kerberos TGT
Більше того, коли користувач аутентифікується в Windows, використовуючи гібридну ідентичність, 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 хеш у відповіді.
Зловживання довірою Cloud Kerberos для отримання прав Domain Admin
Коли AzureAD генерує частковий TGT, він використовує деталі, які має про користувача. Отже, якщо Глобальний адміністратор може змінити дані, такі як ідентифікатор безпеки та ім'я користувача в AzureAD, при запиті TGT для цього користувача ідентифікатор безпеки буде іншим.
Це неможливо зробити через Microsoft Graph або Azure AD Graph, але можливо використовувати API, який використовує Active Directory Connect для створення та оновлення синхронізованих користувачів, що може бути використано Глобальними адміністраторами для зміни імені SAM та SID будь-якого гібридного користувача, а потім, якщо ми аутентифікуємося, ми отримуємо частковий TGT, що містить змінений SID.
Зверніть увагу, що ми можемо зробити це з AADInternals і оновити синхронізованих користувачів за допомогою команди Set-AADIntAzureADObject.
Передумови атаки
Успіх атаки та отримання привілеїв Domain Admin залежать від виконання певних передумов:
Можливість змінювати облікові записи через Synchronization 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
