Kali365: Wie die Phishing-Plattform MFA in Microsoft 365 aushebelt, und wie Conditional Access davor schützt

Kategorie

Phishing & Identity Security

Thema

Kali365 / Device-Code-Phishing

Zielgruppe

IT-Leitung, M365-Admins, CISOs

Lesezeit

ca. 11 Minuten

Die Zeiten, in denen Multi-Faktor-Authentifizierung (MFA) als „gelöstes Problem“ galt, sind vorbei. Seit April 2026 verbreitet sich eine Phishing-as-a-Service-Plattform namens Kali365, die genau das ausnutzt, worauf sich viele Unternehmen bislang verlassen haben: MFA schützt nicht mehr vor dem Login selbst, sondern nur noch vor dem Erraten eines Passworts. Das FBI und die amerikanische Cybersicherheitsbehörde CISA haben in einer gemeinsamen Warnung ausdrücklich vor Kali365 gewarnt, weil die Plattform es auch technisch wenig versierten Angreifern erlaubt, Microsoft-365-Konten vollständig zu übernehmen, ohne ein Passwort zu stehlen und ohne eine einzige MFA-Abfrage zu umgehen. In diesem Beitrag zeigen wir genau, wie der Angriff technisch funktioniert, warum MFA dabei wirkungslos bleibt, und wie Conditional Access und Security-Awareness wirksam schützt.

Das FBI hat am 21. Mai 2026 eine offizielle Public Service Announcement (PSA) über die Internet Crime Complaint Center (IC3) veröffentlicht. Darin warnt die Behörde ausdrücklich vor Kali365 und beschreibt den Angriffsablauf in vier Schritten. Auch CISA hat die Warnung aufgegriffen und Unternehmen aufgefordert, Device-Code-Flow einzuschränken und auf phishing-resistente Authentifizierung umzusteigen.

Warum MFA allein heute keinen Schutz mehr bietet

Klassisches Phishing zielt auf das Passwort. MFA wurde genau dafür entwickelt und funktioniert dort nach wie vor gut: Wer nur das Passwort kennt, kommt ohne den zweiten Faktor nicht weiter. Kali365 und vergleichbare Angriffstechniken wie Adversary-in-the-Middle-Phishing (AiTM) und Device-Code-Phishing setzen aber gar nicht mehr am Passwort an. Sie zielen auf das, was nach einer erfolgreichen Anmeldung entsteht: das Sitzungstoken (Access- und Refresh-Token), das Microsoft Entra ID nach abgeschlossener MFA-Prüfung ausstellt.

Dieses Token ist der digitale Ausweis, der einem Gerät bestätigt: „Diese Person hat sich soeben erfolgreich mit Passwort und zweitem Faktor angemeldet.“ Wer dieses Token besitzt, muss sich nicht mehr anmelden, er ist bereits angemeldet. Genau dieses Token ist es, was Kali365 abgreift, nicht das Passwort und nicht den MFA-Code.

So läuft der Kali365-Angriff im Detail ab

Kali365 missbraucht dafür keine Sicherheitslücke, sondern eine ganz legitime Microsoft-Funktion: den OAuth 2.0 Device Authorization Grant, besser bekannt als Device-Code-Flow. Dieser wurde ursprünglich dafür entwickelt, Geräte ohne eigene Tastatur oder Browser, etwa Smart-TVs, Streaming-Boxen, Drucker oder Konferenzraum-Systeme, über ein zweites Gerät anzumelden. Der Nutzer ruft dazu die echte Microsoft-Seite microsoft.com/devicelogin auf und gibt dort einen kurzen Code ein, den ihm das Gerät angezeigt hat. Der Angriff läuft laut FBI-Advisory in vier Schritten ab:

Der Köder

Das Opfer erhält eine täuschend echte Phishing-Mail, die eine vertrauenswürdige Cloud- oder Dokumenten-Freigabe imitiert, zum Beispiel eine angebliche SharePoint- oder Teams-Benachrichtigung. Die Mail enthält einen Gerätecode und die Aufforderung, diesen auf einer „Verifizierungsseite“ einzugeben.

Die Autorisierung

Das Opfer klickt auf den Link und landet nicht auf einer gefälschten Seite, sondern tatsächlich auf der echten Microsoft-Seite microsoft.com/devicelogin. Dort gibt es den vom Angreifer bereitgestellten Code ein und bestätigt die Anmeldung, meist inklusive der eigenen MFA-Abfrage. Es gibt keine gefälschte Domain, keinen Tippfehler in der URL und keine verdächtige Login-Maske zu erkennen.

Der Tokendiebstahl

Im Hintergrund fordert die Kali365-Plattform selbst genau diesen Gerätecode bei Microsoft an. Sobald das Opfer den Code bestätigt und seine MFA absolviert, stellt Microsoft das Access- und Refresh-Token nicht dem Opfer, sondern dem Gerät des Angreifers aus. Der Angreifer erhält damit ein vollständig gültiges, MFA-bestätigtes Sitzungstoken, ohne selbst jemals einen Faktor eingeben zu müssen.

Die Persistenz

Mit dem gestohlenen Token hat der Angreifer sofortigen Zugriff auf Outlook, Teams, OneDrive und SharePoint sowie auf jede weitere per Single-Sign-On angebundene SaaS-Anwendung, ganz ohne Passwort und ohne erneute MFA-Abfrage. Refresh-Tokens sind zudem oft über Wochen gültig.

Genau hier liegt die Antwort auf die Frage, warum MFA nicht hilft: Die MFA-Prüfung findet ganz normal statt, nur eben auf dem Gerät des Angreifers und nicht auf einem, das dem Unternehmen gehört. Das Opfer erledigt die MFA-Bestätigung quasi stellvertretend für den Angreifer. Es gibt keinen Moment im Ablauf, an dem ein klassischer zweiter Faktor den Zugriff noch verhindern könnte, denn der Angreifer braucht ihn nicht selbst zu besitzen.

Nach FBI-Angaben bietet Kali365 seinen Kunden dazu ein komfortables Dashboard mit KI-generierten Phishing-Vorlagen, automatisierten Kampagnen und einer Live-Übersicht, welche Opfer bereits den Code eingegeben haben, inklusive automatischer Übergabe der erbeuteten Tokens.

Wie einfach ist es, sich Kali365 zu „buchen“?

Das eigentlich Beunruhigende an Kali365 ist nicht die Technik im Hintergrund, sondern der Vertriebsweg. Laut FBI und mehreren Sicherheitsanalysten wird Kali365 offen über Telegram-Kanäle als monatliches Abonnement angeboten, im klassischen Software-as-a-Service-Modell. Wer bezahlt, bekommt Zugang zu einem Web-Dashboard, fertigen Phishing-Vorlagen, KI-gestützten Textgeneratoren für die Köder-Mails und einer Tracking-Oberfläche für die laufende Kampagne. Programmierkenntnisse, Server-Administration oder Wissen über OAuth-Flows braucht dafür niemand mehr, das übernimmt die Plattform vollständig.

Damit sinkt die Einstiegshürde für diese Art von Angriff auf nahezu null. Aus Sicht eines Unternehmens bedeutet das: Die Bedrohung geht nicht mehr nur von hochspezialisierten Angreifergruppen aus, sondern potenziell von jedem, der ein paar Dutzend Euro für ein Abo übrig hat. Genau deshalb stufen FBI und CISA Kali365 als so gefährlich ein und begründen damit auch die Dringlichkeit ihrer gemeinsamen Warnung.

Was passiert nach einer erfolgreichen Kompromittierung?

Ein gestohlenes Token ist für Angreifer kein Selbstzweck, sondern der Startpunkt für die eigentliche Angriffskette. In den vom FBI und von Sicherheitsdienstleistern dokumentierten Fällen laufen danach typischerweise mehrere Schritte automatisiert oder halbautomatisiert ab:

📂

Datenabfluss über OneDrive & SharePoint

Der Angreifer durchsucht mit dem gültigen Token systematisch OneDrive, SharePoint und Teams-Dateien des Opfers nach sensiblen Dokumenten, Zugangsdaten oder Finanzunterlagen und lädt diese in großem Umfang herunter.

📥

Verdeckte Postfachregeln

Im Outlook-Postfach werden unauffällige Regeln angelegt, die bestimmte Antworten (etwa auf Betrugsversuche oder Rückfragen von Kollegen) automatisch in versteckte Unterordner verschieben oder löschen, damit das Opfer den Missbrauch möglichst spät bemerkt.

✉️

Missbrauch für weiteres Phishing

Über das kompromittierte, vertrauenswürdige Postfach verschickt der Angreifer weitere Phishing- und Spam-Mails an Kollegen, Kunden und Partner, die diesen Absendern typischerweise eher vertrauen als einer fremden Adresse.

🔑

Ausweitung auf weitere Systeme

Da ein Microsoft-365-Konto häufig per Single-Sign-On auch Zugriff auf weitere SaaS-Dienste wie Salesforce oder HR-Systeme gewährt, nutzt der Angreifer das Token, um sich lateral in weitere Cloud-Anwendungen des Unternehmens auszubreiten.

Weil weder ein Passwort geändert noch ein ungewöhnlicher MFA-Prompt ausgelöst wird, bleiben solche Kompromittierungen oft wochenlang unentdeckt. Erste verlässliche Warnsignale sind unbekannte Geräteregistrierungen, Anmeldungen aus ungewöhnlichen Regionen sowie neue, vom Nutzer nicht selbst angelegte Weiterleitungs- oder Postfachregeln in den Microsoft-365-Anmelde- und Prüfprotokollen.

Der wirksamste Hebel: Device-Code-Flow per Conditional Access einschränken

Da der Angriff eine legitime Microsoft-Funktion missbraucht, hilft kein Virenscanner und keine zusätzliche MFA-Methode allein. Der zuverlässigste Schutz ist, den Device-Code-Flow für alle Konten zu blockieren, die ihn nicht tatsächlich benötigen. Microsoft selbst empfiehlt genau das über eine eigene Bedingung in Conditional Access. So richtet ihr die Regel im Microsoft Entra Admin Center Schritt für Schritt ein:

Im Microsoft Entra Admin Center anmelden, mindestens mit der Rolle Conditional Access Administrator.
Im linken Menü zu Schutz (Protection) → Conditional Access → Richtlinien (Policies) navigieren.
Oben auf Neue Richtlinie (New policy) klicken und einen eindeutigen Namen vergeben, zum Beispiel „Block Device Code Flow (außer Ausnahmen)“.
Unter Zuweisungen (Assignments) → Benutzer (Users) auf „Einschließen“ Alle Benutzer auswählen. Unter „Ausschließen“ mindestens eure Notfallzugriffskonten (Break-Glass-Accounts) eintragen, damit ihr euch bei einer Fehlkonfiguration nicht selbst aussperrt.
Unter Zielressourcen (Target resources) die Option Cloud-Apps wählen und dort Alle Cloud-Apps einschließen.
Zum Abschnitt Bedingungen (Conditions) → Authentifizierungsabläufe (Authentication flows) wechseln, „Konfigurieren“ auf Ja stellen und dort Gerätecodeflow (Device code flow) aktivieren. Mit „Fertig“ bestätigen.
Im Bereich Zugriffssteuerung (Access controls) → Gewähren (Grant) die Option Zugriff blockieren (Block access) auswählen und mit „Auswählen“ bestätigen.
Ganz unten „Richtlinie aktivieren (Enable policy)“ zunächst auf Nur Bericht (Report-only) stellen und mit Erstellen (Create) speichern.
Die Auswirkung einige Tage lang über „Policy Impact“ bzw. die Anmeldeprotokolle beobachten. Erst wenn keine unerwarteten Blockaden auftreten, die Richtlinie von „Nur Bericht“ auf Ein (On) umstellen.

Wichtiger Hinweis zur Aktualität: Die Bezeichnungen und die Menüführung im Entra Admin Center ändern sich immer wieder leicht. Prüft die aktuellen Klickpfade daher zusätzlich in der offiziellen Microsoft-Dokumentation, bevor ihr die Richtlinie produktiv schaltet.

📹 Ausnahmen für Konferenzsysteme nicht vergessen

Wer die Regel wie oben beschrieben auf „Alle Cloud-Apps“ und „Alle Benutzer“ anwendet, blockiert damit auch legitime Nutzung des Device-Code-Flows. Konferenzraumsysteme, Teams-Rooms-Geräte, manche Streaming-Boxen, Drucker und ältere IoT-Geräte melden sich häufig genau über diesen Mechanismus an. Bevor ihr die Regel scharf schaltet, solltet ihr daher in den Entra-Anmeldeprotokollen gezielt nach dem Authentifizierungsprotokoll „Device Code“ filtern, um herauszufinden, welche Konten und Geräte diesen Flow tatsächlich brauchen.

Legt für diese Geräte anschließend eine eigene Sicherheitsgruppe an (zum Beispiel „Ausnahme Device-Code-Flow – Konferenzräume“) und tragt diese Gruppe unter „Zuweisungen → Benutzer → Ausschließen“ in eurer Blockier-Richtlinie ein. So bleibt der Login der Konferenzraum-Systeme funktionsfähig, während für alle regulären Benutzerkonten der Device-Code-Flow konsequent gesperrt ist. Diese Ausnahmeliste sollte dokumentiert und regelmäßig überprüft werden, damit sie nicht unbemerkt wächst und zu einem eigenen Einfallstor wird.

Conditional Access reicht allein nicht, Awareness gehört dazu

Conditional Access schließt bei Kali365 den technischen Angriffsweg. Es ändert aber nichts daran, dass der Angriff mit einer glaubwürdigen Phishing-Mail beginnt, die einen Menschen zu einer Handlung bewegen will. Solange Mitarbeitende E-Mails mit Gerätecodes ungeprüft folgen, funktionieren auch abgewandelte Varianten dieser Angriffstechnik, sei es über andere OAuth-Flows, QR-Codes oder neue, aktuell noch unbekannte Tricks.

Unser Rat: Kombiniert technische Kontrollen mit gezielter Phishing-Awareness. Mitarbeitende sollten konkret lernen, wie ein Device-Code-Login aussieht, warum eine unaufgeforderte Aufforderung, einen Code auf microsoft.com/devicelogin einzugeben, grundsätzlich misstrauisch machen sollte, und an wen sie sich im Zweifel wenden können, bevor sie den Code bestätigen.

Wie Mint Secure euch dabei unterstützt

Wir helfen Unternehmen dabei, sich gegen genau diese Art von Identitätsangriffen abzusichern, technisch und organisatorisch:

Conditional-Access-Assessment

Wir prüfen euren Microsoft-365-Tenant auf riskante Authentifizierungsabläufe, identifizieren echte Device-Code-Flow-Nutzer und entwerfen mit euch passgenaue, produktionstaugliche Conditional-Access-Richtlinien inklusive Ausnahmen.

Phishing-Simulationen & Awareness-Trainings

Mit realitätsnahen Kampagnen, auch zu Device-Code-Phishing, schulen wir eure Mitarbeitenden praxisnah und messen den Trainingserfolg über die Zeit.

Incident Response

Im Ernstfall unterstützen wir bei der forensischen Aufarbeitung eines Kontodiebstahls, dem Aufspüren manipulierter Postfachregeln und der schnellen Eindämmung des Vorfalls.

M365-Security-Health-Check

Wir bewerten euren gesamten Microsoft-365-Tenant gegen aktuelle Bedrohungen und Best Practices, weit über Conditional Access hinaus.

Ihr wollt wissen, ob euer Tenant für Device-Code-Phishing wie Kali365 anfällig ist? Wir prüfen eure Conditional-Access-Konfiguration und schließen gemeinsam mit euch die Lücke. Jetzt Kontakt aufnehmen.