Wichtige Erkenntnisse
- Device Code Phishing missbraucht die Erteilung von OAuth 2.0-Geräteautorisierung, die für Geräte entwickelt wurde, die keine „normale“ Anmeldeseite anzeigen können.
- Bei einem Angriff auf den Microsoft Authentication Broker, kann eine einzige Genehmigung dazu führen, dass nicht autorisierte Geräte registriert und langlebige Aktualisierungs-Token generiert werden, mit einem dauerhaften Zugriff anstelle einer einmaligen Anmeldung.
- Anwender sollten den Geräte-Code-Flow dort blockieren, wo er nicht benötigt wird, und eine Erkennungslösung einsetzen, die das Verhalten erfasst und die zugrunde liegenden Ereignisse überwacht.
Multi-Faktor-Authentifizierung (MFA) galt jahrelang als bester Schutz vor Kontoübernahmen, und MFA wehrt nach wie vor die meisten passwortbasierten Angriffe ab. Doch Angreifer passen sich an.
Die erste große Veränderung war das „Adversary-in-the-Middle“-Phishing, wobei sich eine Proxy-Site zwischen Nutzer und Microsoft schaltet und die Anmeldedaten in Echtzeit weiterleitet, um das Sitzungs-Cookie abzufangen.
Das Device Code-Phishing ist der nächste Schritt und in gewisser Weise für den Angreifer eleganter. Es muss keine gefälschte Anmelde-Site vorhanden sein, die blockiert werden könnte, und für den Nutzer gibt es optisch nichts Auffälliges, da die Seite, auf der er sein Passwort eingibt, tatsächlich von Microsoft stammt. Das Einzige, was ungewöhnlich ist, ist ein kurzer Code und ein plausibler Grund, diesen einzugeben.
Authentifizierung per Geräte-Code
Authentifizierung per Geräte-Code gibt es nur deshalb, weil manche Geräte keine normale Anmeldeseite anzeigen können oder über keine Tastatur verfügen, so etwa Smart-TVs und Konferenzraumsysteme. Anstatt ein Passwort auf dem Gerät einzugeben, erhalten Nutzer einen kurzen Code, um die Anmeldung auf einem zweiten Bildschirm abzuschließen.
Im üblichen Ablauf fordert das Gerät einen Code bei Microsoft an, und der Nutzer öffnet microsoft.com auf dem Smartphone oder Laptop, gibt den Code ein und bestätigt ihn. Microsoft sendet die Tokens dann an das anfordernde Gerät zurück. Wichtig ist dabei, dass das Gerät, das den Zugriff anfordert, und die Person, die ihn genehmigt, zusammengehören und sich im selben Raum befinden.
Ein Angriff funktioniert, indem er diese Annahme vefälscht. Der Angreifer schlüpft in die Rolle des Geräts mit eingeschränkter Eingabemöglichkeit und initiiert eine echte Geräte-Code-Anfrage. Er erhält einen echten Microsoft-Code und bringt das Opfer einen Köder mit einem glaubwürdigen Grund (in der Regel zum Anzeigen eines freigegebenen Dokuments oder zur Verifizierung seines Kontos) für dessen Verwendung anschließend dazu, diesen zu genehmigen. Das Opfer meldet sich an, und der Angreifer erfasst das Ergebnis. Der Angreifer nutzt diese Tokens von seinen eigenen Systemen aus, um häufig Geräte zu registrieren, sich bei Microsoft 365 Outlook anzumelden und Postfachregeln zu erstellen, damit der Zugriff bestehen und unbemerkt bleibt.
Fallbeispiel der Übernahme eines Microsoft 365-Kontos
Ein aktueller Fall zeigt, wie ausgefeilt diese Vorgehensweise mittlerweile ist. Der Angriff begann nicht mit einer einzelnen Mail, sondern mit einem Gespräch. Der Angreifer, der sich als Partner einer Anwaltskanzlei ausgab, begann mit einer freundlichen Nachricht über eine mögliche Zusammenarbeit und tauschte mehrere Nachrichten aus, bevor er überhaupt einen Link verschickte. Als der Link schließlich eintraf, wirkte er wie ein ganz normaler Teil des Chats.
Der Link selbst war so gestaltet, dass er einer Überprüfung standhalten würde. Der Text auf dem Bildschirm zeigte eine vertraut wirkende Unternehmensadresse, doch das eigentliche Ziel war eine Seite, die auf Google Sites gehostet wurde. Von dort wurde das Opfer über eine offene Weiterleitung auf eine kompromittierte, legitime Website umgeleitet, wobei eine harmlose Scheinadresse offen sichtbar war und das eigentliche Ziel in einem Parameter versteckt war. Die Zielseite befand sich hinter einer gefälschten Aufforderung zur manuellen Bestätigung, um automatisierte Scanner fernzuhalten. Die Landingpage sah aus wie ein Portal zum Teilen von Dokumenten. Sie zeigte einen Bestätigungscode an und führte den Nutzer durch die Eingabe dieses Codes bei der Microsoft-Anmeldung.
In einem der von uns untersuchten Fälle meldete sich der Angreifer wenige Stunden, nachdem der Nutzer die Anfrage genehmigt hatte, aus dem Ausland an, registrierte eine Reihe von Geräten unter dem Konto, richtete eine versteckte Posteingangsregel ein, um Antworten und Rückmeldungen zu verbergen, und nutzte das Postfach, um die nächste Phishing-Welle an Hunderte externer Empfänger zu versenden. Der Endpunkt selbst wurde dabei nie berührt. Alles geschah in der Cloud, außerhalb des Computers des Opfers, was mit ein Grund dafür ist, warum diese Art von Angriff mit Endpunkt-Tools allein nur schwer zu erkennen ist.
Erkennen von Device Code-Phishing
Da der Angriff auf der Identitätsebene stattfindet, lassen sich die relevanten Signale auch dort erkennen:
- Anmeldungen mit Geräte-Code: Jede Anmeldung mit Hilfe des Authentifizierungsprotokoll mit Geräte-Code sollte in den meisten Umgebungen selten vorkommen und nachvollziehbar sein.
- Aktivitäten des Authentifizierungs-Brokers: Anmeldungen beim Microsoft Authentication Broker aus einem unbekannten Land, Netzwerk oder von einem nicht verwalteten Gerät.
- Spitzen bei der Geräteregistrierung: Neue Geräteregistrierungen, insbesondere mehrere innerhalb eines kurzen Zeitraums oder von unbekannten IP-Adressen.
- Änderungen an Postfachregeln: Neue Posteingangsregeln, die E-Mails in obskure Ordner verschieben, als gelesen markieren oder löschen – ein klassischer Aufräumschritt nach einer Übernahme.
- Unmögliche oder untypische Reisen: Erfolgreiche Anmeldungen von außerhalb der Regionen, in denen ein Benutzer normalerweise arbeitet, in Verbindung mit den oben genannten Ereignissen.
Schutz vor Angriffen
Es bedarf eines mehrschichtigen Schutzes, der bei den Menschen ansetzt und durch Richtlinien untermauert wird.
- Sensibilisierung steht an erster Stelle. Eine unerwartete Aufforderung zur Eingabe oder zum Vorlesen eines Codes sollte als Warnsignal bekannt sein und einfach gemeldet werden können.
- Blockieren Sie den Geräte-Code-Ablauf. Deaktivieren Sie den OAuth-Geräte-Code-Authentifizierungsablauf mithilfe einer Conditional Access-Richtlinie, wo immer er nicht wirklich erforderlich ist.
- Geräte einschränken und überwachen. Legen Sie fest, wer Geräte registrieren darf, schreiben Sie für den Zugriff auf E-Mails und Daten verwaltete und konforme Geräte vor, und senken Sie die Geräteobergrenze pro Benutzer.
- Verschärfen Sie die Identitätskontrollen. Setzen Sie Richtlinien für bestimmte Standorte durch, aktivieren Sie die kontinuierliche Zugriffsbewertung und den Token-Schutz und beenden Sie Sitzungen automatisch, wenn das Risiko steigt.
Fazit
Phishing über Gerätecodes macht deutlich, dass Angreifer nicht nur die Funktionen selbst ins Visier nehmen, sondern auch die Schnittstellen zwischen ihnen. Hier liegt kein Softwarefehler vor. Es handelt sich um einen legitimen Ablauf, eine vertrauenswürdige Anmeldeseite und eine glaubwürdige Geschichte, die zu einem Angriff kombiniert werden, der die wichtigste Sicherheitsmaßnahme, auf die sich die meisten Unternehmen verlassen, unbemerkt umgeht.
Erkennung mit TrendAI Vision One™
Auf der Web-Ebene werden die bei diesem Angriff verwendeten Phishing-URLs von den TrendAI Vision One™ Web Reputation Services als gefährliche URLs erkannt, wobei die Seite zum Ausspähen von Anmeldedaten unter „HTML.Phish.Microsoft“ markiert wird. Durch das Blockieren dieser URLs wird verhindert, dass das Opfer jemals zur Code-Eingabeaufforderung gelangt, weshalb Web-Reputation und URL-Filterung eine nützliche Absicherung neben der Sensibilisierung der Benutzer darstellen.
TrendAI Vision One™ Threat Intelligence Hub
Hier finden sich die neuesten Erkenntnisse zu aufkommenden Bedrohungen und Bedrohungsakteuren, exklusive strategische Berichte von TrendAI™ Research sowie den TrendAI Vision One™ Threat Intelligence Feed.
TrendAI Vision One™ XDR Data Explorer-App
Kunden von TrendAI Vision One™ können die XDR Data Explorer-App nutzen, um die Indicators for Compromise mit Daten aus ihrer Umgebung abzugleichen oder danach zu suchen.
Ist Microsoft Entra ID in TrendAI Vision One™ integriert, liefern die folgenden Abfragen in der XDR Data Explorer-App die beiden Ereignisse, die bei diesem Angriff am wichtigsten sind. Die erste Abfrage liefert alle erfolgreichen Autorisierungen per Gerätecode, die in den meisten Umgebungen selten vorkommen und erklärbar sein sollten. Die zweite Abfrage liefert neu registrierte Geräte – auf diese Weise verwandelt der Angreifer eine einmalige Genehmigung in dauerhaften Zugriff:
Obwohl der oben genannte Filter Ereignisse zur Geräteregistrierung erkennen würde, ist davon auszugehen, dass er eine hohe Rate an legitimen Aktivitäten aufweist. Das Authentifizierungsereignis auf der Ressource „Device Registration Service“ könnte nachverfolgt werden, um Sitzungen zu identifizieren, bei denen die ursprüngliche Übertragungsmethode der „Device-Code-Flow“ ist. Dies könnte eine Warnung auslösen, dass ein Device-Code-Token zur Anmeldung beim Geräteregistrierungsdienst verwendet wird.
Dieselben Verhaltensmuster werden auch nativ in TrendAI Vision One™ über „Observed Attack Techniques“ und Workbench-Erkennungsregeln angezeigt: Mögliche Generierung eines Gerätecode-Tokens und Zugriff auf die Geräteregistrierungsressource über ein Geräte-Code-Token
Der Originalbeitrag beinhaltet zudem eine Tabelle mit MITRE ATT&CK-Techniken.