What You Need to Know First

Kerberos remains foundational in Active Directory, with service tickets and SPNs (Service Principal Name) validation defining access boundaries. The rise of certificate-based authentication (PKINIT) vulnerabilities such as insecure template permissions and loose UPN mapping has also led to exploitation of user identities in ways that traditional protocol documentation did not fully anticipate. CVE-2025-33073 allows authenticated domain users to escalate privileges to SYSTEM on Windows machines that don’t enforce SMB signing. The vulnerability exploits authentication reflection through a DNS manipulation technique combined with flaws in both NTLM and Kerberos local authentication logic, such as bypassing Service Principal Name validation. There have been multiple write-ups on this CVE, but I wanted to focus on detection and mitgation and the realization that Patching and SMB signing are only the first step.

CVE-2025-33073
Last Updated: June 11, 2025
Severity: Critical (CVSS 7.8)
Status: Patched (June 2025) - Root cause NOT fully addressed
Estimated remediation time: 48-72 hours for 500-system environment

  • Microsoft’s June 2025 patch blocks the DNS exploitation technique against SMB (via SmbCeCreateSrvCall function modification)
  • The underlying privilege escalation logic was NOT patched
  • SMB signing enforcement provides complete protection from escalation via SMB
  • Alternative exploitation methods may be discovered
  • Detection is feasible with proper monitoring

The Bottom line here is: Patch immediately, enforce SMB signing, and implement detection—in that order.

Required attacker privileges:

  • Any domain user account
  • Network access to Victim system
  • Ability to register DNS records (enabled by default for authenticated users in most domains)
  • Access to authentication coercion method (multiple available)

How the Attack Works (Technical Overview)

Phase 1: DNS Record Creation

The attacker registers a malicious DNS record that matches the vitims with the addition of a base64 encoded structure using a legitimate Windows API structure:

hostname: Victim
DNS points to: Victim’s IP

Attacker created hostname: Victim1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA
DNS points to: Attacker controlled IP

The suffix 1UWhRCAAAA…YBAAAA is a Base64-encoded CREDENTIAL_TARGET_INFORMATIONW structure—a legitimate Windows feature designed to pass authentication metadata in hostnames.

Why this matters for detection: This DNS record is unusual and can be detected via DNS audit logs.

Prerequisites to create this record:

  • Domain user account (default permissions in most AD environments)
  • Network access to DNS server
  • Tools: PowerShell + dnstool.py (from krbrelayx), ADSI Edit, or legitimate DNS management tools

Phase 2: Authentication Coercion

The attacker forces the target system to authenticate using one of several methods:

Limited list of available coercion methods (as of June 2025):

  • Windows Search Protocol (WSP)
  • clientswspcoerceEFSR
  • Print Spooler (PrinterBug)
  • DFSNMDFS

Key point: Multiple coercion methods exist, and new ones may be discovered. Focus on defense/detection, not blocking individual methods.

Phase 3: SPN Decoupling

When Windows (Victim) resolves the Attacker’s hostname:

  • During name resolution:
    • Full hostname: Victim1UWhRC…YBAAAA
    • DNS resolves to: Attacker IP
  • During Kerberos ticket request:
    • Function: lsasrv!LsapCheckMarshalledTargetInfo
    • Input: cifs/Victim1UWhRC…YBAAAA
    • Output: cifs/Victim (suffix stripped, which creates a TGS for the Victim machine instead of the Attacker)

Result: Service ticket issued for cifs/Victim This creates a disconnect: the ticket is for the legitimate machine, but the connection goes to the attacker.

Phase 4: Privilege Escalation (The Core Vulnerability)

When the reflected authentication succeeds, Windows incorrectly grants SYSTEM privileges through two possible paths:

Path 1: NTLM Local Authentication

When Windows detects the target matches the local machine name (after the suffix is stripped), it enables “local NTLM authentication”:

msv1_0!SsprHandleNegotiateMessage

if (client_workstation == local_hostname && 
    client_domain == local_domain) {
    
    // Enable special local authentication mode
    set NTLMSSP_NEGOTIATE_LOCAL_CALL flag;
    
    // Copy the calling process's token
    // If lsass.exe is coerced, this is SYSTEM token
    copy_token_to_context(SYSTEM_token);
}

Path 2: Kerberos Subkey Matching

When SYSTEM services authenticate via Kerberos, they store their tokens in a global list:

kerberos!SpInitLsaModeContext

if (user_logon_id == SYSTEM_LUID) {
    create_subkey_entry(logon_id, subkey, SYSTEM_token);
    add_to_global_list(subkey_entry);
}

Later, when AP-REQ is reflected back:

kerberos!KerbCreateTokenFromTicketEx

if (client_name == machine_account_name &&
    subkey_exists_in_list(reflected_subkey) &&
    associated_logon_id == SYSTEM_LUID) {
    
    // VULNERABILITY: Create SYSTEM token instead of machine account token
    create_system_token();
}


The flaw: Windows assumes that if a machine account authenticates back to itself with a SYSTEM-associated subkey, it must be a legitimate local operation deserving SYSTEM privileges. The DNS manipulation bypasses this assumption.

Kerberos → SMB Loopback Flow
Shows the protocol-level sequence where an SMB/PKINIT authentication coercion from the attacker leads to Kerberos exchanges with the KDC, followed by local ticket reflection on the victim host and resulting SYSTEM-level execution.

sequenceDiagram
    participant Attacker
    participant Victim
    participant KDC

    Attacker->>Victim: SMB/PKINIT Auth Request/Coercion
    Victim->>KDC: AS-REQ / TGS-REQ
    KDC-->>Victim: Service Ticket
    Victim->>Victim: Reflect Ticket (SPN Validation Bypass)
    Victim-->>Attacker: SYSTEM Execution

What Microsoft Patched ( … and Didn’t)

The June 2025 patch adds a check in the SMB client (mrxsmb.sys) as discovered after “diffing” mrxsmb.sys before and after the patch.

mrxsmb!SmbCeCreateSrvCall

NTSTATUS SmbCeCreateSrvCall(...)
{
    // NEW CODE: Check for marshalled target info
    if (CredUnmarshalTargetInfo(TargetName, ...) != STATUS_INVALID_PARAMETER) {
        return STATUS_INVALID_PARAMETER; // Block connection
    }
    // ... rest of function
}

What This Fixes:

Prevents SMB connections to hostnames with CREDENTIAL_TARGET_INFORMATIONW suffixes.

What This Does NOT Fix:

  • The NTLM local authentication token copying logic
  • The Kerberos subkey privilege escalation logic
  • Alternative methods to trigger the same conditions
  • The fundamental design issue

Implication: If someone discovers a different way to make Windows think it’s authenticating to itself while actually connecting elsewhere, the privilege escalation vulnerability remains.

Detection Strategy

CVE-2025-33073 leaves extensive forensic evidence. Focus on:

  • Anomalous DNS records (prevention/early warning)
  • Loopback authentication with machine accounts (active exploitation)
  • Privilege escalation patterns (successful compromise)

Before implementing detection, ensure these audit policies are enabled:

Via Group Policy:

Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Audit Policies

Enable:

  • Audit Logon (Success and Failure)
  • Audit Special Logon (Success)
  • Audit File Share (Success)
  • Audit Kerberos Service Ticket Operations (Success and Failure)

OR

Via Command Line (immediate):

auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Special Logon" /success:enable
auditpol /set /subcategory:"File Share" /success:enable
auditpol /set /subcategory:"Kerberos Service Ticket Operations" /success:enable

Verify settings:

auditpol /get /category:"Logon/Logoff"
auditpol /get /category:"Account Logon"


Detection Layer 1: DNS Anomalies

What to look for: DNS A/AAAA records containing Base64-like patterns after the hostname.

Method 1: DNS Server Debug Logs (Windows DNS Server)

Enable DNS debug logging:

Set-DnsServerDiagnostics -All $true -LogFilePath "C:\DNSLogs\dns.log"

Monitor for record creation:

# Parse DNS logs for suspicious patterns
Get-Content C:\DNSLogs\dns.log -Tail 1000 | 
    Where-Object {$_ -match 'update.*1UWhRC[A-Za-z0-9+/=]{20,}'} |
    Select-String -Pattern "(\d+\.\d+\.\d+\.\d+)" |
    ForEach-Object {
        [PSCustomObject]@{
            Timestamp = ($_ -split '\s+')[0,1] -join ' '
            SuspiciousHostname = ($_ -match '1UWhRC\w+')
            SourceIP = $Matches[1]
        }
    }

Method 2: Active Directory DNS Zone Monitoring

Query AD-integrated DNS zones:

# Find suspicious DNS records in AD
$DNSZone = "DC=DomainDnsZones,DC=cloud,DC=lab"
  
Get-ADObject -SearchBase $DNSZone -LDAPFilter "(objectClass=dnsNode)" -Properties dnsRecord,whenCreated |
    Where-Object { $_.Name -match '1UWhRC[A-Za-z0-9+=/]{20,}' } |
    Select-Object Name, @{N='CreatedDate';E={$_.whenCreated}}


Detection Confidence: High (legitimate hostnames don’t use this pattern)
False Positive Rate: Near zero
Response Time: Minutes to hours (depending on log collection frequency)

Detection Layer 2: Windows Event Logs

Event ID 4624 - Network Logon by Machine Account to Loopback

Event ID: 4624
Logon Type: 3 (Network)
Account Name: Ends with $ (machine account)
Source IP: 127.0.0.1 or ::1
Elevated Token: Yes

PowerShell Detection:

param(
    [int]$Hours = 24,
    [int]$MaxEvents = 10000
)

$StartTime = (Get-Date).AddHours(-$Hours)

# Use FilterXPath for performance (10x faster than FilterHashtable on large logs)
$XPath = @"
*[System[(EventID=4624) and TimeCreated[timediff(@SystemTime) <= $($Hours*3600000)]]] 
and
*[EventData[Data[@Name='LogonType']='3']]
and
*[EventData[Data[@Name='IpAddress']='127.0.0.1' or Data[@Name='IpAddress']='::1']]
"@

Get-WinEvent -LogName Security -FilterXPath $XPath -MaxEvents $MaxEvents -ErrorAction SilentlyContinue |
    ForEach-Object {
        $EventXML = [xml]$_.ToXml()
        $EventData = $EventXML.Event.EventData.Data
        
        # Parse event data by name (version-safe)
        $TargetUserName = ($EventData | Where-Object {$_.Name -eq 'TargetUserName'}).'#text'
        $IpAddress = ($EventData | Where-Object {$_.Name -eq 'IpAddress'}).'#text'
        $LogonType = ($EventData | Where-Object {$_.Name -eq 'LogonType'}).'#text'
        $ElevatedToken = ($EventData | Where-Object {$_.Name -eq 'ElevatedToken'}).'#text'
        
        # Filter for machine accounts
        if ($TargetUserName -match '\$$') {
            [PSCustomObject]@{
                TimeCreated = $_.TimeCreated
                Computer = $_.MachineName
                Account = $TargetUserName
                SourceIP = $IpAddress
                LogonType = $LogonType
                ElevatedToken = $ElevatedToken
                Severity = 'CRITICAL'
                Alert = 'Possible CVE-2025-33073 exploitation'
            }
        }
    } | 
    Sort-Object TimeCreated -Descending |
    Format-Table -AutoSize

Expected false positives:

  • Failover cluster heartbeats (look for regular intervals, specific cluster node names)
  • Some backup agents (validate against known backup schedules)
  • Monitoring tools (cross-reference with monitoring agent processes)

Tuning for false positives:

# Exclude known cluster nodes
$ExcludeAccounts = @('CLUSTER-NODE1$', 'CLUSTER-NODE2$')

# Add to the Where-Object clause:
if ($TargetUserName -match '\$$' -and $TargetUserName -notin $ExcludeAccounts) {
    # ... create object
}
# Rest of code



Event ID 4672 - Special Privileges Assigned to Machine Account

Event ID: 4672
Subject Account: Ends with $ (machine account)
Privileges: Includes SeDebugPrivilege or SeBackupPrivilege
Source IP: Loopback (correlate with 4624)

PowerShell Detection:

$XPath = @"
*[System[(EventID=4672)]]
and
*[EventData[Data[@Name='PrivilegeList'] and (contains(., 'SeDebugPrivilege') or contains(., 'SeBackupPrivilege'))]]
"@

Get-WinEvent -LogName Security -FilterXPath $XPath -MaxEvents 5000 |
    ForEach-Object {
        $EventXML = [xml]$_.ToXml()
        $EventData = $EventXML.Event.EventData.Data
        
        $SubjectUserName = ($EventData | Where-Object {$_.Name -eq 'SubjectUserName'}).'#text'
        $PrivilegeList = ($EventData | Where-Object {$_.Name -eq 'PrivilegeList'}).'#text'
        
        if ($SubjectUserName -match '\$$') {
            [PSCustomObject]@{
                TimeCreated = $_.TimeCreated
                Computer = $_.MachineName
                Account = $SubjectUserName
                Privileges = $PrivilegeList
                Alert = 'Suspicious privilege assignment to machine account'
            }
        }
    }



Event ID 4769 - Kerberos Service Ticket Request (Reflection Pattern)

Event ID: 4769
Service Name: cifs/ OR host/ Account Name: $ Ticket Options: Typically includes forwardable flag

PowerShell Detection:

$LocalHostname = $env:COMPUTERNAME

$XPath = @"
*[System[(EventID=4769)]]
and
*[EventData[Data[@Name='IpAddress']='::ffff:127.0.0.1' or Data[@Name='IpAddress']='127.0.0.1']]
"@

Get-WinEvent -LogName Security -FilterXPath $XPath -MaxEvents 5000 |
    ForEach-Object {
        $EventXML = [xml]$_.ToXml()
        $EventData = $EventXML.Event.EventData.Data
        
        $ServiceName = ($EventData | Where-Object {$_.Name -eq 'ServiceName'}).'#text'
        $TargetUserName = ($EventData | Where-Object {$_.Name -eq 'TargetUserName'}).'#text'
        $IpAddress = ($EventData | Where-Object {$_.Name -eq 'IpAddress'}).'#text'
        
        # Check if service name matches local host
        if ($ServiceName -like "*$LocalHostname*") {
            [PSCustomObject]@{
                TimeCreated = $_.TimeCreated
                Computer = $_.MachineName
                ServiceName = $ServiceName
                RequestingAccount = $TargetUserName
                SourceIP = $IpAddress
                Alert = 'Kerberos reflection pattern detected'
            }
        }
    }


Detection Confidence: High
False Positive Rate: Low (requires investigation of legitimate loopback Kerberos usage)
Response Time: Real-time (if event forwarding is configured)
Detection Layer 3: SIEM Integration

Centralized Monitoring Across Multiple Systems.

Splunk Query Example

index=windows sourcetype=WinEventLog:Security
(EventCode=4624 OR EventCode=4672 OR EventCode=4769)

| eval IsMachineAccount=if(match(TargetUserName, "\$$"), 1, 0)
| eval IsLoopback=if(match(IpAddress, "^(127\.0\.0\.1|::1|::ffff:127\.0\.0\.1)$"), 1, 0)
| eval IsNetworkLogon=if(LogonType=3, 1, 0)

| where IsMachineAccount=1 AND IsLoopback=1 AND (IsNetworkLogon=1 OR EventCode=4672 OR EventCode=4769)

| stats 
    count as EventCount,
    values(EventCode) as EventIDs,
    earliest(_time) as FirstSeen,
    latest(_time) as LastSeen,
    values(PrivilegeList) as Privileges
    by host, TargetUserName, IpAddress

| eval Duration=LastSeen-FirstSeen
| eval Severity=case(
    EventCount > 5, "CRITICAL",
    EventCount > 2, "HIGH",
    1=1, "MEDIUM"
)

| table FirstSeen, LastSeen, host, TargetUserName, EventIDs, EventCount, Severity
| sort -FirstSeen


Set up alert:
Alert Type: Real-time
Trigger: Per-Result
Throttle: 15 minutes per host
Action: Email security team + Create incident ticket
Priority: Critical

Microsoft Sentinel/Defender KQL Query Example

// CVE-2025-33073 Detection Rule
// SMB CLient Patched: June 2025 Updates

SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID in (4624, 4672, 4769)
| where TargetUserName endswith "$" 
| where IpAddress in ("127.0.0.1", "::1", "::ffff:127.0.0.1")
| extend 
    LocalHostname = tostring(split(Computer, ".")[0]),
    MachineAccountName = tostring(split(TargetUserName, "$")[0])
| where LocalHostname =~ MachineAccountName
| extend
    IsNetworkLogon = (LogonType == 3),
    HasElevatedPrivileges = (PrivilegeList contains "SeDebugPrivilege" or PrivilegeList contains "SeBackupPrivilege")
| summarize 
    EventCount = count(),
    EventTypes = make_set(EventID),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated),
    Privileges = make_set(PrivilegeList)
    by Computer, TargetUserName, IpAddress, Account
| extend 
    Severity = case(
        EventCount > 5, "High",
        EventCount > 2, "Medium",
        "Low"
    )
| project 
    FirstSeen,
    LastSeen,
    Computer,
    TargetUserName,
    EventTypes,
    EventCount,
    Severity,
    Privileges
| order by FirstSeen desc


Create Alert Rule:

  1. Navigate to: Sentinel → Analytics → Create → Scheduled query rule
  2. Name: “CVE-2025-33073 - Reflective Authentication Detection”
  3. Paste query above
  4. Run frequency: Every 5 minutes
  5. Lookup data from: Last 15 minutes
  6. Alert threshold: Greater than 0 results
  7. Event grouping: Group all events into single alert
  8. Incident settings: Create incidents
  9. Automated response: (optional) Run playbook to isolate machine

Elastic Stack (EQL) Detection Rule Example (not tested)

// CVE-2025-33073 Detection
// For: Elastic Security

sequence by host.name with maxspan=5m
  [authentication where 
    event.outcome == "success" and
    user.name like "*$" and
    source.ip in ("127.0.0.1", "::1") and
    event.code == "4624"
  ]
  [authentication where
    event.code == "4672" and
    user.name like "*$" and
    winlog.event_data.PrivilegeList in ("SeDebugPrivilege", "SeBackupPrivilege")
  ]


Configuration
Rule name: CVE-2025-33073 Reflective Authentication
Risk score: 99
Severity: Critical
MITRE ATT&CK: Privilege Escalation - Valid Accounts (T1078)
Index patterns: winlogbeat-*
Run every: 5 minutes
Additional look-back time: 15 minutes

Detection Layer 4: Network Monitoring (not tested)

For environments with network visibility (Zeek, Suricata, etc.). Suricata Rule Example for NTLM Local Call Detection

Alert Example:

# CVE-2025-33073 - NTLM Local Call Reflection
alert smb $HOME_NET any -> $HOME_NET 445 (
    msg:"CVE-2025-33073 - NTLM Negotiate Local Call Detected";
    flow:to_server,established;
    content:"|4e 54 4c 4d 53 53 50|"; offset:0; depth:7;
    content:"|00 00 00 02|"; distance:0; within:4;
    byte_test:4,&,0x00004000,48; 
    threshold:type limit, track by_src, count 1, seconds 300;
    classtype:attempted-admin;
    priority:1;
    reference:cve,2025-33073;
    reference:url,github.com/RedTeamPentesting/CVE-2025-33073;
    sid:20250001; rev:1;
)

# CVE-2025-33073 - SMB Connection to Loopback
alert tcp $HOME_NET any -> 127.0.0.1 445 (
    msg:"CVE-2025-33073 - SMB Connection to Loopback Address";
    flow:to_server,established;
    content:"|ff|SMB"; offset:4; depth:4;
    threshold:type limit, track by_src, count 1, seconds 300;
    classtype:attempted-admin;
    priority:1;
    reference:cve,2025-33073;
    sid:20250002; rev:1;
)

Wrap-up

While Microsoft’s June 2025 patch successfully blocks the specific SMB-based exploitation path for CVE-2025-33073, the underlying architectural vulnerabilities in Windows authentication remain unresolved. The patch represents a surface-level fix on a deeper issue in how Windows handles local authentication privileges and Kerberos subkey validation. Organizations must recognize that patching the SMB client does not eliminate the root cause, only the currently known attack vector. The fundamental design flaws in NTLM’s local authentication token-copying logic and Kerberos’ subkey-to-privilege mapping still exists in the Windows authentication stack. This means that alternative methods to trigger the same reflection conditions could still exist. Whether through different protocols, new DNS manipulation techniques, or undiscovered coercion methods, it’s potentially possible to bypass the current patch. The attack surface extends beyond SMB to any authentication mechanism that might allow similar reflection conditions, including HTTP, LDAP, RPC, and other network protocols that support both NTLM and Kerberos authentication. The security community should approach this vulnerability with the understanding that CVE-2025-33073 is likely not the last chapter in reflection-based privilege escalation attacks. Defense-in-depth remains critical: enforce SMB signing universally, implement the detection strategies outlined above, maintain advanced audititng, and treat any loopback authentication by machine accounts as suspicious until proven otherwise. Organizations with mature security operations should establish baseline behaviors for their environments and investigate deviations aggressively.

Most importantly, assume that other exploitation pathways exist or will be discovered. Stay vigilant. Stay secure.