Identity Incident: eindämmen, Spuren sichern, Zugriff prüfen
Einen möglichen Identitätsvorfall belastbar einordnen.
Der Prüfauftrag
Für autorisierte Reaktion auf einen vermuteten kompromittierten Entra-/Microsoft-365-Benutzer. Maßnahmen mit Vorfallleitung und Betriebsverantwortlichen abstimmen; Beweissicherung und erforderliche Eindämmung parallel planen. Quellenstand: 09.11.2026.
Am Ende hast du:Eine dokumentierte Erstprüfung mit nachvollziehbaren Nachweisen und einer Liste offener Maßnahmen.
Beweisen statt vermuten.
Mit einem ausschließlich dafür bestimmten Testkonto eine Sitzung widerrufen und die Restgültigkeit in der jeweiligen Testanwendung prüfen.
Status, Prüfbereich und Notizen bleiben in diesem Browser. Keine Übertragung an MauriSec. Ohne Speicherung geht der Stand beim Verlassen verloren; gespeicherte Daten bleiben bis zu deiner Löschung. Keine Geheimnisse, Zugangsdaten oder fremden personenbezogenen Daten eintragen.
Betroffenes Konto, Zeitpunkt, Meldeweg und vermutete Folgezugriffe erfassen; Hypothesen von bestätigten Befunden trennen.
So belegst du es: Fall-ID, Zeitleiste, Quellen und dokumentierte Unsicherheiten.
Nachweis und nächsten Schritt notieren
Anmelde-, Audit- und relevante Ressourcenprotokolle rechtzeitig exportieren und nachvollziehbar sichern.
So belegst du es: Zeitfenster, Korrelations-IDs, Exportzeit und geschützter Ablageort.
Nachweis und nächsten Schritt notieren
Konto bei bestätigtem Verdacht möglichst sperren; notwendige Ausnahmen ausdrücklich entscheiden und überwachen.
So belegst du es: Zeitpunkt und Verantwortlichkeit der Eindämmung; dokumentierter Alternativplan bei notwendiger Verfügbarkeit.
Nachweis und nächsten Schritt notieren
Anmeldesitzungen und Refresh-Token widerrufen; Wirksamkeit je betroffener Anwendung überprüfen.
So belegst du es: Ausgeführte Aktion und neue Zugriffsversuche im relevanten Ressourcenprotokoll.
Nachweis und nächsten Schritt notieren
Passwort und registrierte Authentifizierungsmethoden prüfen; kompromittierte Mittel kontrolliert ersetzen.
So belegst du es: Änderungsereignisse und sichere Wiederherstellung mit der betroffenen Person.
Nachweis und nächsten Schritt notieren
Neu erteilte App-Zustimmungen und Anwendungsberechtigungen untersuchen und unzulässige Freigaben entziehen.
So belegst du es: Berechtigungsbestand, Audit-Ereignisse und überprüfter Entzug.
Nachweis und nächsten Schritt notieren
Posteingangsregeln, externe Weiterleitung, Delegierungen und auffällige Mailaktivität auf Persistenz prüfen.
So belegst du es: Vorher-Nachher-Bestand und Begründung für entfernte oder erhaltene Einstellungen.
Nachweis und nächsten Schritt notieren
Anwendungseigene Sitzungen und gegebenenfalls direkt verwaltete Konten zusätzlich beenden beziehungsweise sperren.
So belegst du es: Bestätigung der jeweiligen Anwendungsverantwortlichen und geprüfte Zugriffsverweigerung.
Nachweis und nächsten Schritt notieren
Wiederfreigabe erst nach Ursachenprüfung, notwendiger Bereinigung und dokumentierter Nachkontrolle entscheiden.
So belegst du es: Freigabe, verbleibende Risiken, Überwachungszeitraum und nächste Maßnahmen.
Nachweis und nächsten Schritt notieren
Deine nächste Arbeit.
Beginne mit den vorrangigen Punkten. Markierte Lücken erscheinen hier mit deinen nächsten Schritten.
Grenzen und Primärquellen
Ein Passwortwechsel oder revokeSignInSessions macht nicht jedes bereits ausgegebene Access-Token sofort ungültig. Ohne unterstützte kontinuierliche Zugriffsauswertung oder zusätzliche Ressourcenkontrollen kann Zugriff bis zum Ablauf bestehen. Auch CAE ist ressourcen- und clientabhängig; Ereignisverteilung benötigt Zeit. App-eigene Sitzungen und lokal gespeicherte Daten sind eigenständig zu behandeln. Keine Log-Treffer beweisen keinen ausbleibenden Datenabfluss.
Microsoft Learn: Revoke user access in an emergency ↗Microsoft Learn: Continuous access evaluation ↗Microsoft Learn: Respond to a compromised cloud email account ↗Microsoft Learn: Review application permissions ↗Prüfbericht / Selbsteinschätzung
Identity Incident: eindämmen, Spuren sichern, Zugriff prüfen · v2026.11 · 10.11.2026 ·
0/9 bearbeitet · 0 Lücken. Keine unabhängige Prüfung oder Zertifizierung.
1. Betroffenes Konto, Zeitpunkt, Meldeweg und vermutete Folgezugriffe erfassen; Hypothesen von bestätigten Befunden trennen.
Status: Offen
Erwarteter Nachweis: Fall-ID, Zeitleiste, Quellen und dokumentierte Unsicherheiten.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
2. Anmelde-, Audit- und relevante Ressourcenprotokolle rechtzeitig exportieren und nachvollziehbar sichern.
Status: Offen
Erwarteter Nachweis: Zeitfenster, Korrelations-IDs, Exportzeit und geschützter Ablageort.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
3. Konto bei bestätigtem Verdacht möglichst sperren; notwendige Ausnahmen ausdrücklich entscheiden und überwachen.
Status: Offen
Erwarteter Nachweis: Zeitpunkt und Verantwortlichkeit der Eindämmung; dokumentierter Alternativplan bei notwendiger Verfügbarkeit.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
4. Anmeldesitzungen und Refresh-Token widerrufen; Wirksamkeit je betroffener Anwendung überprüfen.
Status: Offen
Erwarteter Nachweis: Ausgeführte Aktion und neue Zugriffsversuche im relevanten Ressourcenprotokoll.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
5. Passwort und registrierte Authentifizierungsmethoden prüfen; kompromittierte Mittel kontrolliert ersetzen.
Status: Offen
Erwarteter Nachweis: Änderungsereignisse und sichere Wiederherstellung mit der betroffenen Person.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
6. Neu erteilte App-Zustimmungen und Anwendungsberechtigungen untersuchen und unzulässige Freigaben entziehen.
Status: Offen
Erwarteter Nachweis: Berechtigungsbestand, Audit-Ereignisse und überprüfter Entzug.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
7. Posteingangsregeln, externe Weiterleitung, Delegierungen und auffällige Mailaktivität auf Persistenz prüfen.
Status: Offen
Erwarteter Nachweis: Vorher-Nachher-Bestand und Begründung für entfernte oder erhaltene Einstellungen.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
8. Anwendungseigene Sitzungen und gegebenenfalls direkt verwaltete Konten zusätzlich beenden beziehungsweise sperren.
Status: Offen
Erwarteter Nachweis: Bestätigung der jeweiligen Anwendungsverantwortlichen und geprüfte Zugriffsverweigerung.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
9. Wiederfreigabe erst nach Ursachenprüfung, notwendiger Bereinigung und dokumentierter Nachkontrolle entscheiden.
Status: Offen
Erwarteter Nachweis: Freigabe, verbleibende Risiken, Überwachungszeitraum und nächste Maßnahmen.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
Ein Passwortwechsel oder revokeSignInSessions macht nicht jedes bereits ausgegebene Access-Token sofort ungültig. Ohne unterstützte kontinuierliche Zugriffsauswertung oder zusätzliche Ressourcenkontrollen kann Zugriff bis zum Ablauf bestehen. Auch CAE ist ressourcen- und clientabhängig; Ereignisverteilung benötigt Zeit. App-eigene Sitzungen und lokal gespeicherte Daten sind eigenständig zu behandeln. Keine Log-Treffer beweisen keinen ausbleibenden Datenabfluss.