Auditing the WebClient Service: WebDAV Coercion and the SearchConnector Trap

Most coercion hardening advice stops at SMB. Teams disable NTLM over SMB, enforce signing, and assume authentication coercion is handled. But there is a second, quieter transport that changes the entire threat model: WebDAV over HTTP, driven by the built-in WebClient service. When WebClient is running, a UNC path like \\attacker@80\share is silently resolved over HTTP, and the machine leaks its NTLM credentials to an endpoint the attacker controls — outside the SMB namespace, often outside SMB-focused detections, and frequently through egress that firewalls allow because it looks like ordinary web traffic.

Why WebDAV coercion is worse than SMB coercion

SMB coercion (PetitPotam, PrinterBug, and friends) is well understood and increasingly mitigated. WebDAV coercion inherits every one of those coercion primitives but adds three properties that make it far more dangerous in practice:

• It authenticates. SMB coercion to a remote host that isn't in the local intranet zone often falls back to anonymous. WebDAV, by contrast, will happily send NTLM to arbitrary hosts, and can even be pushed to send Kerberos in some configurations.
• It crosses network boundaries. WebDAV rides HTTP/HTTPS on ports 80/443, so coerced authentication can leave a segment that blocks outbound SMB (445) entirely. Your egress rules probably permit 80/443.
• It enables relay to protocols SMB can't reach. A relayed WebDAV auth is the classic front half of relay-to-AD CS (ESC8) and relay-to-LDAP for shadow-credential and RBCD attacks — turning one coerced machine account into domain-wide escalation.

The SearchConnector trap

The subtle part is triggering WebClient without admin rights. On many systems the service is set to Manual (Trigger Start), so it isn't running until something touches a WebDAV path. Attackers weaponize file formats that Explorer parses automatically — most notably .searchConnector-ms and .library-ms files, plus .url, .lnk, and desktop.ini entries pointing at a remote WebDAV URL. Drop one of these in a share, a Downloads folder, or an email attachment, and simply browsing the folder starts WebClient and coerces authentication. No macro, no execution, no user click beyond opening a directory.

The dangerous default isn't "WebClient is running." It's "WebClient can be started on demand by any file a low-privileged user can drop." Trigger-start is the vulnerability.

Auditing your fleet

The first question for every endpoint is simple: is WebClient present, and can it be triggered? Check the service state and start type:

Get-Service WebClient | Select-Object Name, Status, StartType

# Trigger-start config (Manual + a trigger = on-demand exposure)
sc.exe qtriggerinfo WebClient
sc.exe qc WebClient

WebClient ships with the WebDAV Redirector feature (part of "WebDAV" / Desktop Experience). On servers it is usually absent; on workstations it is commonly installed. Confirm the feature and its registry surface:

Get-WindowsOptionalFeature -Online -FeatureName WebDAV-Redirector `
  | Select-Object FeatureName, State

# Redirector policy knobs
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\WebClient\Parameters' `
  -ErrorAction SilentlyContinue

Two Parameters values matter most: BasicAuthLevel (should be 0 or 1 — never 2, which permits Basic auth over cleartext HTTP) and SupportLocking. Even with WebClient hardened, verify NTLM sending is restricted at the network layer via Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers, so a coerced auth to an off-box host is blocked before it leaves.

Remediation that actually holds

For the vast majority of endpoints, WebDAV is a legacy convenience, not a requirement. The durable fixes, in order of preference:

1. Disable and de-trigger the service. Set WebClient to Disabled. A disabled service cannot be trigger-started, which closes the SearchConnector path entirely: Set-Service WebClient -StartupType Disabled; Stop-Service WebClient -Force.
2. Remove the redirector feature where WebDAV is genuinely unused, so the surface can't be re-enabled by a local admin foothold.
3. If WebDAV is required (some line-of-business or SharePoint-mapped-drive workflows need it), restrict outbound NTLM, set BasicAuthLevel to 1, and pin the allowed server list so the redirector won't authenticate to arbitrary hosts.
4. Enforce EPA and channel binding on relay targets (AD CS web enrollment, LDAP signing/channel binding) so even a leaked credential can't be relayed.

Where WinSentinel fits

WebDAV coercion is exactly the kind of finding that hides between checklists: it's not an SMB setting, not a firewall rule, not a single GPO, but the intersection of a service start type, an optional feature, and an NTLM policy. WinSentinel audits all three on the local machine as part of its coercion and NTLM-exposure checks — every module, no gating, on your own box for free. It flags WebClient that is enabled or trigger-startable, reports BasicAuthLevel and outgoing-NTLM policy, and maps the finding to the relay techniques it feeds so you understand the blast radius, not just the setting.

For organizations, the fleet story is where this becomes tractable: the Pro central node rolls WebClient posture up across every enrolled machine, so you can answer "which of my 200 endpoints can still be coerced over WebDAV?" in one view, watch for drift when a Windows feature update or a re-imaged laptop quietly re-enables the redirector, and dispatch the disable-and-de-trigger remediation as a policy rather than a per-machine chore. Coercion resistance isn't a one-time hardening pass — it's a posture you have to keep enforced as machines churn.

Audit the transport attackers hope you forgot. If WebClient can be trigger-started anywhere in your estate, treat it as a live NTLM leak and shut the door before someone relays it.