This Rogue MFA Provider Can Steal the Password You Just Reset
A password reset normally ends one part of an identity incident. TrustSink shows how it can instead deliver the replacement password to an attacker during the user’s next legitimate Microsoft Entra sign-in.
Varonis Threat Labs demonstrated a post-compromise technique that registers a rogue External Authentication Method provider in a tenant. Entra sends the user to that provider during MFA. The attacker-controlled page asks for the password again, captures it in plaintext, then returns a correctly signed token so the login finishes without an error.
The attacker must already control a powerful identity
TrustSink is not an initial-access technique and the research does not establish malicious exploitation. The researchers say registering the provider requires a Global Administrator or Authentication Policy Administrator account. The deployment also creates or changes an application registration, service principal, consent grant and Authentication Methods Policy configuration.
That prerequisite is serious, but it is not a reason to dismiss the technique. A threat actor that has compromised one privileged identity can turn the authentication control plane into a standing credential trap for other users. From the victim’s perspective, the sign-in works. They first enter their password on Microsoft’s real domain, encounter what looks like another Microsoft prompt during MFA and arrive at the expected application.
Rotation has to follow removal
Varonis found that resetting a captured password did not remove the rogue provider. It stayed in the authentication flow and collected the replacement at the next sign-in. The correct containment order is therefore important: remove the unapproved external provider and all associated identity artefacts first, then rotate the affected credentials and invalidate sessions.
- Inventory every External Authentication Method provider, assigned group and business owner.
- Alert on new
externalAuthenticationMethodConfigurationentries outside an approved change. - Correlate Authentication Methods Policy changes with application registrations, service-principal creation and consent grants.
- Review redirect and reply URLs, signing keys and issuers for infrastructure the organisation does not control.
- Search sign-in logs for unfamiliar external issuers carrying hardware-key claims such as
hwk. - Reduce standing Global Administrator and Authentication Policy Administrator access.
- Update the identity incident runbook so rogue providers are removed before password resets begin.
A real third-party MFA integration may create similar objects, so detection cannot be a simple ban on external providers. The reliable baseline is ownership: every provider, application, service principal, permission grant, callback and signing key in the authentication path should map to an approved service and named operator.
TrustSink changes the incident question from “whose password was stolen?” to “who controls the screen and token exchange during sign-in?” If the answer is uncertain, credential rotation is only a temporary action. The trust anchor must be restored first.
Sources
- Varonis Threat Labs, TrustSink research, last updated 16 September 2026. The page provides no publication or update time.
- BleepingComputer independent report, published 22 September 2026 at 17:45 as displayed. The page does not label the timezone.
