TrustSink in Microsoft Entra ID: Rogue MFA Providers Can Steal Passwords After Admin Compromise

What TrustSink actually is​

Varonis describes TrustSink as a credential-phishing technique that turns a trusted external authentication provider into a persistent credential trap within a legitimate sign-in flow. The researchers say the technique can work in any provider, but they demonstrated it end-to-end using Microsoft Entra. So far, other platforms are a theoretical extension, not a confirmed one.

The feature being abused is a legitimate one. Entra's external MFA feature, previously named external authentication methods, lets an organization plug a third-party MFA product into the Entra sign-in flow over OpenID Connect: the user signs in to Entra, Entra redirects them to the external provider for the second factor, and the provider sends back a signed token saying the check passed. As BleepingComputer explained, if the provider returns a valid signed token indicating that the second factor was completed, Entra considers the MFA requirement satisfied.

TrustSink abuses that handoff. Varonis found that an attacker who has already compromised a highly privileged Entra account can register a rogue External Authentication Method (EAM) as one of these external MFA providers and use it to insert a convincing Microsoft password prompt into the legitimate authentication flow.

Summary: This isn't a flaw in the Microsoft login page. It's a malicious use of a supported feature, set up by someone who already holds admin rights.

A correction to the "federated trust" framing​

MSSP Alert describes TrustSink as abusing Entra ID's "federated trust model" and says organizations with "federated identity configurations" face higher risk. That wording can mislead admins. Many of them hear "federation" and think of AD FS or SAML domain federation. Microsoft documents those as a separate setup, where a trusted identity provider issues federation tokens for a verified domain.

TrustSink, as Varonis demonstrated it, needs neither AD FS nor a federated domain. It works through an external MFA provider entry in the Authentication Methods Policy. A tenant that uses only cloud authentication is just as exposed if an attacker gets the right admin role. Both cases involve trusting outside identity infrastructure, but they are different mechanisms and need different controls.

How the trap works, step by step​

According to Varonis, the user's experience looks like this:

1. The user enters their email and password at Microsoft's real sign-in page. That first password goes to Microsoft.
2. MFA kicks in. Entra redirects the browser to the attacker's external provider.
3. Instead of displaying a legitimate second-factor challenge, the malicious provider presents a convincing replica of Microsoft's password prompt.
4. The user types the password again, and this time it goes to the attacker.
5. The fake prompt captures the user's password in plaintext before the malicious provider returns a valid signed token to Entra, causing the login to complete without displaying an error.

The timing is what makes it work. Varonis points out that the user has just typed a real password on Microsoft's own domain, so a second request inside the same flow doesn't look as odd as a link in an email would. Varonis also reports that "In our test tenant, every sign-in completed normally while our server received passwords with timestamps and source IP addresses."

Under the hood, Varonis built its demonstration provider as a lightweight Python and FastAPI OIDC server. It exposes an OpenID discovery document, a JSON Web Key Set endpoint, an authorization endpoint, and a credential-capture endpoint. Varonis says the provider served a public key from a self-signed RSA key pair. In this flow, Entra checked that the key ID matched and that the signature was valid. It did not check the certificate chain or where the key came from. The returned token included the claims acr: "possessionorinherence" and amr: ["hwk"], which tell Entra that a hardware-key check succeeded. No such check took place.

Summary: Entra sees a valid signed token. The user sees a familiar password box. Only the attacker sees the password.

The prerequisite that changes the risk picture​

The MSSP Alert brief doesn't mention this, and it matters most for prioritizing. TrustSink is not an initial-access attack and requires an attacker to already control a highly privileged Entra account. An attacker must first obtain a highly privileged Entra role, such as Global Administrator or Authentication Policy Administrator, to alter the Authentication Methods Policy.

The roles may not be quite that simple. One analysis on DEV Community notes that Global Administrator covers the full chain, while narrower roles may require additional privileges or pre-existing consent. That's because the setup also involves creating an app registration, a service principal and an admin consent grant.

There's also no evidence of real-world use so far. The same analysis says Varonis has demonstrated this behavior in their test tenant, but no exploitation in real-world environments has been confirmed, and it lists no CVE.

So why worry about a technique that needs Global Admin, which already gives full control of the tenant? Because of what happens after admin access is lost. A compromised admin account might be found and locked within hours. A rogue MFA provider labelled something harmless can keep collecting passwords long after that. Those passwords can work in places Entra doesn't control, such as reused personal accounts or on-premises systems that share credentials. As GBHackers put it, once those privileges are available, the rogue provider can become a durable credential trap targeting users assigned to its scope.

Prior art: this trust boundary isn't new​

TrustSink builds on earlier work. Security researcher Dirk-jan Mollema's 2025 x33fcon presentation showed how a rogue Entra external authentication provider could return a signed token and bypass MFA checks. Mollema used the rogue provider to skip MFA. Varonis uses the same opening to collect passwords. The weakness is the same in both cases: Entra trusts whatever a registered provider shows the user and accepts whatever signed token it sends back.

Why a password reset alone won't fix it​

This is the part incident responders most need to know. Varonis reports: "Resetting a captured password did not remove the rogue provider. It remained in the authentication flow and captured the replacement password at the user's next sign-in."

If your first step is to force password resets for everyone, you may simply hand the attacker a fresh set of passwords. Based on Varonis's guidance, the order matters:

1. Remove the provider first. Disable the external method in the Authentication Methods Policy and remove its group assignments before resetting any passwords.
2. Remove the supporting objects. Delete the app registration, the service principal, its signing keys, the openid/profile consent grant and the callback redirect URI.
3. Find who was affected. Use sign-in logs to identify every user who authenticated through the provider.
4. Then reset and review. Reset those users' passwords and check what their accounts did afterwards.
5. Audit Conditional Access. Look for policies changed to target new groups, especially any edited around the time of a suspicious registration.

Detection: where TrustSink leaves traces​

Varonis reports that most stages of the setup leave a trace in the logs:

Varonis also saw a FIDO key added to the test user's SearchableDeviceKey property, which it describes as an unintended side effect. That's a lab observation, not a guaranteed indicator. Cyber Security News, as quoted by Cryptika, gives the simplest place to start: security teams should review every externalAuthenticationMethodConfiguration entry and investigate additions outside approved deployments.

Hardening: the broader lessons​

Two of Varonis's recommendations deal with the root cause rather than the symptoms:

• Cut standing privilege. Limit permanent Global Administrator and Authentication Policy Administrator assignments. Microsoft's own Entra guidance recommends Privileged Identity Management for just-in-time role activation, with phishing-resistant authentication required to activate a role. It also recommends alerts on tenant-wide changes, including new applications, service principal credentials and consent activity.
• Change what users expect. Move users to FIDO2 passkeys or Windows Hello for Business. Once users never type a password during MFA, a password box at that stage looks suspicious instead of routine.

Microsoft hasn't published a TrustSink-specific advisory in the material reviewed here. Its general guidance is defence in depth, not a fix for this technique.

The bottom line​

The MSSP Alert brief is right that TrustSink turns trusted login infrastructure into a password trap. It overstates the threat by leaving out the admin-access requirement, and its "federated identity" wording points in the wrong direction. For Windows and Entra admins, the takeaway is to audit external MFA providers as carefully as admin role assignments. If you ever find one you didn't add, remove it before you reset anyone's password.