· via dev.to (home feed)
TrustSink: rogue external MFA providers in Microsoft Entra ID can steal sign-in passwords
Varonis's TrustSink research shows how a rogue External Authentication Method in Microsoft Entra ID can capture plaintext passwords while users sign in, with the login still completing normally.

Security researchers at Varonis have demonstrated a post-compromise attack, which they call TrustSink, that turns Microsoft Entra ID's External Authentication Methods feature into a password-harvesting mechanism. Once a rogue MFA provider is registered in a tenant, users are redirected to it during sign-in, asked to retype their password on a page that mimics Microsoft's, and then logged in without any error — leaving the attacker holding the plaintext credential. A detailed summary of the research was republished on dev.to, and BleepingComputer has also issued a technical report on the findings.
How the attack chain works
According to Varonis, this is not an initial-access technique. The attacker must already control sufficient privileges in the tenant: a Global Administrator role covers the entire chain, while less powerful roles would need additional rights or consent that was granted previously.
With that foothold, the attacker creates an application and service principal, grants consent, registers the application as an External Authentication Method (EAM) provider, and assigns the method to a chosen group of users. The provider must be reachable at a public HTTPS URL, because both the user's browser and Entra itself communicate with it.
The attack then unfolds inside an otherwise ordinary sign-in:
- The target user completes the first factor on Microsoft's genuine sign-in page.
- Entra redirects the browser to the attacker-controlled provider for the second factor.
- The provider shows a password prompt styled to look like a Microsoft page and records what the user types, in plaintext.
- The provider returns a signed token asserting that MFA succeeded, and Entra finishes the login.
Varonis confirmed the full sequence, including password capture and sign-in completion via signed tokens, in its own test tenant. The dev.to summary stresses that no exploitation in real-world environments has been confirmed, no malware or threat group has been tied to it, and there is no associated CVE.
Why users and admins miss it
From the user's perspective, the only oddity is being asked for the same password twice in quick succession on what appears to be a Microsoft screen. Because the sign-in completes normally, nothing signals that a theft occurred. Varonis also notes that if a victim changes their password while the rogue provider is still registered, the new password can be captured at the next sign-in.
For administrators, the stronger signals sit in tenant configuration and logs: external methods appearing in the Authentication Methods Policy, changes to target groups, and applications, service principals, signing keys and consent grants created within a short window, alongside MFA success records from issuers the organisation does not recognise. Varonis observed one unintended side effect in its lab — a FIDO key was appended to the test user's SearchableDeviceKey property — which can serve as an additional forensic clue.
Recommended defences
Varonis's mitigations centre on limiting and watching the privileges that make the attack possible:
- Do not keep rights to modify authentication methods permanently, and monitor for privilege escalation and changes to the Authentication Methods Policy.
- If a rogue EAM is discovered, disable its settings and group assignments first, then delete the related applications, service principals, signing keys and consent grants. Rotate affected passwords and revoke active sessions and tokens.
- Prefer FIDO2 keys or Windows Hello for Business, so that any password re-entry during an MFA prompt stands out as anomalous.
Investigations should combine identity logs with proxy and browser history to trace redirects toward unfamiliar external domains during sign-in. Varonis cautions that Entra caches provider metadata, so JWKS or metadata retrieval events may not line up in time with the malicious sign-ins.
Why it matters
External Authentication Methods exists so organisations can plug third-party MFA vendors into Entra ID. TrustSink shows that the same trust mechanism, once administrative control of a tenant is lost, becomes a credential-theft channel embedded in the official login flow — one that even produces valid, signed MFA tokens. There is no vulnerability to patch and no malware to detect on the endpoint; the defence is operational. Treat the Authentication Methods Policy as tier-zero configuration, alert on every change to it, and continue moving users toward phishing-resistant credentials that never ask for a password at all.
- #security
- #microsoft-entra-id
- #mfa
- #identity
- #cloud-security