Last updated: September 2026
TrustSink is a technique, published by Varonis Threat Labs in September 2026, in which an attacker who already holds a highly privileged Microsoft Entra ID role registers a rogue external MFA provider (a feature Microsoft previously called external authentication methods). When a user reaches the MFA step, Entra sends them to the attacker’s provider, which shows a convincing copy of the Microsoft password page, records the password in plain text, and then returns a validly signed token so the sign-in succeeds. Nothing looks broken to the user, and resetting their password does not help, because the rogue provider stays in the flow and captures the new one. The controls that actually reduce this risk are tight protection of the roles that can change authentication policy, alerts on every change to that policy, and phishing-resistant sign-in with passkeys, which satisfies MFA without ever sending the user to an external provider’s page.
This post explains what TrustSink is, why it matters beyond Entra, and how the same hygiene applies to any identity provider, including Keycloak. It is written for the people who own an organization’s identity setup, and it assumes you know what MFA is but not necessarily how external MFA providers work.
What is TrustSink?
TrustSink is a post-compromise persistence technique, not a way in. Varonis describes it in its research post “TrustSink: How a Rogue External MFA Provider Steals Passwords” (September 2026), and BleepingComputer covered it on 22 September 2026 in “Rogue external MFA providers can steal passwords during logins”. Both are clear that the attacker must already control an account with the Global Administrator or Authentication Policy Administrator role in Entra ID before any of this is possible.
The feature being abused is a legitimate one. Entra’s external MFA feature (documented on Microsoft Learn in “How to manage external MFA in Microsoft Entra ID”, and previously named external authentication methods) lets an organization plug a third-party MFA product into the Entra sign-in flow over OpenID Connect: the user signs in to Entra, Entra redirects them to the external provider for the second factor, and the provider sends back a signed token saying the check passed. Entra trusts that token because an administrator told it to trust that provider.
TrustSink uses that trust in four steps, as Varonis describes them:
- The attacker, holding a privileged role, registers a new external MFA provider pointing at a server they control.
- A targeted user signs in normally and, at the point where they expect a second factor, is redirected to the attacker’s provider.
- That provider shows a page styled like the Microsoft password prompt, with the same fonts, layout and buttons, and the user types their password again because a second prompt during MFA does not feel unusual.
- The provider returns a valid signed token, so Entra completes the sign-in and the user carries on without any error.
The research builds on earlier work by Dirk-jan Mollema, whose x33fcon 2025 talk “Bringing Your Own Identity Provider to Entra for Persistence and MFA Bypasses” showed that a rogue external provider could bypass MFA by returning a signed token without checking anything. TrustSink uses the same trust boundary for a different goal, which is harvesting plaintext passwords.
Why does a password reset not remove the trap?
A password reset changes the credential but leaves the authentication policy alone, and the rogue provider lives in the policy. According to Varonis, the provider stayed in the flow after the victim’s password was reset and captured the replacement at the next sign-in. The response therefore has to start with removing the rogue external MFA provider and reviewing who can create one, and only then move on to resetting credentials, because resetting first only gives the attacker the new password at the user’s next sign-in.
Why is this an IAM lesson and not just an Entra quirk?
Every identity provider has a place where someone decides which authentication steps run and which outside systems get to take part in them. In Entra that is the authentication methods policy and Conditional Access. In Keycloak it is the realm’s authentication flows and its identity-provider configuration. In both cases, whoever can edit that configuration can decide what the user sees during sign-in, and a user has very little ability to tell a legitimate step from a malicious one.
That means the configuration itself is part of your attack surface, in the same way that an admin account or a signing key is. Most organizations audit who can create users and grant roles, but fewer treat “added a new authentication provider” or “changed the login flow” as events that someone should look at the same day. TrustSink is a good argument for changing that, whatever product you run.
There is also a lesson for users. A password prompt that appears after you have already entered your password and reached the MFA step is unusual in almost every system. Security awareness training rarely covers this case, because the page is on a legitimate sign-in path, but it is worth telling people that a second request for the same password during MFA should be reported, not answered.
Which controls actually reduce this kind of risk?
The controls fall into three groups, and they work best together: protect the roles that can change authentication, watch the changes, and reduce what a fake page can steal.
Least privilege for the roles that change authentication policy
TrustSink starts with a privileged role, so the strongest control is making those roles hard to reach and short-lived. For Entra, that means few permanent Global Administrator and Authentication Policy Administrator assignments, just-in-time elevation where possible, and phishing-resistant MFA required for every administrator. Microsoft documents a Conditional Access policy for that last point on Microsoft Learn, in “Require phishing-resistant multifactor authentication for Microsoft Entra administrator roles”.
It is worth being honest about the limits here. A Global Administrator can change almost anything, including the policies meant to constrain them, so none of the controls below will stop an attacker who holds that role indefinitely. The goal is to make the role rare, time-boxed and loud, so that an attacker has less time with it and more chance of being noticed.
Alerts on every change to authentication configuration
Varonis points to the Entra audit log entries for changes to the authentication methods policy and for newly added external MFA providers as the signals to watch. Those events are rare in a healthy tenant, so an alert on each one costs little and catches the exact moment TrustSink is set up. Send them to whatever system your security team actually reads, and make someone responsible for confirming each change against a ticket.
Phishing-resistant methods over passwords and password re-prompts
Phishing-resistant MFA is any sign-in method that cannot be replayed through a fake page, because the credential is cryptographically tied to the real site’s domain and there is no code or password for the user to hand over. In practice that means methods built on the FIDO and WebAuthn standards, such as passkeys and security keys, and PKI-based methods such as smart cards, which are the two families CISA describes in its fact sheet “Implementing Phishing-Resistant MFA”.
Phishing-resistant methods such as passkeys (FIDO2 and WebAuthn credentials) help in two ways. First, a user who signs in with a passkey satisfies MFA with that sign-in, so they are not sent on to an external MFA step where the fake page waits, and if their account no longer has a password at all, there is nothing for a fake page to collect. Second, a passkey is bound to the real sign-in domain by the browser, so it cannot be relayed through a look-alike page.
There is also a policy effect in Entra. Microsoft’s page on managing external MFA states, as of September 2026, that external MFA methods are not currently supported with authentication strengths, so grant controls based on authentication strengths, including the built-in MFA strength, are not satisfied by an external MFA method. In practice, a rogue provider can only complete MFA for sign-ins governed by the older “require multifactor authentication” grant. Moving your Conditional Access policies to authentication strengths, and to the phishing-resistant strength where you can, takes those sign-ins out of the rogue provider’s reach. An attacker with enough privilege can still edit the policies, which is why the audit alerts above matter, but they now have to make two visible changes instead of one.
How do the same controls map to Keycloak?
Keycloak does not have an external MFA provider setting that an administrator can register from the admin console the way Entra does. Adding a new type of authenticator means deploying a provider JAR to the server, which moves that capability away from console administrators and onto whoever controls the deployment pipeline. The closer analogues are two things a realm administrator can do from the console: edit authentication flows, and add identity providers (including the Identity Provider Redirector step, which sends users straight to an external identity provider during login). Either can put an outside system in front of a user’s credentials.
The hygiene carries over directly:
- Limit who can change flows and identity providers. In Keycloak those abilities come from the
manage-realmandmanage-identity-providersroles on the realm-management client. Give them to few people, and use separate admin accounts for administration. - Turn on admin events and alert on the ones that matter (on Skycloak, admin configuration changes also appear in our audit logs). With admin events enabled, Keycloak records create, update and delete operations with resource types such as
AUTH_FLOW,AUTH_EXECUTION,AUTHENTICATOR_CONFIGandIDENTITY_PROVIDER. Those are the Keycloak equivalents of the Entra audit entries Varonis highlights, and our auditing and event logging guide shows how to enable them and ship them to a log pipeline. - Move users to passkeys. Since Keycloak 26.4, enabling passkeys in the WebAuthn Passwordless Policy activates passkey sign-in in the default browser flow. Our passkeys and WebAuthn guide covers the setup, and the Entra SMS retirement migration post covers moving an existing user base off weaker factors.
- Require phishing-resistant sign-in for administrators first. The master realm and any realm-management accounts are the Keycloak version of Global Administrator, and they are the obvious first group to move onto WebAuthn.
If you want a refresher on how Entra and Keycloak concepts line up more generally, our post on learning Entra ID through a Keycloak lens walks through the mapping.
How is TrustSink different from other MFA phishing?
Most MFA phishing happens before the attacker has any foothold. MFA fatigue floods a user with push prompts until they approve one, which we covered in our MFA fatigue and helpdesk vishing post. Adversary-in-the-middle kits and device-code lures trick a user into signing in through an attacker’s page or approving an attacker’s session, which is the subject of our device-code phishing post.
TrustSink is the opposite case. The attacker is already inside with administrative power and uses the identity provider’s own configuration to build a trap on the real sign-in path. That is why the most important controls are about administrators and configuration changes, and why phishing-resistant methods help mostly by removing the password the trap is designed to catch.
What should you do this week?
If you run Entra ID, list the external MFA providers configured in your tenant and confirm each one is expected, check how many people hold the two roles that can add them, and set up an alert on changes to the authentication methods policy. If you run Keycloak, confirm admin events are enabled with an alert on flow and identity-provider changes, and review who holds manage-realm and manage-identity-providers in each realm. In both cases, start moving administrators, and then everyone else, onto passkeys.
Frequently asked questions
Can TrustSink be used to break into an Entra tenant?
No. Varonis is explicit that TrustSink is not an initial-access technique. The attacker must already control an account with the Global Administrator or Authentication Policy Administrator role. It is a way to turn one compromised privileged account into a lasting source of other users’ passwords.
Does resetting a user’s password stop TrustSink?
Not on its own. Varonis found that the rogue external MFA provider stayed in the sign-in flow after a reset and captured the new password at the next sign-in. Remove the rogue method first, review who can add authentication methods, and then reset the affected credentials.
Do passkeys stop TrustSink?
They reduce the damage considerably. A user who signs in with a passkey satisfies MFA with it and is not sent to the external MFA step where the fake page waits, and a user with no password left has nothing for the page to collect. In Entra, Microsoft states that external MFA methods do not satisfy authentication strengths, so a policy that requires the phishing-resistant strength will not accept a rogue external provider as the MFA step. An attacker with enough privilege can still change that policy, so alerting remains necessary.
How do I detect a rogue external MFA provider?
Watch the Entra audit log for changes to the authentication methods policy and for newly added external MFA providers, and alert on every one. These events are rare in a normal tenant, so each alert is worth a human look. In Keycloak, the equivalent signals are admin events on authentication flows, authenticator configuration and identity providers.
Is Keycloak vulnerable to TrustSink?
TrustSink as published is specific to Entra’s external MFA feature, which Keycloak does not have in that form. The underlying risk, an administrator changing the login flow to put an outside system in front of users, does apply to Keycloak through flow edits and identity-provider settings. The same controls apply: few people with those rights, admin events with alerts, and passkeys for users.
