Externe Multi-Faktor-Authentifizierung (MFA) gilt als sichere Ergänzung zu Passwörtern. Doch was, wenn der MFA-Anbieter selbst zur Falle wird? TrustSink – eine von Varonis Threat Labs entdeckte Angriffsmethode – zeigt, wie Angreifer einen scheinbar vertrauenswürdigen externen Authentifizierungsanbieter in Microsoft Entra (ehemals Azure AD) als dauerhafte Passwortfalle missbrauchen. Das Tückische: Selbst nach einem Passwort-Reset bleibt die Falle aktiv – und fängt das neue Passwort beim nächsten Login ab.
Wie TrustSink funktioniert: Der Angriffsablauf
- Vorbereitung: Der gefälschte Anbieter
Ein Angreifer mit Global Administrator- oder Authentication Policy Administrator-Rechten registriert einen rogue External Authentication Method (EAM)-Anbieter in Microsoft Entra. Dieser Anbieter:- Präsentiere dem Nutzer eine 1:1-Kopie der Microsoft-Login-Seite (inkl. Layout, Schriftarten, Buttons).
- Gibt gegenüber Entra vor, eine gültige MFA-Prüfung durchgeführt zu haben – ohne echte Authentifizierung.
- Leitet die eingegebenen Passwörter im Klartext an den Angreifer weiter, während er gleichzeitig ein signiertes JWT-Token an Entra zurücksendet, um den Login abschließen zu lassen.
- Der Nutzer sieht: Business as usual
Aus Nutzerperspektive läuft alles normal ab:- Login auf
login.microsoftonline.com→ Passworteingabe (an Microsoft). - MFA wird ausgelöst → Weiterleitung zu einer zweiten Passwortabfrage (die gefälschte Seite).
- Eingabe des Passworts → automatische Weiterleitung zum Zielsystem.
Kein Fehler, keine Warnung. Die zweite Passwortabfrage erscheint logisch, da sie direkt im bekannten Login-Flow eingebettet ist.
- Login auf
- Die Falle schnappt zu
- Das Passwort wird im Klartext an den Angreifer gesendet (inkl. Zeitstempel und IP-Adresse).
- Selbst nach einem Passwort-Reset bleibt der EAM-Anbieter aktiv – und fängt das neue Passwort beim nächsten Login ein.
Warum TrustSink gefährlich ist
- Persistenz: Die Falle bleibt bestehen, bis der EAM-Anbieter manuell entfernt wird.
- Hohe Glaubwürdigkeit: Die gefälschte Seite ist pixelgenau und erscheint im offiziellen Microsoft-Flow.
- Umgehung von MFA: Der Angreifer nutzt eine Vertrauensgrenze in Entra: Solange der EAM-Anbieter ein gültiges Token zurückgibt, wird die Authentifizierung akzeptiert – unabhängig davon, was dem Nutzer angezeigt wird.
- Schwierige Erkennung: Nutzer erkennen den Betrug nicht, da die URL nur kurz im Browser sichtbar ist (z. B. auth-verify.microsoft-sso.com).
Erkennung und Abwehr: Was Unternehmen jetzt tun müssen
| Bereich | Maßnahme | Warum? |
|---|---|---|
| Authentifizierungsrichtlinien | Überwachen Sie Änderungen in der Authentication Methods Policy (neue EAM-Anbieter). | Jeder nicht autorisierte Eintrag ist ein Warnsignal. |
| Anwendungsregistrierungen | Prüfen Sie neue App-Registrierungen mit unbekannten Redirect-URIs (z. B. externalauthprovider). | Angreifer nutzen oft generische Namen wie „Security Verification“. |
| Service Principals | Analysieren Sie neue Service Principals mit unbekannten Zertifikaten oder Schlüsselmaterial. | Diese werden automatisch bei der App-Registrierung erstellt. |
| Login-Logs | Filtern Sie nach unbekannten Issuern (z. B. acr: "possessionorinherence", amr: ["hwk"]). | Genuine Hardware-Key-Logs enthalten diese Claims nur nach echter Authentifizierung. |
| Automatisierte Tools | Achten Sie auf häufige Graph-API-Aufrufe in kurzer Zeit (z. B. Add application, Add service principal). | Angreifer nutzen Skripte für schnelle Bereitstellung. |
Sofortmaßnahmen bei Verdacht:
- EAM-Anbieter deaktivieren (in der Authentication Methods Policy).
- App-Registrierung und Service Principal löschen (inkl. Zertifikate und Berechtigungen).
- Betroffene Nutzer identifizieren (über Login-Logs) und Passwörter zurücksetzen.
- Conditional Access-Richtlinien prüfen (wer hat Zugriff auf die Authentifizierungspfade?).
- Auf FIDO2/Windows Hello umstellen – Passwortabfragen während der MFA sind dann verdächtig.
Fazit: Vertrauen ist gut – Kontrolle ist besser
TrustSink nutzt eine Systemschwäche aus: Microsoft Entra vertraut blind auf signierte Tokens von registrierten EAM-Anbietern – ohne zu prüfen, was diesen Anbietern angezeigt wird. Für Angreifer ist dies eine hocheffiziente Persistenzmethode; für Verteidiger eine weitere Erinnerung, dass Identitätsinfrastrukturen genauso überwacht werden müssen wie Login-Versuche selbst.
Handlungsempfehlung:
- Regelmäßige Audits der Authentifizierungsrichtlinien und App-Registrierungen.
- Einschränkung von Admin-Rechten (Global Administrator, Authentication Policy Administrator).
- Nutzer für ungewöhnliche Passwortabfragen sensibilisieren – selbst wenn sie „offiziell“ aussehen.
Weiterführende Links:
Varonis Threat Labs: TrustSink Deep Dive (englisch)
Microsoft-Dokumentation: Externe Authentifizierungsmethoden
Frage an Sie:
Haben Sie bereits Erfahrungen mit externen MFA-Anbietern in Ihrer Umgebung gemacht? Wie überwachen Sie aktuell Änderungen in Ihrer Identitätsinfrastruktur?