Diese Woche hatte ich einen Fall, den vermutlich jeder kennt, der M365-Umgebungen betreut: Ein Mitarbeiter bekommt eine Mail im Stil von „Es wurde ein Dokument mit Ihnen geteilt“, klickt auf den SharePoint-Button, landet auf einer sauber nachgebauten Anmeldeseite und tippt brav seine Zugangsdaten ein. Wenige Minuten später ist das Konto in fremder Hand.
Der erste Reflex ist meistens richtig – und trotzdem der Punkt, an dem die meisten aufhören: Passwort ändern. Notwendig, aber allein nutzlos, sobald der Angreifer sich in der Zwischenzeit schon angemeldet hat. Warum das so ist und wie ein belastbares Vorgehen aussieht, hier der Reihe nach.
Warum das neue Passwort nicht ausreicht
Wenn sich der Angreifer einmal erfolgreich angemeldet hat, besitzt er ein Refresh-Token. Damit lässt sich der Zugriff verlängern, ohne dass das Passwort noch einmal abgefragt wird. Du kannst also das Kennwort dreimal ändern – die bestehende Session des Angreifers läuft munter weiter. Deshalb gehört das Invalidieren aller aktiven Sitzungen zum Pflichtprogramm, in der Regel per PowerShell:
Revoke-MgUserSignInSession -UserId benutzer@kundendomain.deErst danach ist der Zugang tatsächlich zu. Alternativ geht das auch im Entra-Portal über „Sitzungen widerrufen“ am Benutzer.
1. Eindämmen (bevor du analysierst)
In dieser Reihenfolge, weil jede Minute mehr Zugriff mehr möglichen Schaden bedeutet:
- Passwort zurücksetzen
- Alle Sitzungen/Token widerrufen (siehe oben)
- MFA erzwingen bzw. neu registrieren
- Konto im Zweifel kurz blockieren, solange du noch nicht weißt, was passiert ist
2. Herausfinden, was wirklich passiert ist
Das ist der Teil, den man sich nicht schenken darf – vor allem, wenn man dem Kunden später sagen will, ob Daten abgeflossen sind. Die wichtigsten Anlaufstellen:
Anmeldeprotokolle (Entra ID): Fremde IP-Adressen, ungewöhnliche Standorte, „unmögliche Reisen“, erfolgreiche Fremd-Logins im Zeitfenster zwischen Eingabe und Kennwortänderung.
Unified Audit Log / Purview: Zugriffe auf Postfach, OneDrive, SharePoint. Hier siehst du, ob und worauf tatsächlich zugegriffen wurde.
Postfach- und Posteingangsregeln: Der absolute Klassiker. Angreifer legen gern eine Regel an, die Antworten des echten Nutzers direkt in den Papierkorb oder einen unauffälligen Ordner verschiebt oder alles nach extern weiterleitet. Unbedingt prüfen und entfernen.
OAuth-App-Berechtigungen (Enterprise Applications): Der fiese Fall. Wurde eine bösartige App autorisiert, hilft weder Passwortwechsel noch Session-Revoke – die App behält ihren Zugriff. Erteilte Consents durchgehen und Verdächtiges entziehen.
Gesendet-Ordner und Message Trace: Wurden vom gekaperten Konto Mails an die Kontaktliste verschickt? Bei der SharePoint-Masche fast immer, weil sich der Angriff so weiterträgt. Das ist meist auch der Grund, warum die Kontakte des Kunden aktiv gewarnt werden müssen.
3. Aufräumen
Was du in Schritt 2 gefunden hast, wird jetzt beseitigt: Regeln löschen, OAuth-Consents widerrufen, Weiterleitungen deaktivieren, Legacy-Authentifizierung prüfen. Dann noch einmal gegenprüfen, dass nichts zurückkommt.
4. Der rechtliche Teil – nicht optional
Sobald personenbezogene Daten Dritter betroffen sein könnten, ist man schnell im Anwendungsbereich der DSGVO. Art. 33 kennt eine 72-Stunden-Meldefrist an die zuständige Aufsichtsbehörde. Ob eine Meldung nötig ist, entscheidet nicht das Bauchgefühl, sondern die Prüfung aus Schritt 2 – und im Zweifel der Datenschutzbeauftragte oder eine Rechtsberatung. Auch wenn man zu dem Schluss kommt, dass keine Meldung nötig ist, sollte man diese Entscheidung dokumentieren. (Das hier ist keine Rechtsberatung, sondern der Hinweis, dass man das aktiv klären muss.)
5. Kommunizieren
Weil die Phishing-Mail in aller Regel vom gekaperten Konto weiterversendet wurde, sollten die Kontakte des Kunden gewarnt werden. Wichtig: ehrlich und belastbar formulieren. Ein pauschales „Es sind keine Daten abgeflossen“ darf nur drinstehen, wenn die Protokolle das auch hergeben. Sonst lieber „nach aktuellem Kenntnisstand keine Anhaltspunkte für unbefugten Zugriff“ – das ist verteidigungsfähig, das andere ist eine Behauptung, die einem später um die Ohren fliegen kann.
6. Danach: absichern, damit es nicht wieder passiert
Ein Vorfall ohne gezogene Konsequenzen ist ein halber Vorfall. Was hilft:
- Phishing-resistente MFA (FIDO2 / Passkeys) statt SMS oder simpler App-Bestätigung. Genau die klassische MFA-Bestätigung lässt sich nämlich mit modernen Phishing-Kits durchreichen.
- Conditional Access: Zugriff auf bekannte Länder, konforme Geräte und definierte Bedingungen eingrenzen.
- Legacy-Authentifizierung abschalten, wo es geht.
- Alarmierung auf neu angelegte Postfachregeln und auffällige Anmeldungen.
- Awareness: Der Mitarbeiter, der geklickt hat, ist nicht das Problem – die fehlende zweite Sicherheitsebene ist es. Schulung hilft, aber Technik, die den Fehler abfängt, hilft mehr.
Fazit
Ein gephishtes M365-Konto ist kein Weltuntergang, aber „Passwort neu, fertig“ ist gefährlich unvollständig. Sitzungen widerrufen, sauber analysieren, aufräumen, die rechtliche Seite klären und ehrlich kommunizieren – in dieser Reihenfolge. Wer die Analyse überspringt, kann dem Kunden am Ende schlicht nicht sagen, ob wirklich nichts passiert ist. Und genau diese Frage wird er stellen.