Hard_Configurator - Windows Hardening Configurator

[Victor M]

When you run Control Panel via the system shortcut, it is opened by Explorer as a shell folder (control.exe and rundll32.exe are skippepassd).

i don't understand. In my imolementation with WDAC, i blocked rundll32. And the control panel applets were blocked. Wen I unlbock rundll32, the conotrol panel applets works. So why didn't you place rundll32 into your list of sponsers lolbins? Sorry if I am being pig headed. Or did you designed your app this way so that using Cotnrol Panel desktop shortcut to access those CPL will bypass rundlll32, in other words its a feature ? If it is a secret sauce feature just say so and then I won;t ask.

 

[Andy Ful]

So why didn't you place rundll32 into your list of sponsers lolbins?

It is unnecessary to block RunDLL32 while using H_C. The attacks via CPL files are rare and already well blocked by H_C.
Other attacks (executing DLLs) are mainly prevented by script restrictions, and if necessary, they can be more conveniently covered via FirewallHardening or MD ASR rule.
Blocking RunDLL32 in H_C would also trigger too many false positives.

Post edited.

 

[Victor M]

@Andy Ful Thanks

 

[rashmi]

If it is a secret sauce feature just say so and then I won;t ask.

It is why I like @Andy Ful's tools over my preferred Comodo; the design has a layered approach with strong security and usability, which I've mentioned in multiple threads here. I also recommend that most users use Configure Defender/Microsoft Defender and Firewall Hardening/Microsoft Firewall instead of third-party options to maintain the synergy of the layered design; for instance, if Software Restriction Policies (SRP) are slightly relaxed, ASR rules or Firewall Hardening will intervene to neutralize the threat or infection chain—you get the idea. For home users, @Andy Ful's tools are all you need—IMHO!

 

[Sampei.Nihira]

@Andy Ful

What do you think?

Security News - Hackers Abuse Windows File Explorer and WebDAV for Stealthy Malware Delivery

 

[Andy Ful]

@Andy Ful

What do you think?

Security News - Hackers Abuse Windows File Explorer and WebDAV for Stealthy Malware Delivery

When abusing Windows File Explorer and WebDAV, the outbound connection is triggered by Explorer. This can be mitigated by blocking outbound connections of Explorer (like in FirewallHardening). A similar situation is when using scripts.
On Windows Home/Pro, the attacks targeted at enterprises will fail because the WebClient service is stopped. However, when home users are targets, the service can be restarted with Admin rights before using WebDAV.

Update.
The important role of blocking outbound connections in the WebDAV attack is explained here:

Post in thread 'Hard_Configurator - Windows Hardening Configurator'

Feb 28, 2026

Component	Role in the Chain
explorer.exe	User initiates a request (e.g., clicking a link or typing a UNC path or clicking a LNK file with a UNC path in the command line).
MPR.dll	Determines which Network Provider (RDP, SMB, WebDAV) should handle the request.
Web Client Provider	Recognizes the path as a WebDAV request and signals the service (in the malicious WebDAV campaign).
svchost.exe	The WebClient Service executes...

• Andy Ful

• 
• 
• 

 

[Sampei.Nihira]

When abusing Windows File Explorer and WebDAV, the outbound connection is triggered by Explorer. This can be mitigated by blocking outbound connections of Explorer (like in FirewallHardening). A similar situation is when using scripts.
On Windows Home/Pro, the attacks targeted at enterprises will fail because the WebClient service is stopped. However, when home users are targets, the service can be restarted with Admin rights before using WebDAV.

Thank you for your reply.
Yes, considering that I use a Standard Account on a daily basis, I am in a privileged position.
However, I will leave the blocking rule I wrote anyway... it can't hurt.

 

[ForgottenSeer 123960]

When abusing Windows File Explorer and WebDAV, the outbound connection is triggered by Explorer. This can be mitigated by blocking outbound connections of Explorer (like in FirewallHardening). A similar situation is when using scripts.
On Windows Home/Pro, the attacks targeted at enterprises will fail because the WebClient service is stopped. However, when home users are targets, the service can be restarted with Admin rights before using WebDAV.

The WebClient service is set to Manual (Trigger Start) across Home, Pro, and Enterprise editions. Being "stopped" at boot is irrelevant; the OS will dynamically start the service the millisecond it detects a WebDAV UNC path.

The Trigger-Start mechanism is an OS-level function designed to be seamless for standard users. Zero Admin rights are required for the service to wake up and execute the payload connection.

While explorer.exe initiates the file request, it hands the UNC path off to the Multiple Provider Router (MPR). The MPR passes it to the Web Client Network Provider, which instructs the WebClient service to fetch the file. The actual outbound HTTP/HTTPS connection is executed by svchost.exe (specifically the instance hosting the LocalService network group). Blocking explorer.exe at the firewall does nothing to stop WebDAV.

*****************************

Proof that explorer.exe hands off the connection and does not execute the network request itself.

Multiple Provider Router (MPR) Architecture

Proof that standard users interacting with a file will automatically "wake up" the service, requiring zero Admin rights.

Service Trigger Events (Service Control Manager

Proof that the WebClient service operates as the WebDAV redirector handling these specific UNC paths.

WebClient Service (WebDAV Mini-Redirector)

 

[ForgottenSeer 114717]

Component	Role in the Chain
explorer.exe	User initiates a request (e.g., clicking a link or typing a UNC path or clicking a LNK file with a UNC path in the command line).
MPR.dll	Determines which Network Provider (RDP, SMB, WebDAV) should handle the request.
Web Client Provider	Recognizes the path as a WebDAV request and signals the service (in the malicious WebDAV campaign).
svchost.exe	The WebClient Service executes the actual outbound HTTP/HTTPS GET/PROPFIND.
Firewall	Sees traffic originating from System/Service PID, not Explorer.

 

[Andy Ful]

Component	Role in the Chain
explorer.exe	User initiates a request (e.g., clicking a link or typing a UNC path or clicking a LNK file with a UNC path in the command line).
MPR.dll	Determines which Network Provider (RDP, SMB, WebDAV) should handle the request.
Web Client Provider	Recognizes the path as a WebDAV request and signals the service (in the malicious WebDAV campaign).
svchost.exe	The WebClient Service executes the actual outbound HTTP/HTTPS GET/PROPFIND.
Firewall	Sees traffic originating from System/Service PID, not Explorer.

The behavior of WebDAV is more complex.
When FirewallHardening blocks outbound connections of Explorer, I get the error while opening the UNC path "\\live.sysinternals.com\tools" in Explorer:

Event[1]:
Local Time: 2026/03/01 02:38:55
ProcessID: 8984
Application: C:\windows\explorer.exe
Direction: Outbound
SourceAddress: xxxxxxxxxx
SourcePort: 54972
DestAddress: 74.242.189.11
DestPort: 80
Protocol: 6
InterfaceIndex: 19
(...)

It is easy to check that Explorer tried to make an outbound connection to Sysinternals tools (DestAddress: 74.242.189.11), and the Explorer outbound connection via port 80 (HTTP) was blocked. The WebClient service remains stopped.

When I use PowerShell with the UNC path "\\live.sysinternals.com\tools", the connection to the same server is blocked by FirewallHardening, but the port 443 (HTTPS) is used:

Event[1]:
Local Time: 2026/03/01 03:17:55
ProcessID: 9296
Application: C:\windows\system32\windowspowershell\v1.0\powershell.exe
Direction: Outbound
SourceAddress: xxxxxxxx
SourcePort: 59819
DestAddress: 74.242.189.11
DestPort: 443
Protocol: 6
InterfaceIndex: 19

If I remove Explorer from the BlockList, WebDAV works, and the WebClient starts running.
If I manually start the WebCient service, WebDav works even when Explorer is blocked in FirewallHardening.

 

[ForgottenSeer 123960]

The behavior of WebDAV is more complex.
When FirewallHardening blocks outbound connections of Explorer, I get the error while opening the UNC path "\\live.sysinternals.com\tools" in Explorer:

View attachment 296049



It is easy to check that Explorer tried to make an outbound connection to Sysinternals tools (DestAddress: 74.242.189.11), and the Explorer outbound connection via port 80 (HTTP) was blocked. The WebClient service remains stopped.

When I use PowerShell with the UNC path "\\live.sysinternals.com\tools", the connection to the same server is blocked by FirewallHardening, but the port 443 (HTTPS) is used:


If I remove Explorer from the BlockList, WebDAV works, and the WebClient starts running.
If I manually start the WebCient service, WebDav works even when Explorer is blocked in FirewallHardening.

Your experiment inadvertently proves our architectural baseline. Your explicit telemetry ("WebDav works even when Explorer is blocked") mathematically confirms that svchost.exe handles the actual WebDAV network connection, not explorer.exe.

The initial block you observed was merely the firewall halting Explorer's preliminary "Path Discovery" probe. Threat actors delivering crafted .url files bypass this probe entirely by feeding strict, pre-resolved UNC paths (using \DavWWWRoot\) directly into the OS shell, triggering the payload execution regardless of Explorer's outbound firewall status.

 

[Andy Ful]

WebDAV domain request is also blocked when using the default-deny domain filtering system-wide (outside the web browser).

 

[ForgottenSeer 123960]

WebDAV domain request is also blocked when using the default-deny domain filtering system-wide (outside the web browser).

While technically accurate, operating a true "default-deny" domain filter is notoriously difficult and operationally heavy, particularly for home users, as it breaks standard internet functionality.

 

[piquiteco]

@Andy Ful Is everything okay with you? Are you using any third-party antivirus software?

 

[Andy Ful]

@Andy Ful Is everything okay with you? Are you using any third-party antivirus software?

Thanks, I am OK.
I use/test many security solutions.

 

[Andy Ful]

It is worth noting that in the H_C Recommended settings, abusing Explorer by using UNC WebDAV paths is mainly covered by SRP, just like in the case of standard local paths. Furthermore, the <Forced SmartScreen> feature works as usual and prevents WebDAV from bypassing MotW.

However, FirewallHardening restrictions can still be recommended when EXE/MSI files are allowed. Files downloaded/executed from WebDAV do not have MotW, so SmartScreen does not check them. One has to remember to use on-demand Run By SmartScreen or add Explorer to the FirewallHardening BlockList. At home, WebDAV attacks are rare, so Explorer is not on the Recommended H_C BlockList in FirewallHardening (it is included in the LOLBins BlockList).
A simple prevention is also to disable the WebClient service.
The WebDAV attacks can be efficiently mitigated by using Microsoft Defender with ConfigureDefender MAX settings.

In WHHLight, WebDAV is also fully covered by WDAC.

Post edited and updated.

 

[ForgottenSeer 123960]

It is worth noting that in the H_C Recommended settings, abusing Explorer by using UNC WebDAV paths is mainly covered by SRP, just like in the case on standard local paths. Furthermore, the <Forced SmartScreen> feature works as usual and prvents WebDAV from bypassing MotW.

View attachment 296073

However, FirewallHardening restrictions can still be required when Explorer is a default application that opens archives, disk images, and URL files (Internet Shortcuts). In those cases Windows uses handlers that can bypass SRP and blocking outbound connections of Explorer is necessary (Install By SmartScreen / Run By SmartScreen are not bypassed even without FirewallHardening).
At home, the attacks via WebDAV are rare, so in FirewallHardening the Explorer is not on the Recommended H_C BlockList (it is included in the LOLBins BlockList).

In WHHLight, WebDAV is covered by WDAC or via FirewallHardening restrictions.

This is technically contradictory to OS design. When Windows mounts a WebDAV share via a UNC path, the Internet.cpl (Internet Options) security zones engine classifies it as Intranet. Files executed from the Intranet Zone do not receive a Zone.Identifier Alternate Data Stream (MotW). Without MotW, SmartScreen is not invoked.

Your claim "handlers that can bypass SRP and blocking outbound connections of Explorer is necessary" when dealing with .url files. This repeats the previous network routing error. When a .url file is executed, the shell handler reads the URL=file://\\malicious\share string and passes it to the Multiple Provider Router (MPR). The MPR hands it to the WebClient service. The outbound TCP 80/443 connection is executed by svchost.exe, not explorer.exe. Therefore, the Explorer firewall block remains useless.