A newly published Synacktiv proof-of-concept shows how attackers could bypass Microsoft’s CVE-2025-33073 mitigation and obtain NT AUTHORITY\SYSTEM shells on patched Windows Server 2025 systems by abusing SMB authentication reflection over arbitrary TCP ports before Microsoft patched the follow-on flaw in March 2026. The important part is not that another PoC exists; Windows gets those every week. The important part is that this one exposes a familiar pattern in platform security: a narrow fix can close the reported exploit path while leaving the underlying class of behavior intact. For defenders, that distinction is the difference between “we installed the update” and “we understood the risk.”
CVE-2025-33073 was never just an SMB bug in the way administrators usually think about SMB bugs. It was an authentication reflection problem: Windows could be coerced into authenticating to an attacker-controlled endpoint, and that authentication could then be relayed back in a way that let the attacker act with far higher privileges than they started with.
The original technique revolved around CredMarshalTargetInfo, or CMTI, a Windows mechanism that allows extra target information to be embedded into authentication target names. Synacktiv’s earlier research showed that carefully crafted target names could survive long enough to influence how authentication was generated, while being normalized away by LSASS before the final NTLM or Kerberos blob was built. That mismatch created the opening.
Microsoft’s June 2025 fix targeted the SMB client driver,
That is the uncomfortable lesson here. A patch can be correct within its immediate threat model and still incomplete against the vulnerability class. Synacktiv’s new work argues exactly that: Microsoft closed the named exploit route, but the architecture still had places where authentication identity, transport reuse, and protocol-specific behavior could be made to disagree.
Those constraints are what make the research interesting. The team was not satisfied with an artificial lab condition requiring exotic configuration, user clicks, or services that are rarely enabled. Their target was a default Windows 11 or Windows Server 2025 setup, with no user interaction, and an outcome that mattered: remote code execution or local privilege escalation.
That methodology quickly narrowed the field. RPC and DCOM were less attractive because Microsoft’s post-2022 hardening around packet integrity has made many old relay tricks harder to use. HTTP over WebDAV had its own problem: the WebClient service is not running by default on servers, and many Windows HTTP clients lowercase hostnames in ways that break the case-sensitive base64 encoding used by the CMTI technique.
SMB, however, still had a surprise. Windows 11 24H2 and Windows Server 2025 introduced support for connecting to SMB shares on arbitrary TCP ports. A feature that looks like ordinary flexibility for administrators became, in this context, a way to build a more interesting authentication trap.
The problem appears when that feature meets SMB session multiplexing and connection reuse. The SMB2 protocol allows multiple authenticated sessions over a single TCP connection. The Windows SMB client can reuse an existing TCP connection rather than opening a clean one for each new authentication context.
Synacktiv’s exploit chain took advantage of that behavior. An attacker first started a rogue SMB server on a custom port and connected to it with low-privileged credentials, creating a persistent TCP connection. Then the attacker coerced a privileged local service, such as LSASS, into authenticating to the same share path.
Because the SMB client reused the already established connection, the privileged NTLM authentication blob traveled over a channel controlled by the attacker. The attacker could then relay that local authentication back to the real SMB service on the machine. The result was an authenticated SMB session as NT AUTHORITY\SYSTEM.
That is the kind of vulnerability chain Windows defenders hate because no single step looks outrageous in isolation. A user mounts a share. A service authenticates. SMB reuses a connection. NTLM relay tooling does what NTLM relay tooling has done for years. The vulnerability lives in the composition.
That combination is not new in spirit. PetitPotam and NTLM relay attacks have been part of the Windows security conversation for years, especially in Active Directory environments where service accounts, machine accounts, and legacy authentication paths create an enormous relay surface. What is new is the route around a mitigation that many administrators reasonably assumed had killed this particular reflection pattern.
The larger story is NTLM’s persistence. Microsoft has spent years hardening Windows against relays, adding signing requirements, improving channel binding, and nudging organizations away from legacy authentication. But NTLM remains deeply embedded in compatibility scenarios, and every remaining edge case becomes a place where identity can be separated from intent.
This is why reflection bugs are so stubborn. They do not always require stealing a password, dumping a hash, or exploiting memory corruption. They exploit the fact that a machine can be made to say, “Yes, I am this privileged identity,” in a place where that statement can be replayed against itself.
This is a recurring Windows security theme. Microsoft can ship the same or similar plumbing across editions while applying different defaults for usability, compatibility, and enterprise deployment reasons. Those defaults often decide whether a theoretical bug becomes an operational exploit.
For Windows 11 24H2, enforced SMB signing changes the economics. Relay attacks depend on being able to forward authentication in a form the target will accept. Signing binds the authentication to the session, preventing the attacker from simply replaying it as if nothing happened. It does not make every authentication problem disappear, but it breaks this chain.
For Windows Server 2025, the lesson is sharper. Servers are the machines most likely to carry sensitive roles, run privileged services, and sit inside trust-rich environments. If their defaults leave room for local authentication reflection while client defaults do not, defenders should not treat “fully patched” as equivalent to “configured with modern relay resistance.”
The researchers describe a separate Kerberos authentication coercion path involving DNS control and discrepancies in how Windows components handle target names. The details are more complex than the NTLM local privilege escalation chain, but the strategic point is straightforward: if one protocol-specific patch leaves the general authentication reflection model intact, attackers will look for another protocol path.
This is where Microsoft’s product security problem becomes harder. Fixing SMB client behavior can be the right immediate patch. But if LSASS, name canonicalization, DNS resolution, SPN construction, and protocol clients do not share a single hardened model of target identity, security researchers will keep finding seams.
The issue is not that Kerberos is “broken” in the broad sense. It is that Windows is an ecosystem of old and new components that must interpret names consistently under hostile input. When they do not, attackers can turn ambiguity into authority.
This research is a reminder that patch status is a snapshot, not a security proof. A system can have every vendor update installed and still be exposed to a bypass of the previous fix, a configuration-dependent relay path, or a protocol interaction nobody considered when the original patch shipped.
That does not mean patching failed. Microsoft’s March 2026 update for CVE-2026-24294 closed the newly disclosed LPE vector, and organizations should absolutely apply it. The mistake is treating patching as the end of the story rather than the beginning of the next risk review.
For administrators, the practical implication is to track vulnerability classes, not just CVE numbers. If your environment was concerned about CVE-2025-33073 in 2025, it should also care about follow-on research into authentication reflection in 2026. The relationship between those bugs is operationally meaningful even if the advisories describe different components.
That is why relay vulnerabilities have remained so valuable to attackers. They often turn ordinary domain access into privileged footholds without needing a kernel exploit or a stolen administrator password. In environments with weak segmentation, inconsistent SMB signing, permissive name resolution, and legacy protocol dependencies, the blast radius grows quickly.
The risk is also uneven. A modern Windows 11 fleet with enforced SMB signing, hardened name resolution, and limited local admin sprawl is a very different target from a mixed server estate carrying years of compatibility exceptions. The same CVE can be a curiosity in one network and an incident path in another.
This unevenness complicates patch prioritization. Vulnerability scanners may flag the same issue across thousands of systems, but the systems that matter most are the ones that combine sensitive roles, reachable SMB surfaces, and authentication settings that still tolerate relay-style behavior.
Enterprises run decades of applications, appliances, scripts, backup tools, identity integrations, and line-of-business systems that assume old authentication behavior. Microsoft knows this, which is why Windows hardening often arrives as a long campaign: defaults change gradually, auditing modes appear first, administrators get registry keys and policies, and the final enforcement date moves carefully.
That gradualism is defensible. Breaking authentication at scale can be operationally catastrophic. But the cost is a long middle period where attackers can still exploit the old model faster than defenders can retire it.
CVE-2025-33073 and CVE-2026-24294 sit squarely in that middle period. They are not random mistakes floating outside the Windows security roadmap. They are artifacts of a platform trying to preserve compatibility while tightening the rules around identity, transport, and service names.
SMB signing deserves special attention. Where signing is required, relay paths become dramatically less useful. Where signing is optional, attackers will search for the machines, services, and downgrade opportunities that still allow unsigned or weakly bound authentication.
Administrators should also review exposure of SMB services, local privilege boundaries, and coercion paths. PetitPotam-style techniques have shown repeatedly that Windows services can be induced to authenticate in surprising ways. Reducing unnecessary service reachability and tightening network segmentation will not eliminate every bug, but it can prevent a local primitive from becoming a domain problem.
The final defensive move is cultural: do not archive a vulnerability class after the first patch. Authentication reflection, NTLM relay, Kerberos name confusion, and SMB signing policy should remain part of the same operational conversation. Attackers do not organize their playbooks by Microsoft advisory titles.
Microsoft Fixed the Door Synacktiv Walked Through, Not the Hallway Behind It
CVE-2025-33073 was never just an SMB bug in the way administrators usually think about SMB bugs. It was an authentication reflection problem: Windows could be coerced into authenticating to an attacker-controlled endpoint, and that authentication could then be relayed back in a way that let the attacker act with far higher privileges than they started with.The original technique revolved around CredMarshalTargetInfo, or CMTI, a Windows mechanism that allows extra target information to be embedded into authentication target names. Synacktiv’s earlier research showed that carefully crafted target names could survive long enough to influence how authentication was generated, while being normalized away by LSASS before the final NTLM or Kerberos blob was built. That mismatch created the opening.
Microsoft’s June 2025 fix targeted the SMB client driver,
mrxsmb.sys, and blocked connections to names carrying the embedded target information. That was effective against the disclosed path. It did not, according to Synacktiv’s follow-up work, eliminate the broader possibility that Windows components could still be made to reflect local authentication under the right conditions.That is the uncomfortable lesson here. A patch can be correct within its immediate threat model and still incomplete against the vulnerability class. Synacktiv’s new work argues exactly that: Microsoft closed the named exploit route, but the architecture still had places where authentication identity, transport reuse, and protocol-specific behavior could be made to disagree.
The Bypass Was Built Like a Patch Review, Not a Magic Trick
The new exploit chain matters because it was not discovered by random fuzzing or a lucky crash. Synacktiv approached the patch like an adversarial reviewer would: understand precisely what Microsoft changed, identify what the change did not cover, and then test the uncovered space against realistic constraints.Those constraints are what make the research interesting. The team was not satisfied with an artificial lab condition requiring exotic configuration, user clicks, or services that are rarely enabled. Their target was a default Windows 11 or Windows Server 2025 setup, with no user interaction, and an outcome that mattered: remote code execution or local privilege escalation.
That methodology quickly narrowed the field. RPC and DCOM were less attractive because Microsoft’s post-2022 hardening around packet integrity has made many old relay tricks harder to use. HTTP over WebDAV had its own problem: the WebClient service is not running by default on servers, and many Windows HTTP clients lowercase hostnames in ways that break the case-sensitive base64 encoding used by the CMTI technique.
SMB, however, still had a surprise. Windows 11 24H2 and Windows Server 2025 introduced support for connecting to SMB shares on arbitrary TCP ports. A feature that looks like ordinary flexibility for administrators became, in this context, a way to build a more interesting authentication trap.
Arbitrary SMB Ports Turned a Feature Into a Relay Surface
The decisive building block was simple: a low-privileged domain user could mount an SMB share on a non-standard TCP port usingnet use with the /tcpport option. That does not sound alarming on its own. Windows clients have long needed to connect to file services, and custom port support can be useful in edge cases, test environments, and complex network layouts.The problem appears when that feature meets SMB session multiplexing and connection reuse. The SMB2 protocol allows multiple authenticated sessions over a single TCP connection. The Windows SMB client can reuse an existing TCP connection rather than opening a clean one for each new authentication context.
Synacktiv’s exploit chain took advantage of that behavior. An attacker first started a rogue SMB server on a custom port and connected to it with low-privileged credentials, creating a persistent TCP connection. Then the attacker coerced a privileged local service, such as LSASS, into authenticating to the same share path.
Because the SMB client reused the already established connection, the privileged NTLM authentication blob traveled over a channel controlled by the attacker. The attacker could then relay that local authentication back to the real SMB service on the machine. The result was an authenticated SMB session as NT AUTHORITY\SYSTEM.
That is the kind of vulnerability chain Windows defenders hate because no single step looks outrageous in isolation. A user mounts a share. A service authenticates. SMB reuses a connection. NTLM relay tooling does what NTLM relay tooling has done for years. The vulnerability lives in the composition.
The PoC Is a Reminder That NTLM’s Ghost Still Runs the Building
The public write-up describes a toolchain many red teams and defenders will recognize. Synacktiv used Impacket’ssmbserver.py to receive the privileged authentication blob, ntlmrelayx.py to relay it back to the built-in SMB service, net.exe to mount the custom share, and a modified PetitPotam executable to coerce LSASS authentication locally.That combination is not new in spirit. PetitPotam and NTLM relay attacks have been part of the Windows security conversation for years, especially in Active Directory environments where service accounts, machine accounts, and legacy authentication paths create an enormous relay surface. What is new is the route around a mitigation that many administrators reasonably assumed had killed this particular reflection pattern.
The larger story is NTLM’s persistence. Microsoft has spent years hardening Windows against relays, adding signing requirements, improving channel binding, and nudging organizations away from legacy authentication. But NTLM remains deeply embedded in compatibility scenarios, and every remaining edge case becomes a place where identity can be separated from intent.
This is why reflection bugs are so stubborn. They do not always require stealing a password, dumping a hash, or exploiting memory corruption. They exploit the fact that a machine can be made to say, “Yes, I am this privileged identity,” in a place where that statement can be replayed against itself.
Windows Server 2025 Was the Easier Target Because Signing Still Decides the Game
Synacktiv’s local privilege escalation scenario reportedly worked by default on Windows Server 2025 but not on Windows 11 24H2, where SMB signing is enforced in a way that blocks the relay. That distinction is crucial. The same feature appeared in both client and server releases, but the security posture around SMB authentication differed enough to change the outcome.This is a recurring Windows security theme. Microsoft can ship the same or similar plumbing across editions while applying different defaults for usability, compatibility, and enterprise deployment reasons. Those defaults often decide whether a theoretical bug becomes an operational exploit.
For Windows 11 24H2, enforced SMB signing changes the economics. Relay attacks depend on being able to forward authentication in a form the target will accept. Signing binds the authentication to the session, preventing the attacker from simply replaying it as if nothing happened. It does not make every authentication problem disappear, but it breaks this chain.
For Windows Server 2025, the lesson is sharper. Servers are the machines most likely to carry sensitive roles, run privileged services, and sit inside trust-rich environments. If their defaults leave room for local authentication reflection while client defaults do not, defenders should not treat “fully patched” as equivalent to “configured with modern relay resistance.”
The Kerberos Follow-Up Shows the Class Was Bigger Than SMB
Synacktiv’s second line of research moved from NTLM reflection to Kerberos. That matters because it undercuts the comforting assumption that this was merely a legacy NTLM problem. Kerberos is the preferred Windows domain authentication protocol, but it still relies on names, service principal resolution, and subtle agreement between components about what target is being authenticated.The researchers describe a separate Kerberos authentication coercion path involving DNS control and discrepancies in how Windows components handle target names. The details are more complex than the NTLM local privilege escalation chain, but the strategic point is straightforward: if one protocol-specific patch leaves the general authentication reflection model intact, attackers will look for another protocol path.
This is where Microsoft’s product security problem becomes harder. Fixing SMB client behavior can be the right immediate patch. But if LSASS, name canonicalization, DNS resolution, SPN construction, and protocol clients do not share a single hardened model of target identity, security researchers will keep finding seams.
The issue is not that Kerberos is “broken” in the broad sense. It is that Windows is an ecosystem of old and new components that must interpret names consistently under hostile input. When they do not, attackers can turn ambiguity into authority.
Fully Patched No Longer Means Fully Understood
The phrase “fully patched Windows system” has always carried more emotional weight than technical precision. It reassures executives, auditors, and administrators because it implies closure. Install the cumulative update, reboot, watch the dashboard turn green, move on.This research is a reminder that patch status is a snapshot, not a security proof. A system can have every vendor update installed and still be exposed to a bypass of the previous fix, a configuration-dependent relay path, or a protocol interaction nobody considered when the original patch shipped.
That does not mean patching failed. Microsoft’s March 2026 update for CVE-2026-24294 closed the newly disclosed LPE vector, and organizations should absolutely apply it. The mistake is treating patching as the end of the story rather than the beginning of the next risk review.
For administrators, the practical implication is to track vulnerability classes, not just CVE numbers. If your environment was concerned about CVE-2025-33073 in 2025, it should also care about follow-on research into authentication reflection in 2026. The relationship between those bugs is operationally meaningful even if the advisories describe different components.
The Enterprise Risk Is Concentrated Where Legacy Authentication Meets Default Trust
In a home Windows environment, a local privilege escalation from a low-privileged account to SYSTEM is serious but bounded. In an enterprise, the same primitive can become a stepping stone. SYSTEM on a server can mean access to cached secrets, service tokens, machine account privileges, lateral movement paths, and domain reconnaissance opportunities.That is why relay vulnerabilities have remained so valuable to attackers. They often turn ordinary domain access into privileged footholds without needing a kernel exploit or a stolen administrator password. In environments with weak segmentation, inconsistent SMB signing, permissive name resolution, and legacy protocol dependencies, the blast radius grows quickly.
The risk is also uneven. A modern Windows 11 fleet with enforced SMB signing, hardened name resolution, and limited local admin sprawl is a very different target from a mixed server estate carrying years of compatibility exceptions. The same CVE can be a curiosity in one network and an incident path in another.
This unevenness complicates patch prioritization. Vulnerability scanners may flag the same issue across thousands of systems, but the systems that matter most are the ones that combine sensitive roles, reachable SMB surfaces, and authentication settings that still tolerate relay-style behavior.
Microsoft’s Hardest Problem Is Compatibility With Its Own Past
It is tempting to say Microsoft should simply disable NTLM, require signing everywhere, and reject every ambiguous target name. In security terms, that is the clean answer. In Windows terms, it is also a compatibility grenade.Enterprises run decades of applications, appliances, scripts, backup tools, identity integrations, and line-of-business systems that assume old authentication behavior. Microsoft knows this, which is why Windows hardening often arrives as a long campaign: defaults change gradually, auditing modes appear first, administrators get registry keys and policies, and the final enforcement date moves carefully.
That gradualism is defensible. Breaking authentication at scale can be operationally catastrophic. But the cost is a long middle period where attackers can still exploit the old model faster than defenders can retire it.
CVE-2025-33073 and CVE-2026-24294 sit squarely in that middle period. They are not random mistakes floating outside the Windows security roadmap. They are artifacts of a platform trying to preserve compatibility while tightening the rules around identity, transport, and service names.
Defenders Should Treat This as a Relay-Hardening Drill
The obvious first step is to ensure the March 2026 security updates are deployed across affected Windows Server 2025 systems and any other applicable Windows builds. But the more durable response is to audit the assumptions that made the bypass useful in the first place.SMB signing deserves special attention. Where signing is required, relay paths become dramatically less useful. Where signing is optional, attackers will search for the machines, services, and downgrade opportunities that still allow unsigned or weakly bound authentication.
Administrators should also review exposure of SMB services, local privilege boundaries, and coercion paths. PetitPotam-style techniques have shown repeatedly that Windows services can be induced to authenticate in surprising ways. Reducing unnecessary service reachability and tightening network segmentation will not eliminate every bug, but it can prevent a local primitive from becoming a domain problem.
The final defensive move is cultural: do not archive a vulnerability class after the first patch. Authentication reflection, NTLM relay, Kerberos name confusion, and SMB signing policy should remain part of the same operational conversation. Attackers do not organize their playbooks by Microsoft advisory titles.
The Patch Notes Are Smaller Than the Lesson
The concrete facts are narrow enough to summarize, but the security lesson is broader. Synacktiv’s research shows that Windows authentication hardening is still a moving target, especially where new SMB functionality intersects with old relay assumptions.- CVE-2025-33073 was patched in June 2025, but Synacktiv later demonstrated that the mitigation did not fully address the underlying authentication reflection class.
- The follow-on bypass, tracked as CVE-2026-24294, used SMB connections on arbitrary TCP ports and was patched during Microsoft’s March 2026 Patch Tuesday cycle.
- The demonstrated local privilege escalation worked by default on Windows Server 2025, while Windows 11 24H2 resisted the same path because SMB signing was enforced.
- The exploit chain relied on ordinary-looking components, including SMB connection reuse, NTLM relay tooling, and coerced LSASS authentication.
- The Kerberos follow-up indicates that defenders should think beyond NTLM and SMB when assessing authentication reflection risk.
- The practical response is not only to patch, but to enforce SMB signing, reduce relay surfaces, and track vulnerability classes across multiple advisories.
References
- Primary source: cyberpress.org
Published: Tue, 30 Jun 2026 11:18:05 GMT
- Related coverage: synacktiv.com
Bypassing Windows authentication reflection mitigations for SYSTEM
Bypassing Windows authentication reflection mitigations for SYSTEMwww.synacktiv.com - Related coverage: ampcuscyber.com
CVE-2025-33073: NTLM Vulnerability Exposes Windows SMB
A high-impact NTLM reflection vulnerability (CVE-2025-33073) in Windows SMB clients allows remote command execution. Discover how to mitigate this risk.www.ampcuscyber.com - Related coverage: helpnetsecurity.com
CISA warns of Windows SMB flaw under active exploitation (CVE-2025-33073) - Help Net Security
CVE-2025-33073, a Windows SMB Client vulnerability that Microsoft fixed in June 2025, is being exploited by attackers.www.helpnetsecurity.com - Related coverage: techradar.com
CISA warns high-severity Windows SMB flaw now exploited in attacks, so update now | TechRadar
Watch out for this SMB vulnerability, Windows users toldwww.techradar.com