A security technique called TrustSink demonstrates how an attacker could transform a trusted multifactor authentication integration into a persistent credential collection system. The attack targets Microsoft Entra's External Authentication Methods feature, which allows organizations to use approved third-party services to complete MFA challenges.
Trust Becomes the Attack Surface
TrustSink is not an initial-access vulnerability. An intruder must first compromise an account with powerful administrative permissions, such as Global Administrator or Authentication Policy Administrator. The attacker can then register a rogue external MFA provider and assign it to selected users.
During a normal sign-in, Entra redirects the user to the external provider for the second authentication step. Instead of requesting a legitimate factor, the malicious provider displays a convincing copy of Microsoft's password page. If the user enters the password again, the credential is delivered to the attacker's server. The provider then returns a signed token claiming that MFA succeeded, allowing the login to continue without an obvious error.
The persistence is particularly concerning. Resetting a stolen password does not remove the malicious provider. The replacement password can simply be captured during the user's next authentication attempt.
What Administrators Should Review
- Audit all external authentication methods and confirm that every provider is authorized.
- Monitor changes to authentication policies, enterprise applications, service principals and consent grants.
- Reduce standing access for Global Administrator and Authentication Policy Administrator accounts.
- Require just-in-time elevation and phishing-resistant authentication for privileged identities.
- Remove suspicious providers, applications, keys and redirect addresses before resetting passwords.
Organizations should also preserve audit records if unauthorized authentication changes are discovered. Investigators need to determine which users were assigned to the provider and whether credentials were collected during successful sign-ins.
An Identity Supply Chain Problem
In my view, TrustSink exposes a broader weakness in identity architecture. Authentication platforms increasingly depend on external providers, applications and signed assertions. Each integration becomes part of an identity supply chain whose configuration deserves the same scrutiny as privileged code.
Phishing-resistant factors remain important, but they cannot compensate for an attacker who controls the tenant's authentication policy. The defensive priority must therefore include continuous monitoring of the systems that decide which authentication methods are trusted in the first place.