Az - Exchange Hybrid Impersonation (ACS Actor Tokens)

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks

Podstawowe informacje

W starszych projektach Exchange Hybrid wdrożenie Exchange on-prem mogło uwierzytelniać się jako ta sama tożsamość aplikacji Entra używana przez Exchange Online. Jeśli atakujący przejął serwer Exchange, wyodrębnił prywatny klucz certyfikatu hybrydowego i przeprowadził OAuth client-credentials flow, mógł uzyskać first-party tokens z kontekstem uprawnień Exchange Online.

Praktyczne ryzyko nie ograniczało się do dostępu do skrzynek pocztowych. Ponieważ Exchange Online miał szerokie relacje zaufania na zapleczu, ta tożsamość mogła wchodzić w interakcje z dodatkowymi usługami Microsoft 365 i, w starszym zachowaniu, mogła być wykorzystana do głębszego przejęcia dzierżawy (tenant).

Ścieżki ataku i przebieg techniczny

Modyfikacja konfiguracji federacji przez Exchange

Tokeny Exchange historycznie miały uprawnienia do zapisu ustawień domeny/federacji. Z perspektywy atakującego umożliwiało to bezpośrednią manipulację danymi zaufania domen federowanych, w tym listami certyfikatów podpisujących tokeny oraz flagami konfiguracyjnymi kontrolującymi akceptację roszczeń MFA pochodzących z on-prem infrastruktury federacyjnej.

To oznacza, że przejęty serwer Exchange Hybrid mógł być użyty do przygotowania lub wzmocnienia podszywania się w stylu ADFS poprzez zmianę konfiguracji federacji po stronie chmury, nawet jeśli atakujący rozpoczął jedynie od przejęcia Exchange on-prem.

ACS Actor Tokens i podszywanie się usługa-do-usługi

Ścieżka uwierzytelniania hybrydowego Exchange wykorzystywała Access Control Service (ACS) actor tokens z trustedfordelegation=true. Te actor tokens były następnie osadzane w drugim, niepodpisanym tokenie usługi, który niósł tożsamość docelowego użytkownika w części kontrolowanej przez atakującego. Ponieważ zewnętrzny token był niepodpisany, a actor token delegował szeroko, wywołujący mógł zamieniać docelowych użytkowników bez ponownego uwierzytelniania.

W praktyce, po uzyskaniu actor tokena, atakujący dysponował długożyjącym prymitywem do podszywania się (zwykle około 24 godzin), który było trudno unieważnić w trakcie jego życia. To umożliwiało podszywanie się za użytkowników w ramach Exchange Online oraz interfejsów API SharePoint/OneDrive, włącznie z eksfiltracją danych o wysokiej wartości.

Historycznie ten sam wzorzec działał również przeciwko graph.windows.net poprzez zbudowanie tokena podszywającego się z wartością netId ofiary. To zapewniało bezpośrednie działania administracyjne w Entra jako dowolni użytkownicy i umożliwiało pełne przejęcie dzierżawy (na przykład utworzenie nowego konta Global Administrator).

Co już nie działa

Ścieżka podszywania się graph.windows.net poprzez Exchange Hybrid actor tokens została naprawiona. Stary łańcuch „Exchange do dowolnego administratora Entra przez Graph” należy uznać za usunięty dla tej konkretnej trasy tokenów.

To najważniejsza korekta przy dokumentowaniu ataku: trzymaj ryzyko podszywania się w Exchange/SharePoint oddzielnie od obecnie załatanej eskalacji podszywania się przez Graph.

Co nadal może mieć znaczenie w praktyce

Jeśli organizacja nadal korzysta ze starej lub niepełnej konfiguracji hybrydowej z współdzielonym zaufaniem i ujawnionymi materiałami certyfikatu, wpływ podszywania się w Exchange/SharePoint może pozostać poważny. Kwestia nadużycia konfiguracji federacji może również pozostawać istotna w zależności od konfiguracji dzierżawy (tenant) i stanu migracji.

Długoterminowym środkiem zaradczym Microsoftu jest rozdzielenie tożsamości on-prem i Exchange Online, tak aby ścieżka zaufania shared-service-principal już nie istniała. Środowiska, które zakończyły tę migrację, znacząco zmniejszają tę powierzchnię ataku.

Notatki dotyczące wykrywania

Gdy technika ta jest nadużywana, zdarzenia audytu mogą pokazywać niespójności tożsamości, gdzie user principal name odpowiada podszywanemu użytkownikowi, podczas gdy kontekst wyświetlania/źródła wskazuje na aktywność Exchange Online. Ten mieszany wzorzec tożsamości jest cennym sygnałem do polowania, chociaż obrońcy powinni wyznaczyć bazowy profil legalnych przepływów pracy administratorów Exchange, aby zmniejszyć liczbę fałszywych alarmów.

Referencje

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks