Detecting and Mitigating WinRM Abuse (T1021.006)

Windows Remote Management (WinRM) is how a lot of Windows administration happens at scale. PowerShell remoting runs on top of it. Patch tools, inventory tools and plenty of scripts depend on it.

MITRE tracks the abuse of it as Windows Remote Management, technique T1021.006, under Lateral Movement. It applies to Windows. As with the rest of the Remote Services family, the attacker needs a valid account first.

How attackers use it

WinRM is both a Windows service and a protocol. A user can interact with a remote system through it: run an executable, change the Registry, manage services. It can be called with the winrm command or by programs such as PowerShell. MITRE also notes it can be used as a way of reaching Windows Management Instrumentation (WMI) remotely.

Because the service is built in and used by administrators every day, attacker activity can sit inside a flood of legitimate traffic. The difference is who is connecting, from where, and what runs afterward.

This is why a technique with such a short description deserves attention. There is no exploit and no unusual file. There is a normal management channel in the hands of the wrong person.

How to detect it

MITRE's detection strategy (DET0477) is a chain, not a single event. The pieces are service use, network activity, a remote session logon and process creation, all within a short time window. Specifically, it points to adversaries using WinRM to run commands remotely, launch child processes or reach WMI.

Here is how to turn that into something searchable:

• Network. WinRM listens on TCP 5985 for HTTP and 5986 for HTTPS. Flag connections to those ports from hosts that are not designated admin workstations or jump hosts.
• Logon. A network logon (type 3, event ID 4624) on the target close to the time of the WinRM connection.
• Process creation. On the target, the WinRM host process (wsmprovhost.exe) starting child processes. Capture command lines with process creation auditing (event ID 4688) or Sysmon event ID 1.
• WinRM logs. The Microsoft-Windows-WinRM/Operational event log records remote session activity.
• Timing. Tie the three together by host and account within a few minutes. One alert for the whole sequence beats three noisy alerts for the pieces.

Build a short list of sanctioned WinRM sources and accounts. Anything outside that list is the alert.

How to reduce the risk

MITRE lists three mitigations.

1. Disable the WinRM service on machines that do not need it. Most workstations do not.
2. If WinRM is required, use separate accounts and permissions for critical enclaves. An admin who can manage the web tier should not automatically be able to manage the domain controllers.
3. Use separate WinRM infrastructure and host firewalls to allow communication only to and from specific devices. MITRE points to published WinRM best practices for this.

Together these shrink three things: where WinRM exists, who may use it and which machines may reach it.

Check your own environment

Read-only checks on a Windows host, in an elevated PowerShell session:

# Is the WinRM service present, and is it running?
Get-Service WinRM

# What is WinRM listening on?
winrm enumerate winrm/config/listener

# Who may connect? Show inbound firewall rules in the WinRM group
Get-NetFirewallRule -DisplayGroup "Windows Remote Management" |
    Select-Object DisplayName, Enabled, Direction, Action

# Is process creation auditing on?
auditpol /get /subcategory:"Process Creation"

Then work through these questions:

• Which machines run WinRM, and do they all need to?
• Can any host on the network reach TCP 5985 or 5986 on any other host?
• Which accounts can use remoting on your most sensitive servers?
• Do you collect the WinRM Operational log and process creation events centrally?
• If you are asked tomorrow who used WinRM against a given server last Tuesday, can you answer?

Quick check

Sources

• MITRE ATT&CK, Windows Remote Management (T1021.006)