Security1 publisher2 min readPublished
A rogue Entra MFA provider captures plaintext passwords inside a sign-in that still succeeds
Varonis Threat Labs registered its own External Authentication Method in a test Entra tenant and served a copy of Microsoft's password prompt during the second factor. Every sign-in completed, and the passwords landed in a file.
The Watch · Security desk
What happened
- Varonis Threat Labs demonstrated a technique it calls TrustSink end to end in Microsoft Entra, where an attacker holding high privileges registers a rogue External Authentication Method and places a password page inside the legitimate sign-in flow.
- In the test tenant every sign-in completed normally while the researchers' server received the passwords, each written with a timestamp and the source IP address.
- Resetting a captured password left the rogue provider in the authentication flow, and it captured the replacement password at that user's next sign-in.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- decision Response order changes. Unauthorized providers come out of the Authentication Methods Policy before any credential reset, because a reset run while the provider is live gives the attacker a second working password for the same user.
- exposure The victim has nothing to escalate. No failed login, no MFA denial, no error page, so the user-report channel most tenants rely on for phishing does not fire.
- capability One trust boundary now yields two attacker outcomes from a single policy write: skipping the second factor, or collecting the password behind it in cleartext.
- constraint Detection has to sit on the authentication configuration itself. Hunting for anomalous sign-ins will not find this, since the durable artifact is a registered provider that Entra fetched and accepted.
Registering an External Authentication Method writes to the tenant's Authentication Methods Policy, and Varonis says the attacker needs high privileges to get there [3][8]. TrustSink lands after the account takeover [19]. What it adds to a privileged foothold is a plaintext password feed.
Varonis built the provider as a minimal OpenID Connect server in Python with FastAPI, four endpoints in total, two facing Entra and two facing the user [7]. Entra learns the provider exists by fetching a discovery document at its `/.well-known/openid-configuration` URL, before any user is redirected; if that document is unreachable or invalid, Entra rejects the provider and the user gets an error page [8]. Entra then pulls an RSA public key from the provider's `/jwks` endpoint and caches it [9]. Varonis generated that key pair itself, self-signed, at first launch [9]. Microsoft checks that the key ID matches and the signature is valid [10]. "It does not check the certificate chain or where the key came from," Varonis wrote [11].
The user-facing half is where the password goes. When MFA triggers, Entra redirects the browser to `/eam/authorize` and supplies an `id_token_hint` identifying the user, a nonce tying the response to the request, and the callback URI to post back to [12]. Varonis answered that redirect with what it describes as "a pixel-accurate copy of Microsoft's own password prompt" [13]. The submitted password went to a local credentials file, and the server then built the signed token Entra was waiting for [14].
The key fetch runs on Microsoft's metadata cycle: Entra caches the JWKS and does not pull it again at each sign-in. What repeats for every authentication is the browser redirect to the attacker's page [22].
The trust boundary was published first. Dirk-jan Mollema showed at x33fcon 2025, in a talk called "Bringing Your Own Identity in Entra ID", that a rogue registered EAM provider could bypass MFA by returning a signed JWT without performing a real authentication check [15]. Varonis used the same boundary for a different objective, capturing plaintext passwords from the page the provider controls [16].
Varonis says it published the work to help IT and security teams detect unauthorized changes to authentication infrastructure and remove rogue providers before resetting affected credentials [17]. The post does not report use of the technique against a production tenant, and it carries no response from Microsoft; the research is lab work in the company's own test tenant [23].
What to watch
- Whether Microsoft adds provenance or attestation checks to EAM provider registration, beyond key ID and signature validation.
- Any report of a rogue EAM registration found in a production tenant rather than a lab.
- Whether Entra audit logs surface Authentication Methods Policy writes and provider redirect targets in a form a SOC can alert on.