Blog

ConsentFix - Die neueste Phishing-Methode erklärt

18. Mai 2026 / Jonas Mönnig

Seit Anfang des Jahres kursiert die Phishing-Masche ConsentFix, die so ziemlich das Absurdeste ist, was wir je gesehen haben, aber dennoch von echten Angreifern genutzt wird. Wir konnten ConsentFix bei unseren Kunden testen und können Ihnen jetzt nicht nur erklären, wie die Technik funktioniert, sondern auch, welche Erfolgsaussichten Angreifer damit haben.

Immer mehr Unternehmen setzen phishingresistente Authentifizierungsmethoden, wie zum Beispiel Passkeys ein, wodurch Angreifer mit herkömmlichen Phishing-Techniken ins Leere laufen. Daher sind diese immer auf der Suche nach neuen Techniken, um auch in besonders gehärteten Systemen Erfolg zu haben. Beispielsweise ist seit Längerem das sogenannte Device-Code-Phishing populär, wobei der Device-Code-Flow des OAuth 2.0-Autorisierungsprotokolls missbraucht wird. Als Reaktion haben seitdem viele Unternehmen den Device-Code-Flow in ihren Entra ID-Tenants deaktiviert.

In diesem ständigen Hin und Her zwischen Angreifern und Verteidigern ist Anfang des Jahres eine neue Technik aufgetaucht, die von Sicherheitsforschern ConsentFix getauft wurde. Genau wie beim Device-Code-Phishing greifen Angreifer hier in den OAuth-Flow direkt ein. Um den Angriff zu erklären, müssen wir daher kurz ausholen und erklären, wie ein typischer Autorisierungsprozess über OAuth 2.0 üblicherweise abläuft.

Das OAuth 2.0-Protokoll erklärt

Da der OAuth 2.0-Standard so komplex ist, dass man damit auch zehn Blogartikel füllen könnte, beschränken wir uns auf den Teil, der für den Angriff relevant ist: die Autorisierung einer lokal beim Nutzer laufenden Applikation, wie zum Beispiel dem Azure CLI, mit dem sogenannten Authorization-Code-Flow.

Einigen Lesern ist vielleicht die Verwendung des Worts “Autorisierung” anstelle von “Authentifizierung” aufgefallen. Dies ist kein Zufall, denn die Authentifizierung, also die Verifikation der Identität des Nutzers, ist nur ein kleiner Teil des OAuth-Protokolls. Was dabei eigentlich passiert, ist, dass ein Nutzer einer Applikation bestimmte Rechte zugesteht.

Anhand der obigen Grafik erklären wir stark vereinfacht die für ConsentFix relevanten Schritte des Protokolls.

  1. Die Applikation startet den OAuth-Flow durch einen GET-Request an den /authorize-Endpunkt des OAuth-Servers, was in etwa so aussehen könnte:

    GET /authorize?client_id=04b07795-8...&redirect_uri=https://....

    Die für die Erklärung unerheblichen Parameter haben wir der Einfachheit halber weggelassen. Relevant für uns sind client_id und redirect_uri. Die client_id soll die Applikation eindeutig gegenüber dem OAuth-Provider identifizieren und die Applikation muss dafür im Vorfeld beim OAuth-Provider registriert sein. Die redirect_uri ist die URI, an die später in Schritt 4 der Authorization-Code übermittelt wird. Für jede Client-ID gibt es dabei feste URIs, die als Wert erlaubt sind.

  2. Der OAuth-Provider zeigt dem Nutzer die Login-Seite an.

  3. Der Nutzer meldet sich an. Die Authentifizierungsmethode (Passwort, Passkey, etc.) ist dabei unerheblich.

  4. Der OAuth-Provider übermittelt den sogenannten Authorization-Code an den Client. Dieser ist noch kein Access-Token, sondern muss noch gegen ein solches eingetauscht werden. Der Grund für diesen zweistufigen Prozess ist, dass die Applikation nicht zwingend beim Anwender läuft.

    Hauptsächlich wird OAuth nämlich im Rahmen von Webapplikationen eingesetzt. Dabei tauscht dann die Webapplikation den Authorization-Code gegen ein Access-Token ein. In diesem Fall muss sich die Webapplikation gesondert gegenüber dem OAuth-Provider authentifizieren, damit sichergestellt ist, dass ausschließlich diese bestimmte Applikation den Authorization-Code gegen ein Access-Token eintauschen kann.

    In unserem Beispiel, bei dem die Applikation ausschließlich beim Nutzer selbst läuft und damit kein Applikationspasswort geheim halten kann, wird der Prozess über PKCE abgesichert. Dies haben wir hier bewusst unterschlagen.

    Die Übermittlung des Authorization-Codes wird durch eine Weiterleitung zur in Schritt 1 als redirect_uri angegebenen URL durchgeführt. Dies könnte im Rahmen einer lokalen Applikation in etwa so aussehen:

    HTTP/1.1 302 Found
Location: http://localhost/callback?code=SplxlOBeZQQYbYS6WxSbIA

  5. Die Applikation kann mit dem empfangenen Authorization-Code nun ein Access-Token, üblicherweise ein JSON Web Token (JWT), beim OAuth-Server anfragen. Dies tut Sie, indem sie den Code an den /token-Endpunkt des OAuth-Servers übermittelt.

  6. Die Applikation erhält daraufhin ein JWT vom Server.

  7. Die Applikation kann nun mit dem JWT auf die Ressourcen zugreifen, für die sie im Rahmen des OAuth-Prozesses autorisiert wurde.

ConsentFix erklärt

Jetzt können wir beschreiben, wie Angreifer mit der ConsentFix-Technik in diesen Prozess eingreifen, um an Access-Tokens zu gelangen. Zunächst wird dem Nutzer eine Anmeldeseite angezeigt.

Nach dem Klick auf den “Anmelden”-Button wird in einem neuen Fenster der OAuth-Prozess gestartet. Wenn der Nutzer eingeloggt ist, muss er lediglich den richtigen Account auswählen, wie in folgendem Screenshot zu sehen ist.

Das ist auch das Perfide an dieser Phishing-Technik. Der Nutzer meldet sich tatsächlich auf der echten Microsoft-Login-Seite an und nicht auf der Phishing-Seite selbst.

Der Angreifer greift aber ab hier in den OAuth-Prozess ein, denn die OAuth-Parameter sind vom Angreifer bestimmt und wie bereits oben beschrieben sind zwei davon relevant für die Phishing-Technik:

  • client_id: In unserem Test haben wir hier die Client-ID 04b07795-8ddb-461a-bbee-02f9e1bf7b46, die vom Microsoft-eigenen Kommandozeilenprogramm Azure CLI genutzt wird, verwendet. Dieser Client-ID wird in Entra ID bereits implizit vertraut, da es sich um eine Microsoft First-Party-Applikation handelt. Außerdem wird diese standardmäßg nicht von bestehenden Conditional Access Policies erfasst, sodass mögliche Einschränkungen umgangen werden können.

  • redirect_uri: Hier wird vom Angreifer http://localhost/ angegeben. Dies ist für die verwendete Client-ID ein erlaubter Wert, führt hier aber zu einem Fehler, da beim Opfer mit hoher Wahrscheinlichkeit dort gar kein Dienst läuft.

Nun bringt der Angreifer den Nutzer dazu, die URL im Anmeldefenster in die Phishing-Seite zu kopieren. In der Variante, die wir für unsere Phishing-Kampagne nachgebaut haben, geschieht dies durch eine Drag-and-Drop-Aktion. In der URL befindet sich nämlich der Authorization-Code, an dem der Angreifer interessiert ist. Diesen kann er beim OAuth-Provider gegen ein Access-Token eintauschen und hat somit die Rechte des Nutzers erlangt.

POST /oauth/token HTTP/1.1
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=Qcb0Orv1v3&
client_id=04b07795-8ddb-461a-bbee-02f9e1bf7b46

ConsentFix in der Praxis

Wir konnten ConsentFix bei unseren Kunden im Rahmen von Phishing-Kampagnen testen und die Technik bei mehreren hundert Mitarbeitern anwenden. Da es dafür noch keine verbreiteten Tools gibt, mussten wir uns kurzerhand selbst eines entwickeln. Der Aufwand dafür ist allerdings überschaubar und kann mit KI-unterstützter Entwicklung noch weiter verringert werden. Das Tooling ist für echte Angreifer also relativ leicht zu beschaffen.

Welche Erfolgsaussichten hat also ein Angreifer mit dieser - auf den ersten Blick sehr komplizierten - Technik? In unserer letzten Kampagne hatten wir folgendes Ergebnis:

  • 99 Mitarbeiter klickten auf den Link in der Phishing-Mail
  • 71 Mitarbeiter klickten auf der Phishing-Seite auf Anmelden und starteten den OAuth-Prozess
  • 12 Mitarbeiter kopierten einen Wert in die Phishing-Seite
  • 6-mal konnte damit tatsächlich ein Access-Token geholt werden (der Nutzer hat die Aktion korrekt ausgeführt)

Nach erfolgtem Klick auf den Link konnten wir also in ungefähr 6% der Fälle auch ein gültiges Access-Token erlangen. In normalen Phishing-Kampagnen sind Werte zwischen 50% und 80% üblich. Die Erfolgsquote von ConsentFix beträgt also ungefähr ein Zehntel davon. Allerdings lassen sich damit auch bei besonders gehärteten Cloud-Tenants Access-Tokens stehlen, und bei der Menge an Phishing-Mails, die Cyberkriminelle heutzutage versenden, dürften die Erfolgsaussichten gut sein.

Es ist also nicht verwunderlich, dass diese - auf den ersten Blick absurde - Angriffstechnik auch in der Realität eingesetzt wird.

Fazit und Maßnahmen

ConsentFix ist eine neuartige Phishing-Technik, die auf den ersten Blick absurd wirkt, aber dennoch von Cyberkriminellen eingesetzt wird. Die Erfolgsquote ist zwar deutlich geringer als beim herkömmlichen Abfischen eines Passworts, allerdings kann damit auch Zugriff auf Cloud-Tenants erlangt werden, die ausschließlich phishingresistente Authentifizierungsmethoden einsetzen.

Zwar ist die Methode zum aktuellen Zeitpunkt noch nicht sehr verbreitet, jedoch halten wir es nach unserem Test für wahrscheinlich, dass die Methode in Zukunft an Popularität gewinnen wird.

Als erste technische Maßnahme zum Schutz vor ConsentFix, kann der Zugriff auf First-Party-Applikationen, wie zum Beispiel Azure CLI in Entra ID eingeschränkt werden. Es empfiehlt sich, diese mittels Conditional Access Policies vollständig zu blockieren und dann nur für Nutzer freizugeben, die diese auch tatsächlich benötigen.