Multifactor authentication is meant to be the safety net that saves an account even after the password leaks. Researchers at Varonis have described a way to turn that safety net into the thing that steals the password, by slipping a fake prompt into the middle of a genuine Microsoft sign in.
The technique, which the company's threat research team calls TrustSink, does not defeat multifactor authentication and it is not a way into an organization. It is something an intruder arranges after they already hold a powerful account, so that they can keep collecting passwords long after the first break in. Varonis showed it working against Microsoft Entra, the identity service that stands in front of Microsoft 365 and a great many company applications, and says the same weakness applies to any system that lets an outside service handle the second factor.
How the trap works
Entra can be told to hand off the second authentication step to an external provider. When a user has entered their password, Entra sends them to that provider, and if the provider returns a correctly signed token saying the extra check passed, the login is allowed to finish.
TrustSink abuses that arrangement. An attacker who already controls a high level Entra account registers their own server as one of these trusted providers. From then on, a targeted user signs in as normal, typing their password on the real Microsoft page. Multifactor authentication triggers, and Entra forwards them to the attacker's server. Instead of a genuine second factor, the server shows a copy of the Microsoft password screen. The user, who has just typed their password a moment earlier on a real Microsoft address, types it again. That second entry goes to the attacker. The server then returns a valid token, and the sign in completes with no error at all.
What makes it convincing, Varonis notes, is the timing. The fake screen appears at the one moment when being asked for a password again feels normal, inside a flow the user has just started on Microsoft's own domain. There is no suspicious email, no odd link, and the session ends on the application the person was trying to reach.
Why a password reset does not fix it
The danger is in how long it can last. Because the rogue provider stays registered in the organization's settings, changing a compromised password does not shake it off. The old password stops working, the user sets a new one, and the next time they sign in the same trap captures the replacement. Varonis found that in its test, resetting a captured password simply produced a fresh one for the attacker on the following login.
For that reason the firm stresses an order of operations that is easy to get wrong: remove the malicious provider first, then reset the affected passwords. Doing it the other way round wastes the reset.
The limits, and the defenses
The important caveat is the one Varonis puts up front. Registering an external authentication method is a privileged action. It requires an account with Global Administrator or Authentication Policy Administrator rights, which means the attacker has to have taken over a senior account before any of this is possible. TrustSink is a way to dig in and stay, not a way to get through the front door. It also builds on earlier work, presented at a security conference in 2025, that showed how a rogue external provider could satisfy a multifactor check without performing a real one.
The defenses follow from how the trap is set and how it behaves:
- Watch for changes to the authentication methods policy. An external provider that appears without anyone having scheduled or approved it is the first thing worth catching.
- Keep the number of standing Global Administrator and Authentication Policy Administrator accounts small, since those are the only roles that can alter this part of the system.
- Review new application registrations and service accounts that insert themselves into the login path without a clear business reason.
- Move users onto phishing resistant methods such as FIDO2 security keys or Windows Hello for Business. When a hardware key is the expected second factor, a sudden request to retype a password reads as wrong.
- If a rogue provider is found, use the sign in records to identify everyone who authenticated through it, remove the provider and the accounts it created, and only then reset those users and review what happened on their accounts.
Microsoft has not announced a change to how external providers are handled. The underlying behavior is by design: a signed token coming back from an approved provider is accepted on its own, with no check on what that provider actually put in front of the user. That is why Varonis frames the work as a warning to defenders rather than a single bug waiting for a patch.
