As reported by BleepingComputer, researchers at Varonis Threat Labs have demonstrated a post-compromise attack technique dubbed TrustSink that abuses Microsoft Entra's external authentication method (EAM) framework to harvest user passwords in plaintext during legitimate sign-in flows. The attack is notable not for its initial-access vector — it requires an attacker to already hold a highly privileged Entra account — but for what it reveals about the implicit trust placed in pluggable authentication architectures and the difficulty of evicting a determined adversary once they've modified identity infrastructure.

Cloud Security Alert: As reported by BleepingComputer, researchers at Varonis Threat Labs have demonstrated a post-compromise attack technique dubbed TrustSink that abuses Microsoft Entra's external authentication method (EAM) framework to harvest user passwords in plaintext during legitimate sign-in flows.

Why This Matters Beyond the Headline

Most security conversations about MFA treat it as the defensive control that stops attackers. TrustSink inverts that assumption: once an attacker has privileged access to an identity provider, they can weaponize the MFA layer itself as a credential-harvesting mechanism and a persistence tool. The critical design issue is that Entra delegates the second-factor experience entirely to an external provider and trusts whatever that provider returns — including a valid signed token — without independently validating what the user actually saw or interacted with. Any attacker who can register a rogue EAM controls the user's authentication experience from that point forward.

The most alarming detail in Varonis' findings is resilience: resetting a captured password does not remove the rogue provider. It persists in the authentication flow and captures the replacement credential at the next sign-in. This transforms TrustSink from a one-time credential theft into a self-renewing harvesting loop that survives standard incident-response playbooks.

Who Is at Risk

  • Microsoft Entra tenants using External Authentication Methods — Any organization that has registered third-party MFA providers through Entra's EAM framework is exposed to this technique if a privileged account is compromised.
  • Organizations with lax privileged role management — The attack requires Global Administrator or equivalent elevated privileges to register an EAM. Tenants with over-provisioned admin roles face the highest risk.
  • Any identity provider with a similar delegation model — While Varonis demonstrated the attack against Entra, the underlying architectural pattern (redirecting to an external provider that returns a signed token) is not unique to Microsoft. Other IdPs implementing comparable external authentication flows may be susceptible to analogous abuse.

The Broader Lesson: Trust Delegation Is an Attack Surface

TrustSink illustrates a pattern we see repeatedly in modern identity infrastructure: extensibility becomes exposure. Every pluggable authentication mechanism — external MFA providers, custom claims providers, federation trusts — introduces a new path an attacker can manipulate if they gain sufficient control. The signed token returned by an external provider is treated as proof of authentication completion, but the token says nothing about what the user actually experienced. There is no cryptographic binding between the second-factor challenge presented to the user and the token returned to the IdP. Until identity providers implement tighter verification of external provider behavior — for example, attestation of the authentication UI, or cryptographically binding the user's session to the specific challenge presented — this class of attack will remain viable.

Shield53 Recommendations

Immediate detection actions:

  • Audit all registered External Authentication Methods in your Entra tenant. Any EAM you did not deliberately configure should be treated as a potential indicator of compromise.
  • Review Entra audit logs for Create externalAuthenticationMethodConfiguration or equivalent EAM registration events. Alert on any new registrations outside of planned change windows.
  • Review all Global Administrator and Privileged Authentication Administrator role assignments. Remove standing access where possible and enforce PIM (Privileged Identity Management) just-in-time activation for remaining roles.

Hardening and mitigation:

  • Restrict EAM registration to break-glass accounts and enforce change approval workflows. Monitor for any modification to authentication method policies.
  • If your organization uses external MFA providers, validate the provider's authentication endpoint URLs and certificate fingerprints against known-good values on a recurring basis.
  • Implement conditional access policies that flag or block sign-ins from unfamiliar authentication method combinations.
  • In the event of a confirmed privileged account compromise, do not assume password resets are sufficient. Audit and remove all EAM configurations, review all conditional access policies for tampering, and examine sign-in logs for anomalous MFA provider redirect patterns.
  • Consider whether external MFA providers are necessary for your environment. Native Entra MFA (Microsoft Authenticator, FIDO2 keys) does not expose this same external delegation attack path and should be preferred where feasible.