Multi-factor authentication is designed to add another layer of protection between stolen passwords and sensitive accounts. But that protection depends on the integrity of the authentication infrastructure itself.
According to Cybersecurity News, a newly demonstrated technique called TrustSink shows what can happen when attackers gain control of a highly privileged Microsoft Entra identity and then abuse the trust placed in an external MFA provider.
Researchers at Varonis Threat Labs demonstrated how a rogue External Authentication Method (EAM) can be registered inside Microsoft Entra and inserted directly into an otherwise legitimate authentication flow. Instead of simply sending users to a conventional phishing page, the malicious provider presents a convincing Microsoft password prompt during the MFA stage, captures the replacement password, and then returns a valid signed token so the authentication completes normally.
The result is a credential-theft mechanism that can remain active even after victims change their passwords.
One of the most important details about TrustSink is that it is not an initial-access attack.
The attacker must already control a highly privileged Microsoft Entra account, such as a Global Administrator or Authentication Policy Administrator, before the technique can be deployed.
This changes the security problem considerably.
The attacker is no longer trying to convince a victim to visit a suspicious domain from outside the organization. Instead, the attacker modifies the organization’s own authentication configuration and turns a legitimate identity workflow into the credential-collection mechanism.
The attack can be summarized as:
Privileged Entra compromise → rogue EAM registration → malicious MFA provider → legitimate user login → fake Microsoft password prompt → plaintext credential capture → valid MFA token → successful login
That sequence is what makes TrustSink particularly difficult to recognize through conventional phishing detection.
Microsoft Entra supports external authentication providers that organizations can use to satisfy MFA requirements.
Under a normal configuration, a user first authenticates to Microsoft Entra with their initial factor. When MFA is required, Entra redirects the browser to the configured external provider. The provider performs the additional authentication step and returns a signed token indicating that the MFA requirement was satisfied.
TrustSink abuses that trust relationship.
After compromising the privileged Entra account, the attacker registers a malicious External Authentication Method and configures it as a trusted authentication provider.
The malicious provider can then be assigned to selected users or groups.
From that point forward, the attacker does not need to send those users a conventional phishing email.
The malicious authentication page appears inside the expected authentication sequence.
During Varonis’ proof-of-concept, the victim initially visits the legitimate Microsoft sign-in service and enters their email address and password normally.
When MFA is triggered, Entra redirects the browser to the attacker’s external provider.
Instead of displaying a legitimate second-factor challenge, the malicious provider presents a convincing replica of Microsoft’s password prompt.
The page is designed to look like the user is still completing a normal Microsoft authentication process.
If the victim enters their password again, the credential is transmitted to the attacker-controlled server.
The malicious provider then returns a valid signed token indicating that the MFA step was successfully completed. Microsoft Entra accepts that response and allows the login to continue.
From the user’s perspective, nothing necessarily appears to have gone wrong.
There may be:
The attacker has effectively placed a credential collection point inside a legitimate authentication workflow.
TrustSink becomes even more concerning when considering incident response.
A normal credential-phishing incident often leads organizations to reset the affected password.
But resetting the password alone does not remove the rogue authentication provider.
Varonis demonstrated that after a captured password was reset, the malicious provider remained part of the authentication flow. When the victim logged in again, the replacement password could be captured as well.
This creates a dangerous persistence loop:
Password stolen → password reset → user signs in again → rogue provider captures new password
Therefore, the order of remediation matters.
Security teams need to remove the unauthorized authentication provider and its associated identity infrastructure before treating password rotation as complete containment.
The rogue EAM does not operate in isolation.
The TrustSink research describes a broader configuration sequence involving application registration, service-principal creation, permissions or consent, provider configuration, and user or group assignment.
That gives defenders several opportunities to detect the compromise before widespread credential theft occurs.
Particularly important events include:
The critical detection opportunity is therefore not necessarily the stolen password.
It is the administrative change that makes the password theft possible.
TrustSink demonstrates an important limitation in authentication monitoring.
Many security teams focus heavily on failed authentication attempts, impossible travel, suspicious IP addresses, repeated MFA failures, or unusual login locations.
TrustSink can operate differently.
The victim may successfully authenticate.
The authentication provider may return the expected type of signed response.
The user may reach the intended application.
From a conventional authentication-log perspective, the event can resemble a normal successful sign-in.
The abnormal activity may exist primarily in the identity control plane that was modified beforehand.
This means identity security needs to monitor not only:
Who authenticated?
but also:
Who changed how authentication works?
TrustSink is particularly relevant to aiSIEM / CGuard because the attack crosses multiple identity and application events rather than relying on a single malicious file.
Security teams need to correlate:
Privileged account activity → application registration → service-principal creation → permission grant → external MFA configuration → group assignment → user authentication
A single event may look legitimate.
The sequence is what creates the security signal.
aiSIEM / CGuard can help bring identity, application, network, cloud, and security telemetry together so analysts can investigate unusual authentication configuration changes alongside subsequent authentication activity.
For example, the creation of an unexpected service principal followed immediately by an External Authentication Method configuration and new authentication activity should receive considerably more attention than any one of those events viewed independently.
Although TrustSink operates primarily at the identity and cloud-control-plane level, the initial privileged-account compromise still needs to be investigated.
aiXDR-PMax can provide endpoint-side visibility into suspicious processes, credential-access activity, browser behavior, malware execution, and other activity that may have preceded the Entra takeover.
This creates another important correlation path:
Compromised administrator endpoint → credential theft → privileged Entra access → authentication configuration changes
If the privileged identity was compromised from an endpoint, endpoint telemetry can help provide the missing context behind the cloud-side changes.
aiSecurityScore360 can also contribute at the exposure and posture layer by helping organizations identify weaknesses that could increase the probability of privileged identity compromise.
TrustSink itself is not a vulnerability that can simply be patched.
The prerequisite is control of a privileged identity.
That makes privileged-account exposure, excessive administrative permissions, externally exposed services, and weaknesses around identity security important parts of the broader risk picture.
aiBAS360 can be relevant when organizations want to validate whether their security controls can detect attack paths involving privileged identity compromise and subsequent abuse of authentication infrastructure.
The goal is to test more than whether MFA is enabled.
Organizations need to validate whether their detection and response architecture can identify the sequence that occurs after a privileged identity has already been compromised.
TrustSink changes the way defenders should think about credential theft.
Traditional phishing detection often focuses on identifying the malicious page.
Here, the malicious page is delivered through an authentication mechanism that the organization itself has trusted.
That means defenders should prioritize monitoring for changes such as:
Unexpected External Authentication Method configuration
Unexpected application and service-principal creation
Unusual permission or consent grants
Unexpected provider assignments to users or groups
Authentication events involving unfamiliar external issuers
Privileged identity changes followed by credential-related authentication activity
The earlier the unauthorized control-plane change is identified, the less opportunity the attacker has to collect replacement credentials.
The TrustSink demonstration also reinforces the value of phishing-resistant authentication mechanisms.
Traditional password-based authentication creates a credential that can be entered into a convincing malicious prompt.
Authentication mechanisms such as FIDO2 security keys and Windows Hello for Business can reduce exposure to password-collection techniques because the authentication process is not based on simply submitting a reusable password to a webpage.
However, organizations should not treat stronger authentication as a substitute for monitoring privileged configuration changes.
An attacker who controls a highly privileged identity can still manipulate identity infrastructure, so administrative governance and control-plane monitoring remain essential.
Organizations using Microsoft Entra and external authentication providers should review:
Any provider or application that cannot be tied to an approved business requirement deserves investigation.
If an unauthorized provider is discovered, remediation should not begin and end with password resets.
The rogue provider and its supporting application, service principal, permissions, signing material, assignments, and related configuration need to be removed first, followed by credential rotation and investigation of potentially affected accounts.
TrustSink demonstrates a broader evolution in identity attacks.
Attackers are increasingly targeting the systems that decide who can be trusted, rather than simply attacking the authentication page itself.
In this case, the attacker abuses trust in an external MFA provider.
The user does not necessarily receive a suspicious email.
The login does not necessarily fail.
The MFA process does not necessarily produce an obvious warning.
Instead, the attacker changes the authentication infrastructure so that a legitimate login becomes the delivery mechanism for credential theft.
That makes identity configuration itself a critical security boundary.
TrustSink shows why organizations cannot treat MFA as a single checkbox labeled “enabled.”
The security of an MFA deployment depends on the integrity of the providers, applications, permissions, identities, policies, and administrative workflows surrounding it.
The demonstrated attack requires prior compromise of a highly privileged Microsoft Entra account, but once that prerequisite is satisfied, the rogue External Authentication Method can turn legitimate user authentication into a persistent password-harvesting mechanism.
The most important lesson for security teams is therefore not simply to reset passwords faster.
It is to monitor the identity control plane continuously.
A new authentication provider, unexpected service principal, unusual permission grant, or unexplained authentication-policy change can be the earliest indication that the authentication system itself has been compromised.
With identity, endpoint, cloud, and network telemetry correlated through capabilities such as aiSIEM / CGuard and aiXDR-PMax, organizations can investigate the complete sequence rather than treating each authentication event as an isolated transaction.
Because when attackers gain the ability to modify the mechanism that establishes trust, the authentication process itself can become the attack surface.
