Eine aktive Phishing-Kampagne gegen Microsoft-365-Konten hat seit dem 19. Februar 2026 nach Angaben von Huntress bereits mehr als 340 Organisationen in den USA, Kanada, Australien, Neuseeland und Deutschland getroffen. Die Angreifer missbrauchen den legitimen OAuth Device Authorization Flow, setzen massiv auf Cloud-Infrastruktur und zielen darauf ab, langfristig gültige OAuth-Tokens für den Zugriff auf E-Mails und Cloud-Daten zu stehlen.
Ausmass der Microsoft-365-Phishingkampagne und Zielbranchen
Betroffen sind Unternehmen aus einem breiten Spektrum: Bau und Tendergeschäft, Non-Profit-Organisationen, Projektentwicklung und Immobilien, Fertigung, Finanzdienstleister, Gesundheitswesen, Anwaltskanzleien und Behörden. Diese Diversität zeigt, dass es den Tätern weniger um einzelne Branchen als vielmehr um breit skalierbaren Zugang zu Microsoft 365 geht – insbesondere zu Postfächern, SharePoint, OneDrive und Teams.
Technisch stützt sich die Kampagne auf Cloudflare Workers zur Traffic-Weiterleitung und auf die PaaS-Infrastruktur von Railway als Backend für die Erfassung von Anmeldedaten und Tokens. Ein kleiner Cluster von Railway-IP-Adressen wird intensiv genutzt; rund 84 % der beobachteten Ereignisse entfallen auf nur drei IPs. Dies erleichtert zwar nachträgliche Detektion, erhöht aber gleichzeitig die Effizienz der Angreifer erheblich.
Device Code Phishing in OAuth: Wie ein legitimer Flow zur Waffe wird
Beim Device Code Phishing wird ein legitimer OAuth Device Code Flow missbraucht, der ursprünglich dafür gedacht ist, Geräte ohne vollwertigen Browser (z. B. Smart-TVs, IoT-Geräte) sicher zu authentifizieren. Nutzer sehen einen kurzen Code und sollen ihn auf einer vertrauenswürdigen Seite wie microsoft[.]com/devicelogin eingeben.
Der kritische Punkt: Die Angreifer initiieren den OAuth-Prozess im Hintergrund und präsentieren der Zielperson den bereits generierten Device Code. Gibt diese den Code auf der echten Microsoft-Seite ein, werden die daraus entstehenden Access- und Refresh-Tokens effektiv dem Angreifer-Client zugeordnet. Da Refresh-Tokens oft auch nach einer Passwortänderung gültig bleiben, ermöglicht dies dauerhaften, passwortunabhängigen Zugriff auf Microsoft 365. Microsoft und Volexity hatten vergleichbare Angriffe bereits 2025 dokumentiert; weitere Wellen wurden später von Amazon Threat Intelligence und Proofpoint beobachtet, teils mit mutmaßlichen Bezügen zu russischsprachigen APT-Gruppen.
Angriffskette im Detail: Von der Phishing-Mail zum kompromittierten Microsoft-365-Token
Missbrauch vertrauenswürdiger Redirects und Cloud-Dienste
Die Kampagne startet mit Phishing-E-Mails, deren Links hinter Redirect-Services bekannter Sicherheitsanbieter wie Cisco, Trend Micro oder Mimecast verborgen werden. Dieser Ansatz erschwert die Erkennung durch Secure-E-Mail-Gateways und erzeugt ein trügerisches Gefühl von Legitimität. Anschließend folgt eine Kette von Weiterleitungen über kompromittierte Websites, Cloudflare Workers und Vercel-Instanzen, bis die Opfer auf einer täuschend echt gestalteten Zielseite landen.
Diese Landing-Pages variieren in der Tarnung – etwa als Tenderunterlagen im Bauwesen, DocuSign-Dokumente, Voicemail-Benachrichtigungen oder Microsoft-Forms-Hinweise. Gemeinsam ist allen Seiten die Aufforderung, «Dateien anzuzeigen» und dazu einen bereits angezeigten Gerätecode zu verwenden. Ein Klick auf «Continue to Microsoft» öffnet ein echtes Popup mit dem legitimen Endpoint microsoft[.]com/devicelogin. Da der eigentliche Login vollständig auf Microsoft-Infrastruktur erfolgt, fehlen für Endnutzer typische Phishing-Indikatoren wie gefälschte Domains oder TLS-Probleme.
Auffällig ist, dass nahezu alle beobachteten Device-Code-Phishingseiten auf workers[.]dev-Domains gehostet sind. Angreifer nutzen damit das hohe Vertrauen in die Infrastruktur von Cloudflare, um Webfilter, Proxy-Lösungen und Traffic-Analysen in Unternehmensnetzen gezielt zu umgehen.
EvilTokens: Phishing-as-a-Service professionalisiert Microsoft-365-Angriffe
Huntress bringt die beobachtete Railway-Aktivität mit einer neuen Phishing-as-a-Service (PhaaS)-Plattform namens EvilTokens in Verbindung, die jüngst über Telegram gestartet wurde. Dieser Dienst bietet Kunden einen kompletten Werkzeugkasten: Versand von Phishing-Mails, Umgehung von Spam-Filtern, Verwaltung von Kampagnen über ein zentrales Dashboard sowie vorkonfigurierte Links mit Open Redirects auf verwundbaren Domains zur zusätzlichen Verschleierung der Ziel-URLs.
Bemerkenswert ist das hohe Maß an «Serviceorientierung»: Eine 24/7-Supportstruktur und Feedback-Kanäle unterstreichen die anhaltende Kommerzialisierung und Professionalisierung der Cyberkriminalität. Solche Plattformen senken die Einstiegshürde erheblich, sodass selbst technisch weniger versierte Täter komplexe OAuth-basierte Angriffe auf Microsoft 365 durchführen können.
Anti-Bot- und Anti-Analyse-Techniken: Schutz vor Sicherheitsforschern
Parallel dazu beschreibt Unit 42 (Palo Alto Networks) eine ähnliche Device-Code-Phishing-Kampagne, die bereits am 18. Februar 2026 identifiziert wurde und umfangreiche Anti-Bot- und Anti-Analyse-Mechanismen einsetzt. Beim Laden der Seite werden heimlich Browser-Cookies an die Angreifer übertragen, zudem blockieren die Seiten Rechtsklicks, Textmarkierungen, Drag-and-Drop sowie typische Tastenkombinationen für Entwicklerwerkzeuge (F12, Ctrl+Shift+I/C/J, Ctrl+U).
Darüber hinaus wird aktiv geprüft, ob Developer Tools geöffnet sind – beispielsweise über die Fenstergröße. Wird eine Analyse erkannt, startet ein endloser Debugger-Loop, der die Arbeit von Sicherheitsforschern und automatisierten Scannern massiv erschwert. Solche Techniken entsprechen dem generellen Trend, dass Phishing-Kits zunehmend Funktionen klassischer Malware übernehmen, um Entdeckung und Reverse Engineering zu verhindern.
Organisationen, die Microsoft 365 nutzen, sollten ihre Anmeldeprotokolle auf Logins von Railway-IP-Adressen prüfen, verdächtige Refresh-Tokens umgehend widerrufen und – wo möglich – Authentifizierungsversuche aus Railway- und ähnlich missbrauchsanfälliger PaaS-Infrastruktur blockieren. Darüber hinaus ist es essenziell, Mitarbeitende gezielt zum Thema Device-Code-Aufforderungen zu schulen: Ein echtes Microsoft-Login-Fenster garantiert nicht, dass der dahinterliegende Vorgang legitim ist. Ergänzend sollten Unternehmen ihre OAuth- und App-Governance stärken, Conditional Access-Richtlinien einsetzen, anomale Anmelde- und Token-Nutzungsmuster überwachen und regelmäßige Awareness-Trainings durchführen. In Kombination senken diese Massnahmen das Risiko einer erfolgreichen Token-Kompromittierung und eines langfristigen Missbrauchs der Cloud-Infrastruktur erheblich.
