Security Investigation · 14 min read

The Ghost Service: Investigating WinRM Running on a Machine That Never Asked For It

WinRM was running on Automatic startup, had received 8 requests, and had two HTTP.sys URL reservations — but had no listener configured and no open ports. A deep investigation into what was happening, why, and how to close the attack surface for good.

Published by PrivWarden Team.

A Service Nobody Turned On

Most security problems announce themselves. A strange process in Task Manager, an unexpected network connection, an antivirus alert. WinRM — Windows Remote Management — announced itself more quietly. It was simply there, running, set to start automatically on every boot, with two HTTP.sys URL reservations and a counter showing it had received eight requests. No one had deliberately enabled it. No one was using it. And yet there it was, listening.

This is the story of a security investigation into a service that had no business running, what we found when we dug into it, and what it reveals about the hidden complexity of a modern Windows installation.

What WinRM Actually Is

Windows Remote Management is Microsoft's implementation of the WS-Management protocol — a SOAP-based standard for remotely managing hardware and software. In practical terms, it's the service that lets you run PowerShell commands on a remote machine, manage servers from a central location, or automate administrative tasks across a network. It's an essential tool in enterprise environments. On a personal gaming and streaming PC, it has no legitimate purpose.

The service binds to port 5985 for HTTP and port 5986 for HTTPS. There's also a legacy port, 47001, that appears in some configurations. When WinRM is fully configured with a listener, these ports accept inbound connections and allow remote code execution — with appropriate authentication. Without a listener, the service starts but cannot accept connections.

This distinction — running without a listener — is what made the investigation interesting.

The Initial Evidence

The investigation began with a routine service audit. Running winrm get winrm/config returned an error immediately: Windows Script Host was disabled on the machine, which blocked the underlying CScript engine that the WinRM command-line tools depend on. This was actually a good sign — disabling Windows Script Host is a meaningful hardening measure that prevents many script-based attacks. But it also meant the standard WinRM diagnostic tools couldn't run.

Netstat showed nothing on ports 5985, 5986, or 47001. No open sockets, no listening processes. The service was running, but it wasn't bound to any interface.

The Windows event log told a more detailed story. At boot time — 08:28:14 on the day of the investigation — WinRM started automatically and HTTP.sys registered two URL reservations:

These reservations tell HTTP.sys to route incoming requests on those ports to the WinRM service. But without an active listener, WinRM wasn't actually accepting those connections. The URL reservations were placeholders — infrastructure that existed but wasn't being used.

The counter showing eight received requests was the most puzzling data point. If there was no listener and no open port, how had WinRM received any requests at all? The answer, once we traced the event log carefully, was that those requests came from the machine itself — from a previous PrivacyWarden audit session that had attempted to enumerate WinRM's configuration. The requests were local, not remote, and they had all failed with error code 2150858770: ERROR_WINRM_NO_LISTENER.

The HTTP.sys Reservation Problem

Even though WinRM wasn't accepting connections, the HTTP.sys URL reservations represent a real attack surface that's easy to overlook. HTTP.sys is a kernel-mode driver that handles HTTP traffic before it reaches any user-mode application. When a URL is reserved in HTTP.sys, that reservation persists even if the application that registered it isn't running. It's a low-level hook into the network stack.

The WinRM reservations on ports 5985 and 47001 mean that if anything ever starts a listener on those ports — whether that's WinRM itself after a configuration change, or malware that knows to use the existing reservation — the traffic will be routed correctly without any additional setup. The reservation does some of the attacker's work for them.

The event log also revealed other HTTP.sys reservations that were registered at boot:

The RDP reservation on port 3392 (rather than the standard 3389) suggests the RDP port had been changed at some point — a common but often insufficient security measure. The Remote Assistance reservation is particularly notable: Remote Assistance allows another person to take control of your desktop with your permission, and its URL reservation persisting in HTTP.sys means the infrastructure for that feature is always present, even if you never use it.

Why Was WinRM Running at All?

The most likely explanation is Microsoft Defender for Endpoint. MDE is an enterprise-grade endpoint detection and response platform, and it was confirmed as installed on this machine. MDE uses WinRM internally for some of its management and telemetry operations, and it sets the service to Automatic startup as part of its deployment. This is a known and documented behavior.

This creates an interesting tension: a security product is maintaining a service that is itself an attack surface. MDE's reasoning is sound from an enterprise perspective — it needs reliable remote management capabilities to function. But on a personal machine, the calculus is different. The question isn't whether WinRM is useful in principle; it's whether the benefit of having it available outweighs the risk of having it running.

The answer, for a personal machine, is almost always no.

The Disable Test

The natural next step was to disable WinRM and see what happened. If MDE was managing the service, we expected it to fight back — to re-enable WinRM automatically, or to log errors about a missing dependency.

The commands were straightforward:

powershell Stop-Service WinRM Set-Service WinRM -StartupType Disabled

Both executed cleanly. No errors, no warnings. A verification check confirmed the service was stopped and disabled. And then we waited.

MDE did not fight back. The service stayed disabled through the rest of the session and through a subsequent reboot. This suggests one of two things: either MDE on this particular machine doesn't depend on WinRM for its core functionality, or the version of MDE installed here has been configured in a way that doesn't require the service. Either way, the result was clean — WinRM disabled, no negative consequences.

What the Investigation Revealed About Modern Windows

The WinRM investigation is a useful lens for understanding something broader about Windows security: the operating system ships with a significant amount of infrastructure that exists for enterprise use cases, and that infrastructure runs on personal machines whether you need it or not.

WinRM is not the only example. Remote Assistance, Remote Desktop, the Connected Devices Platform, various telemetry services — all of these are enabled by default or start automatically, and most personal users have no need for any of them. Each one represents an attack surface: a service that could be exploited, a port that could be probed, a credential that could be stolen.

The standard advice is to disable what you don't use. But the challenge is knowing what you're running in the first place. Most users never look at their service list. Most users don't know what HTTP.sys URL reservations are, let alone that WinRM has registered two of them on their machine. The attack surface exists in the gap between what Windows runs by default and what users actually know about.

The Broader Context: Living Off the Land

Security researchers use the term "living off the land" to describe attacks that use legitimate Windows tools and services rather than custom malware. WinRM is a prime example of a living-off-the-land target. An attacker who gains initial access to a machine — through a phishing email, a malicious download, a compromised account — can use WinRM to move laterally through a network, execute commands remotely, and maintain persistence, all using a tool that Windows ships with and that many security products treat as trusted.

For streamers and VTubers, the lateral movement scenario is less relevant than it would be in a corporate environment. But the persistence and remote execution scenarios are directly applicable. If an attacker gains access to your machine and WinRM is running, they have a built-in remote management channel that they can configure and use. Disabling the service removes that option entirely.

Practical Takeaways

The WinRM investigation produced a clear set of recommendations that apply to any personal Windows machine:

Disable WinRM if you don't use remote PowerShell or remote administration. The service provides no benefit to personal users and represents a meaningful attack surface. The disable operation is reversible — if you ever need WinRM for a specific task, you can re-enable it temporarily.

Audit your HTTP.sys URL reservations. Run netsh http show urlacl in an elevated command prompt to see everything that's registered. WinRM, Remote Assistance, and RDP all register URLs here, and those registrations persist even when the services aren't running. Understanding what's registered helps you understand what infrastructure is available to an attacker who gains access to your machine.

Check what's actually listening. netstat -ano shows active connections and listening ports. Running this regularly — or after installing new software — helps you catch unexpected services before they become a problem.

Consider whether enterprise security tools are appropriate for your threat model. MDE is a powerful platform designed for corporate environments. On a personal machine, it adds complexity and maintains services (like WinRM) that you might not want running. Windows Defender, which ships with Windows 11, provides strong protection for personal use without the enterprise overhead.

The ghost service is gone now. WinRM is disabled, the attack surface is reduced, and the investigation produced documentation that's now part of the PrivacyWarden hardening collection. But the broader lesson is worth keeping: on a modern Windows machine, there's always more running than you think.

Explore all PrivacyWarden guides