Business Email Compromise in Microsoft 365 erkennen und stoppen

Business Email Compromise (BEC) in Microsoft 365 ist selten ein Malware-Fall, sondern eine Kette aus Phishing, Session- oder Token-Diebstahl, Inbox-Regeln und OAuth-Consent-Missbrauch. Ein SOC erkennt BEC über korrelierte Signale aus Entra ID, Exchange Online und Defender for Cloud Apps, nicht über den E-Mail-Text allein. Reaktion heisst: Session widerrufen, Inbox-Regeln entfernen, OAuth-Consents zurückziehen, MFA neu erzwingen, dokumentiert nach ISG- und Versicherungslogik.

SOC as a ServiceAlleBusiness Email Compromise in Microsoft 365 erkennen und stoppen

Abgrenzung zu Nachbarthemen

Diese Seite beschreibt den Angriffsvektor BEC in Microsoft 365. Der zugrunde liegende Diebstahl des Anmelde-Materials ist unter Token-Diebstahl und Session-Hijacking beschrieben. Die Plattformseite mit Entra ID, Defender XDR und Sentinel steht unter SOC für Microsoft 365 und Sentinel. Awareness-Programm und Meldebutton auf Phishing-Simulation. Präventive Identitäts-Erkennung im Detail auf ITDR. Servicedefinition auf Was ist ein SOC. Das gesamte Betriebsbild im Pillar SOC as a Service Schweiz.

Was BEC in M365 ist

BEC ist keine Malware-Kategorie, sondern ein Betrugsmuster: Ein Angreifer übernimmt oder imitiert ein legitimes Postfach und wickelt darüber Zahlungsanweisungen, Lieferanten-Wechsel oder Datenabflüsse ab. In Microsoft 365 läuft das fast immer über kompromittierte Identitäten, nicht über infizierte Endpoints. Das Postfach sieht sauber aus, die Nachricht kommt von der echten Adresse, die Signatur stimmt. Genau deshalb versagen E-Mail-Filter allein.

CEO-Fraud: Zahlungsanweisung im Namen der Geschäftsleitung, oft kurz vor Wochenende.
Lieferanten-Umleitung: Änderung der Bankverbindung auf einer echten offenen Rechnung.
Payroll-Umleitung: Änderung der Lohnbankverbindung eines Mitarbeitenden.
Datenabfluss: gezielte Weiterleitung sensibler Anhänge nach extern per Inbox-Regel.

Die typische Angriffskette in M365

Phase	Was der Angreifer tut	Signal im Tenant
1. Phishing / AiTM	Reverse-Proxy-Phishing (z. B. Evilginx) stiehlt Session-Cookie trotz MFA.	Ungewöhnliche Sign-in-Location, Impossible Travel, atypischer User-Agent.
2. Session-Übernahme	Angreifer nutzt Session-Token, umgeht MFA-Prompt.	Entra-ID-Risk-Detection, Non-interactive Sign-in ohne MFA-Claim.
3. Persistenz	Inbox-Regel für Rechnungen mit Weiterleitung in RSS oder Deleted Items, OAuth-App mit Mail.Read.	New-InboxRule, OAuth Consent Grant, App-Only Token.
4. Recherche	Lesen offener Rechnungen, Supplier-Kommunikation, Zahlungsläufe.	MailItemsAccessed-Spitzen, Search-Query-Muster.
5. Ausführung	Antwort auf echten Thread mit geänderter IBAN oder gefälschter Anweisung.	Ausgehende Mail an Finanzabteilung, gleicher Thread, neue Zahlungsinfo.

Merksatz

MFA allein stoppt BEC nicht mehr. Wer nur auf MFA vertraut, schützt gegen 2020er-Angreifer, nicht gegen 2026er.

Was ein SOC im Tenant korreliert

Entra ID: Risky Sign-ins, Impossible Travel, atypische Länder, Non-interactive Logons ohne MFA-Claim.
Exchange Online: New-InboxRule mit Weiterleitung, Löschung oder RSS-Ordner, Set-Mailbox mit ForwardingSmtpAddress.
OAuth-Consent-Grants an unbekannte Apps mit Mail.Read, Mail.Send, offline_access.
MailItemsAccessed und Search-Query-Muster (Rechnungen, IBAN, Payroll, Supplier).
Defender for Cloud Apps: Anomalie-Erkennung auf Massen-Download, ungewöhnliche Client-Apps.
Korrelation mit gemeldeten Phishings über den Meldebutton, siehe Phishing-Simulation.

Response-Playbook BEC

Alle Sessions des betroffenen Users widerrufen (revokeSignInSessions), Passwort erzwingen.
Inbox- und Transport-Regeln inventarisieren und schädliche Regeln entfernen, Backup vorher exportieren.
Verdächtige OAuth-Consents entziehen, App-Only Tokens revoken, Enterprise Apps auditieren.
MFA-Methoden zurücksetzen, Conditional Access auf phishing-resistente MFA (FIDO2 oder CBA) für Risiko-Rollen prüfen.
Finance-Team direkt informieren, offene Zahlungen mit veränderter IBAN aktiv zurückrufen.
Vorfall dokumentieren gemäss Meldepflichten (revDSG, ISG, ggf. FINMA) und Versicherer-Anforderung.

Meldepflichten und Versicherung

BEC mit Zahlungsschaden fällt regelmässig unter die Meldepflicht nach revDSG (Datenschutzverletzung, wenn Personendaten betroffen sind) und nach ISG bei kritischen Infrastrukturen. Cyberversicherer erwarten dokumentierte Reaktionsschritte innerhalb weniger Stunden nach Kenntnis; siehe Anforderungslogik unter Cyberversicherung und SOC. Für die konkrete 72h-Reaktionsfähigkeit siehe Incident Response innert 72 Stunden.

Einordnung im SOC-Betrieb

Wie BEC-Detection in den laufenden 24/7-Betrieb eingebettet wird, steht im Pillar SOC as a Service Schweiz.

Häufige Fragen

Reicht MFA gegen BEC?

Nein. Reverse-Proxy-Phishing wie Evilginx umgeht klassische MFA (SMS, Push, TOTP), indem es die Session nach dem MFA-Prompt stiehlt. Wirksam sind phishing-resistente MFA-Methoden (FIDO2, Certificate-Based Auth) und Detection auf Token-Nutzung; siehe [Token-Diebstahl und Session-Hijacking](/de/soc/token-diebstahl-session-hijacking).

Wie schnell erkennt ein SOC eine BEC-Kompromittierung?

Bei ordentlich angebundenen Entra-ID- und Exchange-Online-Logs innerhalb von Minuten bis wenigen Stunden ab dem ersten Risk-Signal oder der ersten Inbox-Regel. Ohne Anbindung an Sign-in- und Audit-Logs vergehen typischerweise Wochen bis zur Entdeckung durch die Finanzabteilung. Details zur Zeitlogik auf [MTTD und MTTR im SOC](/de/soc/soc-mttd-mttr).

Welche M365-Lizenzstufe braucht es mindestens?

Sinnvoll ab Microsoft 365 Business Premium plus Entra ID P1 für Basis-Conditional-Access. Risikobasierte Erkennung (Risky Sign-ins/Users) und risikobasierte Conditional-Access-Policies erfordern zusätzlich Entra ID P2 (Identity Protection). Für tiefere Erkennung (UEBA, Alert Policies, MailItemsAccessed) sind E5 oder ergänzende Lizenzen üblich. Ohne Audit-Log-Aktivierung ist BEC-Detection nicht rekonstruierbar.

Ist Rückholung des Geldes bei BEC realistisch?

Teilweise, wenn der Rückruf innerhalb weniger Stunden angestossen wird und die Empfängerbank kooperiert. Nach 24 bis 48 Stunden sinken die Chancen deutlich. Deshalb gehört das direkte Anrufen der Bank in das Playbook, nicht in eine spätere Rechtsphase.

Wie hängt BEC mit Awareness-Training zusammen?

Awareness reduziert die Klickrate, aber gute BEC-Wellen sind so glaubwürdig, dass sie auch trainierte Nutzer treffen. Der eigentliche Wert liegt im Meldebutton: schnelle Meldung durch Nutzer plus SOC-Reaktion in Minuten. Siehe [Security-Awareness](/de/services/security-awareness-training) und [Phishing-Simulation](/de/services/security-awareness-training).

Weiterlesen im Cluster

SOC für Microsoft 365 und Sentinel: Was zählt

Ein SOC für Microsoft-365- und Sentinel-Umgebungen korreliert Signale aus Entra ID, Defender XDR, Exchange Online und Azure in einem Detection-Layer und reagiert 24/7. Der Wert entsteht nicht durch die Lizenz, sondern durch Analysten, Playbooks und dokumentierte Reaktion.

Security Awareness Training: aus Klick-Risiko wird Meldebereitschaft

Security-Awareness-Training ist keine E-Learning-Pflichtübung, sondern ein messbarer Verhaltens-Prozess. Ziel ist nicht die Klickrate von null, sondern die Melderate von verdächtigen E-Mails im Zielkorridor von 40 bis 50 Prozent, bevor das SOC eskaliert. ANOMAL kombiniert kurze rollen-spezifische Module, realistische Phishing-Simulationen und eine Meldeschnittstelle in Microsoft 365, damit Awareness zur Detection-Quelle wird. Die Anforderung «Regelmässige Security-Awareness-Trainings mit Phishing-Simulationen» der meisten Schweizer Cyberversicherer wird damit dokumentiert erfüllt.

Incident Response in 72 Stunden

Ein ernsthafter Cyber-Vorfall wird nicht in Wochen gemanagt, sondern in den ersten Stunden entschieden. ANOMAL stellt ein Schweizer Incident-Response-Team, das innerhalb der 72-Stunden-Frist der Cyberversicherung greift: Erstanalyse, Eindämmung, Beweissicherung und Kommunikation mit Versicherung, Regulator und Geschäftsleitung. Kein Retainer erforderlich, aber empfohlen, damit die Uhr nicht erst beim ersten Anruf startet.

SOC und Cyberversicherung: Was Versicherer in der Schweiz verlangen

Cyberversicherer in der Schweiz und der EU verlangen von Antragstellern zunehmend nachweisbare Sicherheitskontrollen. MFA, EDR, getrennte Backups, ein dokumentierter Incident-Response-Plan und ein Patch-Prozess sind auf fast jedem Antragsformular Pflicht. 24/7-Detection über ein Managed SOC oder MDR ist meist keine formale Ausschlussklausel, beeinflusst die Prämie aber stark. In vielen Policen ist sie die Voraussetzung dafür, dass kurze Meldefristen der Police überhaupt eingehalten werden können.

MTTD und MTTR: Die zwei SOC-Kennzahlen, auf die es ankommt

Mean Time to Detect (MTTD) misst, wie schnell ein SOC einen Angriff erkennt. Mean Time to Respond oder Contain (MTTR, MTTC) misst, wie schnell er gestoppt ist. Beide Werte sind der einzige verlässliche Nachweis, dass ein SOC arbeitet und nicht nur läuft.

Kurzdefinitionen im Glossar nachschlagen