TrustSink: How a Rogue MFA Provider Hijacks Microsoft Entra Logins

A newly disclosed attack technique, dubbed TrustSink, shows how an attacker who already holds Authentication Policy Administrator rights in Microsoft Entra ID can turn a trusted step of the sign-in flow into a durable password-harvesting mechanism — without a single phishing email or browser exploit.

What happened

TrustSink abuses Entra's External Authentication Method (EAM) feature, which lets an organization delegate part of multi-factor authentication to an outside provider. Once an attacker has registered a malicious app, created a service principal, granted the right consent, and pointed Entra at an HTTPS endpoint they control, that endpoint becomes an active participant in every login that uses it.

The trick is that the rogue provider shows two different realities to two different audiences. Microsoft Entra receives a cryptographically signed response confirming the additional factor succeeded — the attacker's server even publishes its own discovery document and signing key so the token verifies cleanly. The victim, meanwhile, sees a convincing replica of a Microsoft sign-in screen asking them to re-enter their password "to finish verification." That second password field is never validated against anything real — it exists purely to capture credentials in plaintext while the user is returned, uninterrupted, to the application they were trying to reach.

Because the token can even claim a hardware security key was used, the fraudulent MFA event can look stronger than a normal sign-in in the logs, which makes it easy to miss.

Why it matters

TrustSink doesn't rely on tricking a user into clicking a bad link or exploiting a browser bug. It relies entirely on control over identity infrastructure that a privileged account already has access to — authentication policies, app registrations, and consent grants. That means the real exposure isn't a single unlucky click; it's a compromised or over-privileged admin account being used to quietly convert every subsequent login into a credential-harvesting opportunity. Once in place, the technique gives an attacker a renewable stream of valid passwords long after the original compromise, even from users who reset their credentials in response to unrelated incidents.

What to do

• Audit every externalAuthenticationMethodConfiguration entry in your tenant and flag any that weren't part of an approved deployment.
• Correlate app registrations, service principal creation, consent grants, group assignments, and new redirect URIs that occur close together in time — that clustering is a strong signal of setup activity.
• Review sign-in logs for unfamiliar issuer URLs on external authentication events, especially ones claiming hardware-key-backed verification that your organization never provisioned.
• If you suspect TrustSink is in play, disable and remove the external authentication method and its associated groups before resetting any passwords, then remove the related app registration, service principal, signing keys, consent grants, and redirect URI, and reset credentials for everyone who authenticated through it.
• Tighten standing access to Global Administrator and Authentication Policy Administrator roles, apply least privilege, and review assignments regularly — this is the control that most directly closes the door TrustSink walks through.
• Accelerate the move to phishing-resistant authentication such as FIDO2 security keys or Windows Hello for Business, particularly for admins who can modify identity policy, so a stolen password alone stops being enough.

TrustSink is a reminder that identity infrastructure itself is now an attack surface: the controls that protect logins can be repurposed to attack them once an attacker holds the right administrative role.