What happened
Varonis last updated its TrustSink research on September 16, 2026, and independent reporting on September 22, 2026 brought the privileged configuration sequence and remediation order into the current enterprise decision window. Varonis said registering the rogue method requires a Global Administrator or Authentication Policy Administrator account, making TrustSink a post-compromise technique. The attacker registers an external authentication provider that presents a Microsoft-like password prompt during an otherwise legitimate sign-in and returns a signed token so the login completes normally.
Varonis identified any new externalAuthenticationMethodConfiguration entry outside a planned rollout as the clearest early warning. The proof of concept produced sign-in records with an unfamiliar issuer and hardcoded acr: possessionorinherence and amr: hwk claims. The research deployment generated Add application, Add service principal and Add delegated permission grant events within seconds, stamped with python-requests/2.33.1. Varonis cautions that the user-agent value is a lead rather than a durable signature.
Varonis advises disabling the external method and removing its group assignments, application registration, service principal, signing keys, consent grant and callback URI before resetting affected passwords. No in-the-wild victim, malicious tenant identifier or confirmed actor infrastructure was published. Attribution posture: TrustSink is a laboratory proof of concept; the cited sources establish no in-the-wild actor or victim attribution. The cited source did not publish the relevant infrastructure details described as Confirmed malicious infrastructure or victims.
Why this matters now
TrustSink is not initial access and does not demonstrate an unprivileged Entra takeover. Its enterprise significance begins after a highly privileged identity is compromised, when an attacker can turn authentication configuration into a durable credential-collection mechanism affecting selected users.
The remediation order is the critical control lesson. Resetting passwords while the rogue provider remains registered simply feeds replacement credentials back into the attacker-controlled flow. Identity incident procedures must therefore remove the provider and associated application artefacts before credential rotation.
The technique also illustrates why identity configuration changes require control-plane monitoring. Authentication policy, application registration, service-principal creation, consent grants and Conditional Access targeting should be correlated as one privileged change sequence rather than reviewed by separate operational teams.
The decision for security leaders
Treat authentication-provider configuration as a privileged control plane. Require named ownership, approval, time-bounded administrative access and monitoring for every external provider, application, key, consent grant and user-group assignment.
Update identity containment sequencing. When a rogue provider is suspected, preserve audit and sign-in evidence, disable the provider, remove associated artefacts, identify routed users, examine their activity and only then rotate credentials and restore access.
Do not overstate the threat. The proof of concept requires prior privileged compromise, and no active campaign is established. The appropriate response is a configuration and detection review, not a declaration that Entra tenants using external MFA are already compromised.
Evidence of closure
- Approved inventory accounts for every External Authentication Method provider and assigned group.
- Detection validation confirms alerts for unplanned authentication-policy and provider changes.
- Correlation test joins application, service-principal, consent and Conditional Access events.
- Identity runbook records provider removal before credential rotation and user restoration.
The Security.io assessment
The research is technically older than the immediate publication window, but the new independent reporting materially clarified the executive decision: password resets can fail as containment when a privileged attacker controls the authentication path. That remediation-order issue warrants inclusion despite the absence of active exploitation.
The highest-value detection is the administrative sequence, not the laboratory domain or user-agent string. Authentication Methods Policy changes, application and service-principal creation, consent grants, group targeting and unfamiliar issuer claims should be joined into a single investigation timeline.
No in-the-wild victim, malicious tenant identifier or confirmed actor infrastructure was published. Confidence is therefore medium: the mechanism was demonstrated and the artefacts are actionable, but prevalence, attacker adoption and Microsoft’s longer-term product response remain unresolved.
Questions for the morning meeting
- Are any External Authentication Method providers enabled, and does each have a named business owner?
- Who reviews Authentication Methods Policy, application, service-principal and consent changes as privileged identity events?
- Can the SOC identify every user routed through an unfamiliar external MFA issuer?
- Does the identity incident runbook remove rogue providers before rotating affected credentials?