E-Mail-Konto gehackt: Warum das neue Passwort den Angreifer nicht aussperrt

Mike Kuketz hat am 11. Oktober 2026 von einem Fall aus seinem Umfeld berichtet. Über die Adresse eines Bekannten ging eine dringende Zahlungsanfrage an seine Schwester: er stecke im Ausland fest und brauche 850 Euro. Er reagierte schnell, änderte das Passwort, beendete die angezeigten Sitzungen, schaltete Zwei-Faktor-Authentifizierung ein und ließ einen Virenscanner laufen. Als Kuketz am nächsten Abend die Einstellungen ansah, fanden sich unter den Weiterleitungen eine aktive Adresse bei einem Anbieter, von dem der Besitzer nie gehört hatte, und eine Filterregel, die Nachrichten mit den Wörtern Sicherheitswarnung, Anmeldung und Bestätigungscode ins Archiv schob. Geändert war das Passwort, das Postfach lieferte dem Angreifer weiterhin jede neue Nachricht aus.

Der Bericht lohnt die Aufmerksamkeit, weil das Muster in jedem Postfachsystem gleich ist und die Hersteller das selbst dokumentieren. Ein Passwort ist ein Anmeldemittel. Alles, was ein Angreifer als Einstellung im Konto hinterlässt, ist davon unabhängig gespeichert. Unten steht die Checkliste, die Microsoft für den Ernstfall selbst vorgibt.

Was ein Angreifer im Postfach hinterlässt

Die Microsoft-Dokumentation zum Umgang mit übernommenen Mailkonten führt die typischen Anzeichen einer Übernahme auf: eine neu eingerichtete Weiterleitung nach extern, Regeln, die Nachrichten in die Ordner Notes, Junk E-Mail oder RSS Subscriptions wegschieben, täuschend echte Signaturen in gesendeten Nachrichten, veränderte Kontaktdaten im globalen Adressbuch, häufige Passwortwechsel und Kontosperren. Auffällig an dieser Liste ist, dass fast jeder Punkt eine Einstellung ist und keine Anmeldung.

In Objekte übersetzt sind das die Stellen, die bei einer Übernahme kontrolliert werden müssen: Weiterleitungen auf Mailbox-Ebene, Inbox-Regeln, zusätzliche Anmeldemethoden und Wiederherstellungsadressen, app-spezifische Passwörter, OAuth-Berechtigungen erteilter Anwendungen und, auf Identitätsebene, zugewiesene Rollen. Keines dieser Objekte wird durch einen Passwortwechsel gelöscht oder deaktiviert. Sie überleben das Passwort, ohne jede Frist.

Microsoft 365: Der Passwortwechsel ist Schritt eins von vielen

Die Microsoft-Doku für übernommene Mailkonten ist ein Sechs-Schritte-Programm, und seine Botschaft ist eindeutig: Der Passwortwechsel allein genügt nicht. Schritt 1 ist für Microsoft das Deaktivieren des Kontos bis zum Ende der Untersuchung; ist das nicht möglich, kommt der Passwortwechsel. Dann folgen, in der Reihenfolge des Dokuments: Sitzungen widerrufen, Anmeldemethoden auf fremde Geräte prüfen, erteilte Anwendungsberechtigungen prüfen, Rollen entfernen, Weiterleitungen und Inbox-Regeln durchsehen.

Zwei Sätze daraus sollte man kennen. Der erste: App-Passwörter werden beim Zurücksetzen ausdrücklich nicht widerrufen. Das Dokument hält wörtlich fest, dass die Benutzer bestehende App-Passwörter löschen und neue anlegen sollen. Der zweite: Der Widerruf der aktiven Sitzungen ist ein eigener Befehl, in der Graph-PowerShell ein Revoke-MgUserSignInSession pro Benutzer. Wörtlich begründet Microsoft das damit, dass das Widerrufen der Sitzungen die aktive Nutzung der gestohlenen Anmeldedaten sofort unwirksam macht. Ein Passwortwechsel tut das in diesem Sinne nicht.

Für die Sitzungswiderrufung gilt seit einigen Jahren eine Einschränkung, die man kennen muss: Continuous Access Evaluation (CAE) wertet Passwortwechsel und Kontosperrung als kritische Ereignisse und erzwingt den Sitzungswiderruf nahezu in Echtzeit. Das Dokument nennt eine Latenz von bis zu 15 Minuten über die Ereignisweitergabe. Die erste Implementierung von CAE deckt Exchange, Teams und SharePoint Online ab, und auch dort nur, wenn der Client CAE beim Anmelden aushandelt. Für CAE-Sitzungen hebt Microsoft zudem die statische Token-Lebensdauer auf, sie gelten bis zu 28 Stunden. Ein Mailclient, der kein CAE spricht, sitzt nach einem Passwortwechsel also so lange drin, wie sein Token oder Refresh-Token es zulässt. Positiv für den Windows-Alltag: Das Dokument zum Primary Refresh Token hält fest, dass ein per Passwort erhältlicher PRT beim Passwortwechsel ungültig wird. Die Anmeldung am Windows-Gerät stirbt also mit, viele Cloud-Sessions tun das nur, wo CAE greift.

Google Workspace: Passwort und Sitzungen sind zwei getrennte Schritte

Die Admin-Dokumentation für das Zurücksetzen eines Benutzerpassworts besteht aus zwei Stufen: dem Zurücksetzen des Passworts selbst und dem Zurücksetzen der Anmelde-Cookies. Die Cookie-Stufe begründet Google damit, dass der Nutzer oder Gast sich danach nicht mehr mit dem alten Passwort anmelden kann. Erst wenn beides erledigt ist, gilt der Nutzer laut Dokumentation als aus allen aktiven Sitzungen abgemeldet. Wer nur das Passwort ändert, lässt die angemeldeten Sitzungen laufen.

Dafür erneuert Google die passwortgebundenen Zugänge beim Reset mit: App-spezifische Passwörter für Drittanwendungen, dort ASPs genannt, werden nach einem Passwort-Reset alle widerrufen und müssen neu erzeugt werden. Anwendungen, die per OAuth auf das Mailpostfach zugreifen, stoppen den Sync und brauchen ein neues Token. Die Doku verweist dafür auf ein eigenes Verfahren mit dem Namen Automatic OAuth 2.0 token revocation upon password change.

Stalwart: Die Tokens sterben mit dem Passwort, die Skripte nicht

Der Selbstbau-Mailserver Stalwart, den wir betreiben, dokumentiert für OAuth-Tokens beides: Lebensdauern und Widerruf. Die Standardwerte des Anbieters: Access-Token eine Stunde, Refresh-Token 30 Tage, mit einem Erneuerungsfenster von vier Tagen, dazu ID-Token 15 Minuten, Autorisierungscodes 10 Minuten, die Codes im Gerätefluss eine halbe Stunde. Der eigentliche Hebel ist der Refresh-Token, und seine 30 Tage sind die Zahl, um die es geht.

Zum Widerruf sagt die Stalwart-Doku, Stand 3. Oktober 2026, dass Access- und Refresh-Token durch eine Änderung des Kontopassworts widerrufen werden können und dass das jeden zuvor ausgestellten Token ungültig macht. Verfügbar ist das für Kontobesitzer und für Administratoren. So dokumentiert wäre das mehr, als Microsoft und Google beim reinen Passwortwechsel liefern, gemessen ist es für unseren Stand noch nicht. Die Einstellungen betrifft das nicht: Sieve-Skripte für Filter und Umleitungen liegen als Postfachkonfiguration im Konto und werden von einem Passwortwechsel nicht angefasst. Das Muster von Kuketz gilt hier genauso.

Was wir am eigenen Mailhost gemessen haben

Gemessen am 12. Oktober 2026 auf unserem Mailhost: Das Stalwart-Image stalwartlabs/stalwart:v0.16, Stand 0.16.25, Container-Status healthy. Die Frage, ob der dokumentierte Token-Widerruf durch Passwortwechsel auf genau diesem Stand greift, haben wir nicht beantwortet. Der Changelog der letzten 40 Releases, am selben Tag über die GitHub-API gelesen, enthält keinen Eintrag zu diesem Mechanismus, die Doku beschreibt den aktuellen Stand ohne Versionsangabe. Einen echten Übernahmefall simulieren wir auf dem laufenden Mailserver nicht; dafür gehört ein Test-Klon. Bis dahin steht in unserer Checkliste der manuelle Sieve- und Weiterleitungs-Check drin, unabhängig davon, ob die Tokens ohnehin sterben.

Die Checkliste, die Microsoft selbst vorgibt

Wer den Ernstfall proben will, braucht keine eigene Phantasie; die Doku von Microsoft ist die Checkliste. Für ein Microsoft-365-Konto, sinngemäß verdichtet:

1. Konto deaktivieren, bis die Untersuchung durch ist. Der Befehl in der Graph-PowerShell ist Update-MgUser mit AccountEnabled auf false.
2. Passwort zurücksetzen, stark und frisch, nie per Mail an den Nutzer schicken, denn die Mail liest im Zweifel der Angreifer. Bei AD-Synchronisation passiert das im lokalen AD und dort zweimal, das entwertet Pass-the-hash-Reste.
3. Bestehende App-Passwörter löschen, sie werden beim Reset nicht widerrufen.
4. Sitzungen widerrufen mit Revoke-MgUserSignInSession. Das entwertet die Sitzungen und die Refresh-Tokens, der reine Passwortwechsel nicht.
5. Anmeldemethoden und Geräte prüfen, fremde MFA-Methoden entfernen.
6. Erteilte Anwendungsberechtigungen (consents) und zugewiesene Rollen prüfen und entrümpeln.
7. Weiterleitungen und Inbox-Regeln prüfen, Get-Mailbox auf die Forwarding-Eigenschaften und Get-InboxRule -IncludeHidden auf Regeln, die in Outlook sonst unsichtbar bleiben.

Dazu gehören für die Recherche die Anmeldeprotokolle von Entra, das Audit-Protokoll im Defender-Portal mit einem Zeitfenster vor dem ersten Verdacht und der Message-Trace für das, was das Postfach in der Zeit verlassen hat. Ob und welche Nachrichten schon abgeflossen sind, lässt sich aus dem Postfach selbst selten rekonstruieren; ein eigenes Archiv, etwa das GoBD-konforme Mailarchiv, ist die einzige Instanz, die diese Frage sauber beantwortet. Ein abgeflossenes Passwort-Reset-Mail des Kontos bei einem anderen Dienst bedeutet außerdem: Dort kann der Angreifer ebenfalls weitersammeln, solange seine Regeln dort ungestört laufen.

So haben wir gemessen und geprüft

Den Fall von Kuketz haben wir nicht nachgestellt, wir geben ihn nach seinem Bericht wieder. Die Aussagen zu Microsoft, Google und Stalwart stammen aus den Herstellerdokumenten, die wir am 16. Oktober 2026 erneut gelesen haben: sechs Schritte in der Microsoft-Anleitung, 15 Minuten und 28 Stunden in der CAE-Beschreibung, getrennte Schritte für Passwort und Anmelde-Cookies bei Google, Token-Lebensdauern in der Stalwart-Dokumentation. Auf unserem Mailhost haben wir am 12. Oktober Image-Tag und Container-Status gelesen und den Changelog der letzten 40 Releases über die GitHub-API nach einem Eintrag zum Token-Widerruf durchsucht. Eine Übernahme haben wir nicht simuliert. Zu diesem Fall haben wir keine Forendiskussion gefunden.

Weiterführende Quellen

Fall

• Mike Kuketz, E-Mail-Konto gehackt: Das Passwort war geändert, der Angreifer las trotzdem mit, 11.10.2026

Herstellerdokumentation

• Microsoft, Respond to a compromised email account in Microsoft 365
• Microsoft, Continuous access evaluation in Microsoft Entra
• Microsoft, Primary Refresh Token (PRT)
• Google, Reset a user's password
• Stalwart, OAuth-Token-Dokumentation, Stand 03.10.2026

Allgemein

• OWASP, Session Management Cheat Sheet