Researchers at Varonis Threat Labs have detailed an attack technique called TrustSink that turns Microsoft Entra ID's support for third-party MFA providers into a standing password-theft mechanism. An attacker who already controls a highly privileged Entra account can register a fake "external authentication method," insert a pixel-perfect fake password prompt into the middle of a completely legitimate sign-in flow, and walk away with plaintext credentials — while the victim's login completes normally, with no error and no visible sign anything went wrong.
How TrustSink Works: Turning a Trusted Redirect Into a Password Trap
Entra ID lets organizations offload the second factor of MFA to an External Authentication Method (EAM) — a third-party provider that Entra redirects users to after they've entered their first-factor password. If that external provider sends back a validly signed token asserting the second factor succeeded, Entra considers MFA satisfied and completes the sign-in. It's a legitimate, documented feature meant for organizations that want to plug a non-Microsoft authentication service into their login flow.
Varonis found that an attacker holding Global Administrator or Authentication Policy Administrator rights can abuse that same trust relationship. Registering a rogue EAM means creating an app registration whose redirect URI points at Microsoft's own external-authentication callback endpoint, granting it tenant-wide admin consent, standing up a service principal, and scoping the method to a target group of users in the tenant's Authentication Methods Policy — all actions a top-tier admin account is fully entitled to perform.
Once registered, here's what a victim experiences: they type their real password into Microsoft's genuine login page, exactly as always. Entra then redirects them, as designed, to the attacker's external provider to complete MFA. Instead of a legitimate second-factor challenge, the victim's browser is served what Varonis describes as a pixel-accurate copy of Microsoft's own password prompt — same fonts, same layout, same blue button — arriving at exactly the moment a second verification step would seem plausible. The victim, having just authenticated on Microsoft's actual domain, types their password again. The attacker's server logs it in plaintext along with a timestamp and source IP, then constructs a validly signed token — pulling the user's identity out of the id_token_hint Microsoft supplies, and setting claims like acr: possessionorinherence and amr: hwk to assert a hardware-key factor was satisfied. An auto-submitting form posts that token back to Microsoft's callback, Entra validates the signature, and the sign-in completes without a hitch. As Varonis put it: "In our test tenant, every sign-in completed normally while our server received passwords with timestamps and source IP addresses."
The persistence angle is what makes TrustSink genuinely dangerous rather than a one-off phish. Resetting a compromised password does not remove the rogue provider from the tenant's Authentication Methods Policy. Varonis found that "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." In other words, once installed, the rogue EAM behaves like a standing credential tap that keeps harvesting fresh passwords indefinitely, surviving the exact remediation step defenders would normally reach for first.
Built on Prior Research Into Entra's Trust Model
TrustSink isn't built from scratch. It extends work security researcher Dirk-jan Mollema presented at x33fcon 2025 in a talk titled "Bringing Your Own Identity in Entra ID," which showed that a rogue registered external MFA provider could satisfy Entra's MFA requirement simply by returning a signed token claiming success — without ever performing a real second-factor check. Mollema's research focused on using that gap to bypass MFA outright. Varonis took the same underlying trust boundary — Entra accepting a signed assertion from a registered provider without verifying what that provider actually showed the user — and pointed it at a different goal: silently harvesting the password itself, on every subsequent login, indefinitely.
Not an Initial-Access Attack — Which Doesn't Make It Less Dangerous
It's worth being precise about what TrustSink is and isn't. Registering a rogue EAM requires modifying the tenant's Authentication Methods Policy, which demands Global Administrator or Authentication Policy Administrator privileges. That means TrustSink cannot get an attacker into a tenant in the first place — it's strictly a post-compromise technique, used after an attacker has already obtained top-tier administrative control.
That caveat matters, but it shouldn't be read as reassurance. Attackers routinely do reach Global Administrator through phishing, token theft, or misconfigured privileged-role assignments, and once they're there, TrustSink gives them something more durable than a single stolen session: a covert mechanism for continuously collecting plaintext passwords from targeted users, one that survives password resets and hides inside a legitimate, documented Entra feature rather than a piece of malware that endpoint tooling might catch. No CVE has been assigned to TrustSink — Varonis and BleepingComputer frame it as an abuse of a trust model within a feature working exactly as designed, not a coding flaw to be patched, which means defenders can't wait for a vendor fix and instead have to rely on detection and hardening.
Why This Matters
TrustSink is a reminder that "MFA satisfied" is only as trustworthy as the party Entra delegates that decision to. The External Authentication Method feature exists precisely so organizations can extend that trust to outside providers — and TrustSink shows what happens when the party holding that trust is hostile. Because the technique requires no malware on the victim's endpoint, produces no sign-in error, and keeps working after a password reset, it can go undetected for as long as nobody is specifically auditing changes to the Authentication Methods Policy. For any organization using external MFA providers with Entra ID, that policy — and the admin roles capable of editing it — deserves the same scrutiny as domain admin group membership.
Protective Measures
- Audit the Authentication Methods Policy regularly. Watch for new
externalAuthenticationMethodConfigurationentries, unfamiliar app registrations with redirect URIs pointing at Microsoft's external-auth callback, and service principals with attacker-controlled reply URLs. - Remove the rogue provider before resetting passwords, not after. Because TrustSink survives password resets, disable the external method and strip its group assignments — and delete the associated app registration, service principal, signing keys, and consent grants — before rotating any affected user's credentials.
- Reset credentials for every user who authenticated through a compromised provider, only after the rogue method itself has been fully removed.
- Restrict standing Global Administrator and Authentication Policy Administrator access. Use just-in-time privileged access (PIM) rather than persistent role assignment, since TrustSink is entirely dependent on an attacker holding one of these roles.
- Adopt phishing-resistant MFA, such as FIDO2 security keys or Windows Hello for Business. Methods that never ask a user to re-type a password during the MFA step make a bogus password prompt like TrustSink's immediately conspicuous.
- Monitor sign-in logs for unfamiliar issuers or
hwkclaims, and watch for unusual, scripted Graph API activity (bursts of policy-changing calls seconds apart) consistent with automated rogue-provider registration.