TrustSink: Password Theft via a Rogue External MFA Provider in Microsoft Entra ID

1. Basic Information

• Original Title: TrustSink: Rogue External MFA Providers Can Steal Passwords During Sign-In
• Publisher: Varonis
• Publication Date: 2026-09-16
• Collection Date: 2026-09-23T08:14:06+09:00
• Original Source: Varonis
• Severity: critical
• Basis for Severity: The attacker needs sufficient privileges to configure the EAM and grant consent to the provider application (Global Administrator covers the full chain, while narrower roles may require additional privileges or pre-existing consent). This allows them to capture plaintext passwords re-entered by users while returning a signed token indicating successful MFA. Varonis has demonstrated this behavior in their test tenant, but no exploitation in real-world environments has been confirmed.
• Related Information Source: BleepingComputer: Technical Report
• Related Information Source: Microsoft: Managing External Authentication Methods
• Related Malware: None
• Related Threat Group: Unidentified
• CVE: None
• Target Products/Services: Microsoft Entra ID, External Authentication Methods

2. Executive Summary

TrustSink is a post-compromise authentication infrastructure abuse technique. It injects a malicious External Authentication Method (EAM) into the normal Entra sign-in flow, steals passwords via a Microsoft-looking login screen, and still successfully completes the user login.

3. Attack Flow

From Rogue External MFA Provider Registration to Password Theft

1. The attacker needs sufficient privileges to configure the EAM and grant consent to the provider application. Global Administrator covers the full chain, while narrower roles may require additional privileges or pre-existing consent.
2. The attacker creates the required application and service principal, grants consent, registers a rogue EAM provider, and assigns the external authentication method to a target group.
3. A target user completes the first factor of authentication on the legitimate Microsoft sign-in screen.
4. For MFA, Entra redirects the user's browser to the external provider managed by the attacker.
5. The provider captures the password in plaintext when the user re-enters it on a fake Microsoft password screen.
6. The provider returns a signed token indicating successful MFA to Entra, and the user's sign-in completes without error.

4. Attacker Position and Execution Location

• An attacker who has already obtained sufficient privileges to configure authentication methods and grant application consent in the Entra tenant.
• The rogue provider must be reachable via a public HTTPS URL and is accessed by both the user's browser and Entra.

5. Visibility for Victims and Administrators

Victim

• Immediately after entering the password on the legitimate Microsoft screen, the user is prompted to re-enter the same password on a Microsoft-like screen. Because the final sign-in succeeds, it is difficult for the user to notice the theft.

Administrator

• Clues include the addition of external methods to the Authentication Methods Policy, changes to target groups, the creation of related applications, service principals, and consent grants in rapid succession, as well as MFA success records from unfamiliar issuers.

6. Success and Failure Conditions

Success Conditions

• The attacker has acquired sufficient privileges to configure the EAM and grant consent to the provider application.
• The attacker's public provider is registered and assigned to a target user or group.
• The target user re-enters their password on the rogue provider's screen.

Failure and Prevention Conditions

• Do not keep authentication method modification privileges permanently; monitor privilege escalation and changes to the Authentication Methods Policy.
• Disable and remove suspicious EAM settings and related objects, then revoke credentials and sessions.
• Use FIDO2 or Windows Hello for Business so that password re-entry during MFA is treated as anomalous.

7. What Happens Upon Success

• The attacker obtains the re-entered plaintext password and can simultaneously complete the legitimate sign-in.
• If the password is changed while the rogue provider remains active, the new password may also be captured during the next sign-in.
• The stolen credentials or established sessions could be used to compromise mailboxes and SaaS applications, although no such real-world impact has been publicly reported.

8. Observable Logs

• email: There is no specific mail path inherent to this technique. Check for mailbox operations after the compromise separately.
• proxy_swg_dns: Verify traffic redirected to unfamiliar EAM issuers or external HTTPS domains during sign-in.
• endpoint_edr: Malware execution on the endpoint is not a prerequisite. Use browser history and proxy records to supplement redirect destinations.
• identity_idp: Check for new registrations and group assignments of External Authentication Methods, sign-ins where MFA is satisfied by an unfamiliar issuer, and unexpected changes to SearchableDeviceKey (Varonis observed a FIDO key being appended to the test user’s property as an unintended side effect in its lab).
• saas_cloud: Check if applications, service principals, signing keys, and openid/profile consent grants were created in a short timeframe.
• network: Correlate browser redirects to the suspicious provider with EAM configuration changes and sign-in events. Entra metadata or JWKS retrievals may not occur at the same time because provider metadata is cached.

9. Attack Success Determination

Confirmed via Public Information

• Authentication Success Confirmed in a Research Environment: Varonis demonstrated password retrieval and sign-in completion via signed tokens in their test tenant. Exploitation in real-world environments has not been confirmed.

Organization's Judgment Criteria

• Confirmed Information Theft or Session Compromise: Corroborate form submissions to the rogue provider, MFA success by the same issuer, and the immediately subsequent session establishment for the same user and timestamp.
• Confirmed Subsequent Compromise: Verify mailbox, SaaS, or administrative operations using the established session or stolen password with additional evidence.

10. Investigation Playbook

Trigger

• Start with unexpected registrations or assignments of External Authentication Methods, MFA success by an unfamiliar issuer, or redirection to an external domain during sign-in.

Initial Verification

• Identify the administrator who executed the change, target groups, registration time, issuer, Discovery URL, and related applications and service principals.
• Identify users who authenticated during the same period and their subsequent session and data access.

Endpoint

• Check the target user's browser history, proxy records, and screen recordings (if any) to substantiate the transition to the rogue provider.

Authentication and Cloud

• Review Authentication Methods Policy, application registrations, service principals, consent grants, signing keys, Conditional Access, and sign-in logs in chronological order.

Subsequent Operations

• Track the target user's mailbox, SaaS, administrative operations, credential changes, and session reuse.

Containment

• First disable the rogue EAM settings and group assignments, then delete related applications, service principals, signing keys, and consent grants.
• Change the impacted user's password and revoke existing sessions and tokens.

Judgment Classification

• Assess high-privileged compromise, EAM registration, user re-entry, password retrieval, session establishment, and subsequent use separately.

11. Defense and Detection Ideas

Single Event

• Detect the addition or modification of External Authentication Methods and target group assignments with high priority.
• Detect the creation of unknown applications or service principals that use external authentication callbacks.

Chronological Correlation

• Correlate the use of privileged roles, EAM registration, applications, service principals, consent grants, and MFA success by an unfamiliar issuer as a short sequence of events.

Hunting Perspective

• Search for unplanned externalAuthenticationMethodConfiguration, Discovery URLs with external domains, tenant-wide consent for openid/profile, and hwk claims from unfamiliar issuers.

Log Deficiencies

• Entra audit logs alone cannot verify what the user entered into the fake screen. Combine sign-in logs, proxies, and browser-side evidence.

Priority Countermeasures

• Reduce permanent permissions for Global Administrator and Authentication Policy Administrator, and set up immediate alerts for changes to the authentication infrastructure.
• Establish procedures to remove the rogue provider before resetting credentials and sessions.

12. Facts / Inference / Hypothesis

Facts

• Configuring an EAM and granting consent requires sufficient administrative privileges in the tenant, such as Global Administrator or appropriately scoped roles.
• The rogue provider can obtain the password entered by the user and then return a signed token indicating successful MFA to Entra.
• Varonis demonstrated password theft and sign-in completion in their test tenant.
• Exploitation in real-world environments has not been publicly reported.

Inference

• As long as the rogue provider remains, changing the password alone cannot prevent the new password from being captured again, so it must be handled as an authentication infrastructure compromise.

Hypothesis

• Attackers who have already compromised a tenant may repurpose this as a post-compromise technique to continuously harvest credentials.

13. MITRE ATT&CK Mapping

• T1556.006 Modify Authentication Process: Multi-Factor Authentication (Confidence: high) — Registers a rogue external authentication method and returns a token indicating successful MFA.
• T1056.002 Input Capture: GUI Input Capture (Confidence: high) — Obtains plaintext passwords entered into a fake password screen.

14. Unknowns and Additional Investigation

• Real-world exploitation cases and victim organizations have not been confirmed.
• Additional controls or detection specifications planned by Microsoft are unknown.

15. Impact on SOCs and Organizations

Do not rely on Entra sign-in success alone as proof of security. You must monitor changes to the Authentication Methods Policy and related objects as critical authentication infrastructure events. If compromise is suspected, remove the rogue provider and related objects before changing passwords and revoking sessions.

16. Summary by Role

• For SOCs: Monitor EAM registrations, related applications, service principals, consent grants, and MFA success by unfamiliar issuers within the same timeline.
• For Administrators: Minimize privileges that can modify authentication methods, remove rogue providers, and then reset credentials and sessions.
• For Users: If you are prompted to enter your password again for MFA immediately after entering it on the legitimate Microsoft screen, stop and report it to your administrator.