BEC-Untersuchung in Microsoft 365: Leitfaden für die Praxis
So untersuchen Sie Business E-Mail Compromise in Microsoft 365: welche Protokolle, worauf Sie achten und wie Sie Aktionen der Sitzung des Angreifers zuordnen.
Kurz gesagt. Ein Business E-Mail Compromise (BEC, also die Kompromittierung geschäftlicher E-Mail-Konten) in Microsoft 365 wird anhand von drei Exporten untersucht: dem Unified Audit Log aus Purview (was im Postfach und in den Dateien geschah), den Anmeldeprotokollen von Entra ID, interaktiv und nicht interaktiv (wer sich wann, von wo und mit welcher Sitzung angemeldet hat), und den Überwachungsprotokollen von Entra ID (MFA-Methoden, App-Zustimmungen, Rollen). Die Methode ist immer dieselbe: die Anmeldung des Angreifers finden, über dessen IP, Session ID und Token pivotieren, alle Aktionen mit diesen Kennungen auflisten und dann jeden Persistenzmechanismus prüfen, den er hinterlassen haben kann. Ein reines Zurücksetzen des Passworts behebt nichts davon.
BEC ist kein Randproblem. Der IC3-Bericht 2024 des FBI zählt 21.442 BEC-Anzeigen und rund 2,77 Mrd. US-Dollar gemeldete Verluste allein in diesem Jahr. In Microsoft-365-Tenants ist das Muster, das ich am häufigsten sehe, völlig unspektakulär: Jemand gibt sein Passwort auf einer überzeugenden Anmeldeseite ein, wenige Minuten später verschiebt eine Posteingangsregel namens „.“ Rechnungen in den Ordner RSS Feeds, und eine Woche danach „ändert“ sich die Bankverbindung eines Lieferanten (klassischer Rechnungsbetrug, verwandt mit dem CEO-Fraud). Alles, was man zur Rekonstruktion dieser Kette braucht, steht in Protokollen, die der Tenant bereits hat, sofern sie exportiert werden, bevor die Aufbewahrungsfrist abläuft.
Wie ein BEC in den Protokollen aussieht
| Phase | Was der Angreifer tut | Wo es auftaucht | Wichtige Felder / Vorgänge |
|---|---|---|---|
| Erstzugriff | Password Spraying, Adversary-in-the-Middle-Phishing, Gerätecode-Phishing | Entra-Anmeldeprotokolle | IP-Adresse, ASN, Authentication Protocol, Fehlercodes 50126 / 50074 |
| Sitzungsdiebstahl | Spielt das gestohlene Cookie oder Aktualisierungstoken aus dem eigenen Netz ab | Nicht interaktive Entra-Anmeldungen | Gleiche Session ID, neue IP / neues Land |
| Persistenz | Registriert eine MFA-Methode, stimmt einer OAuth-App zu, fügt App-Geheimnisse hinzu | Entra-Überwachung (auch im UAL, Workload AzureActiveDirectory) | User registered security info, Consent to application, Add service principal credentials |
| Verschleierung | Regeln, die Antworten löschen oder verschieben, Postfachweiterleitung | Unified Audit Log | New-InboxRule, Set-InboxRule, UpdateInboxRules, Set-Mailbox |
| Sammlung | Liest und synchronisiert E-Mails, sucht nach „Rechnung“, lädt Dateien herunter | Unified Audit Log | MailItemsAccessed, SearchQueryInitiatedExchange, FileDownloaded |
| Betrug und Spurenbeseitigung | Versendet die gefälschte Bankverbindung und löscht sie | Unified Audit Log | Send, SoftDelete, HardDelete, MoveToDeletedItems |
MITRE ATT&CK benennt die meisten davon: Email Hiding Rules (T1564.008), Email Forwarding Rule (T1114.003), Web Session Cookie (T1550.004), Steal Application Access Token (T1528).
Schritt 1: sichern, bevor die Aufbewahrung Beweise löscht
Die Aufbewahrung ist die erste Einschränkung, nicht die letzte. Entra ID speichert Anmelde- und Überwachungsprotokolle 7 Tage in der kostenlosen Edition und 30 Tage mit P1/P2. Das Unified Audit Log bewahrt mit Audit (Standard) standardmäßig 180 Tage auf. Wurde der Vorfall drei Wochen zu spät gemeldet, sind in einem kleinen Tenant die Anmeldungen, die ihn erklären, womöglich schon weg.
Exportieren Sie am ersten Tag:
- Das Unified Audit Log für den gesamten Tenant (nicht nur für das Opfer), ab mindestens 30 Tage vor der ersten verdächtigen E-Mail.
- Die interaktiven und nicht interaktiven Benutzeranmeldungen aus dem Entra Admin Center. Token-Replay erscheint nur in der nicht interaktiven Datei.
- Das Entra-Überwachungsprotokoll, möglichst als JSON: Die CSV enthält nur eine begrenzte Zahl an Zielen und geänderten Eigenschaften.
Die Schritt-für-Schritt-Anleitung mit Zeilenlimits und PowerShell-Paging steht unter Unified Audit Log und Entra-Anmeldeprotokolle exportieren. Lassen Sie die Originaldateien unverändert und berechnen Sie Hashwerte: Man wird Sie fragen, was Sie analysiert haben.
Schritt 2: die Anmeldung des Angreifers finden
Gehen Sie von dem aus, was Sie wissen (eine gemeldete E-Mail, eine betrügerische Zahlung, ein Benutzer, der „das nicht war“), und arbeiten Sie sich zur Anmeldung zurück. Suchen Sie in den Anmeldeprotokollen nach:
- Erfolgreichen Anmeldungen aus Hosting- oder VPN-Netzen (Cloud-Anbieter, VPS). AiTM-Kits und Angreifer arbeiten selten über einen privaten Internetanschluss.
- Einer Session ID aus zwei Netzen. Die interaktive Anmeldung kommt vom Phishing-Proxy, die nicht interaktiven Anmeldungen derselben Sitzung dann von woanders. Das ist der verlässlichste Replay-Indikator; siehe AiTM-Phishing und Token-Replay erkennen.
- Fehlschlag-Serien: Password Spraying (eine IP, viele Konten, Fehler 50126) oder wiederholt abgelehnte MFA-Anfragen mit anschließendem Erfolg.
- Anmeldungen per Gerätecode oder über Legacy-Protokolle bei Benutzern, die so etwas nie verwenden.
- Unmögliche Reisen, mit Vorsicht: VPNs und Mobilfunknetze erzeugen viele Fehlalarme. Die Analyse der Entra-ID-Anmeldeprotokolle zeigt, wie man sie auseinanderhält.
Notieren Sie für jede verdächtige Anmeldung: Uhrzeit (UTC), IP, ASN, Land, User-Agent, Anwendung, Session ID und Unique token identifier.
Schritt 3: von der Sitzung zu den Aktionen pivotieren
Hier wird aus einem Verdacht ein Beweis. Microsoft überträgt die Kennungen der Anmeldung in die Workload-Protokolle: Im Unified Audit Log enthalten Exchange- und SharePoint-Einträge AppAccessContext.AADSessionId und AppAccessContext.UniqueTokenId (Exchange zusätzlich SessionId). Microsoft nennt sie verknüpfbare Kennungen und dokumentiert die Zuordnung auf Microsoft Learn.
Filtern Sie das UAL nach diesen Werten und nach den IPs des Angreifers, und Sie erhalten die Aktionen des Angreifers selbst, getrennt von der normalen Aktivität des Benutzers im selben Postfach. Lesen Sie sie dann der Reihe nach: Posteingangsregeln, Weiterleitung, MFA-Änderungen, Zustimmungen, Suchen, Lesezugriffe, Downloads, Sendungen, Löschungen. Der Beitrag zur Untersuchung des Unified Audit Log listet die Vorgänge und die jeweils relevanten AuditData-Felder.
Zwei Einschränkungen. Nicht jeder Eintrag trägt eine Sitzungskennung (manche aggregierten oder Hintergrundeinträge nicht), behalten Sie also den IP-Pivot als Rückfallebene. Und ein reiner IP-Pivot kann in die Irre führen, wenn der Angreifer einen gemeinsam genutzten VPN-Ausgang verwendet, den auch ein legitimer Benutzer nutzt; die Sitzungsübereinstimmung ist belastbarer.
Schritt 4: jeden Persistenzmechanismus prüfen
Angreifer rechnen mit einem Passwort-Reset. Was ihn übersteht:
| Persistenz | Nachweis | Warum ein Reset nicht hilft |
|---|---|---|
| Gestohlene Sitzung / Aktualisierungstoken | Nicht interaktive Anmeldungen von der IP des Angreifers nach dem Reset | Token bleiben gültig, bis sie widerrufen werden oder ablaufen |
| Posteingangsregel mit Weiterleitung nach außen | New-InboxRule mit ForwardTo / RedirectTo | E-Mails fließen weiter ab, ohne Anmeldung |
| Postfachweiterleitung | Set-Mailbox mit ForwardingSmtpAddress | Ebenso |
| OAuth-Zustimmung | Consent to application, Add delegated permission grant | Die App besitzt eigene Token (unrechtmäßige Einwilligungserteilung) |
| MFA-Methode des Angreifers | User registered security info | Der Angreifer besteht die MFA mit dem eigenen Gerät |
| Postfachdelegierung | Add-MailboxPermission, Add-RecipientPermission | Zugriff über ein anderes Konto |
| Privilegierte Rolle, App-Geheimnis, Verbund | Add member to role, Add service principal credentials, Set domain authentication | Zugriff auf Tenant-Ebene, unabhängig vom Benutzer |
Der Beitrag Bösartige Posteingangsregeln und Weiterleitungen vertieft den häufigsten Fall.
Schritt 5: eingrenzen, was gelesen und gesendet wurde
Die Geschäftsleitung wird zwei Fragen stellen: Was haben sie gelesen? und wem haben sie geschrieben? Die erste beantwortet MailItemsAccessed: Bind-Einträge nennen einzelne Nachrichten per InternetMessageId; Sync-Einträge bedeuten, dass ein Client einen ganzen Ordner heruntergeladen hat, der dann als offengelegt gilt. Die zweite beantworten Send-Einträge aus der Sitzung des Angreifers, die Nachrichtenablaufverfolgung sowie die Ordner „Gesendete Elemente“ und „Wiederherstellbare Elemente“ des Opfers. Stichwortsuchen (SearchQueryInitiatedExchange) zeigen, wonach der Angreifer suchte, aber nur, wenn diese Protokollierung aktiviert ist, was laut dem CISA-Leitfaden zu den erweiterten Cloud-Protokollen standardmäßig nicht der Fall ist.
Schritt 6: Zeitleiste und Urteil erstellen
Ein guter BEC-Bericht enthält eine einzige Zeitleiste in UTC, von der ersten Anmeldung des Angreifers bis zur Eindämmung, in der jede Zeile ihren Protokolleintrag zitiert. Er nennt das Urteil mit Begründung („kompromittiert: Posteingangsregel mit externer Weiterleitung, erstellt aus einer Sitzung, die aus einem anderen Land wiederverwendet wurde“), was offengelegt wurde und was nicht geprüft werden konnte. Die Lücken zählen so viel wie die Befunde: keine nicht interaktiven Anmeldungen, kein MailItemsAccessed, 7 Tage Aufbewahrung der Anmeldungen. Der Beitrag Aufbewahrung und fehlende Protokolle listet die üblichen auf.
Ohne SIEM vorgehen
Viele BEC-Untersuchungen betreffen kleine Tenants ohne Sentinel-Arbeitsbereich und ohne Budget, mit Exporten, die in keine Tabellenkalkulation passen. M365 Forensics führt die obigen Schritte im Browser aus: Legen Sie die UAL-CSV und die Entra-Exporte ab, und das Tool liest beide Ebenen des UAL (CSV-Spalten und AuditData-JSON), verknüpft Postfachaktionen mit verdächtigen Anmeldesitzungen und liefert ein Urteil (keine Anzeichen einer Kompromittierung, verdächtige Aktivität oder Kompromittierung wahrscheinlich) mit den Belegzeilen, einer Vorfall-Zeitleiste und einer Behebungsliste. Nichts wird hochgeladen; der Analysator ist WebAssembly, das auf Ihrem Rechner läuft. Die Schritt-für-Schritt-Anleitung zeigt jede Ansicht, und der kommentierte fiktive Vorfall zeigt, wie sich ein realistisches Ergebnis liest.
Es ersetzt nicht das eigene Urteil. Heuristiken weisen den Weg, sie beweisen nichts: Eine Anmeldung aus einem Hosting-Netz kann Ihr eigenes VPN sein, und eine Weiterleitungsregel kann legitim sein. Klären Sie es mit der Kontoinhaberin oder dem Kontoinhaber.
Nach der Untersuchung
Lautet das Urteil „kompromittiert“, kommt die Eindämmung zuerst: Sitzungen widerrufen, Persistenz entfernen, Zahlungen stoppen. Die Reihenfolge ist wichtig und in Die erste Stunde nach einem BEC beschrieben. Microsofts eigene Empfehlungen finden Sie unter Reagieren auf ein kompromittiertes E-Mail-Konto und in den Playbooks für die Reaktion auf Vorfälle.
Häufige Fragen
Welche Protokolle brauche ich, um einen BEC in Microsoft 365 zu untersuchen?
Drei Quellen: das Unified Audit Log aus Purview für Aktionen in Postfächern, Dateien und Verwaltung; die Anmeldeprotokolle von Entra ID (interaktiv und nicht interaktiv) dafür, wer sich von wo angemeldet hat; und die Überwachungsprotokolle von Entra ID für MFA-Methoden, App-Zustimmungen, Rollen und Verbundänderungen.
Beendet ein Zurücksetzen des Passworts einen BEC?
Nein. Gestohlene Sitzungscookies und Aktualisierungstoken, OAuth-Zustimmungen, Posteingangsregeln, Postfachweiterleitungen und vom Angreifer registrierte MFA-Methoden überstehen eine Passwortänderung. Widerrufen Sie die Sitzungen und entfernen Sie jedes Persistenzelement.
Wie weit sollte die Untersuchung zurückreichen?
Mindestens 30 Tage vor der ersten verdächtigen E-Mail, und weiter, wenn die Protokolle es erlauben. Angreifer melden sich oft Tage oder Wochen vor der eigentlichen Tat an, und das Phishing, mit dem die Sitzung gestohlen wurde, liegt meist deutlich vor dem Betrug.
Weiterführende Links
- Microsoft Learn: Reagieren auf ein kompromittiertes E-Mail-Konto
- Microsoft-Security-Blog: From cookie theft to BEC (englisch)
- Glossar: Business E-Mail Compromise, Unified Audit Log, Token-Replay
- Derselbe Ansatz für andere Identitätsanbieter: Protokollforensik für Google Workspace und Okta.