Eine neue Phishing-Masche nutzt nicht die klassische gefälschte Login-Seite, sondern den echten Microsoft-Anmeldeprozess. Genau deshalb ist sie für Unternehmen so unangenehm: Viele gewohnte Warnsignale fehlen.
Der aktuelle n-tv-Bericht zu „EvilTokens“ trifft einen wunden Punkt: Phishing sieht heute nicht mehr zwingend aus wie Phishing. Keine krumme Domain. Keine grob kopierte Anmeldeseite. Keine offensichtlichen Rechtschreibfehler. Stattdessen wird der Nutzer auf eine echte Microsoft-Seite geführt und gibt dort einen Gerätecode ein.
Genau das macht diese Angriffsmethode gefährlich. Der Mitarbeiter denkt: „Die Adresse stimmt, Microsoft fragt mich sauber ab, also wird es schon passen.“ Aus Sicht des Angreifers ist das der Jackpot. Denn er braucht in diesem Ablauf nicht zwingend das Passwort. Er will, dass der Nutzer eine gültige Sitzung autorisiert.
Für kleine und mittlere Unternehmen ist das kein theoretisches Spezialproblem. Microsoft 365 ist in vielen Betrieben das Rückgrat: E-Mail, Kalender, Teams, OneDrive, SharePoint, Kontakte, Rechnungen, Personalunterlagen, Angebote. Wer dort eine Sitzung übernimmt, sitzt nicht irgendwo am Rand. Er sitzt mitten im Büro.
Was bei Device-Code-Phishing passiert
Microsoft bietet den sogenannten Device Code Flow für Geräte an, auf denen eine normale Anmeldung umständlich ist. Typisches Beispiel: ein Gerät ohne komfortable Tastatur. Das Gerät zeigt einen Code an, der Nutzer geht auf eine Microsoft-Anmeldeseite, gibt den Code ein und bestätigt die Anmeldung.
Im legitimen Alltag ist das praktisch. Im Angriff wird der Ablauf verdreht. Der Angreifer startet im Hintergrund eine Anmeldung, erzeugt einen gültigen Gerätecode und bringt das Opfer dazu, diesen Code auf der echten Microsoft-Seite einzugeben. Die Anmeldung wirkt sauber, weil sie technisch tatsächlich über Microsoft läuft.
Nach der Bestätigung erhält nicht der Mitarbeiter den entscheidenden Vorteil, sondern die vom Angreifer gestartete Sitzung. Der Angreifer arbeitet anschließend mit gültigen Zugriffs- oder Aktualisierungstokens weiter. Das ist der große Unterschied zum klassischen Passwortdiebstahl.
Warum MFA allein hier nicht reicht
Multi-Faktor-Authentifizierung bleibt wichtig. Ohne MFA wären viele Angriffe noch deutlich einfacher. Aber bei dieser Masche wird MFA nicht unbedingt technisch ausgehebelt. Der Nutzer wird dazu gebracht, den Zugriff selbst freizugeben.
Das ist unbequem, aber ehrlich: Wer nur sagt „Wir haben MFA, also sind wir sicher“, hat eine Lücke im Sicherheitskonzept. Moderne Angriffe zielen nicht mehr nur auf Passwörter. Sie zielen auf Vertrauen, Gewohnheit und hektische Abläufe im Tagesgeschäft.
Warum das für Geschäftsführer relevant ist
Ein kompromittiertes Microsoft-365-Konto ist selten nur ein IT-Ticket. Es kann schnell zum Geschäftsrisiko werden. Angreifer lesen E-Mails mit, prüfen Zahlungsabläufe, suchen nach Rechnungen, Lieferanten, HR-Kommunikation oder vertraulichen Dokumenten. Danach folgen häufig gezielte Betrugsversuche: geänderte Bankverbindungen, gefälschte Freigaben, manipulierte Weiterleitungen oder neue Postfachregeln.
Besonders kritisch sind Konten aus Geschäftsführung, Buchhaltung, Personal, Einkauf und Vertrieb. Dort liegen die Informationen, mit denen Betrüger überzeugend auftreten können. Ein sauber formulierter Angriff mit echtem Kontext ist für Mitarbeitende viel schwerer zu erkennen als die alte Massenmail mit schlechtem Deutsch.
Was Unternehmen jetzt konkret tun sollten
Die wichtigste Regel für Anwender ist einfach: Einen Gerätecode gibt man nur ein, wenn man den Anmeldevorgang selbst bewusst gestartet hat. Kommt die Aufforderung unerwartet per E-Mail, Teams, Dokumentfreigabe oder angeblicher Signaturanfrage, wird nicht bestätigt. Erst prüfen, dann handeln.
Technisch sollte Microsoft 365 sauber gehärtet werden. Aus unserer Sicht gehört Folgendes auf die Prüfliste:
- Device Code Flow prüfen und möglichst blockieren: In vielen KMU wird dieser Ablauf gar nicht benötigt. Dann sollte er per Conditional Access gesperrt werden. Falls er gebraucht wird, nur für klar dokumentierte Ausnahmen.
- Conditional Access konsequent nutzen: Zugriff abhängig von Risiko, Standort, Gerät, Benutzergruppe und Anmeldeverfahren steuern. Erst im Report-only-Modus testen, dann kontrolliert aktivieren.
- Anti-Phishing- und Safe-Links-Richtlinien aktivieren: Microsoft Defender for Office 365 kann verdächtige Absender, Impersonation und riskante Links besser abfangen, wenn die Richtlinien sauber konfiguriert sind.
- App-Zustimmungen einschränken: Nutzer sollten nicht beliebig Anwendungen Zugriff auf Unternehmensdaten geben können. App Consent gehört kontrolliert, nicht dem Zufall überlassen.
- Anmeldeprotokolle überwachen: Device-Code-Anmeldungen, ungewöhnliche IP-Adressen, neue Geräte, neue Postfachregeln und auffälliger Zugriff auf E-Mails müssen auffallen.
- Notfallprozess festlegen: Wenn ein Nutzer versehentlich bestätigt hat, müssen Sitzungen und Refresh-Tokens widerrufen, Postfachregeln geprüft, Kennwörter neu gesetzt und verdächtige Aktivitäten nachvollzogen werden.
- Mitarbeitende gezielt schulen: Nicht mit Folienfriedhof, sondern mit klaren Beispielen aus dem Arbeitsalltag: „Wann darf ich einen Gerätecode eingeben?“ und „Wen rufe ich im Zweifel an?“
Die saubere Reihenfolge bei der Absicherung
Wir würden das Thema nicht mit Aktionismus angehen. Sinnvoll ist eine geordnete Prüfung:
- Bestandsaufnahme: Wird Device Code Flow im Unternehmen überhaupt legitim genutzt?
- Risikoanalyse: Welche Benutzergruppen wären bei einer Kontoübernahme besonders kritisch?
- Report-only-Test: Conditional-Access-Regel vorbereiten und Auswirkungen beobachten.
- Kontrollierte Sperre: Device Code Flow blockieren oder eng begrenzen.
- Mail-Schutz nachziehen: Anti-Phishing, Safe Links, externe Absenderhinweise und Impersonation-Schutz prüfen.
- Überwachung aktivieren: Alerts für auffällige Anmeldungen, neue Inbox-Regeln und riskante Sitzungen einrichten.
- Meldeweg kommunizieren: Jeder Mitarbeiter muss wissen, wie ein Verdacht gemeldet wird.
Ein Satz, den jeder im Unternehmen kennen sollte
„Ich gebe keinen Microsoft-Gerätecode ein, wenn ich die Anmeldung nicht selbst gestartet habe.“
Das klingt simpel. Genau solche einfachen Regeln funktionieren im Alltag aber besser als lange Sicherheitsrichtlinien, die niemand liest. Technik ist Pflicht. Schulung ist Pflicht. Aber am Ende muss der Mitarbeiter in zehn Sekunden die richtige Entscheidung treffen können.
Wenn der Verdacht besteht, dass bereits geklickt, bestätigt oder ein Passwort eingegeben wurde, hilft der Praxisleitfaden dazu, was Unternehmen nach einer geöffneten Phishing-Mail sofort prüfen sollten.
EDV Systeme Donner unterstützt bei der Microsoft-365-Absicherung
Wenn Sie Microsoft 365 im Unternehmen einsetzen, sollten Sie jetzt prüfen lassen, ob Device-Code-Phishing in Ihrer Umgebung technisch möglich ist und ob verdächtige Anmeldungen zuverlässig auffallen. Wir prüfen Tenant-Konfiguration, Conditional Access, Defender-Einstellungen, App-Zustimmungen, Postfachregeln und die wichtigsten Meldewege.
Quellen und Einordnung
Dieser Beitrag basiert auf einer redaktionellen Einordnung aktueller Meldungen und technischer Hinweise zu EvilTokens, Device-Code-Phishing, Microsoft 365, Conditional Access und Token-Diebstahl. Die Handlungsempfehlungen wurden für den praktischen Einsatz in kleinen und mittleren Unternehmen zusammengefasst.
- n-tv: Brandgefährliche Phishing-Attacken nutzen echte Microsoft-Anmeldung
- Microsoft Security Blog: AI-enabled device code phishing campaign
- Microsoft Learn: Block authentication flows with Conditional Access
- ESET WeLiveSecurity: EvilTokens und legitime Authentifizierungsprozesse
- Sekoia: EvilTokens als AI-augmented Phishing-as-a-Service
Häufige Fragen zu Device-Code-Phishing
Was ist Device-Code-Phishing bei Microsoft 365?
Beim Device-Code-Phishing starten Angreifer eine legitime Anmeldung über den Microsoft Device Code Flow und bringen Nutzer dazu, den erzeugten Code auf einer echten Microsoft-Seite einzugeben. Dadurch wird nicht zwingend ein Passwort gestohlen, sondern eine fremde Sitzung autorisiert.
Schützt Multi-Faktor-Authentifizierung vor dieser Angriffsmethode?
MFA bleibt wichtig, reicht aber allein nicht immer aus. Bei dieser Masche wird der Nutzer dazu verleitet, den Zugriff selbst zu bestätigen. Deshalb braucht es zusätzlich Conditional Access, eingeschränkte Authentifizierungsflüsse, Monitoring und Schulung.
Sollte der Device Code Flow blockiert werden?
Wenn der Device Code Flow im Unternehmen nicht benötigt wird, sollte er möglichst per Conditional Access blockiert werden. Wird er gebraucht, sollte die Nutzung auf dokumentierte und abgesicherte Ausnahmen begrenzt werden.
Was ist zu tun, wenn ein Mitarbeiter einen fremden Gerätecode eingegeben hat?
Der Vorfall sollte sofort an die IT gemeldet werden. Anschließend sollten aktive Sitzungen und Refresh-Tokens widerrufen, Postfachregeln und Weiterleitungen geprüft, Kennwörter geändert und verdächtige Anmeldungen ausgewertet werden.
Wie erkennt man eine verdächtige Gerätecode-Anfrage?
Verdächtig ist jede unerwartete Aufforderung, einen Microsoft-Gerätecode einzugeben, insbesondere wenn sie per E-Mail, Teams-Nachricht, Dokumentfreigabe oder Signaturanfrage kommt und der Nutzer die Anmeldung nicht selbst gestartet hat.