Microsoft 365 Business gehackt: Die häufigsten Ursachen und Angriffsszenarien

1.1 Das Passwort ist nur der erste Faktor

Das Kennwort beantwortet zunächst nur die Frage, ob jemand ein für das Konto gültiges Geheimnis kennt. Wird für eine Anmeldung kein weiterer Nachweis verlangt, kann ein bekannt gewordenes Passwort bereits für eine vollständige Kontoübernahme ausreichen.

Dabei wird häufig zu stark zwischen „schwachen“ und „starken“ Passwörtern unterschieden. Ein kurzes, vorhersehbares Kennwort ist ohne Frage riskanter. Ein zufälliges, 25 Zeichen langes Passwort schützt aber ebenfalls nicht mehr, sobald ein Angreifer es bereits kennt. Es kann beispielsweise auf einer Phishing-Seite eingegeben worden sein, aus einem früheren Datenleck stammen, auf mehreren Diensten wiederverwendet worden sein oder durch Schadsoftware abgegriffen worden sein.

Passwortstärke schützt damit vor allem gegen das Erraten oder systematische Ermitteln eines Kennworts. Sie schützt nicht gegen dessen bereits erfolgte Offenlegung. Genau deshalb ist MFA so wichtig: Selbst ein korrektes Passwort soll allein noch nicht genügen.

1.2 MFA ergänzt die Anmeldung um einen weiteren Nachweis

Multi-Faktor-Authentifizierung, kurz MFA, soll verhindern, dass ein bekannt gewordenes Passwort automatisch auch einen erfolgreichen Login ermöglicht. Microsoft verlangt zusätzlich einen weiteren Authentifizierungsnachweis. Das kann beispielsweise eine Bestätigung in Microsoft Authenticator, ein zeitbasierter Einmalcode, ein Passkey, Windows Hello oder ein FIDO2-Sicherheitsschlüssel sein.

Damit steigt die Hürde erheblich. Ein Angreifer, der lediglich das Passwort besitzt, kommt bei korrekt erzwungener MFA zunächst nicht weiter. Allerdings beschreibt „MFA“ nur, dass eine zusätzliche Authentifizierung beziehungsweise eine entsprechend starke Kombination von Faktoren verlangt wird. Der Begriff sagt noch wenig darüber aus, wie widerstandsfähig das konkret eingesetzte Verfahren gegen moderne Phishingangriffe ist.

1.3 Nach der Anmeldung entsteht ein verwendbarer Sitzungskontext

Nach einer erfolgreichen Anmeldung wäre es unpraktikabel, vor jedem Abruf einer neuen E-Mail, jedem Wechsel von Outlook zu Teams oder jedem Hintergrundzugriff erneut Kennwort und MFA abzufragen. Deshalb stellt Microsoft einen Authentifizierungskontext bereit, mit dem Anwendungen im Namen des bereits erfolgreich angemeldeten Benutzers weiterarbeiten können.

Dazu gehören – abhängig von Anwendung und Anmeldeverfahren – unter anderem Access Tokens, Refresh Tokens, Sitzungscookies und andere Authentifizierungsartefakte. Ein Access Token ermöglicht typischerweise für begrenzte Zeit den Zugriff auf eine bestimmte Ressource. Ein Refresh Token kann unter passenden Bedingungen dazu dienen, später neue Access Tokens zu beziehen, ohne den Benutzer bei jedem Vorgang erneut vollständig interaktiv anzumelden.

Das ist kein Sicherheitsfehler, sondern Voraussetzung für einen praktikablen Cloud-Dienst. Es schafft aber eine weitere Angriffsebene. Ein Täter muss unter bestimmten Umständen nicht mehr versuchen, Passwort oder MFA unmittelbar zu überwinden. Er kann stattdessen versuchen, einen bereits erfolgreich aufgebauten Authentifizierungskontext zu übernehmen oder weiterzuverwenden.

1.4 Authentifizierung und Autorisierung sind nicht dasselbe

Nach erfolgreicher Authentifizierung stellt sich noch eine andere Frage: Was darf der angemeldete Benutzer oder eine Anwendung anschließend tun? Diese Ebene nennt sich Autorisierung.

Ein Benutzer kann einer Anwendung beispielsweise erlauben, auf sein Profil, seinen Kalender, Dateien oder E-Mails zuzugreifen. Das ist im normalen Microsoft-365-Betrieb alltäglich. CRM-Systeme, Terminplaner, Signaturdienste und andere Cloud-Anwendungen funktionieren häufig genau auf dieser Grundlage.

Problematisch wird es, wenn eine solche Berechtigung einer bösartigen oder kompromittierten Anwendung erteilt wird. Dann muss der Angreifer das Benutzerpasswort möglicherweise später überhaupt nicht mehr kennen. Die Anwendung besitzt stattdessen eine von Microsoft akzeptierte Berechtigung und kann im Rahmen dieses Berechtigungsumfangs auf Daten oder Funktionen zugreifen.

1.5 Die sichtbare Manipulation im Postfach ist meist nicht die ursprüngliche Sicherheitslücke

Diese Trennung hilft bei der späteren Aufklärung. Eine unbekannte Weiterleitung, eine Löschregel oder eine verdächtige SendAs-Berechtigung ist normalerweise nicht der ursprüngliche Angriffsweg. Sie zeigt vielmehr, was ein Angreifer nach erfolgreichem Zugriff getan hat.

Wer bei einem Sicherheitsvorfall lediglich die gefundene Regel löscht, beseitigt deshalb möglicherweise nur das sichtbare Symptom. Besteht der eigentliche Zugriff über eine weiterhin aktive Sitzung, eine fremde MFA-Methode, eine OAuth-Berechtigung oder ein anderes berechtigtes Benutzerkonto fort, kann der Angreifer erneut handeln.

2.1 E-Mail-Code ist bei normalen Microsoft-365-Benutzern keine reguläre MFA-Anmeldemethode

Bei vielen anderen Online-Diensten wird ein per E-Mail versendeter Einmalcode als zweiter Faktor angeboten. Diese Erfahrung sollte nicht unverändert auf Microsoft 365 übertragen werden. Bei regulären Microsoft-Entra-Mitgliedskonten ist E-Mail keine normale zweite Authentifizierungsmethode für die übliche MFA-Anmeldung. E-Mail kann unter anderem bei der Self-Service-Kennwortzurücksetzung relevant sein; E-Mail-OTP spielt außerdem bei bestimmten Gastbenutzer-Szenarien eine Rolle.

Auch grundsätzlich wäre ein E-Mail-Code als Schutz des E-Mail-Kontos selbst wenig überzeugend, wenn beide Sicherheitsstufen letztlich von derselben kompromittierbaren Mailbox abhängen. Gute Mehrfaktor-Authentifizierung lebt gerade von einer möglichst unabhängigen zweiten Vertrauensebene.

2.2 SMS und Sprachanruf verlieren bei Microsoft ihre bisherige Rolle

Die Entwicklung bei Microsoft zeigt deutlich, wie sich der Sicherheitsmaßstab verändert. SMS und Sprachanrufe werden inzwischen als vergleichsweise anfällige Methoden behandelt. Seit dem 1. September 2026 werden Benutzer, die für Microsoft-seitig bereitgestellte SMS- oder Sprachauthentifizierung aktiviert sind, zusätzlich in Richtung Passkey-Registrierung geführt.

Ab dem 1. Februar 2027 stellt Microsoft die eigene SMS- und Voice-Zustellung für die meisten Benutzer ein. Für Global Administrators und externe Benutzer gilt ein späterer Termin im Juli 2027. Organisationen, die Telefonieverfahren weiterhin benötigen, können dafür kundenseitig verwaltete Anbieter einsetzen.

Die Entwicklung ist damit eindeutig: Der Sicherheitsmaßstab verschiebt sich von „irgendeine MFA“ zu Verfahren, die auch gegen moderne Phishingangriffe möglichst wenig übertragbare Informationen erzeugen.

2.3 Number Matching verhindert blindes Bestätigen – aber nicht jeden vermittelten Phishingangriff

Eine wichtige Verbesserung gegenüber früheren Authenticator-Pushfreigaben ist das sogenannte Number Matching. Bei älteren Pushverfahren konnte die Benutzerentscheidung im Wesentlichen daraus bestehen, eine Anmeldung zu genehmigen oder abzulehnen. Ein Angreifer, der bereits das Passwort kannte, konnte deshalb immer wieder neue Versuche auslösen und darauf hoffen, dass der Benutzer irgendwann versehentlich oder aus Gewohnheit bestätigt.

Beim heute üblichen Number Matching zeigt Microsoft während eines Browser-Logins eine Zahl auf der Anmeldeseite an. Gleichzeitig erscheint die Authenticator-Anfrage auf dem Smartphone. Dort muss der Benutzer genau diese Zahl eingeben beziehungsweise – abhängig vom jeweiligen Konto- und Authentifizierungsflow – den passenden Wert bestätigen. Damit reicht ein völlig kontextloser Push nicht mehr aus. Der Benutzer benötigt eine Information aus dem gerade laufenden Anmeldevorgang.

Das ist ein wirksamer Schutz gegen klassisches Push-Bombing. Number Matching beantwortet aber eine engere Frage, als oft angenommen wird: Stimmen die Challenge des laufenden Logins und die Bestätigung auf dem Smartphone zusammen? Es beweist nicht automatisch, dass die Webseite, auf der der Benutzer diese Challenge gesehen hat, tatsächlich die legitime Microsoft-Seite ist.

Genau diese Grenze wird bei Adversary-in-the-Middle-Phishing relevant. Wenn eine fremde Webseite einen echten Microsoft-Anmeldevorgang in Echtzeit vermittelt, kann sie auch die von Microsoft erzeugte Zahl an den Benutzer weiterreichen. Der Benutzer sieht dann auf der Phishing-Seite beispielsweise die Zahl „42“, erhält parallel die echte Authenticator-Anfrage und trägt dort ebenfalls „42“ ein. Aus Sicht von Microsoft passen Challenge und Antwort korrekt zusammen.

Bei persönlichen Microsoft-Konten oder einzelnen Phone-sign-in-Varianten kann die Oberfläche anders aussehen, etwa indem der passende Wert aus mehreren Zahlen ausgewählt wird. Für die Sicherheitsbetrachtung ändert das wenig: Auch dort besteht der Zweck darin, den Vorgang auf dem Smartphone mit einer sichtbaren Challenge des laufenden Logins zu verknüpfen. Wird diese Challenge über eine fremde Vermittlungsseite in Echtzeit an den Benutzer weitergereicht, kann auch sie Teil des Social Engineerings werden.

Authenticator kann zusätzlich Kontext wie die anfragende Anwendung oder einen aus der IP-Adresse abgeleiteten Standort anzeigen. Das erhöht die Chance, einen ungewöhnlichen Vorgang zu erkennen. Eine kryptografische Bindung an die tatsächlich vom Benutzer besuchte Web-Domain ersetzt dieser Zusatzkontext jedoch nicht.

2.4 Die stärkste registrierte Methode ist nicht automatisch die erzwungene Sicherheitsstufe

Ein weiterer wichtiger Punkt wird in der Praxis häufig übersehen: Ein Benutzer kann mehrere Anmeldemethoden gleichzeitig registriert haben – beispielsweise einen FIDO2-Sicherheitsschlüssel oder Passkey und zusätzlich klassische Authenticator-Benachrichtigungen.

Microsofts sogenannte system-preferred authentication versucht, zunächst die sicherste verfügbare Methode zu bevorzugen. Hat ein Benutzer einen Passkey registriert, kann dieser gegenüber einem Kennwort oder einer schwächeren Methode bevorzugt angeboten werden.

„Bevorzugt“ bedeutet allerdings nicht „zwingend“. Der Benutzer kann grundsätzlich „Auf andere Weise anmelden“ auswählen und eine andere registrierte Methode verwenden, sofern diese für den konkreten Zugriff weiterhin zugelassen ist.

Damit sind zwei Aussagen zu unterscheiden: Ein Benutzer besitzt eine phishing-resistente Methode – und ein Benutzer muss für einen bestimmten Zugriff eine phishing-resistente Methode verwenden. Nur die zweite Aussage garantiert die entsprechende Mindeststärke.

Conditional Access kann dafür eine Authentication Strength vorgeben. Wird beispielsweise „phishing-resistant MFA“ verlangt, reicht ein vorhandener Authenticator-Push für diesen Zugriff nicht mehr aus, auch wenn er weiterhin am Benutzerkonto registriert ist.

Das häufig verwendete Bild von der „schwächsten Methode des Kontos“ muss deshalb etwas präziser formuliert werden. Eine schwächere Methode reduziert das Sicherheitsniveau nur dann, wenn sie für den konkreten Zugriff tatsächlich akzeptiert wird. Genau deshalb ist die Frage nach den zulässigen Methoden wichtiger als die bloße Liste aller registrierten Verfahren.

2.5 Starke Authentifizierung benötigt einen ebenso durchdachten Wiederherstellungsweg

Wer schwache Fallbacks konsequent entfernt, muss gleichzeitig sicherstellen, dass ein verlorener Sicherheitsschlüssel oder ein defektes Gerät nicht zum organisatorischen Notfall wird. Sicherheit und Verfügbarkeit gehören deshalb zusammen.

Ein sinnvoller Aufbau kann beispielsweise aus mehreren phishing-resistenten Methoden bestehen: einem primären Passkey beziehungsweise Sicherheitsschlüssel und einer zweiten unabhängigen starken Methode als Reserve. Für kontrollierte Wiederherstellungsszenarien kann außerdem ein Temporary Access Pass eingesetzt werden, mit dem anschließend eine neue starke Methode registriert wird.

Weniger überzeugend ist die Konfiguration „starke MFA für den Alltag, schwache MFA für den Notfall“, wenn die schwächere Methode für dieselben besonders sensiblen Zugriffe weiterhin uneingeschränkt zugelassen bleibt. Damit wird der komfortable Recovery-Pfad gleichzeitig zu einem alternativen Angriffsweg.

3.1 Microsoft liefert eine grundlegende Sicherheitsbaseline bereits mit

Bei der Bewertung eines aktuellen Microsoft-365-Business-Tenants sollte berücksichtigt werden, dass neue Entra-Tenants bereits mit den sogenannten Security Defaults ausgestattet werden. Microsoft konfiguriert diese Sicherheitsstandards bei neuen Tenants standardmäßig; derzeit besteht nach der Erstellung zunächst eine kurze Nachfrist, bevor die Schutzmaßnahmen vollständig durchgesetzt werden.

Security Defaults lassen sich funktional als eine von Microsoft vorgegebene Grundsicherung verstehen. Technisch handelt es sich nicht einfach um ein kleines Paket frei sichtbarer und editierbarer Conditional-Access-Regeln. Die Konfiguration ist bewusst vereinheitlicht und richtet sich gerade an Organisationen, die keine eigene komplexe Conditional-Access-Architektur betreiben.

Die Sicherheitsstandards sorgen unter anderem dafür, dass Benutzer für MFA registriert werden, privilegierte Konten stärker abgesichert werden und ältere Authentifizierungsprotokolle blockiert werden, die moderne Schutzmechanismen umgehen könnten. Neuere Security-Defaults-Konfigurationen berücksichtigen außerdem zusätzliche bekannte Phishingpfade wie den Device-Code-Flow.

3.2 Security Defaults ersetzen keine gezielte Conditional-Access-Strategie

Security Defaults bedeuten nicht, dass jeder Benutzer bei jeder Anmeldung erneut einen zweiten Faktor eingeben muss. Moderne Authentifizierung arbeitet mit bestehenden Sitzungen und bereits erfüllten Authentifizierungsanforderungen. Ebenso bedeuten Security Defaults nicht, dass ausschließlich phishing-resistente Verfahren akzeptiert werden.

Für kleinere Unternehmen ist diese Baseline trotzdem ein erheblicher Fortschritt gegenüber älteren Tenants, bei denen MFA nie eingerichtet und Legacy Authentication über Jahre unverändert weiterbetrieben wurde.

Sobald eine Organisation jedoch unterschiedliche Benutzergruppen, besonders schützenswerte Administratoren, verwaltete und nicht verwaltete Geräte oder verbindlich phishing-resistente Authentifizierung unterscheiden möchte, stößt das vereinfachte Modell an seine Grenzen. Dafür ist Conditional Access mit gezielten Authentication Strengths vorgesehen.

4.1 Szenario 1: Das Passwort ist kompromittiert und wirksame MFA fehlt

4.1.1 So kann es für den Benutzer aussehen

Der Benutzer bemerkt zunächst möglicherweise überhaupt nichts. Er hat keinen auffälligen Link geöffnet, keine überraschende Authenticator-Anfrage bestätigt und auch keine neue Software installiert. Trotzdem erscheint irgendwann eine fremde Anmeldung oder es werden Veränderungen im Postfach entdeckt.

Das Passwort kann auf völlig anderem Weg bekannt geworden sein. Typisch sind Passwortwiederverwendung, Credential Stuffing mit Zugangsdaten aus früheren Leaks oder Password-Spray-Angriffe gegen häufig verwendete Kennwörter. Gerade in Unternehmen können auch historisch gewachsene Kennwortmuster problematisch sein, beispielsweise der Firmenname kombiniert mit Jahr oder Jahreszeit.

4.1.2 Was technisch passiert

Der Angreifer meldet sich mit einem gültigen Benutzernamen und dem korrekten Passwort bei Microsoft an. Wird für diesen Zugriff keine weitere Authentifizierung verlangt, erhält er denselben grundlegenden Benutzerzugriff wie der legitime Kontoinhaber.

Was anschließend möglich ist, hängt vom Konto ab. Bei einem normalen Benutzer kann der Täter beispielsweise E-Mails lesen und versenden, Dateien öffnen oder vorhandene Berechtigungen nutzen. Bei einem Administratorkonto kann aus derselben einfachen Passwortkompromittierung ein wesentlich größerer Tenant-Vorfall entstehen.

4.1.3 Warum dieses Szenario heute weitgehend vermeidbar ist

Eine wirksam durchgesetzte MFA unterbricht diesen simplen Ablauf. Das bekannte Passwort bleibt ein Sicherheitsproblem, genügt aber nicht mehr allein. Genau deshalb ist fehlende MFA bei einem produktiv genutzten Microsoft-365-Business-Konto heute ein grundlegendes Defizit.

Typischer Angreiferaufwand: ★☆☆☆☆ bis ★★☆☆☆

4.2 Szenario 2: Credential-Phishing ohne wirksame MFA

4.2.1 So sieht die gefälschte Anmeldeseite in diesem einfacheren Fall aus

Eine E-Mail kündigt beispielsweise eine Rechnung, eine neue Voicemail, ein freigegebenes SharePoint-Dokument, einen Dateitransfer oder eine Nachricht eines Geschäftspartners an. Der darin enthaltene Link führt auf eine Webseite, deren Gestaltung die Microsoft-Anmeldung nachahmt.

Bei einfachem Credential-Phishing kann diese Seite technisch relativ banal sein. Sie benötigt vor allem ein überzeugendes Erscheinungsbild und Eingabefelder für E-Mail-Adresse und Passwort. Der Benutzer trägt seine Daten ein, die Phishing-Infrastruktur erfasst sie und der Täter verwendet sie anschließend separat bei Microsoft.

Die Seite kann danach einen Fehler anzeigen, den Benutzer zur echten Microsoft-Anmeldung weiterleiten oder ihn sogar zur ursprünglich erwarteten Datei bringen. Gerade dieser plausible Abschluss verhindert häufig, dass die Eingabe der Zugangsdaten unmittelbar als Sicherheitsvorfall erkannt wird.

4.2.2 Der entscheidende Unterschied zu AiTM

Beim einfachen Credential-Phishing sammelt die falsche Seite im Wesentlichen Eingaben. Der eigentliche Microsoft-Login des Angreifers findet danach getrennt statt. Die Phishingseite muss deshalb nicht jeden einzelnen Schritt der echten Microsoft-Anmeldung dynamisch nachbilden.

Genau das ändert sich beim später beschriebenen AiTM-Szenario: Dort wird aus der bloßen Nachbildung eine interaktive Vermittlungsschicht, die mit dem realen Microsoft-Anmeldevorgang in Echtzeit zusammenspielt.

4.2.3 Was eine klassische MFA hier bewirkt

Ist eine wirksame MFA aktiviert, besitzt der Angreifer nach diesem einfachen Phishing zunächst nur den ersten Faktor. Er kennt das Passwort, kann die zusätzliche Authentifizierungsanforderung aber nicht automatisch erfüllen. Damit scheitert der einfache Angriff – sofern der Täter nicht auch die zweite Stufe angreift.

Typischer Angreiferaufwand: ★★☆☆☆

4.3 Szenario 3: MFA-Fatigue – der Benutzer genehmigt die Anmeldung des Angreifers

4.3.1 Der Angriff beginnt mit bereits bekannten Zugangsdaten

Der Täter kennt das Passwort bereits und startet damit eine echte Microsoft-Anmeldung. Microsoft erkennt, dass MFA erforderlich ist, und schickt die Authenticator-Anfrage an das Smartphone des legitimen Benutzers.

Bei älteren Pushverfahren bestand die Benutzerentscheidung im Wesentlichen aus „Genehmigen“ oder „Ablehnen“. Dadurch konnte ein Täter wiederholt neue Anmeldeversuche auslösen und darauf hoffen, dass der Benutzer irgendwann versehentlich, aus Gewohnheit oder schlicht aus Genervtheit bestätigt.

Die MFA wurde dabei nicht technisch gebrochen. Microsoft verlangte einen zweiten Faktor und der Benutzer lieferte ihn – allerdings für die falsche Anmeldung.

4.3.2 Number Matching macht blindes Push-Bombing deutlich schwieriger

Mit Number Matching reicht eine unerwartete Pushnachricht allein nicht mehr aus. Beim üblichen Browser-Flow sieht derjenige, der die Anmeldung durchführt, auf der Microsoft-Anmeldeseite eine Zahl. Diese Zahl muss anschließend in Authenticator bestätigt oder eingegeben werden.

Ein Angreifer, der lediglich aus der Ferne immer neue MFA-Anfragen auslöst, kann deshalb nicht mehr darauf hoffen, dass das Opfer ohne jeden Kontext auf „Genehmigen“ tippt. Dem Benutzer fehlt die Zahl des fremden Anmeldevorgangs.

Um diese Hürde in einem klassischen MFA-Fatigue-Szenario zu überwinden, benötigt der Täter zusätzliche soziale Interaktion – etwa einen glaubwürdigen Kommunikationskanal, über den er dem Opfer die passende Zahl mitteilt und es zur Eingabe bewegt. Damit steigt der Aufwand gegenüber blindem Push-Bombing deutlich.

Typischer Angreiferaufwand: ★★☆☆☆ bis ★★★☆☆

4.4 Szenario 4: Phishing trotz MFA – Adversary-in-the-Middle

Adversary-in-the-Middle-Phishing, kurz AiTM, ist gerade deshalb gefährlich, weil die Phishingseite hier nicht bloß wie Microsoft aussieht. Sie verhält sich für den Benutzer wie eine interaktive Vermittlungsschicht des echten Microsoft-Anmeldevorgangs.

4.4.1 Moderne AiTM-Seiten sind keine statischen Kopien

Bei einfachem Credential-Phishing kann die falsche Webseite im Wesentlichen aus einem nachgebauten Loginformular bestehen. Bei AiTM ist das Modell dynamischer: Die vom Angreifer kontrollierte Infrastruktur vermittelt in Echtzeit zwischen dem Browser des Benutzers und dem tatsächlichen Microsoft-Anmeldevorgang.

Der Benutzer gibt auf der fremden Seite beispielsweise seine E-Mail-Adresse ein. Die Infrastruktur verwendet beziehungsweise vermittelt diese Eingabe gegenüber Microsoft und erhält daraufhin den nächsten echten Schritt des Anmeldevorgangs. Fordert Microsoft anschließend das Passwort an, erscheint auch beim Benutzer die entsprechende Eingabe. Wird MFA verlangt, setzt sich derselbe Vorgang fort.

Die Phishingseite ist damit keine einfache Fotokopie einer Microsoft-Seite, sondern eine hochinteraktive Zwischenebene. Sie reagiert sowohl auf die Eingaben des Benutzers als auch auf die Antworten des echten Microsoft-Dienstes. Dadurch wirkt der Ablauf wesentlich glaubwürdiger als bei einem statischen Formular.

4.4.2 Das „Puppentheater“: Der Benutzer bedient indirekt den echten Microsoft-Login

Anschaulich lässt sich der Vorgang wie ein Puppentheater beschreiben. Der Benutzer glaubt, unmittelbar mit Microsoft zu kommunizieren. Tatsächlich sitzt die Angreifer-Infrastruktur dazwischen und reicht die relevanten Eingaben und Herausforderungen in beide Richtungen weiter.

Gibt der Benutzer sein Passwort ein, gelangt diese Information in den vermittelten echten Microsoft-Anmeldevorgang. Microsoft erkennt anschließend, dass für das Konto Authenticator-MFA erforderlich ist, und sendet die echte Pushbenachrichtigung an das Smartphone des Opfers.

Jetzt kommt Number Matching ins Spiel. Microsoft erzeugt für den laufenden Login beispielsweise die Zahl „42“. Diese Zahl würde der legitime Benutzer normalerweise auf der echten Anmeldeseite sehen. Da die Angreifer-Infrastruktur denselben laufenden Microsoft-Login vermittelt, kann sie die zu diesem Vorgang gehörende Challenge ebenfalls auf ihrer eigenen Seite darstellen.

Der Benutzer erlebt nun einen scheinbar vollkommen stimmigen Ablauf: Auf der Webseite steht „42“, auf seinem Smartphone erscheint eine echte Microsoft-Authenticator-Anfrage und Authenticator verlangt die Zahl des Anmeldevorgangs. Der Benutzer trägt „42“ ein. Microsoft sieht eine korrekte Antwort auf die von Microsoft selbst erzeugte Challenge und kann die MFA-Anforderung deshalb als erfüllt betrachten.

Bei Authenticator-Flows, in denen statt einer manuellen Eingabe ein passender Wert ausgewählt oder bestätigt wird, gilt dasselbe Prinzip. Die genaue Oberfläche unterscheidet sich, der relevante Punkt bleibt gleich: Die Challenge des echten Logins wird über die fremde Vermittlungsseite an den Benutzer weitergereicht.

4.4.3 Warum die echte MFA den Angriff für den Benutzer sogar glaubwürdiger machen kann

Dieser Ablauf ist psychologisch erheblich überzeugender als simples Passwort-Phishing. Der Benutzer sieht nicht nur eine plausible Webseite. Sein echtes Smartphone meldet sich mit Microsoft Authenticator. Die angezeigte Zahl passt. Möglicherweise wird zusätzlich ein bekannter Anwendungsname angezeigt.

Aus Sicht des Benutzers scheint Microsoft damit gerade die Echtheit des Vorgangs bestätigt zu haben. Tatsächlich bestätigt Authenticator aber in erster Linie die Authentifizierungsanforderung. Er bestätigt nicht, dass die Webseite, auf der der Benutzer die Challenge gesehen hat, vertrauenswürdig war.

Zusätzlicher Authenticator-Kontext wie Anwendungsname oder aus der Quell-IP abgeleitete Standortinformationen kann bei der Erkennung helfen. Ein völlig unerwarteter Standort oder eine fremde Anwendung ist ein Warnsignal. Diese Hinweise ersetzen aber keine kryptografische Bindung an den legitimen Ursprung.

4.4.4 MFA-Fatigue und AiTM sind deshalb zwei verschiedene Probleme

Beim klassischen MFA-Fatigue-Angriff startet der Täter eine fremde Anmeldung und versucht, den Benutzer zur Bestätigung zu bewegen. Number Matching unterbricht diesen Ablauf wirkungsvoll, weil das Opfer die Challenge des fremden Logins normalerweise gar nicht kennt.

Beim AiTM-Angriff liefert die Phishingseite genau diesen fehlenden Kontext. Die fremde Seite zeigt dem Benutzer die Challenge des echten Microsoft-Logins an. Damit wird die zusätzliche Hürde nicht technisch abgeschaltet, sondern in das Social Engineering eingebunden.

4.4.5 Warum Passkeys und FIDO2 grundlegend anders funktionieren

Phishing-resistente Verfahren lösen deshalb nicht lediglich das Problem der fehlenden Zahl. Sie verändern die Vertrauensbeziehung selbst. Bei FIDO2 und Passkeys ist die Authentifizierung kryptografisch an den legitimen Dienst beziehungsweise dessen Web-Ursprung gebunden. Eine fremde Domain kann nicht einfach dieselbe Authentifizierungsantwort erhalten, nur weil sie sichtbare Informationen zwischen Benutzer und Microsoft weiterreicht.

Das ist der entscheidende Unterschied zwischen zusätzlichen Bedienhinweisen und phishing-resistenter Authentifizierung. Number Matching hilft dem Menschen, eine offensichtlich fremde Anmeldung zu erkennen. FIDO2 und Passkeys sorgen zusätzlich dafür, dass die kryptografische Authentifizierung selbst nicht für den falschen Ursprung erzeugt wird.

4.4.6 Der Rechner muss dabei nicht kompromittiert sein

Ein AiTM-Angriff setzt nicht voraus, dass Malware auf dem PC installiert wurde. Ein technisch sauberer Rechner genügt, wenn der Benutzer im Browser den falschen Anmeldeweg benutzt. Das ist für die spätere Incident-Response wichtig: Ein kompromittiertes Microsoft-365-Konto ist hier kein automatischer Beweis für einen kompromittierten Endpoint.

Typischer Angreiferaufwand: ★★★☆☆ bis ★★★★☆

4.5 Szenario 5: Session- oder Token-Diebstahl durch ein kompromittiertes Endgerät

4.5.1 So kann es für den Benutzer aussehen

Der Benutzer arbeitet ganz normal. Outlook ist angemeldet, Teams funktioniert und es erscheint keine neue MFA-Anfrage. Trotzdem können Authentifizierungsinformationen abfließen, wenn der Rechner selbst mit einem Infostealer oder anderer Schadsoftware kompromittiert wurde.

Gerade Infostealer interessieren sich nicht nur für klassische Passwörter. Moderne Schadsoftware sammelt häufig Browserprofile, gespeicherte Zugangsdaten, Cookies und andere verwertbare Authentifizierungsinformationen. Was davon im konkreten Microsoft-365-Szenario tatsächlich wiederverwendbar ist, hängt vom jeweiligen Authentifizierungsverfahren und vorhandenen Schutzmechanismen ab.

4.5.2 Was technisch anders ist als bei AiTM

Der entscheidende Unterschied liegt in der Position des Angreifers. Beim AiTM-Szenario wird der Anmeldeweg manipuliert. Beim Infostealer sitzt die Schadsoftware bereits auf dem Endgerät oder hat dort Zugriff auf Daten des Benutzers.

Nicht jedes Token und nicht jede Microsoft-Sitzung lässt sich beliebig auf einen anderen Rechner kopieren. Gerätegebundene Anmeldeinformationen, TPM-gestützte Schlüssel, Token Protection und weitere Schutzmechanismen können Replay-Angriffe deutlich erschweren. Trotzdem ist der Diebstahl verwertbarer Sitzungs- und Authentifizierungsdaten durch Malware eine reale Angriffsklasse.

4.5.3 Die Konsequenz für die Bereinigung ist eine andere

Bei reinem Credential-Phishing oder AiTM kann das Endgerät technisch sauber sein. Bei einem erfolgreichen Infostealer-Angriff ist der Rechner dagegen selbst Teil des Sicherheitsvorfalls. Zugangsdaten sollten dann nicht einfach auf demselben möglicherweise kompromittierten System geändert und anschließend als „bereinigt“ betrachtet werden.

Der Endpoint muss separat untersucht oder – wenn eine verlässliche Bereinigung nicht möglich ist – neu vertrauenswürdig aufgebaut werden. Erst danach sollten neue Zugangsdaten und Authentifizierungsmethoden verwendet werden.

Typischer Angreiferaufwand: ★★★☆☆

4.6 Szenario 6: OAuth- und Consent-Phishing – der Benutzer autorisiert die Anwendung selbst

Dieses Angriffsszenario unterscheidet sich grundlegend von den bisherigen Fällen. Der Täter muss nicht zwingend das Passwort erbeuten oder MFA überwinden. Stattdessen versucht er, eine Anwendung mit ausreichenden Rechten in den Microsoft-365-Tenant beziehungsweise in den Benutzerkontext zu bekommen.

4.6.1 Die Microsoft-Seite kann dabei tatsächlich echt sein

Eine angebliche PDF-Anwendung, ein Signaturdienst, eine Kalendererweiterung, ein KI-Assistent oder eine andere Cloud-Anwendung bittet um Zugriff. Der Benutzer wird zu Microsoft weitergeleitet und meldet sich dort an.

Die entscheidende Besonderheit: Die Microsoft-Seite kann tatsächlich echt sein. Auch der anschließend angezeigte Berechtigungsdialog kann vollständig von Microsoft stammen. Die Täuschung besteht dann nicht darin, eine Microsoft-Anmeldeseite zu fälschen, sondern eine bösartige Anwendung als vertrauenswürdigen Dienst erscheinen zu lassen.

Der Benutzer sieht beispielsweise, dass die Anwendung auf Profildaten, Dateien, Kalender oder E-Mails zugreifen möchte, und klickt auf „Akzeptieren“.

4.6.2 Was technisch passiert

Microsoft speichert die erteilte Zustimmung beziehungsweise die daraus resultierende Berechtigung. Die Anwendung kann anschließend im Rahmen dieser Rechte auf Microsoft-365-Ressourcen zugreifen. Abhängig vom Berechtigungsmodell und den gewährten Scopes kann sie beispielsweise Daten lesen oder Aktionen im Namen des Benutzers ausführen.

4.6.3 Warum ein Passwortwechsel hier nicht automatisch genügt

Ein Passwortwechsel adressiert ein kompromittiertes Passwort. Bei einem bösartigen App-Consent liegt das eigentliche Problem jedoch in der erteilten Autorisierung. Deshalb müssen Enterprise Applications, Service Principals, delegierte Berechtigungen und Consent Grants selbst untersucht und gegebenenfalls widerrufen werden.

Genau dadurch kann ein solcher Vorfall für Betroffene besonders irritierend wirken: Das Passwort wurde bereits geändert, MFA ist aktiviert – und trotzdem scheint weiterhin ungewöhnliche Aktivität stattzufinden.

4.6.4 Auch automatisierte oder KI-generierte Antworten können vollständig extern entstehen

Automatisch formulierte Antworten beweisen nicht, dass auf dem PC des Benutzers ein „Bot“ installiert wurde. Eine externe Anwendung kann bei ausreichender Berechtigung Nachrichten über Microsoft Graph oder andere unterstützte Schnittstellen abrufen, den Inhalt außerhalb des Tenants verarbeiten und anschließend wieder eine Antwort versenden.

Ein solcher Ablauf kann aus Sicht des Benutzers wie ein autonom handelndes kompromittiertes Postfach wirken, obwohl die eigentliche Automatisierung vollständig außerhalb seines Rechners stattfindet.

Typischer Angreiferaufwand: ★★★☆☆

4.7 Sonderfall: Das vermeintlich gehackte Postfach wurde selbst gar nicht kompromittiert

Gerade bei Shared Mailboxes, Funktionspostfächern und historisch gewachsenen Microsoft-365-Umgebungen sollte noch eine weitere Möglichkeit berücksichtigt werden: Der Angreifer hat möglicherweise nicht das sichtbare Zielpostfach übernommen, sondern ein anderes Konto, das bereits darauf zugreifen darf.

Ein Mitarbeiterkonto kann beispielsweise FullAccess und SendAs auf info@unternehmen.de besitzen. Wird dieses Mitarbeiterkonto kompromittiert, kann der Täter unter Umständen das Funktionspostfach benutzen, obwohl dessen eigene Anmeldeinformationen nie gestohlen wurden.

Noch weiter reicht eine kompromittierte administrative Identität. Ein Angreifer mit ausreichenden Rechten kann zusätzliche Mailboxberechtigungen vergeben und sich damit selbst oder einem anderen kontrollierten Konto Zugriff verschaffen.

Für die Aufklärung bedeutet das: Die Aussage „Aus info@ wurden fremde Nachrichten verschickt“ beweist nicht, dass jemand das Passwort von info@ kannte. Mailboxdelegationen, SendAs-Rechte und administrative Änderungen gehören deshalb immer in die Betrachtung.

6.1 Interactive bedeutet nicht automatisch „Passwort und MFA wurden gerade neu eingegeben“

Bei einem Interactive Sign-in befindet sich die Anmeldung in einem Benutzer-Authentifizierungsflow. Dabei kann eine Benutzereingabe erforderlich sein – beispielsweise Kennwort, MFA, Passkey oder Biometrie. Es ist aber nicht zwingend erforderlich, dass bei genau diesem Ereignis sämtliche Faktoren erneut abgefragt werden.

Microsoft kann bereits vorhandene Authentifizierungsnachweise berücksichtigen. In den Authentication Details kann deshalb beispielsweise erscheinen, dass eine Anforderung „Previously satisfied“ war oder ein vorhandener Claim bereits die MFA-Anforderung erfüllt hat.

Für den Benutzer kann ein solcher Vorgang vollkommen unspektakulär aussehen: Er öffnet eine Microsoft-365-Anwendung, der Browser durchläuft den Authentifizierungsprozess und die Ressource öffnet sich ohne neue Passwort- oder MFA-Abfrage. Trotzdem kann der zugehörige Sign-in als interaktiv klassifiziert sein.

6.2 Non-interactive bedeutet nicht automatisch „verdächtiger Hintergrundzugriff“

Bei einem Non-interactive Sign-in arbeitet eine Anwendung oder Betriebssystemkomponente im Namen des Benutzers, ohne für diesen Vorgang eine neue unmittelbare Benutzereingabe anzufordern.

Ein typisches Beispiel ist Outlook. Der Benutzer hat sich bereits erfolgreich angemeldet. Später muss ein Zugriffstoken erneuert werden. Die Anwendung verwendet dafür den vorhandenen Authentifizierungskontext und bezieht ein neues Token, ohne dass der Benutzer erneut etwas eingeben muss.

Solche Ereignisse gehören zum normalen Microsoft-365-Betrieb. Ein Non-interactive Sign-in ist deshalb keineswegs automatisch verdächtig. Gleichzeitig kann auch ein Angreifer einen zuvor erlangten Authentifizierungskontext auf diese Weise weiterverwenden.

6.3 Die Klassifizierung allein beantwortet nicht, ob ein Angreifer beteiligt war

Für eine forensische Bewertung darf deshalb nicht nur die Spalte „Interactive / Non-interactive“ betrachtet werden. Erst die Kombination aus Zeitpunkt, IP-Adresse, Anwendung, Zielressource, Client, Gerät, Authentication Details und den unmittelbar davor und danach stattfindenden Ereignissen ergibt ein sinnvolles Bild.

Auch der Standort ist nur ein Indiz. Ein Login aus einem anderen Land kann auffällig sein, aber Angreifer können deutsche VPN-Endpunkte, Residential Proxies oder kompromittierte Rechner innerhalb Deutschlands verwenden. Umgekehrt können legitime Benutzer durch Reisen, Mobilfunknetze oder Unternehmens-VPNs unerwartete Geolokationen erzeugen.

7.1 Entra Sign-in Logs: Wie wurde auf die Identität zugegriffen?

In den Sign-in Logs interessiert zunächst, welche erfolgreichen und fehlgeschlagenen Anmeldungen im relevanten Zeitraum stattgefunden haben. Auffällige IP-Adressen, bislang unbekannte Geräte, abweichende Browser oder Betriebssysteme und ungewöhnliche Anwendungen können wichtige Hinweise liefern.

Besonders wichtig sind die Authentication Details. Sie helfen zu unterscheiden, ob bei einem Ereignis tatsächlich ein Faktor neu erbracht wurde oder ob Microsoft bereits vorhandene Claims beziehungsweise einen bestehenden Authentifizierungskontext akzeptiert hat.

Ein einzelner auffälliger Login sollte möglichst mit dem weiteren Ablauf korreliert werden: Wann wurde die erste verdächtige Mail versendet? Wann tauchte eine Weiterleitungsregel auf? Wann wurde einer Anwendung eine Berechtigung erteilt? Je enger solche Ereignisse zeitlich zusammenliegen, desto belastbarer wird die Rekonstruktion.

7.2 Entra Audit Logs: Wurde die Identität oder ihre Autorisierung verändert?

Im Entra Audit Log sucht man nicht nach gelöschten E-Mails oder Outlook-Inbox-Regeln. Dort geht es um Änderungen im Identitäts- und Verzeichnisbereich.

• Wurde eine neue Authentifizierungsmethode registriert?
• Wurde eine vorhandene MFA-Methode verändert oder entfernt?
• Wurde einer Anwendung ein Consent erteilt?
• Wurde ein delegated permission grant hinzugefügt?
• Wurde einem Service Principal eine App-Rolle zugewiesen?
• Wurde eine Enterprise Application oder ein Service Principal angelegt oder verändert?
• Wurde einem Benutzer eine privilegierte Rolle zugewiesen?
• Wurde das betroffene Benutzerkonto selbst verändert?

Diese Informationen sind besonders wichtig, wenn ein Täter nach dem ersten Zugriff versucht hat, eine langlebigere Zugriffsmöglichkeit einzurichten. Eine neu hinzugefügte Authenticator-Methode oder eine bösartige Enterprise Application kann wesentlich folgenreicher sein als die zuerst entdeckte Inbox-Regel.

7.3 Purview / Unified Audit: Was geschah in Exchange und Microsoft 365?

Exchange-spezifische Handlungen gehören dagegen in das dienstübergreifende Microsoft-365-Audit beziehungsweise Purview Audit. Dort können – abhängig von Lizenzierung, aktivierter Protokollierung und Ereignistyp – unter anderem Inbox-Regeln, Mailboxänderungen, Sendevorgänge und Löschaktionen nachvollzogen werden.

Gerade bei älteren oder sehr kleinen Tenants sollte geprüft werden, ob die entsprechende Audit-Erfassung zum Zeitpunkt des Vorfalls tatsächlich aktiv war. Eine nachträgliche Aktivierung erzeugt keine historischen Ereignisse für einen Zeitraum, in dem nichts protokolliert wurde.

7.4 Message Trace: Welche Nachrichten haben das System tatsächlich verlassen?

Exchange Message Trace ist besonders wertvoll, wenn ein Täter ausgehende Nachrichten anschließend aus dem sichtbaren Ordner „Gesendet“ entfernt hat. Der Mailtransport ist von dieser Ordneransicht unabhängig.

Damit lässt sich häufig feststellen, wann ein ungewöhnlicher Versand begann, welche Empfänger betroffen waren und wann die Aktivität endete. Der Zeitpunkt der ersten nachweislich missbräuchlichen Nachricht ist außerdem ein sinnvoller Anker, um in den Sign-in- und Audit-Logs zeitlich zurückzugehen und nach dem unmittelbar vorausgehenden Zugriff zu suchen.

7.5 Bei kleinen Tenants ist Zeit ein entscheidender Faktor

Bei Microsoft Entra ID Free werden Entra Sign-in Logs und Entra Audit Logs nur für einen vergleichsweise kurzen Zeitraum vorgehalten. Höhere Entra-Lizenzstufen bieten längere reguläre Aufbewahrungszeiten. Ein späteres Lizenzupgrade stellt bereits abgelaufene Daten nicht rückwirkend wieder her.

Wird ein Sicherheitsvorfall erst Tage später bemerkt, kann deshalb gerade der ursprüngliche Einstieg bereits aus dem sichtbaren Logzeitraum verschwunden sein. Dann sind eventuell nur noch spätere Non-interactive Vorgänge, Exchange-Aktivitäten oder andere Folgeereignisse vorhanden.

Das ist auch der Grund, warum das Fehlen eines verdächtigen Interactive Sign-ins keine sichere Entwarnung darstellt. Der ursprüngliche Authentifizierungsvorgang kann schlicht außerhalb des noch verfügbaren Zeitfensters liegen.

8.1 Eintritt: Wie entstand der erste unberechtigte Zugriff?

Hier wird nach der eigentlichen Ursache gefragt. Wurde ein Passwort gestohlen? Hat der Benutzer eine fremde Anmeldung bestätigt? Wurde eine Sitzung über AiTM übernommen? Stammt der Zugriff von einem kompromittierten Endgerät? Oder wurde einer Anwendung eine missbräuchliche Berechtigung erteilt?

Diese Frage ist entscheidend für die zukünftige Absicherung. Wer den Eintrittsweg nicht kennt, kann zwar sichtbare Manipulationen entfernen, weiß aber nicht zuverlässig, welche Schutzmaßnahme eine Wiederholung verhindert.

8.2 Persistenz: Wie kann der Zugriff nach dem ersten Einbruch fortbestehen?

Nach einem erfolgreichen Zugriff kann ein Täter versuchen, sich vom ursprünglichen Einbruchsweg unabhängiger zu machen. Denkbar sind beispielsweise weiterhin gültige Sessions, eine zusätzlich registrierte Authentifizierungsmethode, ein App-Consent, neue Mailboxberechtigungen oder ein weiteres kontrolliertes Konto.

Genau deshalb kann ein Passwortwechsel allein unzureichend sein. Er beseitigt das bekannte Passwort als zukünftigen Anmeldeweg, nicht automatisch sämtliche anderen bereits entstandenen Zugriffsmöglichkeiten.

8.3 Missbrauch: Was hat der Angreifer tatsächlich getan?

Erst die dritte Ebene betrifft den sichtbaren Schaden. Wurden Nachrichten gelesen? Wurden Kunden angeschrieben? Wurde eine Zahlungsaufforderung verändert? Wurden Nachrichten gelöscht, weitergeleitet oder automatisiert beantwortet?

Bei Business-E-Mail-Compromise ist dieser Teil besonders wichtig. Ein Angreifer kann über längere Zeit lediglich mitlesen und auf den passenden Moment warten, um sich beispielsweise in eine laufende Rechnungs- oder Zahlungsabwicklung einzuschalten. Das Fehlen großer Mengen versendeter Spam-Nachrichten bedeutet deshalb nicht automatisch, dass der Vorfall geringfügig war.

11.1 Für kleine Unternehmen ist eine überschaubare, konsequente Konfiguration oft wertvoller als unnötige Komplexität

Nicht jeder kleine Betrieb benötigt eine hochkomplexe Enterprise-Zero-Trust-Architektur. Gerade bei wenigen Benutzern können bereits sauber gepflegte Konten, aktuelle Security Defaults beziehungsweise passende Conditional-Access-Regeln, starke Authentifizierungsmethoden, klare Administratorrollen und eine überschaubare Liste autorisierter Anwendungen einen erheblichen Sicherheitsgewinn bringen.

Problematisch sind dagegen historisch gewachsene Tenants, bei denen niemand mehr genau weiß, welche Benutzer noch existieren, welche Dienstleister Administratorrechte besitzen, welche Anwendungen irgendwann autorisiert wurden und welche Mailboxberechtigungen noch aus früheren Projekten stammen.

Microsoft-365-Sicherheit besteht deshalb nicht nur aus einer Einstellung. Sie hängt auch davon ab, wie nachvollziehbar der Tenant administriert wird.

11.2 „Passkey eingerichtet“ und „phishing-resistente Anmeldung erzwungen“ sind zwei verschiedene Aussagen

Besonders für Administratoren und andere sensible Konten sollte nicht nur geprüft werden, ob ein Passkey oder FIDO2-Schlüssel vorhanden ist. Entscheidend ist, ob ein Benutzer für denselben Zugriff auf eine schwächere Methode ausweichen könnte.

Genau hier liegt der praktische Mehrwert von Authentication Strengths. Sie erlauben es, für definierte Zugriffe die tatsächlich akzeptierte Mindeststärke festzulegen, statt lediglich darauf zu hoffen, dass der Benutzer die stärkste registrierte Methode auswählt.