Token-Diebstahl Playbook

Dieser Artikel und das dazugehörige Verzeichnis bieten eine Richtlinie für Sicherheitsanalysten und Vorfallbearbeiter, um Token-Diebstahlsangriffe in einem Unternehmen zu identifizieren und zu untersuchen. Während Unternehmen ihre Sicherheitsvorkehrungen erhöhen, verwenden Bedrohungsakteure immer ausgefeiltere Techniken, um Ressourcen zu kompromittieren. Es ist eine schnelle Reaktion erforderlich, um Schäden zu untersuchen, einzudämmen und zu beheben, die durch Token-Diebstahl-Angriffe entstanden sind.

Ein Token-Diebstahl liegt vor, wenn Bedrohungsakteure die an einen Benutzer ausgegebenen Token kompromittieren und wieder abspielen, selbst wenn dieser Benutzer die Multifaktor-Authentifizierung erfüllt hat. Da die Authentifizierungsanforderungen erfüllt sind, erhält der Bedrohungsakteur mit dem gestohlenen Token Zugriff auf Unternehmensressourcen.

Weitere Informationen:

Voraussetzungen

  • Zugriff auf die Anmelde- und Prüfprotokolle von Microsoft Entra ID (früher Azure AD) für Benutzer und Dienstprinzipale
  • Ein Konto, dem eine der folgenden Microsoft Entra-Rollen zugewiesen wurde:
    • Sicherheitsadministrator
    • Globaler Administrator
    • Sicherheitsleseberechtigter
    • Globaler Leser
    • Sicherheitsoperator

Empfehlungen

Dies ist zwar nicht erforderlich, wird aber empfohlen:

  • Aktivieren Sie die erweiterte Suchfunktion und den Zugriff auf die Ereignisdaten der letzten sieben Tage.
  • Rufen Sie das Unified Access Log für zusätzliche Signale auf
  • Die Premium-Risikoerkennung von Microsoft Entra ID in den Lizenzen Microsoft Entra ID P2 und E5 ermöglicht detailliertere Trigger und Anweisungen für Untersuchungen
  • Verwenden Sie eine verwaltete Authentifizierungskonfiguration mit Passwort-Hash-Synchronisierung (PHS), nicht im Verbund, um auf zusätzliche Signale zuzugreifen

Anforderungen

Konfigurieren einer SIEM

Tools für das Sicherheitsinformations- und Ereignis-Management (SIEM) wie Microsoft Sentinel bieten einen zentralen Einblick in die Protokolle. Konfigurieren Sie das SIEM, um Risikoereignisse zu erfassen:

  • Anmeldungsprotokolle und Audit-Protokolle
  • Integration von Microsoft Sentinel (Vorschau) beschreibt, wie Sie Microsoft Defender for Cloud Apps mit Microsoft Sentinel (einem skalierbaren, Cloud-nativen SIEM und SOAR) integrieren, um eine zentrale Überwachung von Warnmeldungen und Erkennungsdaten zu ermöglichen.
  • Anmeldungsprotokolle und Audit-Protokolle in Office
  • Konfigurieren Sie relevante Warnmeldungen

Weitere Informationen:

Konfigurieren Sie die Regeln von Microsoft Sentinel (oder SIEM eines Drittanbieters) für die Erkennung von und Reaktion auf Bedrohungen, indem Sie die Richtlinien in Bedrohungen sofort erkennen befolgen.

Weitere Informationen:

  • Richten Sie Microsoft Entra ID Protection-Warnungen ein. Anleitung: Exportieren von Risikodaten beschreibt, wie Sie Daten über längere Zeiträume speichern können, indem Sie die Diagnoseeinstellungen in Microsoft Entra ID ändern, um RiskyUsers, UserRiskEvents, RiskyServicePrincipals und ServicePrincipalRiskEvents Daten an einen Log Analytics-Arbeitsbereich zu senden, Daten in einem Speicherkonto zu archivieren, Daten an einen Event Hub zu streamen oder Daten an eine Partnerlösung zu senden.

Integrieren Sie ein SIEM mit Microsoft Defender für Cloud Apps

Microsoft Defender für Cloud Apps und Microsoft Sentinel sind standardmäßig verbunden. Wenn Sie Microsoft Sentinel nicht verwenden, verbinden Sie Ihr SIEM mit Microsoft Defender for Cloud Apps, das Microsoft Sentinel, ArcSight by Open Text und das generische Common Event Format (CEF) unterstützt.

Weitere Informationen:

Integrieren Sie SIEM mit Microsoft Graph API

Verbinden Sie SIEM mit der Microsoft Graph Security API.

  • Unterstützte Integrationsoptionen – Code schreiben, um Ihre Anwendung zu verbinden und Erkenntnisse zu gewinnen. Der Überblick über die Microsoft Graph-Sicherheits-API beschreibt die wichtigsten Funktionen und enthält Codebeispiele.
  • Native Integrationen und Connectoren – erstellt von Microsoft-Partnern
  • Connectors – für die API durch SIEM-Lösungen, Security Orchestration Automated Response (SOAR), Incident Tracking und Service Management (ITSM), Reporting und so weiter

Untersuchungen

In den folgenden Abschnitten finden Sie Richtlinien zu Triggern, die Checklisten für die Untersuchung und mehr. Nutzen Sie das Verzeichnis des Workflows für den Token-Diebstahl, um Ihre Ermittlungen und Entscheidungen zu unterstützen.

Untersuchungstrigger

In jeder Organisation gibt es typische und untypische Szenarien. Verwenden Sie die folgende Untersuchungscheckliste, um Trigger oder ungewöhnliche Aktivitäten zu ermitteln:

  • Identities
  • Anmeldeprotokolle
  • Überwachungsprotokolle
  • Office-Apps
  • Mit den betroffenen Benutzern verbundene Geräte

Wenn diese Aktivitäten des Benutzers als gültig bestätigt werden, liegt kein Verstoß vor. Wenn die Gültigkeit der Daten nicht bestätigt werden kann, gehen Sie von einem Verstoß aus und ergreifen Sie Maßnahmen zur Schadensbegrenzung. Erkennen Sie Versuche des Token-Diebstahls, indem Sie im Microsoft Sentinel Portal oder in einem SIEM nach Ereignistypen suchen und diese untersuchen.

Weitere Informationen:

Stellen Sie sicher, dass Sie bei den folgenden Ereignissen, die auf einen Token-Diebstahl hindeuten könnten, eine Warnung erhalten:

Die Funktion Microsoft Entra ID Protection hat die folgenden Trigger:

  • Anomaler Token (Offline-Erkennung) – Erkennung atypischer Token-Merkmale oder eines Tokens, der von einem unbekannten Ort aus verwendet wurde. Die Algorithmen, die dieses Verhalten erkennen, verwenden Daten von Microsoft Entra ID mit Microsoft 365 Eigenschaften. Diese Erkennung zeigt an, ob der Angreifer den Token erneut abspielt.

  • Ungewohnte Anmeldeeigenschaften – Die Anmeldung ist anomal im Vergleich zu den Verlaufsdaten der Anmeldung. Dieses Ereignis tritt ein, wenn die Anmeldungseigenschaften des Benutzers nicht bekannt sind.

  • Ungewohnte Anmeldung – eine nicht-interaktive Anmeldung erfolgt. Erhöhte Kontrolle bei unbekannten Anmeldungen, insbesondere wenn sie mit verdächtigen Geräten entdeckt werden. Wir empfehlen Ihnen, der Erkennung von nicht-interaktiven Anmeldungen sofortige Aufmerksamkeit zu schenken.

  • Versuchter Zugriff auf das Primary Refresh Token (PRT) – in Windows 10 und 11 erkennt Microsoft Defender for Endpoint verdächtige Zugriffe auf PRT und zugehörige Artefakte. Erkannte Risiken fließen in die Microsoft Entra-Risikobewertung ein, die den bedingten Zugriff auf Ressourcen kontrolliert. Diese Entdeckung ist wenig umfangreich und kommt selten vor.

  • Microsoft Defender XDR-Erkennungen – Integrieren Sie den Microsoft Entra ID-Schutz und Microsoft Defender XDR, um Erkennungen in einem Portal anzuzeigen.

    • Standardmäßig sind die wichtigsten Warnungen für das Security Operation Center (SOC) aktiviert. Nehmen Sie für alle Microsoft Entra IP-Risikoerkennungen oder zum Deaktivieren der Integration die Änderung in der Einstellung des Microsoft Defender XDR-Einstellungen des Benachrichtigungsdienstesvor.

    Screenshot of the Show high impact alerts only option.

  • Verdächtige URLs – ein Benutzer könnte auf einen Phishing-Link in einer E-Mail geklickt haben. Bei der verdächtigen E-Mail könnte es sich um ein AiTM-Phishing-Kit (Adversary-in-the-Middle) handeln, das den Beginn eines Angriffs darstellt.

    Screenshot of a list of suspicious activity.

  • Andere verdächtige Verhaltensweisen – Defender für Microsoft 365 Erweiterte Suchalarme und Alarmtabellen zeigen Aktionen an, die auf Token-Diebstahl hinweisen. Prüfen Sie die Protokolle, um zu ermitteln:

    • Massen-Download von Dateien durch einen Benutzer
    • Ungewöhnlicher Dateidownload durch einen Benutzer
    • Hinzufügen von Multifaktor-Authentifizierung oder passwortlosen Zugangsdaten zu einem Konto
    • Mailbox-Weiterleitungsregeln hinzugefügt oder bearbeitet

Beginn der Untersuchung

Bevor Sie beginnen: Vervollständigen und aktivieren Sie die Voraussetzungen. Außerdem geht dieses Playbook davon aus, dass Microsoft-Kunden und Untersuchungsteams möglicherweise nicht über Microsoft 365 E5 oder Microsoft Entra ID P2 Lizenzsuite verfügen oder diese nicht konfiguriert haben. Beachten Sie daher die Richtlinien zur Automatisierung.

Für diese Untersuchung gehen wir davon aus, dass Sie einen Hinweis auf einen möglichen Token-Diebstahl haben:

  • Ein Bericht eines Benutzers
  • Beispiel für Microsoft Entra-Anmeldeprotokolle
  • Erkennung von Microsoft Entra ID Protection

Checkliste für die Untersuchung

Ermitteln Sie anhand Ihrer typischen Szenarien Anomalien oder ungewöhnliche Aktivitäten für:

  • Identities
  • Anmeldeprotokolle – unerwarteter Ort oder Gerät
  • Audit-Protokolle – neu registrierte Geräte, zusätzliche Multifaktor-Authentifizierungsoptionen oder Änderungen der Anmeldeinformationen.
  • Office Apps – Änderungen seit dem Auftreten des Triggers
  • Geräte – die mit den betroffenen Benutzern verbunden sind. Bewerten Sie die Alarme seit dem Trigger des Vorfalls.

Nachweis einer Kompromittierung oder eines Token-Diebstahls: Bestätigung durch den Benutzer

Nachdem Sie potenziell gefährdete Benutzer-Konten identifiziert haben, überprüfen Sie die verdächtigen Aktivitäten. Dieser Prozess ist bei jedem Unternehmen anders.

Weitere Informationen:

Benutzer- und/oder Geräteuntersuchung

Wenn Sie glauben, dass ein Konto oder mehrere Benutzerkonten kompromittiert wurden, unterscheiden Sie bei Ihren Ermittlungen zwischen zwei Kontexten: Benutzer-Sitzungen und Computer-Geräte.

Checkliste für die Untersuchung von Benutzern

Untersuchen Sie Protokolle, die das Verhalten von Benutzern enthalten. Es gibt verdächtige Benutzeraktivitäten, wenn:

  • In Microsoft Entra ID Protection oder einer ähnlichen Funktion werden Warnungen ausgegeben, die auf einen Token-Diebstahl hindeuten
  • Zusätzliche Anmeldeinformationen oder Geräte, die dem Benutzer hinzugefügt wurden
    • Aufzeichnung der Liste der zu widerrufenden Identitäten
  • Betroffene Benutzer erhalten verdächtige E-Mails
  • Phishing-Untersuchung bietet Richtlinien zur Identifizierung und Untersuchung von Phishing-Angriffen in Ihrem Unternehmen.
  • Privilegierte Konten betroffen
    • Überprüfen Sie Änderungen an privilegierten Konten, die nach der Kompromittierung vorgenommen wurden.
  • Erstellung von Posteingangsregeln
    • Regeln für verdächtige Mailboxen aufzeichnen
    • Kompromittierte Benutzer
    • IP-Adressen und das/die Benutzerkonto/Benutzerkonten dokumentieren
    • Ermitteln Sie andere potenziell gefährdete Konten
    • Identifizieren Sie zusätzliche Authentifizierungen anhand der verdächtigen IP-Adresse oder des Benutzer-Agenten-Strings

Phishing oder bösartige E-Mails

Wenn es Hinweise auf Phishing oder andere bösartige E-Mails gibt, beschreibt Untersuchung von bösartigen E-Mails in Microsoft 365, wie Sie verdächtige E-Mails finden und untersuchen können.

Authentifizierungen von Angreifer-IP-Adressen oder Benutzer-Agenten-Strings

Die folgenden Abfragen beziehen sich auf Tabellen in Sentinel. Achten Sie auf Anzeichen von Persistenz: Anmeldung mit Multifaktor-Authentifizierung, Geräteanmeldung, Regeln für die Weiterleitung von Postfächern oder Posteingangsregeln.

Erfahren Sie mehr über Regeln im Microsoft Entra Sicherheitsleitfaden.

AADUserRiskEvents
| where RiskEventType contains "unfamiliar" or RiskEventType contains "anomalous"
| where IpAddress == "x"

Oder verwenden Sie die Anmeldeprotokolle, um Benutzer mit derselben IP-Adresse zu finden.

SigninLogs
| where IPAddress == "x"

Für privilegierte Benutzer bestätigen Sie alle Änderungen im Zeitfenster.

AuditLogs
| where TimeGenerated between (datetime(2023-03-01) .. datetime(2023-03-15))
| where InitiatedBy == "x"

Änderung der Authentifizierungsmethode für ein privilegiertes Konto

Verwenden Sie die folgende Abfrage, um alle Änderungen in den Sicherheitsinformationen von Benutzern zu finden, denen privilegierte Admin-Rollen zugewiesen sind.

Query
  let queryperiod = 14d;
  let queryfrequency = 2h;
  let security_info_actions = dynamic(["User registered security info", "User changed default security info", "User deleted security info", "Admin updated security info", "User reviewed security info", "Admin deleted security info", "Admin registered security info"]);
  let VIPUsers = (
      IdentityInfo
      | where TimeGenerated > ago(queryperiod)
      | mv-expand AssignedRoles
      | where AssignedRoles matches regex 'Admin'
      | summarize by tolower(AccountUPN));
  Audit logs
  | where TimeGenerated > ago(queryfrequency)
  | where Category =~ "UserManagement"
  | where ActivityDisplayName in (security_info_actions)
  | extend Initiator = tostring(InitiatedBy.user.userPrincipalName)
  | extend IP = tostring(InitiatedBy.user.ipAddress)
  | extend Target = 
tolower(tostring(TargetResources[0].userPrincipalName))
  | where Target in (VIPUsers)

Fragwürdige Identitäten und Anomalien

Verwenden Sie Log Analytics oder Sentinel (Log in Microsoft Entra ID), um fragwürdige Identitäten und Anomalien zu entdecken.

SigninLogs
    | where UserId == "x"
    | extend deviceId_ = tostring(DeviceDetail.deviceId)
    | extend displayName_ = tostring(DeviceDetail.displayName)
    | extend city_ = tostring(LocationDetails.city)
    | extend countryOrRegion_ = tostring(LocationDetails.countryOrRegion)
    | summarize min(TimeGenerated), max(TimeGenerated) by IPAddress, ResultDescription, deviceId_, displayName_, city_, countryOrRegion_, AppDisplayName

Hinweis

Nicht alle Microsoft Entra-Aktivitätswarnungen haben einen entsprechenden Eintrag in SigninLogs, wie bei der Erkennung anomaler Token zu sehen ist. Wir empfehlen Ihnen, sich auch andere Tabellen anzusehen, z. B. OfficeActivity und AuditLogs.

OfficeActivity
    | where UserId == "x"
    | summarize min(TimeGenerated), max(TimeGenerated) by ClientIP, OfficeWorkload

Aktivität in CloudAppEvents-Tabellen in Microsoft Defender XDR

Die Verwendung dieser Methode hängt von der Einrichtung der Protokollierung ab.

M365D AH
CloudAppEvents
| where AccountId == "x"
| summarize min(Timestamp), max(Timestamp) by IPAddress, CountryCode, City, Application

CloudAppEvents beschreibt das erweiterte Hunting-Schema, das Informationen über Aktivitäten in verschiedenen Cloud-Apps und -Diensten enthält, die von Microsoft Defender für Cloud Apps abgedeckt werden.

Bösartige Aktionen in AuditLogs, AzureActivity, AzureDevOpsAuditing und CloudAppEvents

Bestätigen Sie, worauf der Angreifer zugegriffen hat: Identitätsdokumente, Code, Repositories usw. Überprüfen Sie die Elemente auf sensible Informationen oder hartkodierte Anmeldedaten, wie im folgenden SharePoint-Beispiel gezeigt.

OfficeActivity
    | where OfficeWorkload contains "SharePoint" (or other)
    | where ClientIP == "bad IP"
    | project TimeGenerated, Operation, OfficeObjectId

Checkliste für Geräteuntersuchungen

Untersucht Protokolle, die das Geräteverhalten aufzeichnen. Eine verdächtige Geräteaktivität liegt vor, wenn:

  • Microsoft Defender-Portal:
    • Das Gerät verfügt über Warnmeldungen zum Diebstahl von Token. Suche nach Geräte-ID: join AlertInfo auf AlertId| wobei DeviceId gleich x ist
    • Versucht, auf das primäre Aktualisierungs-Token (PRT) zuzugreifen
    • Der Benutzer hat verdächtige Anwendungen oder Erweiterungen installiert oder er hat kürzlich verdächtige Websites besucht. Suchen Sie in den Warnungen von Microsoft Defender für Endpoints nach verdächtigen Prozessen oder Dateien. Die Warnungen können verdächtige Informationen enthalten: implantierter Prozess einer bekannten neuen Bedrohung, Prozessname, Prozessverhalten, gestarteter Dienst oder geplante Aufgabenaktivität. Für mögliche C2-Kommunikation verwenden Sie Mögliche Befehls- und Kontrolltätigkeit.
    • Untersucht Microsoft Defender auf Endpoint-Warnungen beschreibt, wie Sie Alarme, die Ihr Netzwerk betreffen, untersuchen, verstehen, was sie bedeuten, und wie Sie sie beheben können.
  • Erweitertes Hunting:
    • Das Gerät hat ausgehende Netzwerkverbindungen von verdächtigen Prozessen. Achten Sie auf ungewöhnliche ausgehende Aktivitäten während des Trigger-Fensters.
    • Lokale Konten führten verdächtige Aktivitäten aus

Weitere Informationen:

Isolieren Sie das Gerät vom Netzwerk

Schließen Sie das Gerät ein. Reaktionsmaßnahmen auf einem Gerät in Microsoft Defender für Endpoint durchführen beschreibt, wie Sie schnell auf entdeckte Angriffe reagieren können, indem Sie Geräte isolieren oder ein Untersuchungspaket zusammenstellen.

Daten, auf die der Angreifer zugreift

Datenverlust ist die Zerstörung oder das Durchsickern von Daten. Finden Sie heraus, worauf der Angreifer zugegriffen hat und wie sensibel die Daten sind. Untersuchen Sie SharePoint, OneNote, Azure DevOps. Rotieren Sie die Anmeldeinformationen.

Verfahren bei Datenverlust

Nutzen Sie die Richtlinien Ihres Disaster Recovery Plans zum Zugriff von Angreifern auf Unternehmensdaten. Nutzen Sie die folgenden Richtlinien, um Datenverlusten vorzubeugen und einen Notfallwiederherstellungsplan zu verbessern oder zu erstellen.

Andere betroffene Benutzer oder Geräte: gesamte Umgebung

Abfrage von Indikatoren für Kompromisse in der gesamten Umgebung. Zum Beispiel, mehr betroffene Geräte. Iterieren Sie, um sicherzustellen, dass alle betroffenen Benutzer und Geräte gefunden werden.

Zustand der Eindämmung

Sobald Sie festgestellt haben, dass ein weiterer Benutzer, ein Gerät, eine oder mehrere Anwendungen oder ein Workload böswillig oder gefährdet sind, sollten Sie Maßnahmen ergreifen, um den Angreifer einzudämmen. Wenn die Anwendung kompromittiert wurde, können Sie die Anmeldedaten nicht sofort auslesen und sie auch nicht löschen.

Manchmal ist es wichtiger, Details über den Angreifer zu sammeln, als sofort auf den Angriff zu reagieren. Wir empfehlen Ihnen, die Reihenfolge der folgenden Richtlinien zu beachten. In diesem Beispiel hat die Eindämmung bzw. Schadensbegrenzung Vorrang vor der Informationsbeschaffung.

Wichtig

Bestimmen Sie die Auswirkungen der Deaktivierung von Benutzer- oder Gerätekonten auf die Sicherheit und das Geschäft. Wenn sie zu groß ist, sollten Sie zur Recovery-Phase übergehen.

Aufgabenliste zur Eindämmung

  1. Ändern Sie das Passwort für Konten, bei denen der Verdacht besteht, dass sie verletzt wurden, oder wenn das Konto-Passwort entdeckt wurde.

  2. Blockieren Sie den Benutzer. Widerruf des Benutzerzugriffs in Microsoft Entra ID beschreibt, wie Sie einem Benutzer in Szenarien mit kompromittierten Konten, der Kündigung von Mitarbeitern und anderen Insider-Bedrohungen den gesamten Zugriff entziehen können.

  3. Markieren Sie in Microsoft Entra ID Protection oder einer ähnlichen Funktion die betreffenden Konten als kompromittiert.

  4. Blockieren Sie die IP-Adresse des Angreifers.

    Tipp

    Angreifer können legitime virtuelle private Netzwerke (VPNs) verwenden, die ein größeres Risiko darstellen, da sie die IP-Adresse wechseln. Wenn Sie die Cloud-Authentifizierung verwenden, blockieren Sie die IP-Adresse in Defender für Cloud Apps oder Microsoft Entra ID. Wenn Sie im Verbund arbeiten, blockieren Sie die IP-Adresse auf der Firewall-Ebene vor den Active Directory Federation Services (ADFS).

  5. Aktivieren der mehrstufigen Authentifizierung (MFA): Aktivierung der mehrstufigen Authentifizierung von Microsoft Entra beschreibt, wie Sie Benutzer während eines Anmeldevorgangs auffordern können, sich zusätzlich auszuweisen.

  6. Aktivieren Sie Microsoft Entra ID Protection für Benutzer- und Anmeldungsrisiken. Risiko-Richtlinien: Microsoft Entra ID-Schutz beschreibt Risikorichtlinien in Microsoft Entra Conditional Access, mit denen die Reaktion auf Risiken automatisiert werden kann und die es den Benutzern ermöglichen, erkannte Risiken selbst zu beheben.

  7. Ermitteln Sie die kompromittierten Daten: E-Mails, SharePoint, OneDrive, Apps. Der Filter Microsoft Defender für Cloud Apps Aktivitäten kann Aktivitäten scannen und neue Aktivitäten aktualisieren.

  8. Bewahren Sie die Kennwortkontrolle. Die Whitepaper Passwortrichtlinien enthalten Empfehlungen für die Verwaltung von Passwörtern für Endbenutzer und Identitätsadministratoren.

  9. Wiederholen Sie den Vorgang, bis Sie die betroffenen Konten und Geräte gefunden haben und der Angriff gestoppt ist.

Wiederherstellung

Verwenden Sie die folgenden Abschnitte als Richtlinie nach der Untersuchung und Eindämmung.

Aufgabenliste zur Wiederherstellung

Nachdem Sie die Untersuchung und Eindämmung abgeschlossen haben, beheben Sie den Schaden:

  • Deaktivieren Sie betroffene Benutzer- und Gerätekonten
    • Aktuelle Token widerrufen
    • Zurücksetzen von Kennwörtern
  • Deaktivieren Sie hinzugefügte Anmeldeinformationen und/oder Geräte
    • Beseitigen Sie infizierte Geräte
  • Deaktivieren Sie Regeln für verdächtige E-Mails
  • Machen Sie Änderungen rückgängig, die von kompromittierten privilegierten Konten vorgenommen wurden.

Löschen Sie hinzugefügte Anmeldeinformationen und Geräte

Bevor Sie die betroffenen Konten wieder aktivieren, beachten Sie die folgende Richtlinie. Löschen Sie Anmeldeinformationen, die mit Microsoft Entra Authentifizierungsmethoden Graph API hinzugefügt wurden.

Um eine Benutzer-E-Mail-Authentifizierungsmethode zu löschen, führen Sie die folgende Graph-Anfrage aus:

DELETE /users/{id | userPrincipalName}/authentication/emailMethods/{id}

Oder Sie löschen eine hinzugefügte Authentifizierungsmethode:

DELETE /users/{id | userPrincipalName}/authentication/microsoftAuthenticatorMethods/{microsoftAuthenticatorAuthenticationMethodId}

Weitere Informationen:

Löschen Sie Geräte, die von dem/den identifizierten Benutzer(n) angemeldet wurden. Verwenden Sie die folgenden Graph API-Anfragen:

DELETE /devices/{id}
DELETE /devices(deviceId='{deviceId}')

Daten, auf die ein Angreifer Zugriff hat, enthalten mehr Anmeldeinformationen

Wenn Sie Microsoft Purview aktiviert haben, scannen Sie Ihre Umgebung. Verwenden Sie die Entitätsdefinition Alle Anmeldeinformationen mit den kompromittierten Konten. Verschieben Sie die identifizierten Berechtigungsnachweise wie im folgenden Abschnitt über die Verschiebung von Berechtigungsnachweisen beschrieben.

Weitere Informationen:

Löschen und wechseln Sie durchgesickerte Geheimnisse

Wechseln Sie die Geheiminformationen, die mit den identifizierten Benutzer- oder Gerätedaten verbunden sind.

  • Setzen Sie im Azure-Portal für die Cloud-Konten die Kontopasswörter zurück.
  • Bei hybriden Konten setzen Sie das Kennwort des Benutzers zweimal zurück, wie unter Entzug des Benutzerzugangs in Microsoft Entra ID beschrieben.
  • Überprüfen Sie im Microsoft Entra-Benutzerkonto, ob Geräte und MFA unter der Kontrolle des Benutzers stehen:
    • Deaktivieren oder Löschen unbekannter Geräte
    • Bevor Sie das Benutzerkonto wieder aktivieren, löschen Sie unbekannte MFA-Optionen
  • Lassen Sie die hartkodierten oder Klartext-Anmeldedaten in Ihren Code-Repositories verfallen:
    • Prüfen Sie die durchgesickerten Zugangsdaten. Die Erkennung von Workload-Identitätsrisiken beschreibt, wie Sie Anwendungen und Dienstprinzipale schützen können.
    • Führen Sie eine Überprüfung der Anmeldeinformationen durch Credential Scanning beschreibt, wie Sie ein Projekt automatisch überprüfen können, um sicherzustellen, dass keine Secrets im Quellcode des Projekts enthalten sind.
  • Löschen Sie hinzugefügte oder geänderte Posteingangsregeln im Microsoft 365-Portal:

Sichere Identitäten in Ihrer Umgebung

Die folgenden Artikel enthalten weitere Informationen zur Sicherung von Identitäten.

Ursache für Token-Diebstahl

Manchmal ist es nicht möglich, die eigentliche Ursache zu finden. Wir empfehlen Ihnen, die Untersuchung abzuschließen, um die Details herauszufinden, die die Ursache aufzeigen können. Nach der Wiederherstellung können Sie weitere Untersuchungsschritte durchführen, um die Ursache zu ermitteln.

Untersuchung von bösartigen E-Mails, die in Microsoft 365 zugestellt wurden beschreibt, wie Sie verdächtige E-Mail-Nachrichten finden und untersuchen können.

Nächste Schritte

*Token-Diebstahl Workflow Entscheidungs-Verzeichnis