NTLM Relay
Overview
If name resolution protocol poisoning is not an option, see NTML via SMB or WebDAV.
NTLM authentication does not support mutual authentication. This means the client cannot verify that it is communicating with the legitimate server, and the server cannot verify that the client is connecting directly rather than through an intermediary. Because of this limitation, NTLM authentication can be abused in relay attacks, where an attacker forwards authentication attempts between two parties.
In an NTLM relay attack, the attacker positions themselves between a client and a target server. The attacker impersonates a legitimate service to the client while simultaneously acting as a client to the target server. When the victim authenticates, the attacker relays the authentication exchange to the target system and performs actions using the victim’s privileges.
The attack typically occurs in three phases: pre-relay, relay, and post-relay.
Pre-Relay Phase
The goal of the pre-relay phase is to coerce a victim system into initiating NTLM authentication to a host controlled by the attacker. One of the most common techniques used to achieve this is name resolution poisoning.
Name Resolution Poisoning
When a Windows host attempts to resolve a hostname, it follows (by default) a sequence of resolution mechanisms. The exact order may vary depending on configuration, but the process generally follows this pattern:
The hosts file (
C:\Windows\System32\Drivers\etc\hosts)The local DNS cache
The configured DNS server
Multicast name resolution protocols
If the hostname cannot be resolved through the hosts file, cache, or DNS, Windows may fall back to multicast-based name resolution protocols, including:
LLMNR (Link-Local Multicast Name Resolution)
NBT-NS (NetBIOS Name Service)
mDNS (Multicast DNS)
These protocols operate on the local network segment and broadcast a request asking if any system knows the requested hostname. The problem is that these protocols do not verify the authenticity of responses. Any host on the same network segment can reply to the request, and the client will typically trust the first response it receives. This behavior allows an attacker to impersonate the requested host and capture authentication attempts.
For example, if a user mistypes a network path such as:
instead of:
the system may send an LLMNR or NBT-NS broadcast asking which host owns the name pintserver. An attacker on the same network can respond to this request and claim ownership of the name, causing the victim system to attempt authentication to the attacker-controlled host.
Name resolution poisoning is only one way to obtain a MitM position for NTLM relay attacks. Other techniques can also be used to redirect authentication traffic, including:
Poisoning Tools
Several tools can exploit multicast name resolution behavior by responding to broadcast queries and impersonating legitimate services. Two commonly used tools are Responder (Linux) and Inveigh (Windows). Metasploit's also has the smb_relay module for relaying NTLM.
Responder acts as a multicast poisoning tool and rogue authentication server, capable of responding to LLMNR, NBT-NS, and mDNS requests and capturing authentication attempts over multiple protocols. It supports authentication capture over services, such as SMB, HTTP, LDAP, MSSQL, and FTP. Captured authentication material typically includes NetNTLMv1 or NetNTLMv2 challenge–response data.
Responder also supports an analysis mode, which allows attackers to observe name resolution traffic without actively poisoning responses. This mode is useful for reconnaissance because it reveals which systems are attempting to resolve non-existent or mistyped hostnames.
When poisoning is enabled, Responder will respond to broadcast queries and impersonate the requested service. This causes the victim system to attempt NTLM authentication to the attacker's host. A successful capture might appear as:
Captured hashes are stored in Responder’s logs directory, typically:
It is common to observe multiple hashes for the same user account. This occurs because NTLMv2 authentication uses both a server challenge and a client challenge, each of which is randomly generated for every authentication attempt. As a result, the resulting challenge–response values differ even when the underlying password remains the same.
In addition to Responder and Inveigh, another tool used for name resolution poisoning and authentication capture is Pretender. Pretender is a cross-platform tool written in Go and developed by RedTeam Pentesting. Its primary purpose is to obtain a Machine-in-the-Middle (MitM) position by spoofing name resolution protocols and abusing DHCPv6-based DNS takeover techniques.
Like Responder, Pretender can impersonate network services and respond to name resolution requests in order to trigger authentication attempts from victim systems. However, it also includes functionality for DHCPv6 spoofing, which allows an attacker to influence how clients discover DNS servers on the network. By redirecting DNS resolution to an attacker-controlled system, Pretender can intercept or manipulate authentication traffic.
Pretender includes a dry-run mode (--dry), which allows the tool to observe broadcast traffic without responding to requests. This is useful during reconnaissance because it reveals which name resolution queries are occurring in the environment without actively interfering with network communication.
It is important to use Pretender cautiously in production environments. By default, the tool attempts to poison DHCP requests, which can significantly disrupt network operations. DHCP-based configuration changes may persist on affected machines until the DHCP lease expires, the system is rebooted, or a new DHCP request is forced. During this time, DNS queries from the affected system may be redirected incorrectly, potentially causing connectivity issues or preventing access to legitimate services.
Post-Capture Options
Once NetNTLM authentication material has been captured, two primary attack paths are possible:
Offline Password Cracking
Relay
Relay Phase
Other relay tools: MultiRelay.py, Inveigh.
Instead of cracking the hash, an attacker can relay the captured authentication attempt to another system that accepts NTLM authentication. Tools such as impacket-ntlmrelayx automate this process. The attacker intercepts the authentication attempt and forwards it to a target host, attempting to authenticate as the victim user.
For SMB relay attacks to succeed, SMB signing must not be required on the target system. If SMB signing is enforced, the relay attack will fail because the attacker cannot generate the required message signatures.
When using Responder together with ntlmrelayx, Responder’s SMB server must be disabled so that the relay tool can handle incoming connections.
Once running, ntlmrelayx waits for incoming authentication attempts and relays them to a single (-t) or multiple hosts (-tf). The -smb2support flag provides SMBv2 support for hosts the need it.
If the victim is a privileged account, ntmlrelayx will dump the SAM by default. However, remote code execution (RCE) can be also achieved using the -c flag. For example, a reverse shell can be used as a payload (e.g. revshells' Powershell #3 (Base64) or Invoke-PowerShellTcp.ps1).
To successfully gain remote code execution (RCE) on the target host via NTLM relaying:
The relayed user account must have administrative privileges on the target.
The target host must have UAC remote restrictions disabled; otherwise, command execution will fail unless relaying to the built-in local Administrator account.
If options like -c or -i in ntlmrelayx silently fail but actions like dumping the SAM still succeed, it's likely due to antivirus interference blocking payload execution.
Once the victim authenticates to our server, we poison the response and make it execute our command.
Multi-Relay
We Love Relaying Credentials: A Technical Guide to Relaying Credentials Everywhere
ntlmrelayx supports multi-relay, a feature that allows a single captured NTLM authentication attempt to be reused across multiple relay targets. This provides two main advantages:
It enables the attacker to identify the user associated with the captured NTLM authentication before deciding how to relay it.
It allows a single authentication attempt to be relayed to multiple targets, increasing the chances of successful exploitation.
When multi-relay is enabled, the attacking machine first accepts the authentication locally. The identity of the authenticating user is extracted and the client is then forced to reauthenticate, allowing the credentials to be relayed to one or more defined targets.
This behavior is enabled by default for HTTP and SMB relay servers, except when attacking a single general target. In such cases, multi-relay is disabled unless explicitly enabled. The feature can also be manually disabled using the --no-multirelay option.
Target Definition
Relay targets can be defined either as named targets or general targets:
A named target specifies the identity of the account expected to authenticate.
A general target does not specify any identity and accepts authentication attempts from any user.
Targets follow the general format: scheme://authority/path, where:
Scheme defines the protocol used for the relay. If not specified, SMB is used by default. The keyword
allcan be used to attempt relaying across all supported protocols.Authority specifies the identity and target host in the format
domain-name\username@host:portfor named targets.Path is optional and is mainly used in specific attack scenarios such as accessing restricted HTTP endpoints after relaying authentication.
The multi‑Relay behavior is influenced by the target type.
Single General Target
-t 172.1.117.5 or smb://172.1.117.5
Disabled
Single Named Target
-t smb://MARVEL\\PETER@172.1.117.5
Enabled
Multiple Targets
-tf relayTargets.txt
Enabled
For example:
smb://172.1.117.5defines a general target. In this configuration multi-relay is disabled and only the first captured NTLM authentication will be relayed. This results in a 1:1 relationship between the authentication attempt and the relay attack.smb://INLANEFREIGHT\\PETER@172.1.117.5defines a named target. Multi-relay is enabled and any authentication attempt belonging to the specified user can be relayed to the target host. This allows multiple authentication attempts to trigger multiple relay attacks.If general targets are placed inside a file and passed with the
-tfoption, multi-relay becomes enabled automatically.If a named target is defined but the attacker wishes to relay only the first captured authentication, the
--no-multirelayoption can be used to disable the feature.
SOCKS Support
The -socks option allows ntlmrelayx to retain successfully relayed authenticated sessions and expose them through a local SOCKS proxy. This enables attackers to interact with compromised services using external tools while reusing the authenticated session.
Once authentication attempts are successfully relayed, ntlmrelayx stores the active sessions and exposes them through its internal SOCKS proxy.
Multiple authenticated sessions may be stored simultaneously. When the SOCKS functionality is enabled, ntlmrelayx provides a small CLI interface that can be used to manage and inspect active sessions. The AdminStatus column indicates whether the authenticated user has administrative privileges on the target system.
SOCKS with Proxychains
The SOCKS proxy created by ntlmrelayx allows authenticated sessions to be reused with external tools by routing traffic through proxychains. The default SOCKS port used by ntlmrelayx is 1080, which must be configured in /etc/proxychains4.conf.
Once configured, Impacket tools can be executed through the SOCKS proxy to interact with the relayed sessions. For example, if the account MARVEL/BOB has administrative privileges on the relay target, remote command execution can be achieved. The -no-pass option prevents the tool from prompting for credentials because authentication is performed through the active SOCKS session maintained by ntlmrelayx.
Even if the relayed account does not have administrative privileges, the session can still be used for limited access operations, such as browsing file shares or reading accessible data. For example, MARIA can connect to the target system and enumerate shared folders.
Although these actions do not provide full system compromise, they can still lead to valuable information disclosure.
Interactive SMB Client Shells
ntlmrelayx also supports launching interactive SMB client shells for each authenticated session using the -i or --interactive option. In this mode, each successful relay spawns a local TCP listener that provides an SMB shell connected to the compromised target.
The shell can then be accessed locally using a tool such as netcat. This provides direct access to the SMB session established during the relay attack without requiring additional tooling.
Post Relay
Once the NTLM authentication exchange has been successfully relayed to a target system, the attacker can leverage the authenticated session established with the target server. At this stage, the attacker is effectively operating with the privileges of the victim account whose authentication was relayed. What actions are possible depends primarily on two factors: the privileges of the relayed user account and the protocol being targeted.
Cross-Protocol Attacks
NTLM relay attacks exploit the fact that NTLM authentication can be captured from one protocol and forwarded to another service. Since the NTLM authentication messages are embedded within multiple application protocols, an attacker can extract them from one protocol and reuse them in another. For example, a victim may authenticate to the attacker over HTTP, and the attacker can relay that authentication to SMB on a DC.
Relay attacks fail if the client requires session signing on the protocol used to authenticate to the attacker. Signing cryptographically binds the authentication to the original session, preventing it from being reused elsewhere.
ntlmrelayx supports multiple protocols both as a relay client and as a capture server.
HTTP(S)
HTTP(S)
No
HTTP(S)
IMAP / LDAP(S) / MSSQL / RPC / SMB / SMTP
Yes
SMB
SMB
No
SMB
HTTP(S) / IMAP / LDAP(S) / MSSQL / RPC / SMTP
Yes
WCF
HTTP(S) / IMAP / LDAP(S) / MSSQL / RPC / SMB / SMTP
Yes
Over MSSQL
In this scenario, the goal is to relay NTLM authentication to a Microsoft SQL Server (MSSQL) instance and interact with it through the relayed session.
For post-relay attacks against MSSQL,
ntlmrelayxmust be run asroot.Modern Windows systems prevent NTLM self-relay attacks. This means authentication originating from a host cannot be relayed back to the same host.
Typical setup:
A target host running MSSQL
An attacker capturing NTLM authentication
The authentication is relayed to MSSQL
The attacker interacts with the service through a SOCKS proxy
Over LDAP
Relaying NTLM authentication to LDAP on a DC via ntlmrelax automatically enable several high-impact attacks, including dumping domain info, adding a new DA, and escalating privilege via misconfigured ACLs/DACLs attacks. These can be explicitly disabled with the --no-da and --no-acl flags. The directory for the dump can be specified with the --lootdir option.
Domain Enumeration
The below error:
occurs when attempting to relay SMB NTLM authentication to LDAP on a DC.
SMB signing cryptographically binds authentication to the SMB session
Because of this binding, the authentication cannot be reused in another protocol such as LDAP
As a result, the relay fails. However, several vulnerabilities allow bypassing these protections by modifying NTLM messages:
Drop the MIC – CVE-2019-1040 (
--remove-mic)Drop the MIC 2 – CVE-2019-1166
Your Session Key is my Session Key – CVE-2019-1019 (
--remove-target)
These vulnerabilities allow attackers to remove integrity checks that prevent relaying. A scanner is available to test for CVE-2019-1040:
Unlike SMB, HTTP does not support session signing. Because of this, HTTP NTLM authentication can be relayed to LDAP, even when SMB-to-LDAP relay fails.
Computer Account Creation
ntlmrelayx can attempt to create a new machine account in AD. The NAME and PASSWORD values are optional, if they are not provided, they will be generated automatically.
Privilege Escalation via ACL Abuse
If the relayed account has sufficient privileges, ntlmrelayx may detect misconfigured ACLs/DACLs and automatically escalate privileges.
RBCD
The following attack chain abuses WebDAV + NTLM relay + Resource-Based Constrained Delegation (RBCD) to obtain administrator access on a target machine using Kerberos delegation.
The process works as follows:
Enable WebDAV on a target so it will authenticate over HTTP.
Poison and relay NTLM authentication to LDAP on the Domain Controller (DC).
Modify delegation attributes on the target machine account.
Use Kerberos S4U2Proxy to impersonate a privileged user.
Request a service ticket (TGS) as Administrator and execute commands on the target.
A .searchConnector-ms file is dropped on a writable share. When accessed, this forces the host to interact with a WebDAV server, which enables the WebClient service and allows authentication over HTTP.
ntlmrelayx is configured to relay captured authentication to LDAP over LDAPS on the DC.
--delegate-access→ configures RBCD--escalate-user→ allows the specified account to modify delegation attributes
This grants the attacker-controlled machine account delegation rights on SQL01$.
The PrinterBug attack forces the SQL01$ machine account to authenticate to the attacker over HTTP, the authentication is captured and relayed to LDAP.
Over HTTP
NTLM relay attacks against HTTP services can grant access to restricted web endpoints and allow attackers to perform actions as the authenticated user. Common attack targets include:
Active Directory Certificate Services (AD CS) web enrollment endpoints
Active Directory Federation Services (ADFS) login portals
Other NTLM-enabled web applications
After a successful relay, the attacker can access protected web resources or abuse the authenticated session to perform actions on behalf of the victim. Tools such as NTLMRecon can automate the discovery of NTLM-enabled HTTP endpoints that may be suitable relay targets.
NTLM over HTTP Protocol
The NTLM over HTTP protocol (MS-NTHT) defines how NTLM authentication occurs between a web client and a web server. The process follows a challenge-response exchange.
Initial Request: A client attempts to access a protected resource. At this stage, no authentication information (
Authorizationheader) is included.
Authentication Challenge: The server responds with an HTTP 401 Unauthorized status and indicates that NTLM authentication is required via the
WWW-Authenticateheader. This tells the client to begin the NTLM authentication process.
NTLM Negotiate Message: The web client retrieves the local user's credentials through the NTLMSSP security provider and sends a new request containing a base64-encoded NTLM NEGOTIATE message. This message informs the server of the authentication capabilities supported by the client.
NTLM Challenge Message: The server processes the negotiate message and responds with another 401 Unauthorized response containing a CHALLENGE message. The challenge includes a random value that the client must use to prove knowledge of the user's credentials.
NTLM Authenticate Message: The client processes the challenge and generates a response using the user's credentials. It then sends a final request containing the NTLM AUTHENTICATE message.
Successful Authentication: If the server validates the authentication message, it responds with a successful HTTP 2xx status code and returns the requested resource. This completes the authentication process.
Some HTTP clients (or tools) may not support NTLM authentication:
Proxy-Ez can act as an intermediary that handles multiple HTTP authentication schemes, including NTLM.
The NTLMParse utility from the ADFSRelay project can decode base64-encoded NTLM messages, allowing attackers to inspect the contents of NEGOTIATE, CHALLENGE, and AUTHENTICATE messages.
AD CS - Shadow Credentials
The Shadow Credentials (SC) attack abuses the msDS-KeyCredentialLink attribute to add alternative authentication credentials to an account. If an attacker has GenericAll or similar control over a user, several options exist:
Reset the password → Noisy and easily detected.
Dump and crack the NTLM hash → Opportunistic and potentially time-consuming.
Shadow Credentials → Add alternative authentication material to the account and request TGTs and NTLM authentication. This persistence remains even if the user changes their password.
This makes Shadow Credentials a stealthier and more persistent compromise technique.
ntlmrelayx relays captured authentication to LDAP and adds KeyCredential data to the target account (maria). This effectively registers a certificate-based authentication method for that user.
AD CS - ESC Attacks
AD CS supports several certificate enrollment methods, including HTTP-based enrollment, which allows users and machines to request certificates via a web interface.
One common attack path involves NTLM authentication relay. If NTLM authentication is captured from a victim system, it can be relayed to an AD CS web enrollment endpoint to request a certificate on behalf of that authenticated identity.
The Certification Authority (CA) web enrollment role service exposes several HTTP endpoints used for certificate requests. These endpoints are commonly accessible at:
If the endpoint accepts NTLM authentication, an attacker can relay captured NTLM credentials to the CA and request a certificate as the authenticated user or machine account. If successful, the attacker obtains a certificate that can be used to authenticate to the domain using Kerberos PKINIT, effectively impersonating the victim.
AD CS - ESC8
ESC8 refers to NTLM Relay to AD CS HTTP Endpoints. The environment must contain:
A vulnerable web enrollment endpoint
A certificate template allowing machine enrollment and client authentication (e.g.
Machine)
Unlike LDAP relay attacks which are often blocked by signing requirements, relaying NTLM over HTTP is still permitted, making the AD CS web enrollment interface a juicy target.
Even if Certipy flags a CA as vulnerable, administrators might disable NTLM authentication on the web endpoint, so we must confirm whether the endpoint actually accepts NTLM (NTLMRecon).
If the pre-requisites are met, then an attacker can compromise any computer running the spooler service as follows:
Coerce authentication from a machine account (
printerbug.py).Relay the NTLM authentication to the AD CS HTTP enrollment endpoint (
ntlmrelayx.py).Request a certificate using the relayed identity (
ntlmrelayx.py).Use the certificate for Kerberos authentication (
gettgtpkinit.py).Extract the machine NT hash (
getnthash.py).Forge a Silver Ticket (
ticketer.py).
The --template flag is optional; both ntlmrelayx and Certipy will default to the Machine or User templates based on whether the relayed account name ends with $ . However, relaying a DC's NTLM authentication requires specifying the DomainController template.
With the machine hash and domain SID, we can forge a Kerberos Silver Ticket.
ESC8 can be also performed with Certipy along with the PKINIT tools or ADCSKiller.
From here, we can continue the attack chain and forge a silver ticket with ticketer.py.
Over RPC
Remote Procedure Call (RPC) is a protocol that allows a program to execute procedures on a remote system as if they were local function calls. RPC enables a client to:
Send a request to a remote server
Specify the procedure to execute
Provide the required data
Receive the execution results
To ensure compatibility across platforms and languages, RPC interfaces are defined using an Interface Definition Language (IDL). IDL describes the functions and data structures that can be invoked remotely. Several technologies implement RPC-style communication, including DCE RPC, gRPC, Java RMI, CORBA, and DCOM.
Microsoft implements RPC through Remote Procedure Call Protocol Extensions (MS-RPCE). MS-RPCE extends the original DCE RPC specification by adding additional security mechanisms, introducing new capabilities, and enforcing stricter implementation requirements. One important feature of MS-RPCE is support for multiple authentication providers. For NTLM relay attacks, the important provider is RPC_C_AUTHN_WINNT.
RPC_C_AUTHN_NONE
0x00
No authentication
RPC_C_AUTHN_GSS_NEGOTIATE
0x09
SPNEGO
RPC_C_AUTHN_WINNT
0x0A
NTLM
RPC_C_AUTHN_GSS_SCHANNEL
0x0E
TLS
RPC_C_AUTHN_GSS_KERBEROS
0x10
Kerberos
RPC_C_AUTHN_NETLOGON
0x44
Netlogon
RPC_C_AUTHN_DEFAULT
0xFF
Defaults to NTLM
RPC also supports several authentication levels, which define how much protection is applied to RPC communications. If an RPC interface allows the level: RPC_C_AUTHN_LEVEL_CONNECT then NTLM authentication may only be verified during connection establishment without full message integrity protection. This weaker protection can allow NTLM relay attacks, because the authentication is not cryptographically bound to the RPC session. Higher authentication levels that enforce message integrity or encryption typically prevent relaying.
Only a small number of RPC protocols can realistically be abused for NTLM relay attacks, such as Task Scheduler Service Remoting Protocol (MS-TSCH) and ICertPassage Remote Protocol (MS-ICPR).
AD CS - ESC11
Similar to ESC8, ESC11 which relays authentication to the AD CS's RCP enrolment interface (MS-ICPR). Certificate enrollment requests (CERs) over ICPR are protected by default by this flag:
This flag determines whether certificate requests sent to the CA must be encrypted (signing requirement). If this flag is disabled, the CA will accept unencrypted certificate enrollment requests.
Starting with Windows Server 2012, the IF_ENFORCEENCRYPTICERTREQUEST flag is enabled by default.
This setting was introduced primarily to enforce secure certificate enrollment communications. One side effect is that legacy systems, such as Windows XP clients, cannot request certificates when the flag is enabled because they do not support encrypted certificate request sessions.
For this reason, some environments historically disabled the flag to maintain compatibility with older systems. However, doing so unintentionally exposes the CA to ESC11 attacks.
This misconfiguration makes it possible to:
Coerce SMB NTLM authentication from a victim system.
Relay the captured NTLM authentication to the CA’s ICPR RPC interface.
Establish an authenticated session with the CA.
Request a certificate on behalf of the authenticated machine or user.
Because certificate enrollment is performed within the authenticated session, the attacker effectively obtains a valid certificate for the victim identity. This certificate can then be used for Kerberos PKINIT authentication, enabling the attacker to obtain Kerberos tickets and potentially extract NT hashes or escalate privileges.
From this point onward, the attack chain continues the same way as ESC8, using certipy auth to extract the machine hash and escalate privileges.
NTLM Relay over MS-TSCH
ntlmrelayx supports relaying NTLM authentication to the MS-TSCH. If successful, this can allow an attacker to create scheduled tasks and achieve RCE. This technique has historically been used against Microsoft Exchange servers, where relayed authentication could allow attackers to execute arbitrary commands through the Task Scheduler service.
Over ALL
ntlmrelayx supports the all:// wildcard, which allows attackers to relay authentication attempts to all supported protocols on a target rather than specifying a single service. This approach increases the likelihood of a successful relay by attempting authentication against multiple services simultaneously.
Instead of specifying a single protocol (e.g., smb:// or ldap://), we can use the all:// scheme when defining relay targets.
Before running the attack, all servers in Responder must be disabled to prevent conflicts with ntlmrelayx, which will handle the relay process.
These authenticated sessions can be accessed using tools such as proxychains, smbclient, and mssqlclient. This allows attackers to interact with services using the relayed credentials without knowing the user's password.
NTLM Theft
When LLMNR, NBT-NS, and mDNS poisoning is not an option, NTLM hashes can be extracted via other protocols, such as file uploads via SMB or direct authentication via MSSQL. When extracted, they can either be used for Pass-the-Hash or NTLM relay attacks.
SMB File Uploads
The following techniques generally require WRITE access to an SMB share or directory. However, in some cases share permissions allow folder creation but not file creation, which may still be reported as WRITE access by tools such as NetExec, even though files cannot actually be written to the share.
Two common scenarios exist:
Full
WRITEaccess to the share – automation modules can be used.WRITEaccess only within a subdirectory of a readable share – files must be uploaded manually.
.url, .lnk, and .scf files can trigger NTLM authentication when a user browses a shared folder, as Windows Explorer attempts to retrieve the remote icon defined in the file. However, .scf files may be less reliable on modern Windows systems due to changes in Explorer behavior and endpoint protections. In contrast, .sc files typically require user interaction or execution to trigger authentication.
File Types
A Shell Command File (.scf) is a Windows configuration file used by Explorer to execute basic shell commands. These files can define a remote icon location, causing Windows to attempt authentication to the specified network resource when the folder is viewed.
If a share is locally mounted and WRITE access exists only in a subdirectory, the file can be copied directly:
A Windows Shortcut (.lnk) file points to another file, folder, or program. When Explorer attempts to display the shortcut icon, Windows may attempt to retrieve the icon from a remote location. This remote icon retrieval triggers an NTLM authentication request to the attacker-controlled host.
Placing the @ character at the beginning of the .lnk filename, e.g. @myfile, causes the file to appear at the top of the directory listing in Windows Explorer. This increases the likelihood that the icon is processed immediately when a user browses the share, triggering the remote icon retrieval and the corresponding NTLM authentication attempt.
A Service Configuration (SC) file is used to define Windows services and their configuration parameters. When used in NTLM theft scenarios, it can reference remote network paths, causing authentication attempts. This method is similar to the LNK technique but requires escaping the network path:
A Windows Internet Shortcut (.url) file links to a web or network resource. While not executable, it can specify a remote icon location.
Tools
ntml_theft is a tool used to generate multiple file types that can trigger NTLM authentication attempts when accessed by a Windows system. These files reference attacker-controlled network resources, causing the victim machine to automatically attempt authentication and leak NTLM hashes. The tool can generate 21 different file formats commonly used for NTLM hash theft, including .scf, .lnk, and .url.
NetExec has modules for automating the creation and upload process.
WebDAV
Web Distributed Authoring and Versioning (WebDAV) is an extension of HTTP that allows remote file management operations such as creating, copying, moving, and deleting files. In Windows environments, the WebClient service enables WebDAV functionality and allows systems to access files hosted over HTTP using UNC-style paths.
The WebClient service is enabled by default on Windows workstations, but is typically disabled on Windows servers.
Hosts where the WebClient service is enabled can be identified using NetExec. It is important to note that while the service may be enabled, it is not always actively running on the system.
The WebClient service can often be started by placing a Windows Search Connector (.searchConnector-ms) file on an accessible SMB share.
Search connector files are used to integrate Windows Search with remote web services or data sources. When a user accesses the file, Windows may attempt to connect to the referenced resource, which can cause the WebClient service to start automatically.
Example search connector file:
Once the file is accessed, the WebClient service may start automatically.
After the WebClient service is running, it becomes possible to coerce the system into performing HTTP-based NTLM authentication. This can be achieved by referencing a WebDAV UNC path within a malicious file. For example, a .lnk file can reference a specially crafted path such as:
This forces Windows to attempt authentication to the specified host over HTTP.
Coercive Authentication
Authentication coercion techniques abuse the fact that Windows systems automatically authenticate to remote hosts when accessing UNC paths (e.g., \\172.16.117.30\file.txt). By triggering specific RPC methods, an attacker can force a target system to authenticate to an attacker-controlled machine, allowing the credentials to be captured or relayed.
Typical process:
Authenticate to a remote system using valid domain credentials, typically, over SMB). HTTP-based authentication can be coerced by enabling the WebClient (WebDAV) service and forcing the system to access a WebDAV path.
Access an SMB named pipe such as
\PIPE\netdfs,\PIPE\efsrpc,\PIPE\lsarpc, or\PIPE\lsass.Bind to the corresponding RPC interface and invoke a method that forces the target to authenticate to an attacker-controlled listener.
PrinterBug
PrinterBug abuses the Print System Remote Protocol (MS-RPRN) used by the Print Spooler service, which runs by default on most Windows systems. Several tools implement this technique, such as NXC's coerce_plus module, printerbug.py, MSRPRN-coerce (Python), and SpoolSample (C#).
PetitPotam
PetitPotam abuses methods in the Encrypting File System Remote Protocol (MS-EFSR), more specifically, EfsRpcOpenFileRaw and EfsRpcEncryptFileSrv. Originally, this attack allowed authentication coercion without valid credentials. However, this was patched in CVE-2021-36942, and modern environments typically require valid credentials.
DFSCoerce
DFSCoerce abuses the Distributed File System Namespace Management Protocol (MS-DFSNM) through the following RPC methods: NetrDfsAddStdRoot and NetrDfsRemoveStdRoot. Unlike some other coercion techniques, DFSCoerce does not support HTTP coercion.
Coercer
Searching for RPC Functions to Coerce Authentications in Microsoft Protocols
Coercer is a tool that automates authentication coercion across multiple RPC protocols, supporting 17 different coercion methods.
The scan mode identifies RPC methods capable of triggering authentication.
The coerce mode triggers the authentication for NTLM extraction or relay.
Manual Exploitation
Instead of relying on automated tools, coercion can be performed manually using individual RPC proof-of-concept scripts from the windows-coerced-authentication-methods repository. For example, to abuse the NetrDfsAddStdRoot method of MS-DFSNM:
Other Authentication Coercion Techniques
Additional coercion methods include:
These techniques rely on similar principles, abusing Windows protocols to force systems to authenticate to attacker-controlled hosts.
Coercion via Ligolo
When the relay server runs on the attacker host, to receive the coerced connection, a listener needs to be added for the target port, and the agent must be run with elevated privileges on the pivot host.
Direct Authentication
We can force direct authentication from a compromised host by connecting to an attacker-controller SMB server.
MSSQL
If we gain access to a MSSQL service, we can coerce auth from the account running the service which by default is the computer account.
Web Server Uploads
If we haven't achieved RCE, we could check for a file upload form in a web application on a Windows server and enter a non-existing file with a UNC path such as
If the web application supports SMB uploads, the Windows server will authenticate to our SMB server. The UNC Path Interpretation works as follows:
Powershell interprets UNC paths directly:
\\server\share.Web requests interpret UNC paths according to the programming language used. Most of them treat
\as an escape character, thus, it needs to be doubled in order to make it a literal:\\\\server\\share.
BadPDF
If a file upload functionality is present, we can create and upload a malicious PDF file and force SMB authentication to our attacking machine. See more in: File Uploads → PDFs.
Last updated