Phishing-Kampagnen mit OAuth-Gerätecodes nehmen mithilfe des „EvilTokens“-Toolkits stark zu

4. Mai 2026

Von Rikesh Vekaria, Archa Archa, Hiwot Mendahun, Samantha Clarke und dem Mimecast Threat Research Team

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:

1. Ein Gerät (z. B. ein Smart-TV) generiert einen Gerätecode und zeigt diesen dem Nutzer an
2. Der Benutzer ruft die Seite microsoft.com/devicelogin auf auf einem separaten Gerät
3. Der Benutzer gibt den Gerätecode ein und authentifiziert sich mit seinen Zugangsdaten
4. 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:

1. Registrierung einer bösartigen OAuth-Anwendung bei Microsoft Azure AD
2. Einleitung eines Geräteautorisierungsablaufs in ihrer Backend-Infrastruktur
3. Abruf eines gültigen Gerätecodes von den Autorisierungsservern von Microsoft
4. Die Weitergabe dieses Codes an die Opfer über Phishing-E-Mails und gefälschte Markenseiten
5. Die Opfer dazu zu bewegen, die echte Anmeldeseite von Microsoft für Geräte aufzurufen und den Code einzugeben
6. 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.

1. Startseite: Zeigt das Mimecast-Logo mit der Aufforderung „ "“ (Authentifizierungscode abrufen) an."
2. Code-Anzeige: Nach dem Klicken auf die Schaltfläche wird die Seite aktualisiert und der Gerätecode direkt auf der Webseite angezeigt
3. Dokumentzugriff: Auf der Seite „ "“ wird die Schaltfläche „Dokument anzeigen“ (" ) angezeigt. Wenn Sie darauf klicken, werden Sie zu microsoft.com/devicelogin weitergeleitet.
4. 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."
5. 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:

1. 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.        
2. 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.
3. 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.
 
4. Der Nutzer ruft den Code aus seiner E-Mail ab und gibt ihn in das Eingabefeld auf der Webseite ein
5. 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:

• "DocuSign – Dokument prüfen"
• "Agreement_Review.pdf – Unterschrift erforderlich"
• "Dringend: Vertrag wartet auf Ihre Unterschrift"

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.

Indikatoren für eine Kompromittierung (IOCs)

DocuSign-Kampagne

Phishing-Domains:

• 00a7af15-a112-4457-86c2-5c56751f0f47-endpoint[.]com
• index-yfb.kpenza-htrenchless-com-s-account.workers[.]dev

Beispiele für Betreffzeilen:

• "DocuSign – Dokument prüfen"
• "Agreement_Review.pdf – Unterschrift erforderlich"
• "Dringend: Vertrag wartet auf Ihre Unterschrift"
• "Dokument, das auf Ihre elektronische Unterschrift wartet"

Microsoft-Voicemail-Kampagne

Phishing-Domains:

• voice-mail-auth-office-com.saxeco7653.workers[.]dev
• auth-login-office-com.saxeco7653.workers[.]dev
• delicate-poetry-debc.dporozok.workers[.]dev

Beispiele für Betreffzeilen:

• "Benachrichtigung über eine Voicemail – Bitte um Rückmeldung"
• "Verpasster Anruf – Neue Voicemail-Nachricht"
• "Sie haben eine neue Voicemail von [Name] erhalten"

Mimecast-Kampagne zur Geräteregistrierung

Phishing-Domains:

• sso-nodeconnect[.]icu/

Beispiele für Betreffzeilen:

• "Dokument anzeigen"
• "Agreement_Review.pdf – Unterschrift erforderlich"

Ziele

Geografischer Schwerpunkt: Weltweit – alle Regionen

Branchenbereich: Branchenübergreifend; besonders effektiv bei Unternehmen, die DocuSign, Microsoft oder Mimecast einsetzen

Empfehlungen

Schulung zur Sensibilisierung der Benutzer für Sicherheitsfragen

• Informieren Sie Ihre Mitarbeiter über die spezifischen Merkmale dieser Kampagnen
• 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.

Proaktive Bedrohungssuche

• Durchsuchen Sie die E-Mail-Empfangsprotokolle anhand der vom IOC aufgeführten

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.