Clarissa Hana
Security researchers have unveiled a sophisticated attack dubbed "TrustSink" that exploits a critical vulnerability in how Microsoft Entra ID (formerly Azure Active Directory) integrates with external multifactor authentication (MFA) providers. The technique, developed by Varonis Threat Labs, allows attackers who have already gained privileged access within an organization’s network to register a malicious external MFA provider. This rogue provider then intercepts user credentials during legitimate login attempts, effectively bypassing security measures and stealing passwords in plaintext. The attack highlights a significant risk for organizations relying on the flexibility of third-party authentication solutions.
The TrustSink attack specifically targets the mechanism where organizations can delegate MFA verification to external services. Microsoft Entra ID, a widely adopted identity and access management solution, supports the configuration of external authentication method providers. This feature allows businesses to leverage specialized third-party services to fulfill MFA requirements, offering flexibility and potentially integrating with existing security infrastructure. When a user initiates a login and successfully completes the first authentication factor, such as entering their password, Entra ID can redirect the user’s browser to the configured external MFA provider to complete the second factor. If this external provider returns a valid, signed token indicating successful authentication, Entra ID considers the MFA requirement met, and the login proceeds.
Varonis Threat Labs discovered that an attacker who has already achieved a high level of privilege, specifically by compromising a highly privileged Entra ID account, can exploit this trust. By leveraging such an account, an attacker can register a malicious External Authentication Method (EAM) within the Entra ID tenant. This rogue EAM is then presented to Entra ID as a legitimate external MFA provider. The critical flaw lies in the attacker’s ability to craft a convincing imitation of Microsoft’s password prompt, inserting it directly into the legitimate authentication flow. When a user is prompted for their second factor, instead of encountering a genuine MFA challenge from a trusted provider, they are presented with what appears to be a standard Microsoft password re-entry screen.
"In our test tenant, every sign-in completed normally while our server received passwords with timestamps and source IP addresses," Varonis detailed in their technical analysis of the TrustSink attack. This seamless execution means that from the end-user’s perspective, the login process appears to be entirely normal, with no indication that their credentials have been compromised. The malicious provider, after capturing the user’s password in plaintext, then generates a valid signed token that it sends back to Entra ID. This token deceives Entra ID into believing that the MFA requirement has been successfully satisfied, allowing the login to proceed to the intended application without raising any alerts.
A particularly concerning aspect of the TrustSink attack is its persistence. Varonis researchers observed that even after a user resets a captured password, the rogue provider remains registered within the Entra ID tenant’s authentication policies. Consequently, on the user’s next login attempt, the malicious provider will once again intercept the newly set password. This persistent threat necessitates a proactive approach to remediation, as simply changing a compromised password is not sufficient to neutralize the attack.
It is crucial to reiterate that TrustSink is not an initial-access attack vector. The prerequisite for its successful deployment is that the attacker must already possess control over a highly privileged Entra ID account. This often implies that the organization has already experienced a significant security breach, and the attackers have moved laterally to gain administrative access.
Abusing the Trust in External MFA Providers
The fundamental mechanism exploited by TrustSink is the inherent trust that Microsoft Entra ID places in configured external MFA providers. When an organization designates an external service to handle MFA, Entra ID implicitly trusts that this service will perform its authentication duties correctly and securely. TrustSink weaponizes this trust by creating a deceptive external provider that masquerades as legitimate to Entra ID, while actively deceiving the end-user.
Varonis meticulously crafted a proof-of-concept attack where the malicious provider appeared indistinguishable from a genuine external MFA service to Entra ID. However, for the end-user, it presented a deceptively familiar Microsoft password page. The attack sequence unfolds as follows: a user begins their login process on a legitimate Microsoft domain, such as login.microsoftonline.com, entering their email address and primary password. Once this initial step is verified, Entra ID initiates the MFA challenge. At this juncture, instead of redirecting the user to a legitimate MFA prompt (e.g., an authenticator app notification, a one-time code, or a hardware token verification), Entra ID redirects the browser to the attacker-controlled external MFA provider.
This rogue provider then displays a pixel-perfect replica of Microsoft’s password entry page. The visual fidelity is so high – employing the same fonts, layout, and button designs – that a user, already expecting another authentication step, is likely to believe it is a legitimate request from Microsoft. If the user enters their password into this fake prompt, those credentials are immediately transmitted in plaintext to the attacker’s server. Following the credential theft, the attacker’s malicious provider generates a signed token, falsely attesting that the MFA challenge has been successfully completed. This token is then sent back to Entra ID, allowing the user to proceed to their intended application, unaware that their password has been compromised.
This deceptive tactic is particularly effective because it plays on user expectations. After successfully entering their primary password, users anticipate a subsequent verification step. The malicious prompt, appearing immediately after their initial password entry and mirroring Microsoft’s familiar interface, serves to reinforce this expectation, making it easier to trick them into re-entering their credentials.
Building on Previous Research
The TrustSink attack is not entirely novel in its underlying principle. Varonis acknowledges that its research builds upon prior work presented by security researcher Dirk-Jan Mollema at the x33fcon 2025 conference. In his presentation, titled "Bringing Your Own Identity in Entra ID," Mollema demonstrated how a compromised privileged account could register a rogue external MFA provider that could bypass MFA requirements by returning a signed JSON Web Token (JWT) that falsely claimed authentication had succeeded. While Mollema’s research highlighted the vulnerability in the MFA bypass mechanism, TrustSink expands upon this by weaponizing it for direct credential theft through the insertion of a convincing password prompt.
The process of registering a malicious external method within Entra ID requires significant administrative privileges. Varonis outlines that it involves modifying the tenant’s Authentication Methods Policy, creating a new application, registering a service principal, and obtaining a consent grant. These actions are typically restricted to users with Global Administrator or Authentication Policy Administrator roles. This reinforces the understanding that TrustSink is a post-compromise attack, requiring attackers to first gain deep access to the organization’s identity infrastructure.
Once successfully deployed, the rogue external MFA provider can persist within the authentication flow for targeted users across multiple login sessions. The persistent nature stems from its registration within the tenant’s Authentication Methods Policy. This means that even if an affected user changes their password, the malicious provider will still be in place to capture the new password during their subsequent login attempt.
Implications and Recommendations
The discovery of the TrustSink attack has significant implications for organizations that utilize external MFA providers within their Microsoft Entra ID environments. The attack underscores the critical importance of securing privileged accounts, as their compromise can unlock sophisticated post-exploitation techniques. The ability of an attacker to remain undetected while actively stealing credentials during legitimate login processes poses a severe threat to data confidentiality and integrity.
Varonis strongly advises administrators to take immediate action to mitigate this risk. Their primary recommendation is to meticulously review and remove any suspicious or unauthorized external MFA providers and their associated applications, keys, and redirect URIs from their Entra ID tenant. This cleanup should be performed before resetting the passwords of potentially affected users. Failure to remove the rogue provider first will result in the new password being captured immediately upon the user’s next login.
Beyond immediate remediation, Varonis offers broader strategic recommendations for enhancing security posture. Organizations should implement robust monitoring of changes to their Authentication Methods Policy, as any unauthorized modifications could signal a potential compromise. Furthermore, limiting standing privileges for Global Administrators and Authentication Policy Administrators is crucial to minimize the attack surface. This involves employing just-in-time (JIT) access and the principle of least privilege.
The researchers also advocate for the adoption of phishing-resistant authentication methods. Technologies such as FIDO2 security keys and Windows Hello for Business offer a significantly higher level of security against credential theft compared to password-based or even typical token-based MFA. These methods are inherently more resistant to phishing attacks and man-in-the-middle attempts, providing a more resilient defense against evolving threats like TrustSink.
The continued evolution of identity-based attacks, exemplified by TrustSink, highlights the ongoing cat-and-mouse game between attackers and defenders in the digital realm. As cloud-based identity solutions become more prevalent and flexible, understanding and securing their configuration, particularly concerning integrations with third-party services, remains paramount for safeguarding sensitive organizational data. Organizations must remain vigilant, regularly audit their security configurations, and stay informed about emerging threats to effectively protect their digital assets.
