Reflecting Your Authentication: When Windows Ends Up Talking to Itself
Authentication reflection has been around for more than 20 years, but its implications in modern Windows networks are far from obsolete. Even after all the patches Microsoft has rolled out over the years, reflection attacks are still very much exploitable 😉
This post walks through what authentication reflection actually is, why it remains dangerous today, and how the most recent discoveries prove that reflection keeps coming back in places where it really shouldn’t. We will explore how recent Windows behaviors introduced entirely new attack surfaces involving Kerberos, NTLM, SMB, HTTP and DCE/RPC. We’ll also look at Ghost SPNs, the CredMarshalTargetInfo (CMTI) trick, and multiple cases where a single reflected authentication was enough to compromise an entire domain.
The goal is also to keep the explanations clear enough for readers who aren’t experts on these topics, without losing the important technical details
What Authentication Reflection Actually Is
Authentication reflection is deceptively simple:
A victim (machine or user) is coerced into authenticating to an attacker-controlled endpoint.
The attacker reflects that authentication attempt back to a service the victim host runs itself.
The victim ends up authenticating to its own service using its own identity.
If the victim is a domain-joined Windows machine, the identity used is the computer account , effectively granting NT AUTHORITY\SYSTEM on that host.
Depending on the coercion vector, this results in:
➔ Local Privilege Escalation (LPE)
➔ Remote Privilege Escalation (RPE)
➔ Full domain compromise when the reflected authentication hits LDAP/LDAPS on a DC under certain conditions
Reflection attacks don’t steal credentials. They make Windows authenticate to itself, on your behalf.
A Very Old Problem: MS08-68
Authentication reflection was first widely exploited in 2008 via MS08-68, where NTLM authentication could be reflected back to SMB on the same host, yielding SYSTEM privileges.
Microsoft eventually patched classic NTLM loopback reflection, including:
But the story didn’t end, there was still NTLM local authentication…
Kerberos Reflection: HardeR, Not Impossible
Kerberos does not have a universal reflection-detection mechanism, but requiring control of the target SPN and valid Kerberos tickets makes such attacks substantially harder to exploit in practice.
Ok, I said, harder but for sure not impossible 😉
The CredMarshaltargetinfo (cmti) Trick: abusing spn metadata
To perform a reflection attack, we must convince Windows to direct the authentication back to itself. In practice, this means spoofing the hostname so that the authentication is sent to an endpoint under our control, while the client still believes that the target hostname is local.
To achieve this, we need to control the Service Principal Name (SPN) that Kerberos and NTLMv2, as well, use to identify the target service.
In other words, for our forged SPN the ideal situation is that the client uses an SPN/TARGET where TARGET resolves to an IP address we control, but is still considered local by the client.
In the DCOM scenario, by abusing the various ‘*potato’ techniques, we can create a fake OXID Resolver. This allows us to instruct the client to use an SPN associated with the victim (SPN/VICTIM) while still contacting the endpoint under our control. That gives us the victim’s authentication, which we can then reflect back to the victim’s own service, because he is the victim 😉
However, if we want to use other protocols, such as SMB, which don’t give us control over the SPN, we need an alternative.
Windows SSPI supports a “special” SPN format that includes an embedded Marshal Target Information block:
➔ ServiceClass/Server[TargetInfo]
where:
TargetInfo is a serialized, base64-like structure called Credential Target Information
The shortest valid blob is:
➔ 1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA
This tiny blob is enough for Windows to consider the SPN well-formed, but it also allows us to spoof the hostname inside the SPN in a way that survives SPN canonicalization, Kerberos processing, and NTLM’s AV-pair parsing.
Even better: a standard domain user can by default create DNS records, which means they can freely introduce new names that point to attacker-controlled IP addresses.
When the SPN includes a CMTI blob, here’s what happens:
➔ Kerberos will request a TGS for ServiceClass/Server
➔ NTLM will embed the value into MsvAvTargetName
➔ The client (SMB, RPC, DCOM, …) will actually contact the host named:
If that “hostname” resolves to an attacker-controlled IP, but the internal TargetInfo makes Windows treat it as local, then we get the exact situation reflection attacks rely on:
The authentication is sent to the attacker, but processed as if it were going to a local service.
This is what allows SMB→SMB reflection even without direct SPN control, and it’s why CMTI-based spoofing became such a powerful tool in modern reflection attacks.
Remote Kerberos Reflection — DCOM → HTTP
Abusing DCOM isn’t new, but Windows exposes interfaces that are particularly useful for coercion.
On Windows Servers with the Certificate Services role installed, the system exposes the AD CS CertSrv Request interface, which can be instantiated remotely by any domain user and will trigger an outbound machine authentication from the AD CS server.
It is not possible to reflect DCOM → SMB, because SMB enforces anti-reflection protections for both Kerberos and NTLM. In this path, the ISC_REQ_UNVERIFIED_TARGET_NAME flag, set by the DCOM client, is actually honored by the SMB client, which prevents authentication from being reused against the same host by stripping the SPN in the case of loopback authentication.
SMB → SMB Kerberos/NTLM Reflection
Prior to June 2025, SMB callback coercion using PrintSpooler, EFSRPC, or DFS could force SMB clients to authenticate to arbitrary endpoints.
By abusing CMTI, a remote attacker could abuse Kerberos and NTLM reflective authentication and ultimately gain SYSTEM privileges.
In the case of NTLM, this will trigger NTLM local authentication; more on this later…
Microsoft patched SMB client behavior in CVE-2025-33073, rejecting invalid and empty CMTI TargetInfo data when establishing SMB sessions.
Ghost SPNs and the “Ghost Reflection” Attack
After CVE-2025-33073, I wondered whether authentication reflection could still be abused after the patch. Enter the GHOST SPN: SPN that references hostnames that are not (or no more) registered in DNS. If present, then Kerberos SMB➔SMB reflection could still be abused!
By creating a Ghost SPN in DNS and pointing it to an IP address controlled by the attacker, the attacker can trick the target machine into performing a reflective authentication with Kerberos, resulting in a valid service ticket for the non-existent Ghost computer.
My detailed description of the attack can be found here
MS fixed this in October 2025 in the SMB server driver (SRV2.SYS) by validating Loopback addresses (CVE‑2025‑58726)
NTLM Local Authentication and Reflective Abuse
NTLM Local Authentication is a special type of authentication occurring in the same machine context and is negotiated by the Client and the Server.
In NTLM Local Authentication, the “Reserved Field” in the NTLM 2 message is not empty, but will reference the LSASS “Context” handle that the client should associate with
The NTLM 3 Authenticate message will be completely empty:
The first abuse of this particular local reflection was our “Local Potato” a local DCOM➔ SMB abuse.
By swapping the authentication contexts between a privileged RPC/DCOM client and the attacker-controlled SMB client, the unprivileged user could impersonate SYSTEM. This effectively resulted in a local privilege escalation and was patched by Microsoft under CVE-2023-2174
However, remote variants remained viable through 2025.
Remote NTLM Reflection Against Domain Controllers
Before June 2025 , there was a low-hanging fruit that was never officially reported and was unintentionally fixed with CVE-2025-33073.
As mentioned, in NTLM local authentication, the NTLM3 message is completely empty, which means that the NTLMv2 validations MIC, MsAVFlags, NtProofStr were probably skipped…
So what does this mean? It allowed us to drop the SIGN flag without interfering with the Message Integrity Check (MIC), which opened the door to reflecting authentication across protocols, even in cases like SMB → LDAP(S), where signing should have stopped it.
But it didn’t stop there. With LDAPS or HTTPS, the channel-binding requirement would be completely bypassed !!!
By making some small changes to ntlmrelayx , mostly removing SIGN/SEAL while keeping NTLM3 intact, I could coerce a domain controller to authenticate and then reflect that authentication back to LDAPS, resulting in a complete domain takeover from a standard domain user!
So this meant that before June 2025 ANY domain user could take over an AD Domain 😱
In fact , by inhibiting the CMTI trick in SMB, this sort of highly disruptive abuse was no longer possible.
Remote NTLM Authentication Reflection abuse in server 2025
In Windows Server 2025, Microsoft tightened printing security 😁. As part of this, the PrintNotify() callback was moved away from Named Pipes (SMB) and now uses DCE/RPC. The unintended side effect is that DCE/RPC still supports the CMTI trick.
And here’s another interesting aspect: with DCE/RPC, we no longer need to spoof the SPN or manipulate DNS records. Using the attacker’s IP address is enough, NTLM will happily negotiate local authentication 😇
This could allow ANY domain user to take over a Windows Server 2025 DC with PrintSpooler enabled
➔ Enforce signing and channel binding everywhere They stop entire classes of reflection and relay attacks, and there’s really no reason not to enable them in 2025.
➔ Patch all known coercion vectors PrintSpooler, EFSRPC, DFS, AD CS interfaces, legacy DCOM paths – anything that can trigger machine authentication should be reviewed and patched.
➔ Harden systems by disabling unnecessary services, and use RPC filters to block specific authentication-triggering attack surfaces. Reducing the exposed attack surface is still the most effective long-term mitigation.
FINAL NOTES
There are a couple of other reflection attacks I’ve already submitted to MSRC, but those fixes won’t arrive until January/February 2026. 😉
Also worth mentioning: the CMTI trick still works when triggered from RPC/DCOM clients, and the NTLM local-authentication behavior in Windows Server 2025 remains another interesting reflection opportunity.
Decoder's Blog 