TrustSink: Rogue MFA Provider Steals Entra Passwords

The second factor is supposed to be the part of a login that a stolen password cannot beat. In TrustSink, the second factor is the thief. Varonis Threat Labs published the technique in September 2026, and in its write up the researchers put the result plainly: "In our test tenant, every sign-in completed normally while our server received passwords with timestamps and source IP addresses." Nothing broke. Nobody saw an error. The passwords just flowed out.

Key Takeaways

• Varonis Threat Labs named the technique TrustSink and demonstrated it against Microsoft Entra ID's external MFA feature, formerly called external authentication methods (EAM).
• An attacker who already holds Global Administrator or Authentication Policy Administrator rights registers a rogue provider that shows a fake Microsoft password prompt, then returns a validly signed token so the login succeeds.
• Password resets do not evict the attacker, because the rogue provider stays registered and captures the new password on the next sign in.
• Microsoft Entra ID validates that the returned token was signed by the configured provider, so it has no way to see what the provider page actually asked the user for.
• Every harvested Entra password is also the key to that user's Exchange Online mailbox, which makes TrustSink a quiet engine for email account compromise.

What Is TrustSink?

TrustSink is a post compromise credential harvesting technique that abuses Microsoft Entra ID's trust in external MFA providers to collect plaintext passwords during otherwise legitimate sign ins. It is not an initial access attack. The attacker must first control a highly privileged Entra account, which BleepingComputer's coverage stresses as the main limiting factor.

That limit is real, but it is not comforting. Tenant admin accounts get phished too, and once an intruder has them, TrustSink turns a temporary foothold into a durable one. Varonis frames it as persistence: a way to keep collecting fresh credentials long after the original compromise.

The research builds on a trust boundary Dirk-jan Mollema highlighted in his x33fcon 2025 talk, "Bringing Your Own Identity in Entra ID," where a rogue provider was used to bypass MFA by returning a signed token without doing any real check. TrustSink repurposes the same gap for password capture rather than bypass.

How Does a Rogue External MFA Provider Work?

A rogue external MFA provider works because Entra hands the user's browser to whatever OpenID Connect server the admin configured and then trusts the signed token that comes back. Microsoft's external MFA provider reference describes the legitimate flow: the provider needs an OIDC discovery endpoint, an authentication endpoint and a published public key location, and "Microsoft Entra ID validates that the token's signature came from the configured external MFA provider, and then checks the contents of the token."

Varonis's proof of concept followed that contract exactly:

• A minimal OIDC server exposes /.well-known/openid-configuration, a /jwks key endpoint and an /eam/authorize endpoint.
• The attacker registers an application whose redirect URI is https://login.microsoftonline.com/common/federation/externalauthprovider, grants tenant wide consent for the openid and profile scopes, and adds the provider to the Authentication Methods Policy as an externalAuthenticationMethodConfiguration entry scoped to a target group.
• After the user types their real password on the real Microsoft page, Entra redirects them to the rogue endpoint, which shows a pixel accurate Microsoft password prompt.
• The server records the password, signs a JWT with acr: "possessionorinherence" and amr: ["hwk"], and auto posts it back to Microsoft.
• Entra accepts the token and the user lands in their app.

The hwk claim means "proof of possession of hardware-secured key" in Microsoft's own claim table. The rogue server is asserting that a hardware key was used when all it actually collected was the password a second time. Entra cannot tell the difference, by design.

Why Doesn't a Password Reset Fix It?

A password reset fails because it rotates the credential without removing the collector. Varonis puts it this way: "Resetting the password doesn't work with TrustSink. The old credential dies, but the provider is still live, so it harvests the replacement on the next sign-in."

This inverts the standard incident response reflex. The usual first move after suspected credential theft is a forced reset, which here simply hands the attacker a fresh password and a timestamp. Compare that with the password spraying wave that surged 155x by skipping the MFA prompt: there, a reset plus closing legacy flows ends the attack. With TrustSink, order of operations decides whether cleanup works at all.

What This Means for Your Inbox

The Varonis write up does not discuss email, but the implication is direct. In a Microsoft 365 tenant, the Entra password is the Exchange Online password. Every credential TrustSink collects is a working key to that user's Outlook mailbox, delivered in plaintext, refreshed automatically after every reset.

Mailbox access is usually the point of an intrusion like this. We have seen it repeatedly this year, from passkey themed phishing that loots Microsoft 365 inboxes to adversary in the middle kits hijacking Outlook sessions. Those campaigns steal a session that eventually expires. TrustSink steals the password itself, over and over, which supports long running business email compromise: reading invoice threads, planting inbox rules, replying from a trusted address.

There is a spillover risk too. Plaintext passwords are exactly what attackers test against other services. If an employee reuses their work password on a personal Gmail or Yahoo account, a tenant level compromise quietly becomes a personal inbox compromise.

How Do You Detect and Remove a Rogue MFA Provider?

You detect it by auditing changes to the Authentication Methods Policy and removing the provider before rotating any credentials. Varonis lists these audit signals:

• "Update authentication methods policy" and "Add external authentication method" events in Entra audit logs.
• New service principals with non Microsoft reply URLs, and Add delegated permission grant events for openid and profile scopes.
• Sign ins showing an unfamiliar issuer URL alongside amr: ["hwk"].
• Bursts of Microsoft Graph calls within seconds, with scripted user agents such as python-requests.

Remediation order matters. Disable the external method and remove its group assignments first. Then delete the application registration, service principal and signing keys, revoke the consent grants, and remove the callback redirect URI. Only then reset passwords for every user who authenticated through the provider and review their account activity, including mailbox rules and forwarding.

Prevention starts with fewer standing admins. Limit permanent Global Administrator and Authentication Policy Administrator assignments, and move users toward phishing resistant methods like FIDO2 and Windows Hello for Business, as Varonis recommends. Microsoft's external MFA management guide shows where these providers live in the admin center; if your tenant has no legitimate external MFA vendor, that list should be empty, and any entry there is an alert.

The Authentication Strength Angle

One line in Microsoft's documentation deserves more attention than it has received: "Grant controls based on authentication strengths, including the built-in MFA strength, aren't satisfied by the external MFA method." Microsoft presents this as a limitation for vendors. For defenders, it reads as a mitigation. Conditional Access policies that require an authentication strength, rather than the plain "Require multifactor authentication" grant, should not be satisfiable by any external provider, rogue or legitimate.

That is our inference from the documentation, not something Varonis tested, and an attacker with Global Administrator rights can edit Conditional Access too. But it raises the cost: a quiet policy entry becomes a visible policy change. Pair it with the lessons from the 39 documented attacks against passkey authentication and the pattern is consistent: the cryptography holds, and attackers target the configuration layer that decides which cryptography is trusted.

Looking Ahead

Microsoft's EAM framework is designed to extend trust to third parties, and TrustSink shows that an extensibility point in the login flow is also a persistence point. As BleepingComputer reported, any provider that relies on this external authentication model could be exposed. Treat your list of trusted identity providers the way you treat your list of mail forwarding rules: short, reviewed, and alarming whenever it changes.