A targeted espionage campaign exploiting a zero-day vulnerability in Windows' WebDAV component has reignited calls for users to disable unnecessary built-in services. The Stealth Falcon group, uncovered in June 2025, chained CVE-2025-33053 with legitimate Windows binaries to execute remote code—all because an obscure file-sharing feature was left running. Now a practical hardening guide, verified against both recent intelligence and historical Microsoft advisories, lists five commonly unneeded capabilities that every Windows user should consider turning off.

Every extra Windows component increases complexity and potential vulnerability. Services that listen on network ports, run with high privileges, or process remote content are especially dangerous. Disabling them follows simple logic: minimize the code running on a device and close off attacker entry points. Microsoft itself has recommended this approach as an emergency workaround when critical flaws emerge—most notably for the WebClient service in MS10-045, a 2010 Outlook remote code execution bug that returned to relevance with the 2025 WebDAV zero-day.

1. Stop Windows from Auto-Connecting to Public Wi‑Fi

Windows remembers every network you connect to and can silently rejoin them whenever in range. That convenience opens the door to Evil Twin and man-in-the-middle attacks—an attacker spoofs a previously trusted SSID, and your machine may link up before VPNs or endpoint protections activate, exposing credentials and traffic.

How to disable it
- Go to Settings → Network & internet → Wi‑Fi → Manage known networks.
- Select a network, click Edit (or Properties), then toggle Connect automatically when in range off.
- For command-line automation: netsh wlan set profileparameter name="<ProfileName>" connectionmode=manual replaces <ProfileName> with the saved profile name.

Pros: Prevents silent reconnection to untrusted hotspots. Low-risk change with immediate security gains.
Cons: You must manually connect to trusted networks. Slightly less convenience for road warriors.

If you rely on many ephemeral hotspots, keep auto-connect enabled only for home and workplace SSIDs and forget public networks after use. Combining this with automatic VPN policies further hardens the device.

2. Disable the WebClient (WebDAV) Service

WebClient is the built-in Windows sub‑system that lets you access remote WebDAV shares like a local drive. When enabled, it can process attacker-controlled remote content—a fact that Microsoft highlighted in MS10-045 and reinforced in MS11-073, advising users to turn it off as a mitigation.

The 2025 Stealth Falcon campaign showed just how dangerous WebDAV remains. Attackers weaponized a crafted .url shortcut that set a remote WebDAV working directory, tricking Windows into executing malicious binaries hosted on a remote server. The zero-day (CVE-2025-33053) allowed code execution without the victim directly launching an .exe, using the trusted WebDAV redirector to bypass common defences.

How to disable WebClient
Open Services (type services.msc in the Start menu), locate WebClient, right‑click → Properties. Click Stop (if running), then set Startup type to Disabled. Reboot to ensure the change takes effect.
Re‑enable by reversing these steps and setting Startup type back to Automatic or Manual.

Pros: Eliminates a proven remote‑code‑execution vector. Simple, reversible, low‑impact for users who do not use WebDAV.
Cons: Breaks legitimate WebDAV access and any app that depends on the service (e.g., mapped WebDAV drives, certain collaboration tools). May trigger System log errors for dependent services.

In enterprise settings, if WebDAV must remain available, restrict it to internal trusted hosts via network controls and block outbound WebDAV to the internet. As an emergency measure, disabling WebClient is a Microsoft‑accepted workaround while patches are being tested.

3. Turn Off the Print Spooler Service

Print Spooler runs with high privileges and has a long history of critical vulnerabilities, grouped under the “PrintNightmare” cluster. Because it handles remote printer driver installation and network print jobs, it exposes a broad attack surface. Microsoft, along with security vendors, repeatedly recommended disabling the service outright when zero-day exploits were in the wild.

How to disable Print Spooler
Option A – Services GUI: Open services.msc, find Print Spooler, right‑click → Properties. Click Stop, set Startup type to Disabled.
Option B – PowerShell (scriptable): 

Stop-Service -Name Spooler -Force
Set-Service -Name Spooler -StartupType Disabled

To re‑enable: Set-Service -Name Spooler -StartupType Automatic followed by Start-Service -Name Spooler.

Pros: Removes a high‑privilege local attack surface. Simple to script across machines where printing is not required.
Cons: Stops all local and network printing. Can disrupt workflows that depend on printers—assess dependencies before wide deployment.

For organizations that must retain printing, use Group Policy to block inbound spooler client connections on servers (while allowing local printing), isolate print servers on secure VLANs, and enforce strict authentication for driver installation. Domain controllers are prime candidates for having the spooler disabled entirely.

4. Toggle Off Network Discovery

Network Discovery makes your PC visible on local networks and lets you discover other devices for file and printer sharing. On untrusted or public networks, this visibility increases the chance an attacker will find exposed services. For laptop and tablet users who rarely share local resources, turning it off is a net security improvement.

How to disable Network Discovery
Go to Settings → Network & internet → Advanced network settings → Advanced sharing settings. Under the active profile (Private, Guest, or Public), set Network discovery to Off. Alternatively, use Control Panel → Network and Sharing Center → Change advanced sharing settings.

Pros: Reduces visibility on local networks. Prevents accidental exposure of file/print sharing.
Cons: Disables quick discovery of printers, NAS devices, or local file shares. Temporary re‑enable when needed.

5. Disable Windows Script Host (WSH)

Windows Script Host executes .vbs and .js files and is a common infection vector for phishing and ransomware. Attackers embed malicious VBScript or JScript in attachments, and WSH provides an easy launch point. Security vendors routinely recommend disabling WSH unless your environment explicitly requires legacy script automation.

How to disable WSH via the registry (always back up the registry first)
Open Registry Editor and navigate to:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Script Host\Settings
(On 64‑bit systems, also check HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows Script Host\Settings)
Create a new DWORD (32‑bit) named Enabled and set its value to 0. For per‑user blocking, replicate the key under HKEY_CURRENT_USER.
To re‑enable, delete the Enabled value or set it to 1. Test by trying to run a .vbs or .js file—Windows will show “Windows Script Host access is disabled.”

Pros: Blocks a common, easy script‑based infection vector. Straightforward to deploy via Group Policy or Intune.
Cons: Breaks legitimate local scripts, installers, or automation tools that depend on WSH. Does not block Office macros; macro security must be handled separately.

Deployment Guidance: Test, Roll Out, and Monitor

Hardening must be thoughtful, not haphazard. For each change, inventory dependencies first—scan for services, scheduled tasks, and applications that rely on the feature. Test on a small set of non‑critical machines to ensure users don’t lose crucial capability. Use management tooling like Group Policy, PowerShell DSC, or Intune for consistent rollout and fast rollback. Monitor logs and helpdesk tickets for unexpected breakages, and create a short‑term exception process for legitimate needs.

Lessons from the Stealth Falcon Campaign

The June 2025 Stealth Falcon intrusion is a textbook example of why unused subsystems matter. Attackers combined a WebDAV‑related zero‑day (CVE-2025-33053) with living‑off‑the‑land binaries to bypass detection and implant spyware—all because WebClient was left active on targeted machines. The chain underscores four principles:
- Rarely used features can become critical escalation points when chained with other techniques.
- Emergency mitigations like disabling WebClient are practical stopgaps while patches are developed.
- Microsoft has a long history of advising service shutdowns as workarounds (e.g., MS10-045, PrintNightmare).
- Layered defenses—feature reduction, prompt patching, endpoint detection, and network segmentation—must work together.

For individuals and small businesses that do not require shared printing, WebDAV mounts, or legacy VBScript automation, this baseline is sensible:
- Disable auto‑connect for public/untrusted Wi‑Fi networks.
- Disable WebClient (WebDAV) if you don’t use mapped WebDAV drives.
- Disable Print Spooler on machines that never print (or use Group Policy to block inbound client connections).
- Turn off Network Discovery on public network profiles.
- Consider disabling Windows Script Host unless VBScript/JScript is actively required.

Keep Windows Update active, maintain up‑to‑date antimalware, and back up important data. Hardening reduces the attack surface, but it cannot replace a full security stack.

Final Thoughts — Hardening with Context

Disabling unused Windows features is a high‑leverage, low‑cost way to reduce risk. The changes are often small but compound: remove one service, close one port, and you eliminate an entire class of attacks. Recent weaponized attacks that abuse benign functionality—like the Stealth Falcon WebDAV chain—prove that even legacy or low‑use functionality can be an active threat vector. Apply restrictions thoughtfully, document exceptions, and use compensating controls when a feature must stay. Security is a layered process: reduce the surface where possible, patch swiftly, monitor actively, and build reversibility into every change. When convenience and compatibility are essential, don’t open the door wide; instead, segment, apply least privilege, and enforce allow‑listing. As attackers grow more adept at chaining legitimate tools into attack paths, the best defence is often the simplest—turn off what you don’t need.