Microsoft Entra TrustSink Attack Uses Rogue MFA Provider to Steal Passwords

TrustSink, a post-compromise credential-phishing technique that abuses Microsoft Entra External Authentication Methods (EAMs) to place a rogue password prompt inside an otherwise legitimate Microsoft sign-in flow.

The attack enables an adversary with elevated tenant privileges to capture plaintext passwords while returning a valid signed token to Entra, allowing the victim’s login to complete without an error.

The feature is designed to let organizations integrate third-party MFA services, but a malicious administrator can register an attacker-controlled provider and scope it to target users.

When MFA is invoked, Entra redirects the user’s browser to the external provider, which is trusted to perform the authentication check and return signed claims.

In the TrustSink proof of concept, the rogue provider presents a pixel-accurate imitation of a Microsoft password page after the victim has already entered their legitimate password at Microsoft’s domain.

Because the second prompt appears during an expected MFA sequence, it can look credible to users.

The attacker-controlled page records the password, timestamp, and source IP address, then generates a signed JWT indicating that the required authentication step was completed.

Entra validates the signature against the provider’s published key and allows the login to proceed.

The technique is particularly dangerous because the victim experiences no failed authentication, suspicious redirect warning, or visible interruption.

From the user’s perspective, the process appears routine: enter the Microsoft password, complete an MFA-related step, and access the intended application.

The attacker, however, receives reusable credentials while retaining a persistent foothold in the tenant’s authentication infrastructure.

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 Threat Labs said that, TrustSink exploits a critical trust boundary in Entra’s support for external OpenID Connect (OIDC)-based authentication providers.

Microsoft Entra TrustSink

Entra uses the discovery metadata and public signing key to establish trust in the external provider, while the victim is redirected to the provider-controlled password collection page during authentication.

An id_token_hint identifying the user, a nonce tying the response to this request, and the callback URI to post back to. 

The research follows prior work by security researcher Dirk-jan Mollema, whose 2025 x33fcon presentation showed how a rogue Entra external authentication provider could return a signed token and bypass MFA checks.

That research demonstrated the broader risk of allowing an attacker-controlled identity provider to assert successful authentication; TrustSink applies the same trust model to credential theft rather than solely MFA bypass.

TrustSink is not an initial-access technique. An attacker must first obtain a highly privileged Entra role, such as Global Administrator or Authentication Policy Administrator, to alter the Authentication Methods Policy.

However, once those privileges are available, the rogue provider can become a durable credential trap targeting users assigned to its scope.

Entra fetches the discovery document and signing keys over HTTPS, and the victim’s browser is sent to the same place during the redirect, so the provider needs a public URL.

Password resets alone do not remediate the incident. If the malicious EAM remains registered, the next sign-in can capture the replacement password.

Defenders must remove the unauthorized provider before rotating credentials and should treat the event as a potential tenant-level compromise.

Security teams should monitor Entra audit logs for new externalAuthenticationMethodConfiguration entries, unexpected Authentication Methods Policy changes.

Newly created application registrations using the external authentication callback URI, and unfamiliar service principals with externally hosted reply URLs.

Sign-in logs may also expose the rogue provider’s issuer URL and suspicious MFA claims, including hardware-key assertions such as acr: possessionorinherence and amr: ["hwk"] that do not match the organization’s approved authentication architecture.

Organizations using external MFA providers should strictly limit roles capable of changing authentication policies, require privileged identity monitoring, maintain an approved-provider inventory, and investigate any unplanned OIDC metadata or signing-key changes immediately.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC