Hybridkonten (d. h. aus Active Directory synchronisierte Konten) mit privilegierten Rollen in Entra ID stellen ein Sicherheitsrisiko dar, weil sie es Angreifern, die AD kompromittieren, ermöglichen, auch Entra ID anzugreifen. Privilegierte Konten in Entra ID müssen reine Cloudkonten sein.

Wenn Ihre Organisation die <a href="https://learn.microsoft.com/en-us/entra/identity/hybrid/what-is-inter-directory-provisioning">Verzeichnissynchronisierung</a> eingerichtet hat, beispielsweise mit „<a href="https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-azure-ad-connect">Microsoft Entra Connect</a>“ (vormals „Azure AD Connect“) oder „<a href="https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync">Microsoft Entra Cloud Sync</a>“ (vormals „Azure AD Connect Cloud Sync“), um Benutzer und andere Elemente aus Active Directory (On-Premises) in Entra ID (in der Cloud) zu synchronisieren, geraten Sie möglicherweise in Versuchung, Hybrid-AD-Konten für privilegierte Rollen in Entra ID zu verwenden. Dies bietet Angreifern jedoch die Möglichkeit, ihre böswillige Kontrolle auf Entra ID auszuweiten, nachdem sie Active Directory kompromittiert haben. Angreifer verfügen über verschiedene Techniken, um die Identität eines beliebigen AD-Benutzers anzunehmen, und wenden diesen Identitätswechsel auch auf Entra ID an.
Aus diesem Grund warnt Microsoft in seinem Artikel „<a href="https://learn.microsoft.com/en-us/entra/architecture/protect-m365-from-on-premises-attacks">Schützen von Microsoft 365 vor lokalen Angriffen</a>“ vor dieser Praxis und gibt zu bedenken, dass „es kein On-Premises-Konto mit Administratorrechten in Microsoft 365 geben sollte“, und empfiehlt sicherzustellen, dass „kein On-Premises-Konto über erhöhte Rechte für Microsoft 365 verfügt“.

Modify Authentication Process: Hybrid Identity

[MITRE ATT&CK®] T1556.007 (Modify Authentication Process: Hybrid Identity)

Privilegiertes Entra-Konto mit AD synchronisiert (Hybrid)

Protecting Microsoft 365 from on-premises attacks

Erstanbieter-Dienstprinzipale haben starke Berechtigungen, die übersehen werden, da sie verborgen, im Besitz von Microsoft und zahlreich sind. Angreifer fügen ihnen Anmeldeinformationen hinzu, um ihre Berechtigungen unbemerkt für Rechteausweitung und Persistenz zu nutzen.

Erstanbieter-Dienstprinzipale (Unternehmensanwendungen) stammen aus Anwendungen (Anwendungsregistrierungen), die Microsoft gehören. Die meisten haben sensible Berechtigungen in Microsoft Entra ID, die Sie bei Sicherheitsprüfungen oft übersehen. Dadurch können Angreifer ihnen Anmeldeinformationen hinzufügen, um unbemerkt von ihren Berechtigungen zu profitieren.
Dieses Verfahren bietet sowohl Persistenzfunktionen als auch Rechteausweitung, da Prinzipale mit der Anwendungsadministrator-Rolle Anwendungen Anmeldeinformationen hinzufügen können, einschließlich solcher, die über höhere Berechtigungen verfügen.
Erstanbieter-Dienstprinzipale sollten keine Anmeldeinformationen haben, außer in seltenen Fällen (siehe Empfehlungen).
Die APT29-Bedrohungsgruppe hat diese Methode im berüchtigten Angriff von SolarWinds namens Solorigate im Dezember 2020 missbraucht, wie <a href="https://www.microsoft.com/en-us/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/">von Microsoft</a> und <a href="https://www.mandiant.com/sites/default/files/2021-11/wp-m-unc2452-000343.pdf#page=29">von Mandiant</a> dokumentiert.

Azure AD privilege escalation - Taking over default application permissions as Application Admin

Account Manipulation: Additional Cloud Credentials

[MITRE ATT&CK®] T1098.001 (Account Manipulation: Additional Cloud Credentials)

Erstanbieter-Dienstprinzipal mit Anmeldeinformationen

In Microsoft Entra ID ist die Delegierung der Authentifizierung an einen anderen Anbieter über einen Verbund möglich. Angreifer, die erhöhte Rechte erlangt haben, können diese Funktion jedoch missbrauchen, indem sie ihre bösartige Verbunddomäne hinzufügen und so Persistenz und Rechteausweitung ermöglichen.

Ein Microsoft Entra-Mandant kann <a href="https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed">einen Verbund mit einer externen Domäne einrichten</a>, um zu Authentifizierungs- und Autorisierungszwecken eine Vertrauensbeziehung zu einer anderen Domäne herzustellen. IT-Abteilungen nutzen die Verbundfunktion, um die Authentifizierung für Active Directory-Benutzer an ihre On-Premises-Active Directory Federation Services (AD FS) zu delegieren. (Hinweis: Die externe Domäne ist keine Active Directory-„Domäne“.)
Wenn sich jedoch böswillige Akteure erhöhte Rechte in Microsoft Entra ID verschaffen, können sie diesen Verbundmechanismus missbrauchen, um eine Backdoor zu erstellen. Hierzu fügen sie ihre eigene Verbunddomäne hinzu oder bearbeiten eine vorhandene Verbunddomäne, um eine zweite Konfiguration mit ihren eigenen Einstellungen hinzufügen. Dieser Angriff ermöglicht außerdem die Durchführung folgender Aktionen:
<ul>
<li>Identitätswechsel: Die bösartige Verbunddomäne kann Token generieren, um es Angreifern zu erlauben, sich als beliebiger Microsoft Entra-Benutzer zu authentifizieren, ohne dessen Passwort zu kennen oder zurückzusetzen. Dies schließt auch „Nur-Cloud“-Benutzer (nicht hybrid) und externe Benutzer ein. Dadurch werden Angriffe auf Microsoft Entra ID, Microsoft 365 (O365) und andere Anwendungen möglich, die Microsoft Entra ID als Identitätsanbieter nutzen (SSO), selbst wenn Sie MFA erzwingen (siehe unten).</li>
<li>Rechteausweitung: Der Angreifer kann sich durch Identitätswechsel als ein beliebiger Benutzer ausgeben, insbesondere privilegierte Microsoft Entra-Benutzer.</li>
<li>Umgehung der Multifaktor-Authentifizierung: Bei der Verbundauthentifizierung übernimmt die vertrauenswürdige externe Domäne <a href="https://learn.microsoft.com/en-us/graph/api/resources/internaldomainfederation?view=graph-rest-beta#federatedidpmfabehavior-values">die Aufgabe, MFA durchzusetzen</a>. Die bösartige Verbunddomäne kann dann fälschlicherweise behaupten, dass die gespoofte Authentifizierung MFA verwendet hat. Microsoft Entra ID vertraut dieser Behauptung und fordert keine weitere MFA mehr an. So kann ein Angreifer die Identität aller Benutzer annehmen, selbst wenn MFA-Schutz vorhanden ist.</li>
<li>Persistenz: Das Hinzufügen einer bösartigen Verbunddomäne ist eine Tarntechnik, mit der Angreifer, die den Microsoft Entra-Mandanten kompromittiert und sich hohe Berechtigungen angeeignet haben, später wieder Zugriff erhalten können.</li>
</ul>
Dieser Indicator of Exposure erkennt Verbunddomänen-Backdoors, die vom Hacking-Toolkit <a href="https://aadinternals.com/">AADInternals</a> generiert werden, insbesondere die Cmdlets <code>ConvertTo-AADIntBackdoor</code> und <code>New-AADIntBackdoor</code>. Zur Erkennung werden bestimmte Merkmale der erstellten oder konvertierten Backdoor-Domäne herangezogen.
Weitere Informationen finden Sie auch unter dem verwandten Indicator of Exposure „Federation Signing Certificates Mismatch“ (Fehlende Übereinstimmung der Verbundsignaturzertifikate).
Das Verbundprotokoll, dass den Authentifizierungsnachweis von der bösartigen Verbunddomäne an das angegriffene Microsoft Entra ID überträgt, kann entweder WS-Federation oder SAML sein. Bei der Verwendung von SAML ähnelt der Angriff einem „<a href="https://www.mandiant.com/sites/default/files/2021-11/wp-m-unc2452-000343.pdf#page=9">Golden SAML</a>“-Angriff, mit diesen wesentlichen Unterschieden:
<ul>
<li>Anstatt den legitimen SAML-Signaturschlüssel eines vorhandenen Verbunds zu stehlen, schleusen die Angreifer die neue Domäne mit ihrem eigenen Schlüssel ein. </li>
<li>Angreifer präsentieren das gefälschte Token dem Verbunddienst, anstatt einem bestimmten Dienst.</li>
</ul>
Die Berechtigungen <code>microsoft.directory/domains/allProperties/allTasks</code> und <code>microsoft.directory/domains/federation/update</code> gewähren Administratoren die Möglichkeit, die Verbunddomänen zu ändern. Seit November 2023 verfügen die folgenden integrierten Microsoft Entra-Rollen zusätzlich zu potenziellen benutzerdefinierten Rollen über diese Berechtigung:
<ul>
<li>„<a href="https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#domain-name-administrator">Domänennamenadministrator</a>“</li>
<li>„<a href="https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#external-identity-provider-administrator">Externer Identitätsanbieteradministrator</a>“</li>
<li>„<a href="https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#hybrid-identity-administrator">Hybrididentitätsadministrator</a>“</li>
<li>„<a href="https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#global-administrator">Globaler Administrator</a>“</li>
<li>„<a href="https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#partner-tier2-support">Partnersupport der Ebene 2</a>“</li>
<li>„<a href="https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#security-administrator">Sicherheitsadministrator</a>“</li>
</ul>
Die APT29-Bedrohungsgruppe hat diese Methode im berüchtigten Angriff auf SolarWinds namens „Solorigate“ im Dezember 2020 missbraucht, wie <a href="https://www.microsoft.com/en-us/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/">von Microsoft</a> und <a href="https://www.mandiant.com/sites/default/files/2021-11/wp-m-unc2452-000343.pdf#page=23">von Mandiant</a> dokumentiert.

Modify Trusted Domains [Mandiant]

Security vulnerability in Azure AD & Office 365 identity federation

How to create a backdoor to Azure AD - part 1: Identity federation

Deep-dive to Azure Active Directory Identity Federation

Domain Policy Modification: Domain Trust Modification

Forge Web Credentials: SAML Tokens

[MITRE ATT&CK®] T1484.002 (Domain Policy Modification: Domain Trust Modification)

[MITRE ATT&CK®] T1606.002 (Forge Web Credentials: SAML Tokens)

Bekannte Verbunddomänen-Backdoor

Microsoft macht APIs in Microsoft Entra ID verfügbar, um Drittanbieter-Anwendungen die Ausführung von Aktionen für Microsoft-Dienste zu erlauben. Bestimmte Berechtigungen können eine ernste Gefahr für den gesamten Microsoft Entra-Mandanten darstellen. Daher muss die Zuweisung dieser Berechtigungen sorgfältig geprüft werden.

Microsoft macht APIs über Anwendungen in Microsoft Entra ID verfügbar, um Drittanbieter-Anwendungen die Ausführung von Aktionen für Microsoft Entra ID selbst, Microsoft 365 (O365), die Azure-Cloud usw. zu erlauben. „API-Berechtigungen“ schützen den Zugriff auf diese APIs, und nur Dienstprinzipale, die die APIs benötigen, können über diese Berechtigungen verfügen. Die Genehmigung der Berechtigungen wird als „Anwendungsrollenzuweisung“ oder „Einwilligungserteilung“ („consent grant“) bezeichnet.
Bestimmte Berechtigungen für einige Microsoft-APIs (siehe unten) können eine ernste Bedrohung für den gesamten Microsoft Entra-Mandanten darstellen, weil ein Dienstprinzipal mit diesen Berechtigungen über sehr viel Macht verfügt, zugleich jedoch diskreter ist als ein Benutzer mit einer umfassenden Administratorrolle wie z. B. „Globaler Administrator“. Ein Missbrauch dieser Situation kann es einem Angreifer ermöglichen, die Multifaktor-Authentifizierung (MFA) zu umgehen sich dem Zurücksetzen von Benutzerpasswörtern zu widersetzen.
Wenn die Berechtigungen legitim sind, vergrößern sie die Angriffsoberfläche für den Mandanten. Wenn sie nicht legitim sind, kann es sich um einen böswilligen Versuch handeln, Rechte oder die Persistenzmethode auszuweiten. 
Es gibt zwei Arten von API-Berechtigungen in Microsoft Entra ID, wie in der Microsoft-Dokumentation <a href="https://learn.microsoft.com/en-us/entra/identity-platform/permissions-consent-overview">Einführung in Berechtigungen und Einwilligung</a> beschrieben:
<ul>
<li>Anwendungsberechtigungen: Die Einwilligung wird von Administratoren gegeben, und die Berechtigungen gelten mandantenweit.</li>
<li>Delegierte Berechtigungen: Die Einwilligung wird von Benutzern oder Administratoren im Namen der gesamten Organisation gegeben. Beachten Sie, dass diese Berechtigungen die Fähigkeit der Anwendung einschränken, Aktionen auf Basis der Rechte des angemeldeten Benutzers durchzuführen (d. h. Schnittpunkt der Berechtigung und der Rechteebene des Benutzers). Wie gefährlich diese delegierten Berechtigungen sind, hängt daher von den tatsächlichen Berechtigungen des Anwendungsbenutzers ab, wie im Artikel <a href="https://learn.microsoft.com/en-us/security/zero-trust/develop/developer-strategy-delegated-permission">Entwickeln einer Strategie für delegierte Berechtigungen</a> beschrieben. Beispiel: Wenn ein normaler Benutzer die Berechtigung „Group.ReadWrite.All“ delegiert, erlaubt er damit der Anwendung, nur die Gruppen zu ändern, die der Benutzer bearbeiten kann, und nicht alle Gruppen.</li>
</ul>
Dieser Indicator of Exposure untersucht beide Arten von Berechtigungen. Er gibt nur Auskunft über Dienstprinzipale, da API-Berechtigungen nur für Dienstprinzipale gelten können, nicht jedoch für Benutzer.
Dieser Indicator of Exposure konzentriert sich außerdem auf Berechtigungen, die Zugriff auf die <a href="https://learn.microsoft.com/en-us/graph/overview">Microsoft Graph API</a> und die ältere <a href="https://learn.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview">Azure AD Graph API</a> erlauben. Insbesondere die folgenden gefährlichen Berechtigungen können ein Sicherheitsrisiko darstellen:
<ul>
<li><code>RoleManagement.ReadWrite.Directory</code>: Erlaubt es Angreifern, sich selbst auf die Rolle „Globaler Administrator“ hochzustufen.</li>
<li><code>AppRoleAssignment.ReadWrite.All</code>: Erlaubt es Angreifern, sich selbst die Berechtigung <code>RoleManagement.ReadWrite.Directory</code> zu erteilen (siehe oben).</li>
</ul>
Legitime Anwendungen mit diesen gefährlichen Berechtigungen fordern Berechtigungen an, die zu umfassend sein können. Dies kann auch ein Hinweis auf einen als „illegale Einwilligungserteilung“ bezeichneten Phishing-Angriff sein, bei dem Angreifer erfolgreich die Einwilligung eines Administrators einholen.

Phishing

Steal Application Access Token

Use Alternate Authentication Material: Application Access Token

[MITRE ATT&CK®] T1566 (Phishing)

[MITRE ATT&CK®] T1528 (Steal Application Access Token)

[MITRE ATT&CK®] T1550.001 (Use Alternate Authentication Material: Application Access Token)

Gefährliche API-Berechtigungen, die den Mandanten betreffen

MFA bietet starken Schutz von Konten vor schwachen oder gehackten Passwörtern. Best Practices und Standards für Sicherheit empfehlen die Aktivierung von MFA, selbst für nicht-privilegierte Konten. Konten ohne registrierte MFA-Methode können nicht von ihr profitieren.

Multifaktor-Authentifizierung (MFA) oder vorher Zweifaktor-Authentifizierung (2FA) bietet starken Schutz von Konten vor schwachen oder gehackten Passwörtern. Best Practices und Standards für Sicherheit empfehlen die Aktivierung von MFA, selbst für nicht-privilegierte Konten.
Wenn ein Angreifer sich mit einer beliebige Methode ein Passwort eines Benutzers verschafft, blockiert MFA die Authentifizierung, indem sie einen zusätzlichen Faktor anfordert, z. B. einen zeitlich ablaufenden Code aus einer mobilen App, ein physisches Token, ein biometrisches Merkmal usw.
Dieser Indicator of Exposure warnt Sie, wenn ein Konto keine registrierte MFA-Methode hat oder wenn Sie MFA erzwingen. ohne eine Methode zu registrieren. Letzteres kann Angreifern mit einem Passwort erlauben, ihre eigenen MFA-Methoden zu registrieren, und stellt ein Sicherheitsrisiko dar. Dieser Indicator of Exposure kann jedoch nicht darüber Auskunft geben, ob Microsoft Entra ID MFA erzwingt oder nicht, da Richtlinien für bedingten Zugriff die Verwendung von MFA in Abhängigkeit von dynamischen Kriterien erfordern können.
Sie können außerdem die Funktionen „<a href="https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-methods-activity">Aktivität für Authentifizierungsmethoden</a>“ und „<a href="https://learn.microsoft.com/en-us/entra/identity/authentication/howto-mfa-reporting">MFA-Berichte</a>“ in Entra ID verwenden.
Siehe auch den zugehörigen IoE „Fehlende MFA für privilegiertes Konto“ für privilegierte Konten.

Erkennungen

Indicators of Exposure

High

High

Critical

High

Medium