Device-Code-Phishing in Microsoft 365 erkennen und verhindern

Montagmorgen, 9:17 Uhr: Eine Nachricht in Teams wirkt dringend. Der angebliche IT-Support bittet dich, zur „Sicherheitsprüfung“ einen Code auf einer Microsoft-Anmeldeseite einzugeben. Die Seite sieht echt aus, die Adresse gehört tatsächlich zu Microsoft, und anschließend erscheint sogar deine gewohnte MFA-Abfrage. Genau das macht Device-Code-Phishing so gefährlich: Nicht zwingend eine gefälschte Website stiehlt Zugangsdaten, sondern ein Angreifer missbraucht einen legitimen Anmeldevorgang und verleitet dich dazu, seinen Login zu bestätigen.

Beim Device-Code-Phishing nutzen Angreifer den Gerätecodefluss von Microsoft Entra ID. Dieser ist für Geräte und Anwendungen gedacht, die keinen vollwertigen Browser zur Anmeldung bereitstellen können, etwa bestimmte Kommandozeilenprogramme, Smart-TVs oder spezialisierte Clients. Der Ablauf ist legitim. Missbraucht wird er erst durch Social Engineering.

Infografik zu Device-Code-Phishing in Microsoft 365 erkennen und verhindern (KI-generiert).

So funktioniert der Angriff technisch

Ein Angreifer startet zunächst selbst eine Anmeldung bei einer Anwendung, die den Gerätecodefluss unterstützt. Microsoft stellt dafür einen zeitlich begrenzt gültigen Code und eine Anmeldeseite bereit. Anschließend muss ein Benutzer den Code auf der Microsoft-Seite eingeben und sich anmelden.

Der Angreifer schickt diesen Code nun an sein Opfer. Dafür verwendet er häufig:

• gefälschte Teams-Nachrichten im Namen des Service Desk
• E-Mails mit einer angeblichen Aufforderung zur Kontoprüfung
• QR-Codes in E-Mails, Chats oder Dokumenten
• kompromittierte interne Konten, deren Nachrichten besonders glaubwürdig wirken
• fingierte Hinweise auf ablaufende Sitzungen, neue Sicherheitsrichtlinien oder dringende Freigaben

Gibt die betroffene Person den Code ein und schließt die Anmeldung inklusive MFA ab, bestätigt sie nicht ihr eigenes Gerät. Sie autorisiert die vom Angreifer gestartete Sitzung. Dieser kann anschließend je nach Anwendung und erteilten Berechtigungen Tokens erhalten und auf Microsoft-365-Dienste zugreifen.

Der kritische Punkt: Die Microsoft-Seite kann dabei vollkommen echt sein. Auch MFA greift technisch korrekt. Deshalb ist die verbreitete Regel „Achte auf die URL“ zwar weiterhin wichtig, reicht hier aber nicht aus. Entscheidend ist zusätzlich die Frage: Habe ich diesen Anmeldevorgang selbst gestartet und gehört der angezeigte Code zu meinem eigenen Gerät oder meiner eigenen Anwendung?

Warum MFA und Passkeys allein nicht genügen

MFA schützt besonders wirksam gegen gestohlene Passwörter. Beim Device-Code-Phishing wird jedoch kein Passwort abgegriffen, das später wiederverwendet wird. Der Angreifer versucht vielmehr, dich dazu zu bringen, eine echte Anmeldung unmittelbar für seine Sitzung zu bestätigen.

Auch phishing-resistente Methoden wie Passkeys verbessern den Schutz erheblich, weil sie viele klassische Phishing-Angriffe unterbinden. Sie ersetzen aber keine klare Regel für Beschäftigte: Einen Gerätecode darfst du nur eingeben, wenn du den Anmeldevorgang selbst ausgelöst hast und eindeutig weißt, für welche Anwendung er benötigt wird.

Wenn du Passkeys in deinem Mandanten einführen möchtest, findest du in unserem Beitrag Passkeys im Unternehmen einführen: Phishing-resistente Anmeldung mit Microsoft Entra ID wichtige Grundlagen für Planung und Rollout.

Diese Warnsignale sollte dein Team kennen

Die überzeugendsten Device-Code-Angriffe arbeiten mit Zeitdruck und einem plausiblen Vorwand. Eine Nachricht kann technisch sauber formuliert sein, ein echtes Firmenlogo enthalten oder sogar von einem kompromittierten Kollegen stammen. Beurteile deshalb immer den Kontext, nicht nur die Gestaltung.

Situation	Warum sie verdächtig ist	Richtiges Verhalten
Du erhältst ungefragt einen Gerätecode.	Du hast keine Anmeldung gestartet.	Code nicht eingeben und Nachricht melden.
Jemand fordert dich im Chat zur MFA-Freigabe auf.	Support-Mitarbeitende brauchen keine Freigabe für deine Sitzung.	Keine Freigabe bestätigen, Rückruf über bekannten Kanal.
Ein QR-Code soll ein Sicherheitsproblem lösen.	QR-Codes verschleiern Ziel und Kontext.	Nicht scannen, sondern den Vorgang über offizielle Wege prüfen.
Es wird mit Kontosperrung oder Frist gedroht.	Zeitdruck soll Nachfragen verhindern.	Ruhe bewahren und Vorgang unabhängig verifizieren.
Die Anmeldeseite gehört tatsächlich zu Microsoft.	Die Website kann echt sein, der Anlass aber betrügerisch.	Nur fortfahren, wenn du die Anmeldung selbst gestartet hast.

Besonders wichtig ist eine einfache, gut merkbare Formulierung für Awareness-Maßnahmen: „Gib niemals einen Code ein und bestätige niemals eine Anmeldung, die du nicht selbst ausgelöst hast.“

Diese Regel gehört in Onboarding-Unterlagen, Phishing-Simulationen, kurze Teams-Hinweise und die Kommunikation des Service Desk. Weitere typische Angriffsmuster und wirksame Gegenmaßnahmen erklären wir in unserem Beitrag Social Engineering: die Maschen kennen und abwehren. Für allgemeine verdächtige Nachrichten und ihre Prüfung hilft außerdem Phishing erkennen und richtig reagieren.

Gerätecodefluss in Entra ID sinnvoll absichern

Technische Maßnahmen reduzieren die Angriffsfläche deutlich. Beginne aber nicht mit einem ungetesteten pauschalen Verbot. Prüfe zuerst, welche Anwendungen und Arbeitsabläufe in deinem Unternehmen den Gerätecodefluss tatsächlich benötigen. Das können administrative Werkzeuge, Spezialsoftware, Entwicklungsumgebungen oder Geräte ohne Browser sein.

1. Nutzung erfassen und fachlich bewerten

Prüfe Anmeldeprotokolle in Entra ID auf Hinweise zum Gerätecodefluss. Je nach Ansicht und Protokolldetails lässt sich der verwendete Authentifizierungsfluss erkennen. Dokumentiere dabei:

• welche Benutzer und Gruppen den Ablauf verwenden
• welche Anwendungen beteiligt sind
• ob die Nutzung regelmäßig oder nur einmalig vorkommt
• ob es einen dokumentierten fachlichen Grund gibt
• ob eine browsergestützte oder andere sichere Anmeldung möglich ist

Hole für echte Ausnahmen die verantwortlichen Fachbereiche, Administratoren und Anwendungseigentümer ins Boot. Eine Ausnahme ohne Eigentümer und Ablaufdatum wird schnell zur dauerhaften Lücke.

2. Gerätecodefluss standardmäßig blockieren

Wenn dein Unternehmen den Gerätecodefluss nicht benötigt, solltest du ihn mandantenweit deaktivieren oder durch eine passende Conditional-Access-Richtlinie blockieren. In Microsoft Entra ID stehen dafür Einstellungen für Authentifizierungsflüsse sowie Richtlinien zur Steuerung des Gerätecodeflusses zur Verfügung.

Teste die Wirkung vor dem produktiven Rollout mit einer kleinen Benutzergruppe. Prüfe insbesondere administrative Prozesse und Anwendungen außerhalb des klassischen Microsoft-365-Alltags. Das Ziel ist klar: Der Gerätecodefluss soll nur dort verfügbar sein, wo er nachweislich erforderlich ist.

Ausnahmen sollten möglichst eng gefasst sein. Beschränke sie auf konkret benötigte Gruppen, überprüfe sie regelmäßig und schütze betroffene Konten besonders sorgfältig. Pauschale Ausnahmen für alle Administratoren oder ganze Abteilungen sind keine gute Lösung.

3. MFA, Zugriffsrichtlinien und Kontoschutz ergänzen

MFA bleibt unverzichtbar, auch wenn sie diese Angriffsmethode nicht allein stoppt. Ergänze sie durch risikobasierte Zugriffsentscheidungen, restriktive Anmelderichtlinien und eine saubere Trennung administrativer Konten von normalen Benutzerkonten.

Wichtig sind außerdem:

• getrennte Konten für Administration und tägliche Büroarbeit
• möglichst wenige dauerhaft privilegierte Berechtigungen
• kontrollierte externe Zusammenarbeit in Teams
• nachvollziehbare Meldewege für verdächtige Nachrichten
• regelmäßige Prüfung von MFA-Methoden und hinterlegten Authentifikatoren

Auch unerwartete Zustimmungen zu Anwendungen können ein Einfallstor sein. Wie du riskante Berechtigungen und manipulierte Freigabeanfragen reduzierst, zeigen wir in OAuth-Apps im Microsoft-365-Tenant absichern: Consent Phishing erkennen und verhindern.

Ablauf für den Verdachtsfall

Mitarbeitende müssen wissen, dass eine schnelle Meldung wichtiger ist als die Sorge, einen Fehler gemacht zu haben. Formuliere deinen Prozess deshalb einfach und ohne Schuldzuweisung.

Wenn noch kein Code eingegeben wurde

• Nachricht, Absender, Uhrzeit und gegebenenfalls Screenshot sichern.
• Nicht antworten, keinen Link öffnen und keinen QR-Code scannen.
• Den Vorfall über den bekannten Security- oder Service-Desk-Kanal melden.
• Bei angeblich internen Anfragen die Person über eine bekannte Telefonnummer oder einen etablierten Chatkontakt verifizieren.

Wenn ein Code eingegeben oder eine MFA-Anfrage bestätigt wurde

• Den Vorfall sofort an Security oder IT melden.
• Das Konto bei begründetem Verdacht vorübergehend sperren oder den Zugriff gezielt unterbrechen.
• Aktive Sitzungen und Refresh Tokens im betroffenen Konto widerrufen.
• Passwort zurücksetzen, insbesondere wenn nicht sicher ist, welche Eingaben erfolgt sind.
• MFA-Methoden auf unbekannte Änderungen prüfen und nicht bekannte Methoden entfernen.
• Anmeldeprotokolle, Auditdaten und Aktivitäten im relevanten Zeitraum sichern und auswerten.
• Postfachregeln, Weiterleitungen, delegierte Zugriffe, App-Zustimmungen und auffällige Dateizugriffe prüfen.

Beachte: Ein Sitzungswiderruf beendet nicht zwingend jeden bereits ausgegebenen Zugriffstoken im selben Moment. Deshalb gehören Protokollanalyse und eine Bewertung möglicher Folgeaktivitäten immer dazu. Einen strukturierten Prozess für Untersuchung, Eindämmung und Nachbereitung findest du in unserem Beitrag Incident Response: was tun im Ernstfall.

Awareness so aufbauen, dass sie im Alltag wirkt

Eine jährliche Pflichtunterweisung allein reicht nicht. Device-Code-Phishing ist erfolgreich, weil die Anfrage im Arbeitsalltag plausibel wirkt. Trainiere deshalb konkrete Situationen: eine Teams-Nachricht des angeblichen Support, einen QR-Code im E-Mail-Anhang oder eine MFA-Anfrage während eines Videocalls.

Dein Team sollte drei Fragen automatisch stellen:

• Habe ich diese Anmeldung selbst gestartet?
• Weiß ich genau, welche Anwendung oder welches Gerät den Code benötigt?
• Kann ich den Auftrag über einen unabhängigen, bekannten Kontakt prüfen?

Wenn eine dieser Fragen nicht eindeutig mit „Ja“ beantwortet werden kann, wird nichts bestätigt. Passende Seminare und Termine findest du bei uns auf cmt.de.

Device-Code-Phishing zeigt besonders deutlich: Sicherheit entsteht aus dem Zusammenspiel von Entra-ID-Konfiguration, klaren Prozessen, wirksamer Meldestruktur und aufmerksamen Menschen. Blockiere nicht benötigte Authentifizierungsflüsse, überwache Ausnahmen und mache deinem Team klar, dass auch eine echte Microsoft-Seite Teil eines Angriffs sein kann.