BEC-Beispiel: ein fiktiver Microsoft-365-Vorfall erklärt

Fiktives Szenario. Alles in diesem Beitrag ist erfunden: das Unternehmen Meridian Freight (meridianfreight.example), seine Mitarbeitenden, die IP-Adressen (RFC-5737-Dokumentationsbereiche), die Sitzungen und die E-Mails. Echt sind nur die Protokollformate. Es ist der Datensatz Beispiel ausprobieren von M365 Forensics, Sie können ihn also öffnen und mitlesen.

Kurz gesagt. Ein Password Spraying von einem VPS scheitert. Am nächsten Morgen meldet sich eine Mitarbeiterin der Kreditorenbuchhaltung über einen AiTM-Phishing-Proxy an; sieben Minuten später wird ihre Sitzung aus einem anderen Land wiederverwendet. Innerhalb von 90 Minuten registriert der Angreifer eine Authenticator-App, legt zwei Posteingangsregeln namens „.“ und „..“ an, richtet eine Postfachweiterleitung nach außen ein, synchronisiert rund 450 Nachrichten, sucht nach „facture virement IBAN“, stimmt einer Mail-App zu, lädt 64 Rechnungen herunter und verschickt eine gefälschte Bankverbindung, die er anschließend löscht. Das Tool meldet Kompromittierung wahrscheinlich mit 18 Befunden, drei davon kritisch. Hier sehen Sie, wie jeder Schritt in den Protokollen aussieht und wo die Befunde einen menschlichen Blick brauchen.

Die Eingaben

Vier Dateien in den Formaten der echten Exporte:

Abdeckung: 366 Ereignisse vom 2026-09-14 07:02 bis 2026-09-15 16:33 UTC, mit MailItemsAccessed-Einträgen. Der Datensatz enthält auch normale Aktivität von acht Benutzern (Anmeldungen im Büro, E-Mail-Lesen, Dateizugriffe, eine legitime Posteingangsregel); der Angriff muss also gefunden, nicht nur abgelesen werden.

Die Zeitleiste (UTC)

Der kritische Korrelationsbefund „Aktionen aus der Sitzung oder von der IP des Angreifers“ fasst 103 Ereignisse zusammen: alles von den beiden IPs des Angreifers oder aus der wiederverwendeten Sitzung, einschließlich Regeln, Weiterleitung, MFA-Registrierung, Zustimmung, Lesezugriffen, Downloads, Versand und Löschung. Dieser eine Befund beantwortet die Frage „War sie es oder waren es die anderen?“.

Warum das Urteil „Kompromittierung wahrscheinlich“ lautet

Die Regel: mindestens ein kritischer Befund oder zwei verschiedene hohe Befunde für ein Konto. Hier gibt es drei kritische (externe Weiterleitung per Regel, externe Postfachweiterleitung, Sitzung des Angreifers) und acht hohe Befunde für Claires Konto. Die Begründung unter dem Urteil verlinkt sie.

Wo die Analyse noch mitdenken muss

Ein echter Bericht kopiert nicht einfach die Befunde. Drei Beispiele aus diesem Datensatz:

1. Die unmögliche Reise mischt legitime und bösartige Anmeldungen. Ihre Belege zeigen die Sprünge „FR → NL · 694 km in 29 min“ und „NL → US · 6245 km in 7 min“. Der erste Sprung beginnt bei Claires echter Büroanmeldung; der Angreifer sitzt auf der NL- und der US-Seite. Der Befund zeigt auf das richtige Konto, die Belege müssen aber von Hand getrennt werden. Präzise ist der Sitzungsbefund.
2. Schwellenwert-Befunde enthalten die eigene Aktivität der Benutzerin. Die Befunde zu Postfachvolumen und Massendownload listen alle Ereignisse ihres Einstundenfensters, darunter Claires Outlook-Lesezugriffe und eine Datei, die sie im Büro (192.0.2.10) geöffnet hat. Der Anteil des Angreifers ist der von 203.0.113.77 mit dem REST-Client und dem User-Agent rclone.
3. Ein mittlerer Befund ist ein Fehlalarm. Am 14.09. um 09:05 hat Sofia Garcia von der Büro-IP Sicherheitsinformationen registriert. Das wird wie die Registrierung des Angreifers als neue MFA-Methode (mittel) markiert. Nichts sonst verbindet es mit dem Angriff: Eine kurze Rückfrage bei Sofia klärt es.

Thomas Beckers Regel „Newsletters“ (von einem Newsletter-Absender in einen Ordner Newsletters, erstellt im Büro) erzeugt dagegen gar keinen Befund.

Eingrenzung

• Gelesen: Die MailItemsAccessed-Einträge von der IP des Angreifers nutzen den REST-Client und tragen die wiederverwendete Sitzung. Die Liste der InternetMessageId-Werte ergibt die zu prüfenden Nachrichten (was MailItemsAccessed beweist).
• Weitergeleitet: alles vom Lieferanten nach 08:33 (Regel „..“) und jede eingehende Nachricht nach 08:36 (Postfachweiterleitung), bis zur Entfernung.
• Heruntergeladen: 64 Dateien aus sites/Finance/Shared Documents/Factures 2026.
• Gesendet: mindestens eine betrügerische E-Mail an einen Kunden; die Nachrichtenablaufverfolgung würde die Empfänger zeigen.
• Zu entfernende Persistenz: der um 08:24 registrierte Authenticator, die Regeln „.“ und „..“, die Postfachweiterleitung, Erteilung und Dienstprinzipal von „Mail Sync Pro“ sowie die Sitzung selbst.

Die Behebungsliste

Das Tool ordnet die Schritte anhand der Befunde: Sitzungen widerrufen, Anmeldedaten zurücksetzen und MFA neu registrieren, Datenoffenlegung bewerten, Regeln entfernen, Weiterleitung entfernen und automatische externe Weiterleitung blockieren, IPs des Angreifers sperren, auf phishing-resistente MFA umstellen, Kontakte warnen, Zahlungen prüfen, die zugestimmte App entfernen und Benutzerzustimmung einschränken, MFA-Methoden und App-Registrierungen prüfen. Die erste Stunde nach einem BEC erklärt diese Reihenfolge.

Was dieses Beispiel nicht zeigt

Echte Vorfälle sind unordentlicher: Exporte bei 50.000 Zeilen abgeschnitten, Anmeldungen bereits abgelaufen, Angreifer über Residential Proxies statt Hosting-Netze, mehrere Opfer. Die Grenzen stehen in Aufbewahrung und fehlende Protokolle. Die Methode bleibt die aus dem Untersuchungsleitfaden: die Anmeldung des Angreifers finden, der Sitzung folgen, jeden Persistenzmechanismus prüfen.

Weiterführende Links

• Unified Audit Log im Browser analysieren
• AiTM-Phishing erkennen
• Glossar: Adversary-in-the-Middle, Posteingangsregel, unrechtmäßige Einwilligungserteilung