Security researchers have uncovered a new post-compromise technique that turns a trusted identity infrastructure component into a long-running credential trap, and traditional incident response, like a password reset, does nothing to stop it.
Varonis Threat Labs, led by researcher Elad Ghvarh, has detailed a technique dubbed TrustSink that abuses Microsoft Entra ID’s External Authentication Methods (EAM) feature.
EAM lets organizations plug third-party multi-factor authentication providers directly into their sign-in flow. TrustSink shows what happens when an attacker with high-level administrative access registers a malicious provider instead of a legitimate one.
TrustSink Attack: Rogue MFA Provider Steals Passwords Even After Reset
Once registered, the rogue provider is inserted seamlessly into the MFA step of a normal login. The victim sees what looks like an ordinary second Microsoft password prompt, sitting inside a flow they’ve completed hundreds of times before.
Whatever they type is quietly logged complete with timestamp and IP address while the fake provider simultaneously issues a validly signed authentication token back to Entra, so the sign-in completes without a single error message.

The technique works because the rogue service has to satisfy two very different observers simultaneously. To the end user, it must be a convincing replica of Microsoft’s own interface.
To Entra, it must behave like a fully compliant authentication provider: publishing a valid discovery document, serving a signed public key, and responding to redirects with properly formatted tokens.
Crucially, Microsoft’s system validates the cryptographic signature of the returned token but never verifies what content the third-party provider actually displayed to the user. That gap underpins the attack: control the screen, and token verification takes care of the rest.
Perhaps the most alarming finding is persistence. Because the malicious provider is a standing piece of tenant configuration, not a one-time phishing link, resetting a compromised password doesn’t remove it.
The rogue provider stays wired into the authentication flow and simply captures the user’s next password the moment they log in again.
Researchers found the attack could even be fully automated via Microsoft Graph API calls, deploying the entire malicious infrastructure app registration, service principal, consent grant, and policy change in a single scripted command.

“TrustSink is a sobering reminder that identity trust boundaries are only as strong as the least-verified component in the chain.”
“Enterprises have spent years hardening endpoints and hunting phishing emails, but few are auditing changes to their own authentication policy configurations. This attack doesn’t need malware it needs one privileged account and a blind spot in vendor trust.”
Elad Ghvarh note the attack leaves forensic traces at nearly every stage: unexpected entries in the Authentication Methods Policy, unfamiliar app registrations using Microsoft’s external-auth callback URL, newly created service principals pointing to attacker-controlled domains, and sign-in logs showing hardware-key claims that were never actually verified through a real device ceremony.
Automated deployments also leave a giveaway rapid-fire API calls seconds apart, often tagged with a generic scripting user agent.
Mitigation, researchers stress, means removing the rogue provider entirely, not just rotating credentials, while also restricting standing Global Administrator and Authentication Policy Administrator privileges that make the attack possible in the first place, and pushing users toward FIDO2 or Windows Hello for Business, where an unexpected password prompt would immediately look out of place.
Site: Thecyberdef.com
Follow TheCyberDef on Google News, LinkedIn & X for the latest cybersecurity updates. Stay informed.