A technique called TrustSink lets an attacker register a rogue external MFA provider inside Microsoft Entra, silently harvesting users’ plaintext passwords during what appear to be completely normal logins. The TrustSink MFA attack Entra researchers devised is not a way in from the outside, it requires a foothold at the top of the privilege stack first, which is exactly what makes it so useful to an attacker who already has one.
How the TrustSink MFA Attack Entra Works
Varonis Threat Labs developed and named the technique. Microsoft Entra supports external MFA providers through a feature called External Authentication Methods (EAM), which lets organisations route second-factor challenges to third-party authentication services. When a user signs in with a password, Entra can redirect them to a registered external provider to complete MFA. If that provider returns a valid signed token indicating success, Entra accepts the MFA requirement as satisfied and lets the login proceed.
Varonis found that an attacker controlling a Global Administrator or Authentication Policy Administrator account can register a malicious provider as one of these trusted EAMs. That rogue provider, rather than presenting a genuine second-factor challenge, serves the user a pixel-perfect copy of Microsoft’s own password prompt (same fonts, same layout, same button design) appearing immediately after the user has already typed their real password on Microsoft’s legitimate login.microsoftonline.com domain.
The timing is deliberate. The fake prompt appears at the moment the user already expects another authentication step, so re-entering a password feels natural. If they comply, the credential goes straight to the attacker’s server. The rogue provider then generates a valid signed token telling Entra that MFA has been completed, the login finishes without error, and the user reaches whatever application they were trying to access, none the wiser.
‘In our test tenant, every sign-in completed normally while our server received passwords with timestamps and source IP addresses,’ Varonis explains. ‘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.’
Under the Bonnet: FastAPI, ngrok, and a Convincing App Name
The implementation detail Varonis disclosed makes the attack’s accessibility clear. According to Varonis, the team demonstrated the TrustSink MFA attack Entra using a FastAPI server exposed through ngrok, registering an application given an anodyne name such as ‘Security Verification’, scoped to accounts in the organisational directory only, with its Web redirect URI pointed at Microsoft’s external authentication callback. Nothing about that setup would raise immediate alarm in a routine application audit.
According to Gblock, the work was carried out by Varonis Threat Labs researcher Elad Ghvarh, who showed that holding Global Administrator or Authentication Policy Administrator rights is sufficient to plant the fake provider. Registering it requires modifying the tenant’s Authentication Methods Policy and creating an application, a service principal, and a consent grant, privileged operations, but routine ones for an account at that level.
Varonis acknowledges TrustSink builds on earlier research by security researcher Dirk-Jan Mollema, presented at x33fcon 2025 in a talk titled ‘Bringing Your Own Identity in Entra ID’. Mollema showed how a rogue registered external MFA provider could satisfy an MFA requirement by returning a signed JWT claiming authentication had succeeded, without performing any real authentication check. TrustSink turns that same mechanism into an active credential-theft tool.
What Defenders Should Do
Because the rogue provider sits inside the tenant’s Authentication Methods Policy rather than on an individual user’s account, changing a compromised password does nothing to remove the threat. The replacement password will simply be captured at the next login. Varonis is explicit on the order of operations: remove the malicious provider and its associated application, keys, and redirect URIs before resetting any affected users’ credentials.
Beyond the immediate clean-up, Varonis recommends monitoring for changes to the Authentication Methods Policy, reducing standing Global Administrator and Authentication Policy Administrator privileges, and moving users to phishing-resistant authentication methods such as FIDO2 or Windows Hello for Business, which sidestep the password-prompt attack surface entirely. The TrustSink MFA attack Entra exposes is post-compromise by design, but that is cold comfort given how many incidents begin with a single over-privileged account.
