Cybersecurity firm **Varonis Threat Labs** has detailed a sophisticated new attack dubbed **TrustSink**, which exploits the trust placed in external MFA providers to steal user credentials. While applicable to any provider using this external authentication model, the researchers successfully demonstrated the attack using **Microsoft Entra** (formerly Azure AD). **Microsoft Entra** supports integrating third-party authentication services to fulfill MFA requirements. When a user authenticates with a primary factor like a password, **Entra** can redirect them to an external MFA provider for the second factor. If this provider returns a valid, signed token confirming successful second-factor completion, **Entra** considers the MFA satisfied. ## How TrustSink Operates **Varonis** discovered that an attacker, having already compromised a highly privileged **Entra** account, can register a rogue External Authentication Method (EAM) as one of these legitimate external MFA providers. This malicious provider then inserts a convincing, yet fake, **Microsoft** password prompt into the user's authentic login flow.  The fake prompt captures the user's password in plaintext. Crucially, the malicious provider then generates and returns a valid signed token to **Entra**, indicating that MFA was completed successfully. This allows the login to proceed without any errors or suspicious activity from the user's perspective. "In our test tenant, every sign-in completed normally while our server received passwords with timestamps and source IP addresses," **Varonis** explained. "Resetting a captured password did not remove the rogue provider. It remained in the authentication flow and captured the replacement password at the user's next sign-in." ## Post-Compromise Credential Theft It's important to note that **TrustSink** is not an initial-access vector. It requires the attacker to already control a highly privileged **Entra** account, such as a Global Administrator or Authentication Policy Administrator. This makes **TrustSink** a post-compromise technique, allowing an attacker to maintain persistent access and harvest credentials even after initial breach.  *Source: Varonis* During the proof-of-concept, the initial login proceeds normally, with the user entering their email and password on **Microsoft**'s legitimate `login.microsoftonline.com` domain. When MFA is triggered, **Entra** redirects the browser to the attacker's external MFA provider. Instead of a genuine second-factor challenge, the malicious provider displays a nearly identical copy of **Microsoft**'s password prompt. If the victim re-enters their password, believing it's a legitimate part of the authentication process, the credential is sent directly to the attacker-controlled server. The rogue provider then returns a signed token to **Entra**, and the user gains access to their intended application, completely unaware of the compromise. **Varonis** highlights the attack's effectiveness, noting that the fake prompt appears when users anticipate another authentication step, using identical fonts, layout, and button designs as **Microsoft**'s legitimate pages. ## Building on Prior Research **TrustSink** leverages and builds upon previous research presented by security researcher **Dirk-Jan Mollema** at x33fcon 2025 in his talk, "Bringing Your Own Identity in Entra ID." **Mollema** demonstrated how a rogue external MFA provider could satisfy an MFA requirement by returning a signed **JWT** (JSON Web Token) claiming successful authentication without actually performing the expected checks. **TrustSink** weaponizes this concept for credential theft. Registering the malicious external method requires modifying the Authentication Methods Policy and creating an application, service principal, and consent grant. These actions necessitate high-level administrative privileges. Once installed, however, the rogue provider can persist within the authentication path for targeted users across multiple logins. Even if a user changes their password, the malicious provider remains active and will recapture the new password during the next login attempt. Therefore, **Varonis** strongly advises administrators to remove the malicious provider *before* rotating affected credentials. ## Mitigation Strategies To protect against **TrustSink** and similar attacks, organizations should: * **Remove Suspicious Providers**: Immediately remove any suspicious external MFA providers, along with their associated applications, keys, and redirect URIs, *before* resetting affected user passwords. * **Monitor Policy Changes**: Implement robust monitoring for changes to the Authentication Methods Policy within **Microsoft Entra**. * **Limit Privileges**: Strictly limit standing Global Administrator and Authentication Policy Administrator privileges, adhering to the principle of least privilege. * **Phishing-Resistant MFA**: Prioritize and implement phishing-resistant authentication methods such as **FIDO2** security keys or **Windows Hello for Business**.