Ein AiTM-kompromittiertes Microsoft-365-Konto bereinigen

MFA ist aktiv, das Passwort wurde nirgends eingetippt, wo es nicht hingehört – und trotzdem liest jemand das Postfach der Geschäftsleitung. So sieht ein Adversary-in-the-Middle-Angriff (AiTM) von innen aus. Dieser Artikel ist die Checkliste, die ich mir beim ersten Mal gewünscht hätte: wie der Angriff funktioniert, was Angreifer in Microsoft 365 zurücklassen, in welcher Reihenfolge man aufräumt und was man danach härtet.

#So funktioniert AiTM – in einem Absatz

Das Opfer klickt auf einen Link und landet auf einer Seite, die aussieht wie das Microsoft-Login – weil sie das Microsoft-Login ist, durchgereicht über den Proxy des Angreifers. Das Opfer gibt das Passwort ein, bestätigt die MFA-Anfrage, alles funktioniert wie gewohnt. Der Proxy in der Mitte kopiert dabei das Session-Cookie, das Microsoft nach der erfolgreichen Anmeldung ausstellt. Mit diesem Cookie ist der Angreifer als Opfer angemeldet, von überall, ohne Passwort und ohne erneute MFA.

Für die Bereinigung sind zwei Folgen wichtig:

1. Ein Passwort-Reset beendet die Session nicht. Bestehende Tokens bleiben gültig, bis sie widerrufen werden oder ablaufen.
2. Der Angreifer weiss, dass sein Zugang nur vorübergehend ist. Das Erste, was ein kompetenter Angreifer tut, ist den Zugang dauerhaft zu machen – und genau dort liegt die Aufräumarbeit.

#Was Angreifer zurücklassen

In jedem AiTM-Fall, den ich gesehen oder nachgelesen habe, kam die Persistenz aus derselben kurzen Liste. Prüft alles, nicht nur den ersten Fund:

Die Posteingangsregeln sind das typische Erkennungsmerkmal. Klassische Muster: Alles mit «Rechnung», «Zahlung» oder der Domain des Angreifers wird nach RSS-Feeds oder Unterhaltungsverlauf verschoben und als gelesen markiert.

#Die Bereinigung in der richtigen Reihenfolge

Die Reihenfolge ist entscheidend. Wer zuerst das Passwort zurücksetzt, lässt dem Angreifer die Session – und der registriert eine weitere MFA-Methode, während man noch untersucht. Wer die Persistenz entfernt, aber die Session leben lässt, sieht sie gleich wieder auftauchen.

#1. Eindämmen: Anmeldung sperren und Sessions widerrufen

Konto deaktivieren und alle Refresh-Tokens widerrufen. Das zuerst, noch bevor das ganze Bild klar ist. Der betroffenen Person erklären, warum ihr Konto eine Stunde lang gesperrt ist.

Connect-MgGraph -Scopes "User.ReadWrite.All","UserAuthenticationMethod.ReadWrite.All","Directory.AccessAsUser.All"
$upn = "opfer@example.com"

Update-MgUser -UserId $upn -AccountEnabled:$false
Revoke-MgUserSignInSession -UserId $upn

Bereits ausgestellte Access-Tokens können bis zu einer Stunde gültig bleiben. Continuous Access Evaluation verkürzt das für viele Dienste – geplant wird trotzdem mit der Stunde.

#2. Untersuchen: die Zeitachse rekonstruieren

Bevor etwas gelöscht wird: exportieren. Die Nachweise braucht es für den Vorfallbericht und womöglich für den Datenschutzbeauftragten.

• Anmeldeprotokolle, interaktiv und nicht-interaktiv. Token-Replay zeigt sich meist in den nicht-interaktiven Anmeldungen: gleicher Benutzer, neue IP, meist ein Hosting- oder Cloud-Anbieter, oft ein anderes Land, kein MFA-Schritt, weil das Token ihn schon enthält.
• Überwachungsprotokoll für geänderte Authentifizierungsmethoden, Geräteregistrierungen, erteilte Zustimmungen.
• Einheitliches Überwachungsprotokoll (Unified Audit Log) für Postfachaktivität: neue Regeln, gesendete Mails, geöffnete Elemente.

Wer die Entra-Logs nach Log Analytics schickt, findet den Replay so schnell:

AADNonInteractiveUserSignInLogs
| where UserPrincipalName == "opfer@example.com"
| where TimeGenerated > ago(14d)
| summarize first=min(TimeGenerated), last=max(TimeGenerated), count()
    by IPAddress, AutonomousSystemNumber, Location, AppDisplayName
| order by first asc

Eine unbekannte ASN, die kurz nach dem Eintreffen der Phishing-Mail auftaucht, ist euer Angreifer.

#3. Persistenz entfernen

# Authentifizierungsmethoden – mit dem vergleichen, was die Person selbst eingerichtet hat
Get-MgUserAuthenticationMethod -UserId $upn |
  Select-Object Id, @{n='Type';e={$_.AdditionalProperties['@odata.type']}}

# Unbekannte OATH-Tokens / Authenticator / WHfB-Schlüssel entfernen, z.B.:
Remove-MgUserAuthenticationSoftwareOathMethod -UserId $upn -SoftwareOathAuthenticationMethodId <id>
Remove-MgUserAuthenticationMicrosoftAuthenticatorMethod -UserId $upn -MicrosoftAuthenticatorAuthenticationMethodId <id>
Remove-MgUserAuthenticationWindowsHelloForBusinessMethod -UserId $upn -WindowsHelloForBusinessAuthenticationMethodId <id>

# Vom Benutzer registrierte Geräte – Unbekanntes deaktivieren
Get-MgUserRegisteredDevice -UserId $upn
Update-MgDevice -DeviceId <objectId> -AccountEnabled:$false

# Vom Benutzer erteilte OAuth-Zustimmungen
Get-MgUserOauth2PermissionGrant -UserId $upn

Und in Exchange Online:

Connect-ExchangeOnline
Get-InboxRule -Mailbox $upn |
  Format-List Name, Enabled, From, SubjectContainsWords, MoveToFolder, MarkAsRead, DeleteMessage, ForwardTo, RedirectTo
Remove-InboxRule -Mailbox $upn -Identity "<Regelname>"

Get-Mailbox $upn | Format-List ForwardingAddress, ForwardingSmtpAddress, DeliverToMailboxAndForward
Set-Mailbox $upn -ForwardingSmtpAddress $null -ForwardingAddress $null

Ausserdem die gesendeten Elemente und eine Nachrichtenablaufverfolgung prüfen: Welche Mails hat der Angreifer vom Konto aus verschickt? Diese Empfänger – oft Kunden und Partner – brauchen eine Warnung von euch, bevor sie klicken.

#4. Zurücksetzen, freischalten, nochmals widerrufen

Passwort zurücksetzen, MFA im Beisein (oder mit einem Temporary Access Pass) neu registrieren lassen, Konto freischalten und die Sessions ein zweites Mal widerrufen. Der zweite Widerruf erwischt, was dazwischen durchgerutscht ist.

#5. Eine Woche beobachten

Anmeldungen des Kontos und die IP-Bereiche des Angreifers im ganzen Tenant im Auge behalten. Die Phishing-Domain in der Mandanten-Zulassungs-/Sperrliste blockieren. Wenn der Angreifer Mails verschickt hat: prüfen, ob sich Empfänger melden.

#Umfang: War es wirklich nur ein Konto?

Die Frage, die die Geschäftsleitung zuerst stellt. Mit Daten beantworten, nicht mit Hoffnung:

• Anmeldeprotokolle des ganzen Tenants nach den IPs und der ASN des Angreifers durchsuchen.
• Die Phishing-Mail (Betreff, Absender, URL) in allen Postfächern suchen – wer hat sie noch bekommen, wer hat geklickt?
• Prüfen, welche Rollen das kompromittierte Konto hatte. Das ist der unangenehme Teil: Hatte das Konto ständige Global-Admin-Rechte, ist der ganze Tenant betroffen, nicht ein Postfach.
• Prüfen, was das Konto ausserhalb von M365 erreicht: VPN, VDI, Kundenumgebungen, Finanztools mit SSO.

#Der Schweizer Datenschutz-Aspekt

Nach dem revidierten Datenschutzgesetz (nDSG) muss eine Verletzung der Datensicherheit, die voraussichtlich zu einem hohen Risiko für die Persönlichkeit oder die Grundrechte der Betroffenen führt, dem EDÖB «so rasch als möglich» gemeldet werden (Art. 24). Ein Postfach voller Kundenkorrespondenz kann das schnell erfüllen. Zwei praktische Tipps:

• Entscheiden und dokumentieren. Ein kurzes Entscheidungspapier: Welche Daten waren zugänglich, worauf wurde tatsächlich zugegriffen (das Audit-Log zeigt es), wie wird das Risiko eingeschätzt, und wird gemeldet oder nicht. Wer nicht meldet, belegt mit diesem Papier, dass die Frage geprüft wurde.
• Kunden separat betrachten. Auch ohne Meldepflicht verdienen Kunden, deren Daten im Postfach lagen – oder die Phishing von euch bekommen haben –, einen Hinweis. Den Text früh vorbereiten, auch wenn er am Ende nicht verschickt wird.

#Härtung danach

Was den Angriff verhindert oder eingedämmt hätte, ungefähr nach Aufwand sortiert:

1. Keine ständigen Admin-Rechte. Global Admin nur über Just-in-Time-Aktivierung (PIM) oder separate Cloud-only-Admin-Konten. Diese eine Änderung macht aus einer Tenant-Kompromittierung eine Postfach-Kompromittierung.
2. Phishing-resistente MFA zuerst für Admins und Geschäftsleitung: Passkeys / FIDO2 oder Windows Hello. Sie sind an die echte Domain gebunden, ein AiTM-Proxy kann sie nicht durchreichen.
3. Conditional Access: Anmeldungen aus Ländern blockieren, in denen ihr nicht arbeitet; konforme Geräte für Admin-Portale verlangen; Legacy-Authentifizierung blockieren.
4. Registrierung von MFA-Methoden einschränken auf vertrauenswürdige Standorte oder konforme Geräte, damit ein Angreifer nicht von einem Hosting-Anbieter aus seinen eigenen Authenticator hinzufügen kann.
5. Benutzerzustimmung aus, Admin-Zustimmungsworkflow ein.
6. Alarme für neue Posteingangsregeln mit Weiterleitung oder Verschieben nach RSS, für neue Authentifizierungsmethoden und für Anmeldungen privilegierter Konten aus neuen ASNs.
7. Awareness, die Melden belohnt. Der schnellste Detektor ist meiner Erfahrung nach kein Tool, sondern eine Kollegin, die sagt «diese Anmeldeseite sah komisch aus» – und keine Angst hat, es zu sagen.

#Die Kurzfassung

1. Konto sperren und Sessions widerrufen.
2. Logs exportieren, Zeitachse rekonstruieren.
3. MFA-Methoden, Geräte, Zustimmungen, Posteingangsregeln und Weiterleitungen entfernen.
4. Empfänger warnen, an die der Angreifer Mails geschickt hat.
5. Passwort zurücksetzen, MFA neu registrieren, freischalten, nochmals widerrufen.
6. Umfang im ganzen Tenant klären.
7. Die Datenschutzfrage entscheiden und dokumentieren.
8. Die Ursache beheben: ständige Admin-Rechte und phishbare MFA.