Kompromittiertes M365-Konto: Wie ein MFA-Bypass 250.000 € kostete

Unser heutiger Praxisfall spielt in einem mittelständischen Dienstleistungsunternehmen aus dem Bereich Logistik und Fuhrparkmanagement. Das Unternehmen beschäftigt rund 180 Mitarbeiter, betreibt eigene Softwarelösungen für Fahrzeugtracker und Disposition sowie eine multinationale Kundenbasis. Die IT-Landschaft ist typisch gemischt: Lokale File‑Server und eine ältere ERP‑Lösung laufen noch im eigenen Rechenzentrum, während E‑Mail, Collaboration mit Microsoft 365 sowie einzelne SaaS‑Applikationen bereits in der Cloud gehostet werden.

Trotz vorhandener Firewalls, einer Standard‑Antivirus‑Lösung und periodischer Schulungen zum Thema Phishing war der Fokus auf klassischer „Netzwerksicherheit“ verortet. Modernes Identity‑Management, konsequente Multi‑Factor‑Authentication (MFA) und regelmäßige Prüfungen von Administrator‑Accounts standen noch auf der langen To‑Do‑Liste. Das Unternehmen beauftragt einen externen IT‑Dienstleister für Betrieb, Wartung und Support, verantwortlich für Server, Backup und Cloud‑Konten, aber keine eigene Security‑Operations‑Funktion.

Ablauf des Vorfalls: MFA‑Bypass und Account‑Kompromittierung

Der Vorfall beginnt mit einer gefundenen Anmeldedatenkombination aus einem älteren Datenleck, die in einem öffentlichen Datenpool auftaucht. Eine solche E‑Mail‑Adresse gehört einem Key‑User im Finanz‑ und Rechnungswesen, der gleichzeitig über erhöhte Rechte in der ERP‑Lösung und in Microsoft 365 verfügt.

Angreifer starten zunächst eine automatisierte Passwort‑Spray‑Kampagne über das Internet‑Gateway des Unternehmens. Mehrere Login‑Versuche gegen das Microsoft‑365‑Konto scheitern – doch zu einem Zeitpunkt, als der Mitarbeiter gerade von unterwegs über Mobile‑VPN gearbeitet hat, gelingt ein Login‑Versuch trotz aktivierter MFA. Später zeigt sich, dass ein MFA‑Bypass über eine schwach konfigurierte Bedingte‑Zugriffs‑Richtlinie genutzt wurde: Einige mobile Apps oder Legacy‑Protokolle wurden als Ausnahmen definiert, sodass MFA dort nicht vollständig erzwungen wurde.

Nachdem der Account kompromittiert ist, legen die Angreifer zusätzlich einen zweiten, internen Admin‑Account an und konfigurieren Portalschnittstellen so um, dass sie Zahlungsanweisungen und E‑Rechnungen im System verändern können. Die Angriffsdauer zwischen erstem erfolgreichen Login und der ersten verdächtigen Aktivität liegt bei etwa 12 Stunden, ohne dass im Monitoring etwas auffällt.

Auswirkungen auf das Unternehmen

In der Folge kommt es zu mehreren Manipulationen von Zahlungsdaten: Drei Rechnungen eines großen europäischen Kunden werden so umgeleitet, dass die Beträge auf gefälschte Bankkonten gehen. Insgesamt entstehen direkt sichtbare Verluste von rund 180.000 Euro. Zwei weitere Zahlungen werden abgefangen, bevor das Unternehmen die Manipulationen bemerkt, sodass der Gesamtschaden im Bereich von über 250.000 Euro liegt.

Der Betrieb ist für rund 36 Stunden stark eingeschränkt: Die IT stoppt das ERP‑System und die Microsoft‑365‑Unvertraulichen‑Konten zur Sicherheit, was Disposition, Rechnungswesen und den Kundendienst trifft. Die produktiven Teile des Unternehmens laufen anschließend temporär nur noch über manuelle Prozesse und Notlisten. Die interne IT‑Abteilung und der externe Dienstleister arbeiten in Schichten, um Systeme zu sichern, Forensik zu betreiben und die Richtlinienstandards wiederherzustellen.

Als zusätzliche Folge muss das Unternehmen eine Datenschutz‑ und Sicherheitsprüfung durchführen, da Kundendaten über das manipulierte System abgefragt wurden. Es entsteht ein erheblicher Aufwand für die Meldung an die zuständige Aufsichtsbehörde und die interne Dokumentation. Darüber hinaus treten merkliche Ruf‑ und Vertrauensschäden gegenüber Kunden auf, die ihr Zahlungsverhalten und die internen Prozesse des Unternehmens kritisch hinterfragen.

Lessons Learned

Der Vorfall macht deutlich, dass eine reine Netzwerksicherheit nicht mehr ausreicht, wenn nahezu alle Geschäftsprozesse über Identity‑ und Clouddienste laufen. Allein die Tatsache, dass ein Account mit MFA‑Rechten kompromittiert wurde, zeigt, dass Schwachstellen in der Konfiguration von Zugriffsrichtlinien und der Ausnahmebehandlung von Apps existiert haben.

Zweitens zeigt der Fall, wie wichtig ein kontinuierliches Monitoring von Anmelde‑ und Rollenänderungen ist. Die fehlende Alarmierung bei ungewöhnlichen Registrierungen oder bei neuen Admin‑Accounts im Cloud‑Verzeichnis hat das Unternehmen in den ersten Stunden der Angriffsphase blind, während die Angreifer bereits Änderungen an Zahlungsprozessen vornahmen.

Drittens wird ersichtlich, dass Bedrohungen nicht mehr nur an der Firewall entstehen. Die Kombination aus kompromittierter Legacy‑Anmeldedatenbank, unzureichend geschützten mobilen Apps und fehlerhafter MFA‑Konfiguration hat Angreifern einen direkten Zugang zu Geschäftsprozessen eröffnet. Das funktioniert nicht nur mit Phishing, sondern auch mit automatisierten Massen‑Angriffen auf bereits bekannte Kombinationen.

Viertens zeigt sich, dass die klassische Trennung zwischen IT‑Betrieb und Security unsichtbar verschwindet. Die externe IT‑Dienstleistung hat sich hauptsächlich auf den reibungslosen Betrieb und die Wartung konzentriert, während die Security‑Richtlinien und Zugriffs‑Governance nur implizit behandelt wurden. Ein klarer Sicherheits‑Owner und ein Service‑Level‑Agreement mit expliziten Sicherheits‑KPIs hätten hier früher rot blinken lassen.

Konkrete Maßnahmen & Checkliste für KMU und IT‑Dienstleister

Für Unternehmen im Mittelstand und ihre IT‑Betreiber ergeben sich daraus mehrere konkrete Handlungsfelder, die sich in eine pragmatische Checkliste fassen lassen:

• Alle Internet‑zugänglichen Anmeldedienste (Microsoft 365, ERP‑Frontend, VPN‑Gateways) mit MFA sichern und empfohlene Richtlinien zur Cloud‑Sicherheit der BSI prüfen.
• Bedingte‑Zugriffs‑Richtlinien so konfigurieren, dass MFA für alle Anmeldungen aus dem Internet gilt und Ausnahmen nur für klar geregelte, gut dokumentierte Szenarien (z. B. Applikationen mit App‑Passwort) bestehen.
• Registrierung und Zuweisung von Admin‑ und ERP‑Superuser‑Rechten stets über eine zweite autorisierte Person prüfen und in einem Change‑Prozess dokumentieren, etwa nach den Prinzipien eines Informationssicherheitshandbuchs.
• Automatisierte Log‑Monitoring‑Lösungen einsetzen, die bei ungewöhnlichen Anmelde‑Mustern (z. B. Login aus neuen Ländern, mehrfache Anmeldeversuche, neue Admin‑Accounts) Warnungen erstellen und an einen zuständigen IT‑ oder Security‑Verantwortlichen senden.
• Regelmäßige Security‑Reviews mit externen IT‑Dienstleistern durchführen, in denen insbesondere Identity‑, Zugriffs‑ und MFA‑Konfigurationen gemeinsam überprüft und dokumentiert werden.
• Backup‑ und Wiederherstellungstests für ERP‑ und Finanzsysteme mindestens vierteljährlich durchführen, um sicherzustellen, dass auch manipulierte Datenbanken in einen definierten Stand zurückgesetzt werden können.
• Interne Sensibilisierung im Bereich Zahlungsprozesse: Jede Änderung von Bankverbindungen oder Kontodaten im ERP‑System muss über eine zweite, dokumentierte Freigabe laufen und per E‑Mail oder Telefon mit dem verantwortlichen Kundenmanager bestätigt werden.
• Alle Internet‑zugänglichen Systeme regelmäßig auf Basis aktueller Sicherheitsbewertungen der Hersteller prüfen und Patch‑Management‑Prozesse robust umsetzen, um bekannte Schwachstellen zu schließen.

Dieser Praxisfall zeigt eindrucksvoll, dass ein einzelner kompromittierter Account mit falsch konfigurierter MFA genügt, um operative und finanzielle Schäden zu verursachen. Die gute Nachricht ist: Mit konsequenten, aber handhabbaren Maßnahmen im Bereich Identity, Zugriff und Monitoring können KMU und IT‑Dienstleister genau diese Angriffswege effektiv absichern.