TrustSink Attack Uses Rogue MFA Provider to Steal Microsoft Entra Passwords During Legitimate Logins

TrustSink is a newly disclosed identity attack that turns a trusted MFA step into a password-stealing trap. Rather than sending victims to a clearly fake website, it places a convincing password prompt inside a normal Microsoft Entra sign-in.

In the researchers’ test tenant, the victim can complete MFA and reach the intended application without an error. A password reset alone may not solve the problem, because the rogue authentication provider can remain active and capture the replacement credential at the next login.

Researchers at Varonis identified the technique, which they call TrustSink, after demonstrating it in a test Microsoft Entra tenant.

Varonis said in a report shared with Cyber Security News (CSN) that the method is designed as a post-compromise persistence mechanism, not an initial-access tool.

An intruder first needs a privileged Entra account, such as Global Administrator or Authentication Policy Administrator. As cloud identity data theft reporting has shown, such access can have broad consequences.

Here, the attacker changes authentication policy, registers an app and service principal, grants consent, and exposes a provider over HTTPS.

TrustSink Attack Uses Rogue MFA Provider

TrustSink abuses an External Authentication Method, or EAM, which Entra can call during MFA. The malicious provider presents two different views of the same event: Entra receives a signed response saying the check succeeded, while the user is shown a copy of a Microsoft password page.

After the victim enters their normal password, MFA redirects the browser to the attacker-controlled provider. The second, lookalike password prompt appears at a believable point in the process, then silently records what the user types before automatically returning them to the application.

The provider publishes a discovery document and a public signing key that Entra uses to validate its responses. It then submits a signed token containing claims that indicate a hardware-key check succeeded, allowing the login to finish as expected, while making the theft harder to notice.

The same trust relationships have made identity applications attractive to attackers. Earlier reporting on OAuth app persistence techniques described how malicious app registrations and consent can create access paths that survive ordinary credential changes, although TrustSink instead captures fresh passwords during a live sign-in.

The attack is not based on an email lure or a browser exploit. It relies on control of authentication infrastructure after a privileged account has already been compromised, so defenders must monitor changes to policies, app registrations, and permissions.

Detection and Response Priorities

Security teams should review every externalAuthenticationMethodConfiguration entry and investigate additions outside approved deployments.

They should also correlate nearby audit events for a newly created application, service principal, consent grant, group assignment, or unexpected redirect URI, particularly when those actions occur within seconds.

Sign-in logs offer another important signal. Varonis found that the rogue provider leaves its issuer URL in the record and can report hardware-key-related claims despite no genuine key ceremony, so an unfamiliar issuer associated with such claims warrants immediate review.

If TrustSink is suspected, responders should disable and remove the external method and its group assignments before resetting passwords.

They should then remove the related app registration, service principal, signing keys, consent grant, and redirect URI, identify everyone who signed in through the provider, reset affected credentials, and examine their activity afterward.

These actions complement guidance from coverage of OAuth phishing redirect abuse, which stresses reviewing suspicious redirect URLs and unrecognized Entra applications.

Teams should also alert on Conditional Access policies changed to target new groups after questionable authentication changes.

The research recommends moving users toward FIDO2 security keys or Windows Hello for Business, so an unexpected password request during MFA is easier to recognize as abnormal.

The wider phishing-resistant Entra passkey rollout underscores why reducing dependence on reusable passwords matters, particularly for administrators who can change identity controls.

Finally, organizations should restrict standing Global Administrator and Authentication Policy Administrator privileges, using least privilege and frequent reviews.

That reduces the chance that one compromised account can become a durable credential collection point, even after affected users change passwords.

Indicators of compromise (IoCs):-

Type	Indicator	Description
URL	https://trident-sip-filter.ngrok-free.dev	Public HTTPS address used for the proof-of-concept rogue provider
URL	https://trident-sip-filter.ngrok-free.dev/eam/.well-known/openid-configuration	Rogue provider discovery URL configured in the Authentication Methods Policy
URL	https://login.microsoftonline.com/common/federation/externalauthprovider	External authentication callback redirect URI used by the test application
File name	deploy.py	Script used to automate the proof-of-concept deployment
File name	cleanup_eam.py	Script used to remove the proof-of-concept provider and related artifacts
File name	deploy_state.json	State file used by the deployment and cleanup process

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC