Freigeben über

Untersuchung der Zuweisung der App-Einwilligung

  • Artikel

Dieser Artikel enthält Anleitungen zum Identifizieren und Untersuchen von App-Einwilligungsangriffen, zum Schutz von Informationen und zur Minimierung weiterer Risiken.

Dieser Artikel enthält folgende Abschnitte:

  • Voraussetzungen: Beschreibt die zu erfüllenden spezifischen Anforderungen, bevor Sie mit der Untersuchung beginnen. Beispielsweise die Protokollierung, die aktiviert werden soll, Rollen und Berechtigungen, die u. a. erforderlich sind.
  • Workflow: Zeigt den logischen Flow an, den Sie befolgen sollten, um diese Untersuchung durchzuführen.
  • Prüfliste: Enthält eine Liste der Aufgaben für jeden Schritt im Flussdiagramm. Diese Prüfliste kann in stark regulierten Umgebungen hilfreich sein, um Ihre unternommenen Schritte zu überprüfen, oder einfach als Qualitätsstufe für sich selbst.
  • Untersuchungsschritte: Enthält einen ausführlichen schrittweisen Leitfaden für diese spezifische Untersuchung.
  • Wiederherstellung: Enthält allgemeine Schritte zur Wiederherstellung/Behebung nach einem Angriff mit unrechtmäßiger Zuweisung einer Anwendungseinwilligung.
  • Referenzen: Enthält zusätzliches Lese- und Referenzmaterial.

Voraussetzungen

Im Folgenden finden Sie allgemeine Einstellungen und Konfigurationen, die Sie abschließen sollten, wenn Sie eine Untersuchung der Zuweisung von Anwendungseinwilligungen durchführen möchten. Bevor Sie mit der Untersuchung beginnen, stellen Sie sicher, dass Sie die Informationen über Einwilligungsberechtigungstypen lesen, die unter Einwilligungsberechtigungstypen erläutert werden.

Debitorendaten

Um den Untersuchungsprozess zu starten, benötigen Sie die folgenden Daten:

  • Details zu Indikatoren für eine Kompromittierung (IoCs)
  • Das Datum und die Uhrzeit, zu der Sie den Incident bemerkt haben
  • Datumsbereich
  • Anzahl der kompromittierten Konten
  • Namen der kompromittierten Konten
  • Rollen des kompromittierten Kontos
  • Sind die Konten stark privilegiert (GA Microsoft Exchange, SharePoint)?
  • Gibt es Unternehmensanwendungen, die mit dem Incident in Verbindung stehen?
  • Haben Benutzer Anwendungen gemeldet, die in ihrem Namen Zugriffsrechte auf Daten angefordert haben?

Systemanforderungen

Stellen Sie sicher, dass Sie die folgenden Installations- und Konfigurationsanforderungen erfüllen:

  • Das AzureAD PowerShell-Modul ist installiert.
  • Sie verfügen über globale Administratorrechte für den Mandanten, für den das Skript ausgeführt wird.
  • Ihnen wird die lokale Administratorrolle auf dem Computer zugewiesen, den Sie zum Ausführen der Skripts verwenden.

Hinweis

Azure AD- und MSOnline PowerShell-Module sind ab dem 30. März 2024 veraltet. Weitere Informationen finden Sie im Update zur Unterstützungseinstellung. Nach diesem Datum wird die Unterstützung für diese Module auf die Migrationsunterstützung für das Microsoft Graph PowerShell-SDK und Sicherheitskorrekturen beschränkt. Die veralteten Module funktionieren weiterhin bis zum 30. März 2025.

Es wird empfohlen, für die Interaktion mit Microsoft Entra ID (früher Azure AD) zu Microsoft Graph PowerShell zu migrieren. Informationen zu allgemeinen Migrationsfragen finden Sie in den häufig gestellten Fragen zur Migration. Hinweis: Bei der Version 1.0.x von MSOnline können nach dem 30. Juni 2024 Unterbrechungen auftreten.

Installieren des Azure AD-Moduls

Verwenden Sie diesen Befehl, um das AzureAD-Modul zu installieren.

Install-Module -Name AzureAD -Verbose

Hinweis

Wenn Sie aufgefordert werden, die Module aus einem nicht vertrauenswürdigen Repository zu installieren, geben Sie J ein, und drücken Sie die EINGABETASTE.

Installieren des MSOnline PowerShell-Moduls

  1. Öffnen Sie die Windows PowerShell-App mit erhöhten Rechten (als Administrator ausführen).

  2. Führen Sie diesen Befehl aus, damit PowerShell signierte Skripts ausführen kann.

    Set-ExecutionPolicy RemoteSigned

  3. Installieren Sie das MSOnline-Modul mit diesem Befehl.

    Install-Module -Name MSOnline -Verbose

    Hinweis

    Wenn Sie aufgefordert werden, die Module aus einem nicht vertrauenswürdigen Repository zu installieren, geben Sie J ein, und drücken Sie die EINGABETASTE.

Herunterladen des AzureADPSPermissions-Skripts von GitHub

  1. Laden Sie das Skript Get-AzureADPSPermissions.ps1 von GitHub in einen Ordner herunter, in dem Sie das Skript ausführen. Die Ausgabedatei permissions.csv wird ebenfalls in denselben Ordner geschrieben.

  2. Öffnen Sie eine PowerShell-Instanz als Administrator, und öffnen Sie den Ordner, in dem Sie das Skript gespeichert haben.

  3. Stellen Sie eine Verbindung mit Ihrem Verzeichnis mit dem Cmdlet Connect-AzureAD her. Im Folgenden sehen Sie ein Beispiel.

    Connect-AzureAD -tenantid "aaaabbbb-0000-cccc-1111-dddd2222eeee" -AccountId "user1@contoso.onmicrosoft.com"

  4. Führen Sie diesen PowerShell-Befehl aus.

    Get-AzureADPSPermissions.ps1 | Export-csv -Path "Permissions.csv" -NoTypeInformation

    Trennen Sie die Verbindung Ihrer AzureAD-Sitzung mit diesem Befehl.

    Disconnect-AzureAD

Die Zustimmung ist der Prozess, bei dem einer Anwendung die Erlaubnis erteilt wird, im Namen des Benutzers auf geschützte Ressourcen zuzugreifen. Ein Administrator oder Benutzer kann zur Einwilligung aufgefordert werden, um den Zugriff auf seine Organisations-/individuellen Daten zuzulassen.

Einer Anwendung wird der Zugriff auf Daten basierend auf einem bestimmten Benutzer oder für die gesamte Organisation gewährt. Angreifer können diese Einwilligungen missbrauchen, um sich Zugang zur Umgebung zu verschaffen und auf vertrauliche Daten zuzugreifen. Diese Art von Angriffen wird als „unrechtmäßige Einwilligungszuweisung“ bezeichnet. Sie kann durch eine Phishing-E-Mail, eine Kompromittierung des Benutzerkontos durch Kennwortspray oder durch die Registrierung einer Anwendung durch einen Angreifer als legitimer Benutzer erfolgen. In Szenarien, in denen ein Administratorkonto kompromittiert ist, gelten die Registrierung und die Zuweisung der Einwilligung für den gesamten Mandanten und nicht nur für einen Benutzer.

Bevor eine Anwendung auf die Daten Ihrer Organisation zugreifen kann, muss ein Benutzer der Anwendung eine entsprechende Berechtigungen erteilen. Unterschiedliche Berechtigungen erlauben verschiedene Zugriffsebenen. Standardmäßig sind alle Benutzer berechtigt, in Berechtigungen für Anwendungen einzuwilligen, die keine Administratoreinwilligung erfordern. Standardmäßig kann ein Benutzer beispielsweise einwilligen, dass eine App auf sein Postfach zugreifen kann, er kann aber nicht einwilligen, dass eine App uneingeschränkten Lese- und Schreibzugriff auf alle Dateien in Ihrer Organisation erhält.

Hinweis

Wenn Sie es Benutzern ermöglichen, Apps Zugriff auf Daten zu gewähren, können Benutzer problemlos nützliche Anwendungen abrufen und produktiv arbeiten. In einigen Situationen kann diese Konfiguration jedoch ein Risiko darstellen, wenn Sie nicht sorgfältig überwacht und gesteuert wird.

Um mandantenweite Administratorzustimmung erteilen zu können, müssen Sie sich mit mindestens einer der folgenden Rollen anmelden:

  • Anwendungsadministrator
  • Cloudanwendungsadministrator
  • Administrator: Gibt an, dass die Einwilligung vom Administrator (im Auftrag der Organisation) zugewiesen wurde.
  • Einzelner Benutzer – Zeigt an, dass der Benutzer seine Zustimmung gegeben hat und nur Zugriff auf die Daten dieses Benutzers hat.
  • Zulässige Werte
    • AllPrincipals: Einwilligung durch einen Administrator für den gesamten Mandanten
    • Principal: Einwilligung des einzelnen Benutzers für Daten, die sich nur auf dieses Konto beziehen

Die tatsächliche Benutzererfahrung des Erteilens der Einwilligung variiert in Abhängigkeit von den auf dem Mandanten des Benutzers festgelegten Richtlinien, dem Gültigkeitsbereich der Autorität (oder Rolle) des Benutzers und dem Typ der Berechtigungen, die von der Clientanwendung angefordert werden. Dies bedeutet, dass Anwendungsentwickler und Mandantenadministratoren eine gewisse Kontrolle über die Einwilligungserfahrung haben. Administratoren besitzen die Flexibilität, Richtlinien für einen Mandanten oder eine App festzulegen oder zu deaktivieren, um die Einwilligungserfahrung in ihrem Mandanten zu kontrollieren. Anwendungsentwickler können vorgeben, welche Typen von Berechtigungen angefordert werden, und ob sie Benutzer durch den Benutzereinwilligungsflow bzw. den Administratoreinwilligungsflow führen möchten.

  • Benutzereinwilligungsflow: Wenn ein Anwendungsentwickler Benutzer mit der Absicht zum Autorisierungsendpunkt weiterleitet, die Einwilligung nur für den aktuellen Benutzer aufzuzeichnen.

  • Administratoreinwilligungsflow: Wenn ein Anwendungsentwickler Benutzer mit der Absicht zum Administratoreinwilligungs-Endpunkt weiterleitet, die Einwilligung für den gesamten Mandanten aufzuzeichnen. Um sicherzustellen, dass der Administratoreinwilligungsflow ordnungsgemäß funktioniert, müssen Anwendungsentwickler alle Berechtigungen in der Eigenschaft RequiredResourceAccess im Anwendungsmanifest auflisten.

Gegenüberstellung von delegierten Berechtigungen und Anwendungsberechtigungen

Delegierte Berechtigungen werden von Apps verwendet, bei denen ein angemeldeter Benutzer vorhanden ist und deren Einwilligung vom Administrator oder Benutzer angewendet werden kann.

Anwendungsberechtigungen werden von Anwendungen verwendet, die ohne einen angemeldeten Benutzer ausgeführt werden. Beispielsweise Apps, die als Hintergrunddienste oder Daemons ausgeführt werden. Für Anwendungsberechtigungen ist immer die Einwilligung eines Administrators erforderlich.

Weitere Informationen finden Sie unter:

Klassifizieren riskanter Berechtigungen

Es gibt (mindestens) Tausende von Berechtigungen im System, und es ist nicht praktikabel, diese alle aufzulisten oder zu analysieren. Die folgende Liste behandelt häufig missbrauchte Berechtigungen und andere, die bei Missbrauch zu katastrophalen Auswirkungen führen würden.

Auf hoher Ebene habt Microsoft beobachtet, dass die folgenden delegierten „Stammberechtigungen“ (App und Benutzer) bei Einwilligungsphishing-Angriffen missbraucht werden. Der Stamm (Root) entspricht der obersten Ebene. Zum Beispiel Kontakte.* bedeutet, dass alle delegierten Permutationen von Kontaktberechtigungen enthalten sind: Contacts.Read, Contacts.ReadWrite, Contacts.Read.Shared, und Contacts.ReadWrite.Shared.

  1. Mail.* (einschließlich Mail.Send*, aber nicht Mail.ReadBasic*.)
  2. Kontakte. *
  3. MailboxSettings.* (Einstellung der Mailbox
  4. People.* (Personen)
  5. Files.* (Dateien)
  6. Notes.* (Hinweis)
  7. Directory.AccessAsUser.All
  8. User_Impersonation (Benutzer_Impersonation)

Die ersten sieben Berechtigungen in der obigen Liste gelten für Microsoft Graph und die „Legacy“-API-Äquivalente, wie Azure Active Directory (Azure AD) Graph und Outlook REST. Die achte Berechtigung ist für Azure Resource Manager (ARM) konzipiert und könnte auch für jede API gefährlich sein, die vertrauliche Daten über diesen umfassenden Identitätswechselbereich verfügbar macht.

Nach den Beobachtungen des Microsoft Incident Response Team haben Angreifer in 99 % der Einwilligungsphishing-Angriffe eine Kombination der ersten sechs Berechtigungen verwendet. Die meisten Leute denken nicht an die delegierte Version von Mail.Read oder Files.Read als Berechtigung mit hohem Risiko. Die Angriffe sind aber im Allgemeinen großflächig und zielen auf Endbenutzer und nicht mithilfe von Spear-Phishing auf Administratoren ab, die den gefährlichen Berechtigungen tatsächlich zustimmen könnten. Es wird empfohlen, Apps mit diesen „kritischen“ Berechtigungen zu blockieren. Selbst wenn die Anwendungen keine schädlichen Absichten verfolgen und ein böswilliger Akteur die Identität der App kompromittieren würde, könnte Ihre gesamte Organisation gefährdet sein.

Für die Berechtigungen mit den höchsten Risikoauswirkungen beginnen Sie hier:

  • Anwendungsberechtigungsversionen (AppOnly/AppRole) aller oben genannten Berechtigungen, sofern zutreffend

Delegierte und AppOnly-Versionen der folgenden Berechtigungen:

  • Application.ReadWrite.All
  • Directory.ReadWrite.All
  • Domain.ReadWrite.All*
  • EduRoster.ReadWrite.All*
  • Group.ReadWrite.All
  • Member.Read.Hidden*
  • RoleManagement.ReadWrite.Directory
  • User.ReadWrite.All*
  • User.ManageCreds.All
  • Alle anderen AppOnly-Berechtigungen, die Schreibzugriff zulassen

Die Liste der Berechtigungen mit den geringsten Risikoauswirkungen finden Sie hier:

  • User.Read
  • User.ReadBasic.All
  • Open_id
  • E‑Mail
  • Profile
  • Offline_Zugriff (nur in Verbindung mit anderen Berechtigungen auf dieser Liste „geringstes Risiko“)

Anzeigen von Berechtigungen

  1. Um die Berechtigungen anzuzeigen, navigieren Sie in der Unternehmensanwendung zum Bildschirm für die Registrierung.

    Screenshot zum Anzeigen unterschiedlicher Berechtigungen.

  2. Wählen Sie API-Berechtigungen anzeigen aus.

    Screenshot zum Anzeigen und Hinzufügen von API-Berechtigungen.

  3. Wählen Sie Berechtigung hinzufügen aus, und der folgende Bildschirm wird angezeigt.

    Screenshot zum Anfordern von API-Berechtigungen.

  4. Wählen Sie Microsoft Graph aus, um die verschiedenen Berechtigungstypen anzuzeigen.

    Screenshot der verschiedenen Arten von API-Berechtigungen.

  5. Wählen Sie den Berechtigungstyp aus, den die registrierte Anwendung verwendet: Delegierte Berechtigungen oder Anwendungsberechtigungen. In der obigen Abbildung ist Anwendungsberechtigungen ausgewählt.

  6. Sie können nach einer der Berechtigungen mit hohem Risiko suchen, z. B. EduRoster.

    Screenshot einer Beispiel-API-Berechtigungsanforderung.

  7. Wählen Sie EduRoster aus, und erweitern Sie die Berechtigungen.

    Screenshot eines API-Berechtigungselements mit einer QuickInfo.

  8. Sie können diese Berechtigungen jetzt zuweisen oder überprüfen.

    Weitere Informationen finden Sie unter Graph-Berechtigungen.

Workflow

[Flussdiagramm eines App-Zustimmungserteilungsworkflows.]

Weitere Funktionen:

  • Laden Sie den Workflow für die Zuweisung der App-Einwilligung und andere Workflows des Playbooks für die Reaktion auf Vorfälle als PDF herunter.
  • Laden Sie den Workflow für die Zuweisung der App-Einwilligung und andere Workflows des Playbooks für die Reaktion auf Vorfälle als Visio-Datei herunter.

Checkliste

Verwenden Sie diese Prüfliste, um die Überprüfung der Zuweisung der Anwendungseinwilligung durchzuführen.

  • Indikatoren für eine Kompromittierung (IoC)

    Überprüfen der folgenden Indikatoren für eine Kompromittierung (IoC):

    • Wann haben Sie den Incident bemerkt?
    • Datumsbereich des Incidents (wie weit links ist der Zielbeitrag?)
    • Anzahl der kompromittierten Konten
    • Namen der kompromittierten Konten
    • Rollen der kompromittierten Konten
    • Sind die kompromittierten Konten stark privilegiert, ein Standardbenutzer oder eine Kombination daraus?

  • Rollen

    Ihnen müssen die folgenden Rollen zugewiesen sein:

    • Lokale Administratorrolle auf dem Computer, auf dem Sie das Skript ausführen

  • PowerShell-Konfiguration

    Konfigurieren Sie Ihre PowerShell-Umgebung mit diesen Schritten:

    1. Installieren Sie das Azure AD PowerShell-Modul.
    2. Führen Sie die Windows PowerShell-App mit erhöhten Rechten aus. (Als Administrator ausführen.)
    3. Konfigurieren Sie PowerShell zum Ausführen signierter Skripts.
    4. Laden Sie das Skript Get-AzureADPSPermissions.ps1 herunter.

  • Untersuchungstrigger

    • Kontokompromittierung
    • Einstellungen für die App-Einwilligung auf dem Mandanten geändert
    • Warnung/Überwachung: Ereignisstatusgrund „riskante Anwendung“ erkannt
    • Ungewöhnlich aussehende Anwendungen bemerkt

Sie können auch eine Checkliste für die Zuweisung der App-Einwilligung und andere Checklisten des Playbooks für die Reaktion auf Vorfälle als Excel-Datei herunterladen.

Untersuchungsschritte

Sie können die folgenden beiden Methoden verwenden, um die Zuweisungen von Anwendungseinwilligungen zu untersuchen:

  • Azure-Portal
  • PowerShell-Skript

Hinweis

Mithilfe des Azure-Portals können Sie nur die Zuweisungen der Administratoreinwilligungen der letzten 90 Tage anzeigen. Daher empfehlen wir, nur die PowerShell-Skriptmethode zu verwenden, um die Untersuchungsschritte der Angreiferregistrierung zu reduzieren.

Methode 1: Verwenden des Azure-Portals

Sie können das Microsoft Entra Admin Center verwenden, um Anwendungen zu finden, auf die einzelne Benutzer Zugriffsrechte erteilt haben.

  1. Melden Sie sich beim Azure-Portal als Administrator an.
  2. Wählen Sie das Microsoft Entra ID Symbol.
  3. Wählen Sie Benutzer.
  4. Wählen Sie den Benutzer aus, den Sie überprüfen möchten.
  5. Wählen Sie Anwendungen aus.
  6. Sie können die Liste der Apps anzeigen, die dem Benutzer zugewiesen sind, und über welche Berechtigungen diese Anwendungen verfügen.

Methode 2: Verwenden von PowerShell

Es gibt mehrere PowerShell-Tools, die Sie verwenden können, um unrechtmäßige Zuweisungen von Einwilligungen zu untersuchen, z. B.:

PowerShell ist das einfachste Tool und erfordert keine Änderungen beim Mandanten. Wir werden unsere Untersuchung auf die öffentlich zugängliche Dokumentation zum Angriff über die unrechtmäßige Zuweisung von Einwilligungen stützen.

Führen Sie Get-AzureADPSPermissions.ps1 aus, um alle OAuth-Einwilligungszuweisungen und OAuth-Apps für alle Benutzer Ihres Mandanten in eine CSV-Datei zu exportieren. Informationen zum Herunterladen und Ausführen des Skripts Get-AzureADPSPermissions finden Sie im Abschnitt Voraussetzungen.

  1. Öffnen Sie eine PowerShell-Instanz als Administrator, und öffnen Sie den Ordner, in dem Sie das Skript gespeichert haben.

  2. Stellen Sie mithilfe des folgenden Connect-AzureAD-Befehls eine Verbindung mit Ihrem Verzeichnis her. Im Folgenden sehen Sie ein Beispiel.

    Connect-AzureAD -tenantid "aaaabbbb-0000-cccc-1111-dddd2222eeee" -AccountId "user1@contoso.onmicrosoft.com"

  3. Führen Sie diesen PowerShell-Befehl aus.

    Get-AzureADPSPermissions.ps1 | Export-csv c:\temp\consentgrants\Permissions.csv -NoTypeInformation

  4. Sobald das Skript abgeschlossen ist, empfehlen wir Ihnen, die Microsoft Entra-Sitzung mit diesem Befehl zu beenden.

     Disconnect-AzureAD

    Hinweis

    Die Ausführung des Skripts kann abhängig von der Größe und den konfigurierten Berechtigungen sowie von Ihrer Verbindung mehrere Stunden dauern.

  5. Das Skript erstellt eine Datei namens Permissions.csv.

  6. Öffnen Sie die Datei, und filtern Sie dann die Daten, oder formatieren Sie sie in eine Tabelle, und speichern Sie die Daten dann als .xlxs-Datei.

    Die Spaltenüberschriften für die Ausgabe werden in dieser Abbildung dargestellt.

    Screenshot der Excel-Spaltenüberschriften.

  7. Suchen Sie in der Spalte ConsentType (G) nach dem Wert AllPrinciples. Die Berechtigung AllPrincipals erlaubt der Clientanwendung den Zugriff auf die Inhalte aller Personen des Mandanten. Native Microsoft 365-Anwendungen benötigen diese Berechtigung, um ordnungsgemäß zu funktionieren. Jede Nicht-Microsoft-Anwendung mit dieser Berechtigung sollte sorgfältig überprüft werden.

  8. Überprüfen Sie in der Spalte Permission (F) die Berechtigungen, über die jede delegierte Anwendung verfügt. Suchen Sie nach Read- und Write-Berechtigungen oder der *. All-Berechtigung, und überprüfen Sie diese Berechtigungen sorgfältig, da Sie möglicherweise nicht angemessen sind. Screenshot der App-Berechtigungen in Spalte F.

    Hinweis

    Überprüfen Sie die spezifischen Benutzer, denen Einwilligungen zugewiesen wurden. Wenn bedeutenden Benutzern oder intensiven Systembenutzern unangemessene Einwilligungen erteilt wurden, sollten Sie weitere Untersuchungen anstellen.

  9. Suchen Sie in der Spalte ClientDisplayName (C) nach verdächtigen Apps. Beispiel:

    • Apps mit falsch geschriebenen Namen Screenshot eines falsch geschriebenen Namens.

    • Ungewöhnliche oder nichtssagende Namen Screenshotbeispiel für einen ungewöhnlichen Namen.

    • Namen, die einen Zusammenhang mit Hackern aufzuweisen scheinen. Sie müssen diese Namen sorgfältig überprüfen. Screenshotbeispiel eines Hackernamens.

Beispielausgabe: AllPrincipals and Read Write All. Anwendungen weisen möglicherweise nichts Verdächtiges wie nichtssagende Namen auf und verwenden MS Graph. Führen Sie jedoch eine Recherche durch, und ermitteln Sie den Zweck der Anwendungen und die tatsächlichen Berechtigungen, die die Anwendungen im Mandanten aufweisen, wie in diesem Beispiel gezeigt.

Screenshotbeispiel für Anwendungen mit allPrincipals ConsentType.

Im Folgenden finden Sie einige nützliche Tipps zum Überprüfen von Untersuchungen zur Informationssicherheitsrichtlinie (Information Security Policy, ISP):

  • ReplyURL/RedirectURL
    • Suchen Sie nach verdächtigen URLs
  • Wird die URL in einer verdächtigen Domäne gehostet?
    • Ist sie kompromittiert?
    • Ist die Domäne erst kürzlich registriert worden?
    • Handelt es sich um eine temporäre Domäne?
  • Gibt es einen Link zu den Vertragsbedingungen bzw. zum Servicevertrag bei der App-Registrierung?
  • Sind die Inhalte eindeutig und spezifisch für die Anwendung bzw. den Herausgeber?
  • Wurde der Mandant, der die Anwendung registriert hat, entweder neu erstellt oder kompromittiert (wird die App z. B. von einem gefährdeten Benutzer registriert)?

Angriffsverfahren

Während jeder Angriff tendenziell variiert, sind die wichtigsten Angriffsverfahren:

  • Ein Angreifer registriert eine App bei einem OAuth 2.0-Anbieter, wie z. B. Microsoft Entra ID.

  • Anwendungen sind so konfiguriert, dass sie legitim erscheinen. Angreifer könnten z. B. den Namen eines beliebten Produkts verwenden, das im selben Ökosystem verfügbar ist.

  • Der Angreifer ruft einen Link direkt von Benutzern ab. Dies kann durch herkömmliches E-Mail-basiertes Phishing, durch Kompromittierung einer nicht schädlichen Website oder durch andere Techniken erfolgen.

  • Der Benutzer wählt den Link aus und es wird eine authentische Aufforderung zur Einwilligung angezeigt, in der er aufgefordert wird, der schädlichen App Zugriffsrechte auf Daten zu gewähren.

  • Wenn ein Benutzer „Akzeptieren“ wählt, erteilt er der App die Erlaubnis, auf sensible Daten zuzugreifen.

  • Die App erhält einen Autorisierungscode, den sie für ein Zugriffstoken einlöst, und möglicherweise ein Aktualisierungstoken.

  • Das Zugriffstoken wird verwendet, um API-Aufrufe im Auftrag des Benutzers durchzuführen.

  • Wenn der Benutzer zustimmt, kann der Angreifer Zugriff auf die Mails, Weiterleitungsregeln, Dateien, Kontakte, Notizen, das Profil und andere sensible Daten und Ressourcen des Benutzers erhalten.

    Screenshot des Berechtigungsanforderungsbeispiels.

Ermitteln von Anzeichen für einen Angriff

  1. Wechseln Sie im Microsoft 365 Defender-Portal unter https://security.microsoft.com zu Überwachung. Sie können alternativ auch https://security.microsoft.com/auditlogsearch verwenden, um direkt zur Seite Überwachung zu wechseln.

  2. Suchen Sie auf der Seite Überwachung alle Aktivitäten und Benutzer, geben Sie bei Bedarf das Start- und Enddatum ein, und wählen Sie dann Suchen aus.

    Screenshot einer Überwachungsprotokollsuche.

  3. Wählen Sie die Filterergebnisse aus, und geben Sie im Feld Aktivität entsprechend Anwendung zustimmen ein.

    Screenshot des Filterns einer Überwachungsprotokollsuche.

  4. Wenn Sie unter der zuzuweisenden Einwilligung auf eine Aktivität stoßen, fahren Sie wie unten angegeben fort.

  5. Wählen Sie das Ergebnis aus, um die Details der Aktivität anzuzeigen. Wählen Sie Weitere Informationen aus, um Details zur Aktivität abzurufen.

  6. Überprüfen Sie, ob IsAdminContent auf „True“ gesetzt ist.

    Hinweis

    Dieser Vorgang kann zwischen 30 Minuten und 24 Stunden dauern, bis der entsprechende Überwachungsprotokolleintrag in den Suchergebnissen angezeigt wird, nachdem ein Ereignis aufgetreten ist.

    Der Zeitraum, für den ein Überwachungsdatensatz aufbewahrt wird und im Überwachungsprotokoll durchsuchbar ist, hängt von Ihrem Microsoft 365-Abonnement und insbesondere vom Typ der Lizenz ab, die einem bestimmten Benutzer zugewiesen ist. Wenn dieser Wert „true“ ist, gibt er an, dass jemand möglicherweise einen breiten Zugriff auf Daten gewährt hat. Wenn dies unerwartet ist, unternehmen Sie sofort Schritte, um einen Angriff zu bestätigen.

Wie kann ich einen Angriff bestätigen?

Wenn Sie auf eine oder mehrere Instanzen der oben aufgeführten Indikatoren für eine Kompromittierung (Indicators of compromise, IoCs) stoßen, müssen Sie weitere Untersuchungen durchführen, um zu bestätigen, dass der Angriff stattgefunden hat.

Inventarisieren von Apps mit Zugriff in Ihrer Organisation

Sie können die Anwendungen Ihrer Benutzer mit Hilfe des Microsoft Entra Admin-Centers oder der PowerShell inventarisieren oder Ihre Benutzer einzeln ihren Anwendungszugriff aufzählen lassen.

  • Verwenden Sie das Microsoft Entra Admin Center, um Anwendungen und deren Berechtigungen zu inventarisieren. Diese Methode ist gründlich, aber Sie können nur jeweils einen Benutzer überprüfen. Dies kann zeitaufwändig sein, wenn Sie die Berechtigungen mehrerer Benutzer überprüfen müssen.
  • Verwenden Sie PowerShell, um Anwendungen und deren Berechtigungen zu inventarisieren. Diese Methode ist die schnellste und gründlichste Methode mit dem geringsten Mehraufwand.
  • Fordern Sie Ihre Benutzer auf, ihre Apps und Berechtigungen einzeln zu überprüfen und die Ergebnisse zur Behebung zurück an die Administratoren zu melden.

Inventarisieren von Apps, die Benutzern zugewiesen sind

Sie können das Microsoft Entra Admin Center verwenden, um die Liste der Apps anzuzeigen, denen einzelne Benutzer Berechtigungen erteilt haben.

  1. Melden Sie sich mit Administratorrechten beim Azure-Portal an.
  2. Wählen Sie das Microsoft Entra ID Symbol.
  3. Wählen Sie Benutzer.
  4. Wählen Sie den Benutzer aus, den Sie überprüfen möchten.
  5. Wählen Sie Anwendungen aus.

Sie können die Liste der Apps, die dem Benutzer zugewiesen sind, und die Berechtigungen anzeigen, die diesen Apps erteilt wurden.

Ermitteln des Umfangs des Angriffs

Nachdem Sie die Inventarisierung des Zugriffs auf Anwendungen abgeschlossen haben, überprüfen Sie das Überwachungsprotokoll, um den vollen Umfang der Sicherheitsverletzung zu ermitteln. Suchen Sie nach den betroffenen Benutzern, den Zeiträumen, in denen die unrechtmäßige Anwendung Zugriff auf Ihr Unternehmen hatte, und den Berechtigungen der App. Sie können das Überwachungsprotokoll in den Microsoft 365 Security- und Microsoft Purview-Complianceportalen suchen.

Wichtig

Wenn die Überwachung vor dem möglichen Angriff nicht aktiviert wurde, können Sie nicht untersuchen, da Überwachungsdaten nicht verfügbar sind.

Wie können Angriffe verhindert und Risiken verringert werden?

Wenn Ihre Organisation über eine geeignete Lizenz verfügt:

  • Verwenden Sie weitere OAuth-Anwendungsüberwachungsfunktionen in Microsoft Defender für Cloud Apps.
  • Verwenden Sie Azure Monitor-Arbeitsmappen für die Überwachung von Berechtigungen und Einwilligungen und damit im Zusammenhang stehende Aktivitäten. Die Arbeitsmappe Erkenntnisse aus Einwilligungen bietet eine Ansicht der Apps nach der Anzahl fehlerhafter Einwilligungsanforderungen. Dies kann hilfreich sein, um Anwendungen für die Überprüfung durch die Administratoren zu priorisieren und zu entscheiden, ob ihnen eine Administratoreinwilligung gewährt werden soll.

Nachdem Sie eine Anwendung mit unzulässigen Berechtigungen identifiziert haben, deaktivieren Sie die Anwendung sofort gemäß den Anweisungen unter Deaktivieren einer Anwendung. Wenden Sie sich dann an den Microsoft Support, um die bösartige Anwendung zu melden.

Sobald eine Anwendung in Microsoft Entra deaktiviert ist, kann sie keine neuen Token für den Zugriff auf Daten abrufen, und andere Benutzer können sich nicht anmelden oder der App einer Einwilligung erteilen.

Hinweis

Wenn Sie den Verdacht haben, dass Sie in Ihrem Unternehmen auf eine bösartige Anwendung gestoßen sind, ist es besser, sie zu deaktivieren, als sie zu löschen. Wenn Sie die Anwendung nur löschen, kann sie später zurückkehren, wenn ein anderer Benutzer seine Zustimmung erteilt. Deaktivieren Sie stattdessen die Anwendung, um sicherzustellen, dass sie später nicht wieder aktiv werden kann.

Schritte zum Schützen Ihrer Organisation

Es gibt verschiedene Arten von Einwilligungsangriffen. Diese empfohlenen Schutzmaßnahmen entschärfen alle Arten von Angriffen, insbesondere das Einwilligungsphishing, bei dem Angreifer Benutzer dazu bringen, einer schädlichen App Zugriff auf vertrauliche Daten oder andere Ressourcen zu gewähren. Anstatt zu versuchen, das Passwort des Benutzers zu stehlen, versucht ein Angreifer, einer vom Angreifer kontrollierten App den Zugriff auf wertvolle Daten zu ermöglichen.

Um zu verhindern, dass sich Angriffe auf Microsoft Entra ID und Office 365 auswirken, lesen Sie die folgenden Empfehlungen:

Festlegen von Richtlinien

  • Diese Einstellung hat Auswirkungen auf den Benutzer und gilt möglicherweise nicht für eine Umgebung. Wenn Sie Einwilligungen zulassen möchten, stellen Sie sicher, dass die Administratoren die Anforderungen genehmigen.

  • Lassen Sie nur Einwilligungen für Anwendungen von verifizierten Herausgebern und bestimmte Berechtigungstypen zu, die so klassifiziert sind, dass sie nur geringe Auswirkungen aufweisen.

    Hinweis

    Die oben genannten Empfehlungen werden basierend auf den idealsten, sichersten Konfigurationen empfohlen. Da die Sicherheit jedoch ein ausgewogenes Verhältnis zwischen Funktionen und Vorgängen darstellt, können die sichersten Konfigurationen einen Mehraufwand für die Administratoren bedeuten. Diese Entscheidung treffen Sie am besten nach Rücksprache mit Ihren Administratoren.

    Konfigurieren der risikobasierten hochgestuften Einwilligung: Standardmäßig aktiviert, wenn die Benutzereinwilligung für Zuweisungen aktiviert ist

  • Die risikobasierte hochgestufte Einwilligung trägt zur Reduzierung der Benutzergefährdung durch böswillige Apps bei, die unrechtmäßige Einwilligungsanforderungen ausgeben. Wenn Microsoft eine risikobehaftete Anforderung der Endbenutzereinwilligung erkennt, wird die Anforderung stattdessen auf Administratoreinwilligung „hochgestuft“. Diese Funktion ist standardmäßig aktiviert, führt jedoch nur zu einer Änderung des Verhaltens, wenn die Endbenutzereinwilligung aktiviert ist.

  • Wird eine risikobehaftete Einwilligungsanforderung erkannt, zeigt die Einwilligungsaufforderung eine Meldung an, die besagt, dass eine Administratorgenehmigung erforderlich ist. Wenn der Workflow zum Anfordern der Administratoreinwilligung aktiviert ist, kann der Benutzer die Anforderung zur weiteren Überprüfung direkt von der Einwilligungsaufforderung an den Administrator senden. Ist diese Funktion aktiviert, wird die folgende Meldung angezeigt:

    AADSTS90094: <clientAppDisplayName> benötigt eine Berechtigung für den Zugriff auf Ressourcen in Ihrer Organisation, die nur ein Administrator erteilen kann. Bitten Sie einen Administrator, die Berechtigungen für diese App zu erteilen, damit Sie die App verwenden können. In diesem Fall wird auch ein Audit-Ereignis mit der Kategorie „ApplicationManagement“, dem Aktivitätstyp „Zustimmung zur Anwendung“ und dem Statusgrund „Riskante Anwendung entdeckt“ protokolliert.

Hinweis

Alle Aufgaben, für die eine Genehmigung des Administrators erforderlich ist, haben einen operativen Mehraufwand. Die Einstellungen für Einwilligung und Berechtigungen, Benutzereinwilligung weist derzeit den Status Vorschau auf. Sobald sie für die allgemeine Verfügbarkeit (GA) bereit ist, sollte die Funktion „Zustimmung der Benutzer von verifizierten Herausgebern für ausgewählte Berechtigungen zulassen“ den Arbeitsaufwand der Administratoren verringern und wird für die meisten Unternehmen empfohlen.

Screenshotbeispiel für Zustimmungsberechtigungen.

Bringen Sie Ihren Anwendungsentwicklern bei, dem vertrauenswürdigen App-Ökosystem zu folgen. Um Entwickler bei der Erstellung hochwertiger und sicherer Integrationen zu unterstützen, kündigen wir außerdem eine öffentliche Vorschau des Integrationsassistenten in Microsoft Entra App-Registrierungen an.

  • Der Integrations-Assistent analysiert die Registrierung Ihrer App und vergleicht sie mit einer Reihe von empfohlenen bewährten Methoden für die Sicherheit.
  • Der Integrationsassistent hebt Best Practices hervor, die in jeder Phase des Lebenszyklus Ihrer Integration relevant sind – von der Entwicklung bis zur Überwachung – und stellt sicher, dass jede Phase richtig konfiguriert ist.
  • Es erleichtert Ihnen die Arbeit, egal ob Sie Ihre erste App integrieren oder ob Sie ein Experte sind, der seine Fähigkeiten verbessern möchte.

Informieren Sie Ihre Organisation über die Einwilligungstaktiken (Phishingtaktiken, Einwilligungen von Administratoren und Benutzern):

  • Prüfen Sie auf schlechte Rechtschreibung und Grammatik. Wenn eine E-Mail-Nachricht oder der Genehmigungsbildschirm einer Anwendung Rechtschreib- und Grammatikfehler aufweist, handelt es sich wahrscheinlich um eine verdächtige Anwendung.
  • Achten Sie auf App-Namen und Domänen-URLs. Angreifer fälschen gerne App-Namen, die den Anschein erwecken, dass sie von legitimen Anwendungen oder Unternehmen stammen, Sie aber dazu bringen, einer schädlichen App zuzustimmen.
  • Stellen Sie sicher, dass Sie den App-Namen und die Domänen-URL kennen, bevor Sie einer Anwendung zustimmen.

Höherstufen und Zulassen des Zugriffs auf vertrauenswürdige Apps

  • Stufen Sie die Verwendung von Anwendungen höher, die vom Herausgeber überprüft wurden. Die Überprüfung des Herausgebers hilft Administratoren und Benutzern, die Authentizität von Anwendungsentwicklern zu erkennen. Bisher wurden mehr als 660 Anwendungen von 390 Herausgebern überprüft.
  • Konfigurieren Sie Richtlinien für die Anwendungseinwilligung, indem Sie Benutzern gestatten, nur bestimmten Anwendungen zuzustimmen, denen Sie vertrauen, z. B. Anwendungen, die von Ihrer Organisation entwickelt wurden, oder Anwendungen von verifizierten Herausgebern.
  • Informieren Sie Ihre Organisation darüber, wie unser Framework aus Berechtigungen und Einwilligungen funktioniert.
  • Machen Sie sich mit den Daten und Berechtigungen vertraut, nach denen eine Anwendung fragt. Informieren Sie sich außerdem darüber, wie Berechtigungen und Einwilligungen innerhalb unserer Plattform funktionieren.
  • Stellen Sie sicher, dass Administratoren wissen, wie Einwilligungsanforderungen verwaltet und ausgewertet werden.

Überwachen Sie Apps und zugelassene Berechtigungen in Ihrer Organisation, um sicherzustellen, dass die verwendeten Anwendungen nur auf die benötigten Daten zugreifen und das Prinzip der geringsten Rechte einhalten.

Gegenmaßnahmen

  • Aufklären des Kunden sowie Sensibilisierung und Training zum Sichern von Einwilligungszuweisungen für Anwendungen
  • Verschärfung des Prozesses zur Zuweisung von Anwendungseinwilligungen durch organisationsweite Richtlinien und technische Kontrollen
  • Einrichten eines Erstellungszeitplans zum Überprüfen von Anwendungen mit Einwilligung
  • Sie können PowerShell verwenden, um verdächtige oder bösartige Apps zu deaktivieren, indem Sie die App deaktivieren

Zugehöriger Inhalt

Zusätzliche Playbooks zur Reaktion auf Vorfälle

Überprüfen Sie den Leitfaden zum Identifizieren und Untersuchen dieser zusätzlichen Arten von Angriffen:

Ressourcen zur Reaktion auf Vorfälle