The short version
Researchers have documented a technique that turns Microsoft Entra ID's support for external MFA providers into a password-harvesting tool. An attacker who already controls a privileged Entra ID account can register a rogue "external authentication method" and have it silently intercept the passwords of anyone who signs in.
What happened
Entra ID lets organizations delegate the second authentication factor to third-party MFA providers. When a user signs in with their password, Entra can redirect them to that external provider to complete verification, then accepts a signed token back as proof the check passed.
The technique — dubbed TrustSink by the researchers who published it — abuses that trust. Instead of a real MFA challenge, the rogue provider shows the user a convincing copy of Microsoft's own password prompt. The victim, who has already typed their password once and is simply expecting a second-factor step, types it again without suspecting anything. The rogue provider captures that password in plaintext, forwards a validly signed "MFA passed" token back to Entra, and the sign-in completes normally — no error, no visible glitch.
Because the token really is valid, Entra has no way to tell the difference between a legitimate MFA response and one manufactured by the attacker's server. The victim's session opens as expected, and the stolen password sits with the attacker for later use.
The method builds on earlier public research into abusing Entra ID's external identity provider features, and was demonstrated by the researchers against real Entra tenants in a controlled proof of concept.
Why it matters
This isn't a way to break into an account from scratch — it requires an attacker who already holds a highly privileged Entra ID role, enough to register an external authentication method along with its supporting app registration and policy. That makes it a post-compromise technique: a way to expand and entrench access rather than gain initial entry.
That's exactly what makes it dangerous. Once the rogue provider is registered, it keeps working across future logins — including for users who later reset their password. A credential rotation alone doesn't clear the malicious provider from the authentication path; the next password a victim sets gets harvested the same way. For an incident responder, that turns a routine "reset the affected passwords" step into a false sense of resolution unless the rogue provider is explicitly found and removed.
It's also close to invisible from the user's side: same branding, same flow, no failed logins to raise an alarm.
What to do
- Audit external authentication methods and their app registrations in Entra ID regularly — don't assume the list is static.
- Tightly restrict who can modify the Authentication Methods Policy and register external providers — this should sit behind Global Administrator / Authentication Policy Administrator roles with strong monitoring, not routine access.
- Alert on changes to the Authentication Methods Policy, new application/service principal registrations tied to authentication, and new consent grants.
- Don't treat a password reset as remediation after any suspected privileged-account compromise — check for rogue external MFA providers before considering credentials clean, and remove them before rotating affected passwords.
- Move toward phishing-resistant, provider-independent MFA such as FIDO2 security keys or Windows Hello for Business, which are far harder to trick into revealing a reusable secret.