Microsoft 365 – Geräte-Compliance-Bypass

 

Über die Weihnachtsfeiertage wurde ein Angriff auf Microsoft 365 professionalisiert und durch die öffentliche Bereitstellung der entsprechenden Proof-of-Concept-Werkzeuge für die breite Ausnutzung vorbereitet, der die Umgehung von Conditional Access (CA) Regelwerken ermöglicht, die auf die Geräte-Compliance abzielen.

Konkret heißt das: Ein Angreifer ist in der Lage, CA-Regeln zu umgehen und ohne Unternehmensgerät auf den Tenant zuzugreifen.

*//Update 11.01.2025: Im Posting unten sind zwei Updates eingearbeitet vom 01.01. und 11.01.2025.

Der Angriffspunkt: Unternehmens-Portal

Der Angriffspunkt bzw. Schwachstelle in der M365-Sicherheitsarchitektur vieler Unternehmen wurde bereits vor einiger Zeit entdeckt und im Rahmen der BlackHat EU öffentlich gemacht (BlackHat Talk: https://x.com/TEMP43487580, Veröffentlichung der AppID und mehr: https://x.com/_dirkjan)

Der Angriff nutzt einen einfachen Fakt: Möchte sich ein Gerät in Intune registrieren, kann es nicht compliant sein. Es muss also (mindestens) eine App geben, die das CA-Regelwerk ignoriert, wenn „all ressources“ eine Geräte-Compliance erfordern:
Das Microsoft Intune Portal (9ba1a5c7-f17a-4de9-a1f1-6178c8d51223)

Wie alle anderen Enterprise Apps / App Registrations auch, greift auch das Intune-Portal über die Graph-API auf Cloud-Ressourcen von Microsoft 365 zu – und verfügt damit über AccessToken und RefreshToken des angemeldeten Benutzers. Genau dies macht sich das nun veröffentlichte Tool „TokenSmith“ zunutze. Ein ausführlicher Blog-Post in Englisch existiert ebenfalls von JumpSec, die auch Author des Tools TokenSmith sind.

It works – wir haben es probiert

Mit Stand vom 28.12.2024 funktioniert der Angriff tadellos und ist mit dem aktuell verfügbaren Setup und Tooling sehr simpel. Alle Werkzeuge sind frei verfügbar auf GitHub. Hier im Beispiel verwenden wir:

TokenSmith – Führt den Angriff durch und sammelt die Tokens
GraphRunner – Nutzt die Tokens und greift auf den Tenant zu

Alles, was für einen erfolgreichen Angriff benötigt wird, sind die beiden Tools und ein paar Commandline-Befehle. TokenSmith bringt eine Anleitung mit, sodass die Zugriffe auch mit mäßiger technischer Expertise auf Anhieb gelingen.

TokenSmith Login

Die Anmeldung im Browser fordert zum Login in das Intune-Portal auf – für Phishing und co. sicherlich gut – obgleich das blau schon nach Phishing aussieht.. aber gut. So ist das bei Microsoft :-). Der perfide Beigeschmack: Die URL ist (wie bei DeviceCode-Phishing) eine legitime Microsoft-URL und lässt sich daher kaum als Phishing erkennen. Auch „Phishing-resistente“ MFA per YubiKey und co. würden hier nicht schützen und zur erfolgreichen Anmeldung führen.

Microsoft 365 Anmeldemaske für Intune
Microsoft 365 Anmeldemaske für Microsoft Intune

Nach der Anmeldung kommt der eigentliche Trick – der Browser läuft in einen Fehler, gibt aber die Redirect-URL mit den relevanten Anmeldedatne preis:

Login Failed to Launch

Diese Redirect-URL aus dem „Failed to Launch“ wird TokenSmith übergeben und dort passiert die weitere Magie. Am Ende bekommt man die üblichen Verdächtigen: AccessToken & RefreshToken, die oben schon im Bild waren – fehlt noch die Tenant-ID für den erfolgreichen Angriff, die wir über Microsoft-Bordmittel für jeden Tenant per .well-known/openid-configuration ohnehin immer bekommen.

Tenant ID

Damit sind die Zutaten bereit und der Zugriff auf den Tenant kann erfolgen – ohne Geräte-Compliance. Für die weiteren Angriffe können alle Werkzeuge genutzt werden, die mit den Graph-API-Token umgehen können, zum Beispiel GraphRunner. Hierfür werden die Token importiert…

import accesstoken

… und anschließend GraphRunner ausgeführt.

access granted

Der Token-Import war erfolgreich und der Angreifer hat Zugriff auf den Tenant im Namen seines „Opfers“ – und ohne firmeneigenes Gerät. Die Graph-API ermöglicht die weiteren Angriffe, beispielsweise das Auslesen der Nutzer:

get all users

Erkennung und Abwehr

Die Entdeckung kombiniert bekannte Angriffsmuster und Werkzeuge über die Graph-API mit einem neuen Weg an Token zu gelangen. Und der Umgehung von Gerätecompliance – obgleich es schon Angriffe gab, die ein „Gerät“ im Tenant vortäuschten, ist die einfache Umgehung der CA-Regelwerke eine neue Klasse von Angriffen.

Im Rahmen unserer Microsoft 365 SecurityServices schützen wir unsere Kunden vor bekannten und neuartigen Angriffen. Mit Hilfe der Monitoring-as-a-Service-Dienste kümmern wir uns darum, dass Ihr Tenant sicher bleibt und Angriffe frühzeitig erkannt und unterbunden werden!

Was man im Tenant sieht, sind natürlich die Logins. Diese stammen vom Intune Portal als App, was in den meisten Fällen auffällig sein dürfte.

sign in intune success

Dennoch benötigen alle registrierten Geräte diese Möglichkeit – sonst können die Mitglieder nicht mehr auf das Unternehmensportal zugreifen. Auffällig wird die Ausnutzung. Der Angreifer klaut Token und nutzt diese anschließend weiter. Hierbei ändert sich die IP-Adresse der Zugriffe über die Graph-API. Je nach Werkzeug sind auch die Non-Interactive-Sign-Ins auffällig. Im folgenden Beispiel kamen die Zugriffe via GraphRunner einige Minuten nach dem Klau des Tokens – von einer gänzlich anderen IP-Adresse:

signin noninteractive

Diese Dinge lassen sich auch ohne LogAnalytics und co. identifizieren, allerdings wird die Alarmierung schwierig. GraphRunner sollte auch von Microsoft-Defender-Produkten erkannt werden, was aber oft einige Zeit dauert.

Da die Intune-Anwendung auch legitim benötigt wird, ist eine konkrete Abwehr aktuell schwierig. IP-Adressen lassen sich in den wenigstens Fällen klar eingrenzen. Die Sperre der App kann zu anderen Problemen führen. Erkennbar sind Angriffe auf jeden Fall – und das sollte auch auf dem Schirm sein. In den von uns überwachten Tenants erfolgen (legitime) Logins nur sehr selten und wenn dann in Kombination mit weiteren Aktionen wie einer Geräteregistrierung.

In der aktuellen Implementierung des Angriffs wird die aktive Mithilfe des Opfers benötigt – er muss die URL aus dem Fehler im Browser bereitstellen. Da diese aber auch in der HTTP-Response enthalten ist, würde grundsätzlich auch eine Adversary-in-the-Middle-Attacke an diese Daten kommen — Dann allerdings würde Phishing-resistente Authentifizierung per FIDO2-Schlüssel den Angriff wieder unterbinden. Es ist also nicht der große Wurf als Angriffsweg, aber vielleicht der Beginn einer spannenden Reise …

*// Update 01.01.2025:

Martin Willing hat mich auf einen Blog-Post von Quzara aufmerksam gemacht zur Erkennung von TokenSmith. Dort werden die Beta-Logs verwendet. Ich habe die Suche etwas abgewandelt und tatsächlich scheint die recht zielgenau zu sein:

SigninLogs
| where AppId == „9ba1a5c7-f17a-4de9-a1f1-6178c8d51223“
and ResultType == „0“
| extend CAP = parse_json(ConditionalAccessPolicies)
| mv-expand CAP
| where (CAP.enforcedGrantControls has „RequireCompliantDevice“ and CAP.result == „failure“)
| project
TimeGenerated,
CAP.displayName,
CAP.result,
ResourceDisplayName,
IPAddress,
CAP.enforcedGrantControls,
CAP.conditionsSatisfied,
CAP.conditionsNotSatisfied,
CAP.includeRulesSatisfied,
ConditionalAccessStatus

found tokensmith 1

Vielleicht noch nicht das perfekte Query, aber die Kombination aus dem Success im CA-Status für RequireCompliantDevice und insgesamt dem ResultType==0 wirkt recht einzigartig.

*// Update 11.01.2025:

Der Angriff mit TokenSmith umgeht die Compliance-Prüfung. Ein solides CA-Regelwerk kann den Angriff verhindern. Nach eigenen Tests haben sich die Hinweise (Danke @ Martin Schulze für die ausführliche Beschreibung und Verprobung!) als zutreffend heraus gestellt, dass der Join-/Register-Status aktuell mit dem TokenSmith-Weg nicht umgangen wird. Das heißt schon eine relativ kleine CA-Regel reicht aus, damit der Angriff scheitert:

CA Filter DEvice

Das Ergebnis dieser Settings ist, dass nach der Prüfung von Benutzer-Passwort-MFA aber vor dem Ausstellen der Token das CA-Regelwerk dazwischen grätscht und die Anmeldung ablehnt.

CA Block unregistered

Hier erfolgt der Verweis „Unregistered“ und die Anmeldung wird beendet.

Natürlich benötigt es hier eine Ausnahme für das Onboarding der Geräte. Diese Ausnahmen sind so individuell wie das eigene Regelwerk und die gelebten Prozesse. Wer Geräte immer im Office onboarded, der findet schnell eine Regel per Trusted-IP-Address. Wo immer spezifische Accounts das Onboarding übernehmen kann Gruppen als Ausnahme hinzufügen. Filter auf Ebene von Geräteklassen können einen Angreifer durchaus „verwirren“. Wichtig ist aber, dass Geräteklassen über den User-Agent der Anfrage erkannt werden, also keinen wirksamen Schutz vor Manipulation und Angriffen bieten.

Die folgende Regel, um Zugriffe von „Windows“-Geräten zu blocken…

CA Plattform deny

… lässt sich also beispielsweise schon mit dem bösen Hacking-Tool MS Edge umgehen.
Anfrage als Windows-Gerät:

ca block device

Änderung des Geräts per „Geräteemulation“ vom Edge auf Android:

ca bypass device

Ein sinnvolles CA-Regelwerk bleibt eine Herausforderung, es zeigt sich aber einmal mehr, dass es hilfreich ist und unbedingt zu den eigenen Anforderungen passen sollte!
Wird der Angriff geblockt, erscheint auch im Log das relevante Event nicht – ein Nachvollziehen eines laufenden Phishing-Angriffs ist dann nicht mehr so einfach möglich.

Nach oben scrollen