Phishing-Kampagnen mit OAuth-Gerätecodes nehmen mithilfe des „EvilTokens“-Toolkits stark zu
Wichtige Punkte
Seit März 2026 wurden über 50.000 Phishing-Kampagnen mit Gerätecodes beobachtet, was auf eine rasche und groß angelegte Verbreitung der OAuth-Missbrauchsmethode hindeutet.
Das „Phishing-as-a-Service“ (PhaaS)-Toolkit von EvilTokens ermöglicht es auch weniger erfahrenen Angreifern, die Kompromittierung von Microsoft 365-Konten über den legitimen OAuth-Autorisierungsablauf für Geräte zu automatisieren.
Zu den nachgeahmten Marken zählen DocuSign, Microsoft und die Workflows zur Geräteregistrierung von Mimecast – in allen Fällen werden vertrauenswürdige Geschäftsprozesse ausgenutzt
Der Angriff umgeht die Multi-Faktor-Authentifizierung (MFA), indem er über die Microsoft-eigene Infrastruktur legitime OAuth-Token erlangt
Kampagnenübersicht
Das Mimecast Threat Research-Team hat einen deutlichen Anstieg von Phishing-Kampagnen festgestellt, bei denen OAuth-Gerätecodes missbraucht werden und die sich gegen Microsoft 365-Nutzer in allen Regionen und Branchen richten. Seit März 2026 wurden im Rahmen von über 50.000 böswilligen E-Mail-Kampagnen Microsofts legitimer OAuth 2.0-Autorisierungsablauf für Geräte ausgenutzt – ein Mechanismus, der ursprünglich für Geräte ohne Tastatur, wie beispielsweise Smart-TVs und IoT-Geräte, entwickelt wurde –, um Authentifizierungstoken zu stehlen und cloudbasierte Konten zu kompromittieren.
Diese Technik hat sich rasch zu einer bevorzugten Angriffsmethode für Angreifer entwickelt, ähnlich wie im vergangenen Jahr, als ClickFix-Angriffe die Bedrohungslandschaft dominierten. Die Zugänglichkeit dieses Angriffs wurde durch das Aufkommen von „EvilTokens“ noch verstärkt – einem auf Telegram angebotenen „Phishing-as-a-Service“ (PhaaS)-Toolkit, das die gesamte Angriffskette automatisiert. EvilTokens nutzt durch KI generierte Social-Engineering-Inhalte und ermöglicht es damit selbst unerfahrenen Angreifern, überzeugende Kampagnen zur Markenimitation in großem Umfang durchzuführen.
Phishing mit Gerätecodes verstehen
Bei herkömmlichen Phishing-Angriffen wird versucht, Zugangsdaten zu stehlen, indem gefälschte Anmeldeseiten angezeigt werden, die legitime Dienste imitieren. Das sogenannte „Device Code Phishing“ stellt eine grundlegende Weiterentwicklung dar: Anstatt die Anmeldeseite von Microsoft zu imitieren, nutzen Angreifer die Authentifizierungsinfrastruktur von Microsoft selbst aus, um echte, gültige Zugriffstoken zu erlangen. Der OAuth 2.0-Autorisierungsablauf für Geräte funktioniert bei ordnungsgemäßer Nutzung wie folgt:
Ein Gerät (z. B. ein Smart-TV) generiert einen Gerätecode und zeigt diesen dem Nutzer an
Der Benutzer ruft die Seite microsoft.com/devicelogin auf auf einem separaten Gerät
Der Benutzer gibt den Gerätecode ein und authentifiziert sich mit seinen Zugangsdaten
Microsoft stellt dem ursprünglichen Gerät ein Zugriffstoken aus und gewährt ihm damit autorisierten Zugriff
Bei Phishing-Angriffen über Gerätecode nutzen Angreifer diesen Ablauf wie folgt aus:
Registrierung einer bösartigen OAuth-Anwendung bei Microsoft Azure AD
Einleitung eines Geräteautorisierungsablaufs in ihrer Backend-Infrastruktur
Teilen
Abruf eines gültigen Gerätecodes von den Autorisierungsservern von Microsoft
Die Weitergabe dieses Codes an die Opfer über Phishing-E-Mails und gefälschte Markenseiten
Die Opfer dazu zu bewegen, die echte Anmeldeseite von Microsoft für Geräte aufzurufen und den Code einzugeben
Erfassung der dabei generierten OAuth-Token, sobald das Opfer die Authentifizierung abgeschlossen hat
Da sich die Opfer über die echte Infrastruktur von Microsoft authentifizieren und die ausgestellten Token legitim sind, umgeht diese Technik die Multi-Faktor-Authentifizierung, besteht alle Domain-Reputationsprüfungen und entgeht herkömmlichen Mechanismen zur Phishing-Erkennung. Der Angriff basiert nicht auf dem Abfangen von Anmeldedaten – er nutzt vielmehr das Vertrauen der Benutzer in vertraute Geschäftsabläufe aus, um bösartige Anwendungen zu autorisieren.
Das EvilTokens-Ökosystem
Laut einer Studie von Sekoia stellt EvilTokens eine bedeutende Innovation im Bereich der Cyberkriminalität dar: eine vollautomatisierte „Phishing-as-a-Service“-Plattform, die den ausgeklügelten Missbrauch von OAuth zur Massenware macht. Das Toolkit bietet Angreifern folgende Möglichkeiten:
KI-gestütztes Social Engineering: Automatisierte Erstellung überzeugender Phishing-E-Mails und Landingpages, die vertrauenswürdige Marken und Geschäftsprozesse imitieren
Schlüsselfertige Infrastruktur: Vorkonfigurierte Backend-Systeme, die die Generierung von Gerätecodes, die Nachverfolgung von Opfersitzungen und das Sammeln von Tokens verwalten
Echtzeitüberwachung: Dashboard-Oberflächen, die aktive Kampagnen, Interaktionen der Opfer und erfolgreich erfasste Token anzeigen
Skalierbarkeit: Die Fähigkeit, Tausende von Phishing-Kampagnen gleichzeitig mit minimalem technischem Fachwissen zu starten. Diese Demokratisierung fortschrittlicher Angriffstechniken erklärt das seit März 2026 zu beobachtende explosive Wachstum. Während für das „Device Code Phishing“ bislang ausgefeilte technische Kenntnisse erforderlich waren, ermöglicht EvilTokens nun jedem Angreifer mit grundlegenden Kenntnissen im Bereich der operativen Sicherheit, Kampagnen zur Kompromittierung von Konten im Unternehmensmaßstab durchzuführen.
Kampagnenvarianten
Mimecast-Kampagne zur Geräteregistrierung
Diese Kampagne, die erstmals am 16. April beobachtet wurde, verdeutlicht eine besorgniserregende Entwicklung: Angreifer haben begonnen, den Geräte-Registrierungsprozess von Mimecast nachzuahmen, und nutzen dabei den legitimen Sicherheitsworkflow aus, den Kunden für den Zugriff auf geschützte Inhalte verwenden.
Betrügerischer Ablauf der Mimecast-Geräteregistrierung: Die Empfänger erhalten E-Mails, in denen behauptet wird, dass diese geschützte Dokumente oder Links enthalten, für deren Zugriff eine Mimecast-Geräteregistrierung erforderlich ist. Wenn die Opfer auf den Link klicken, gelangen sie auf eine Seite, die optisch identisch mit der Benutzeroberfläche von Mimecast zur Geräteregistrierung ist.
Startseite: Zeigt das Mimecast-Logo mit der Aufforderung „ "“ (Authentifizierungscode abrufen) an."
Code-Anzeige: Nach dem Klicken auf die Schaltfläche wird die Seite aktualisiert und der Gerätecode direkt auf der Webseite angezeigt
Dokumentzugriff: Auf der Seite „ "“ wird die Schaltfläche „Dokument anzeigen“ (" ) angezeigt. Wenn Sie darauf klicken, werden Sie zu microsoft.com/devicelogin weitergeleitet.
Authentifizierungsaufforderung: Die echte Microsoft-Seite fordert den Code an und weist die Benutzer an, den in ihrer App oder auf ihrem Gerät angezeigten Code unter "einzugeben, um die vollständigen Zugriffsrechte für ihr Konto zu erteilen."
Token-Diebstahl: Nach der Authentifizierung erfasst das Backend des Angreifers die OAuth-Token, während die Opfer glauben, sie hätten eine legitime Geräteregistrierung abgeschlossen
Korrekter Ablauf der Mimecast-Geräteregistrierung:
Das Verständnis des authentischen Prozesses ist für die Schulung der Benutzer und die Erkennung von Bedrohungen von entscheidender Bedeutung:
Der Benutzer klickt in einer E-Mail auf einen von Mimecast umgestalteten Link, der eine Geräteregistrierung erfordert, und wird auf die Seite zur Geräteregistrierung von Mimecast weitergeleitet.
Auf der Webseite wird der Nutzer zur Angabe seiner E-Mail-Adresse aufgefordert, die anhand der Mimecast-Kundendatenbank überprüft wird, um sicherzustellen, dass es sich um einen berechtigten Mimecast-Nutzer handelt.
Nachdem Sie auf „ "“ und dann auf „Get Device Enrolment Code“ (" ) geklickt haben, wird die Webseite aktualisiert und zeigt ein Eingabefeld für den Registrierungscode an. Der Benutzer wird darüber informiert, dass der Code an seine E-Mail-Adresse gesendet wurde. HINWEIS: Der Code wird auf der Webseite NICHT angezeigt.
Der Nutzer ruft den Code aus seiner E-Mail ab und gibt ihn in das Eingabefeld auf der Webseite ein
Nach erfolgreicher Validierung wird der Benutzer zu dem ursprünglich angeforderten Inhalt weitergeleitet.
Der entscheidende Unterschied besteht darin, dass bei einer legitimen Geräteregistrierung bei Mimecast Registrierungscodes niemals direkt auf Webseiten angezeigt werden. Die Codes werden stets per E-Mail als sekundärer Verifizierungskanal übermittelt.
Diese Nachahmung ist besonders wirkungsvoll, weil:
Nutzer erwarten Sicherheitsabläufe beim Zugriff auf geschützte Inhalte
Die Geräteregistrierung erscheint als berechtigte Sicherheitsanforderung
Die optische Übereinstimmung der gefälschten Seiten mit dem authentischen Mimecast-Branding ist sehr hoch.
DocuSign-Kampagne zur Dokumentenprüfung
Die am häufigsten anzutreffende Variante dieser Kampagne nutzt die Vortäuschung der Identität der Marke DocuSign aus und macht sich dabei die weit verbreitete Nutzung elektronischer Signatur-Workflows in Unternehmen zunutze. Die Empfänger erhalten E-Mails, in denen angeblich die Überprüfung oder Unterzeichnung von Dokumenten verlangt wird, mit Betreffzeilen wie beispielsweise:
Die Wirksamkeit der Kampagne beruht auf der Ausnutzung eines realen Geschäftsprozesses: Viele Unternehmen integrieren DocuSign tatsächlich in Microsoft 365 zur Identitätsprüfung, wodurch die Überprüfungsanfrage eher routinemäßig als verdächtig wirkt.
Benachrichtigungskampagne zu Voicemail-Nachrichten in Microsoft Teams
Eine weitere Variante dieser Kampagne nutzt die weit verbreitete Nutzung von Microsoft-Voicemail-Benachrichtigungen in Unternehmensumgebungen aus. Da Unternehmen zunehmend auf Unified-Communications-Plattformen setzen, sind Voicemail-Benachrichtigungen zu einer alltäglichen, selbstverständlichen Form der Kommunikation geworden, die von den Mitarbeitern selten genauer unter die Lupe genommen wird. Die Empfänger erhalten E-Mails, die so gestaltet sind, dass sie wie legitime Microsoft-Voicemail-Benachrichtigungen aussehen, mit Betreffzeilen wie beispielsweise:
"Sie haben eine neue Voicemail von [Name] erhalten"
"Verpasster Anruf – Neue Voicemail-Nachricht"
"Microsoft Teams: Neue Sprachnachricht"
"Benachrichtigung über eine Voicemail – Bitte um Rückmeldung"
Technische Analyse: Verschleierung und Umgehung
Mehrschichtiges Verschlüsselungsverfahren
Bei den jüngsten Kampagnen werden Maßnahmen zur Verhinderung von Analysen eingesetzt, um Sicherheitsforscher und automatisierte Systeme daran zu hindern, die Phishing-Infrastruktur zu untersuchen. Als primärer Verschleierungsmechanismus kommt eine AES-GCM-Verschlüsselung mit clientseitiger Entschlüsselung zum Einsatz.
Phase 1: Erste Nutzlast: Wenn Opfer zum ersten Mal auf eine Phishing-URL zugreifen, erhalten sie ein HTML-Dokument, das JavaScript enthält
Eine kleine JavaScript-Ladefunktion dekodiert die Base64-Zeichenfolgen in Byte-Arrays, importiert den AES-GCM-Schlüssel mithilfe der Web Crypto API und entschlüsselt den Chiffretext unter Verwendung des bereitgestellten IV.
Schritt 2: Dynamisches Ersetzen des Inhalts Nach erfolgreicher Entschlüsselung ersetzt das Skript das gesamte HTML-Dokument durch den entschlüsselten Inhalt:
Dieser Ansatz stellt sicher, dass die eigentliche Phishing-Seite – die Markenlogos, Social-Engineering-Texte und bösartige Formularelemente enthält – für folgende Personen unsichtbar bleibt:
E-Mail-Sicherheitsscanner, die die Ziele von Links analysieren
URL-Reputationsdienste, die Seiten crawlen und analysieren
Sicherheitsforscher, die eine erste Einstufung vornehmen
Automatisierte Erfassung von Bedrohungsinformationen
Erst wenn JavaScript in einem vollständigen Browserkontext ausgeführt wird, werden die eigentlichen Phishing-Inhalte sichtbar. Statische Analyse-Tools, die den HTML-Quellcode untersuchen, erkennen lediglich die verschlüsselte Nutzlast und das Ladeskript.
Phase 3: Backend-Koordination Die entschlüsselte Phishing-Seite kommuniziert mit der vom Angreifer kontrollierten Backend-Infrastruktur, um den Code-Fluss auf dem Gerät zu koordinieren:
Sitzungsaufbau:
Diese Anfrage veranlasst das Backend, einen legitimen OAuth-Geräteautorisierungsablauf mit Microsoft einzuleiten. Die Antwort enthält:
userCode: Der tatsächliche Gerätecode, der von den Autorisierungsservern von Microsoft abgerufen wurde
sessionId: Eine eindeutige Kennung zur Nachverfolgung der Sitzung dieses Opfers
Statusabfrage:
Die Phishing-Seite fragt kontinuierlich das Backend ab, um festzustellen, wann das Opfer die Authentifizierung auf der Microsoft-Plattform abgeschlossen hat. Wenn das Backend den Gerätecode erfolgreich gegen OAuth-Token eingetauscht hat, antwortet es mit dem Status: „ "“ (abgeschlossen)". Dadurch wird die Phishing-Seite dazu veranlasst, eine Erfolgsmeldung anzuzeigen und auf die legitime Website der Marke weiterzuleiten.
Infrastruktur und Hosting
Phishing-Seiten werden häufig auf folgenden Plattformen gehostet:
AWS S3-Buckets: Seriöser Cloud-Speicher, der hohe Verfügbarkeit und eine zuverlässige Infrastruktur bietet
Kompromittierte Webserver: Bestehende Domains mit etablierter Reputation, um Blocklisten zu umgehen
Neu registrierte Domains: Domains mit geringer Reputation, die Typosquatting-Varianten legitimer Marken enthalten
Backend-API-Endpunkte, die die Generierung von Gerätecodes und die Erfassung von Token verwalten, werden auf einer separaten Infrastruktur betrieben und nutzen häufig:
Virtuelle Private Server (VPS) von Anbietern, die nur eine minimale Identitätsprüfung verlangen
IP-Adressen mit gültigen TLS-Zertifikaten von Let’s Encrypt, die den Anschein von Legitimität erwecken
Diese Trennung zwischen sichtbaren Phishing-Seiten und der Infrastruktur zur Erfassung von Tokens erschwert die Maßnahmen zur Abschaltung sowie die Rückverfolgung.
Benutzer sollten niemals Gerätecodes aus unaufgeforderten E-Mails eingeben, selbst wenn die Microsoft-Anmeldeseite echt erscheint. Authentische Workflows zur Geräteregistrierung von Mimecast und anderen Diensten folgen bestimmten Mustern: Codes werden per E-Mail übermittelt, nicht auf Webseiten angezeigt, und erfordern niemals eine Authentifizierung auf der Anmeldeseite für Geräte von Microsoft.
Überprüfen Sie die Einwilligungen für OAuth-Anwendungen. Unternehmen sollten die bestehenden Berechtigungen für Anwendungen von Drittanbietern in ihren Microsoft 365-Mandanten überprüfen und dabei Anwendungen mit verdächtigen Namen, kürzlich erfolgten Autorisierungsdaten oder unbekannten Anbietern identifizieren und widerrufen.
Das sogenannte „Device-Code-Phishing“ stellt eine grundlegende Herausforderung für die cloudbasierte Authentifizierung dar: Der Angriff nutzt legitime Funktionen des OAuth-2.0-Designs aus und nicht etwa eine Sicherheitslücke, die durch ein Patch behoben werden kann. Da „Phishing-as-a-Service“-Toolkits wie EvilTokens weiterhin dazu beitragen, dass ausgefeilte Techniken immer breiter zugänglich werden, müssen Unternehmen ihre Abwehrmaßnahmen über herkömmliche Perimeterkontrollen hinaus weiterentwickeln. Microsoft hat risikobasierte Authentifizierungsrichtlinien und Funktionen zur Anwendungssteuerung eingeführt; für einen umfassenden Schutz ist jedoch ein mehrschichtiger Ansatz erforderlich: technische Kontrollmaßnahmen zur Einschränkung der OAuth-Autorisierung, Schulungen für Benutzer zur Erkennung des Missbrauchs von Gerätecodes sowie Sicherheitsmaßnahmen zur raschen Erkennung von Anzeichen für eine Kompromittierung. Die Zunahme von Phishing-Angriffen mittels Gerätecodes macht deutlich, dass Authentifizierungsmodelle, die auf Benutzerfreundlichkeit ausgelegt sind, gleichzeitig Möglichkeiten für Social Engineering in bisher ungekanntem Ausmaß eröffnen.
Behalten Sie Ihren Vorsprung bei der Bedrohungsanalyse
Schließen Sie sich Tausenden von Sicherheitsexperten an, die unsere sorgfältig ausgewählten Warnmeldungen, Expertenanalysen und IOCs für Kampagnen nutzen, um sich gegen neue Cyberbedrohungen zu schützen.
Phishing-Kampagnen mit OAuth-Gerätecodes nehmen mithilfe des „EvilTokens“-Toolkits stark zu | Mimecast
