WinRM and PowerShell Remoting Security: How to Harden Remote Management Without Disabling It

HTTP WinRM (port 5985) sends command output unencrypted. Require HTTPS (5986) for all WinRM connections.

Create an HTTPS listener (requires a machine certificate):

# The machine must have a certificate in the LocalMachine\My store with
# the Subject matching the machine's FQDN (or a wildcard)

# Find the certificate thumbprint
$cert = Get-ChildItem Cert:\LocalMachine\My |
    Where-Object { $_.Subject -match $env:COMPUTERNAME }
$thumbprint = $cert.Thumbprint

# Create the HTTPS listener
New-Item -Path WSMan:\LocalHost\Listener -Transport HTTPS `
    -Address * -CertificateThumbprint $thumbprint -Force

# Verify
Get-ChildItem WSMan:\LocalHost\Listener
# Should show both HTTP and HTTPS (or HTTPS only if you delete the HTTP listener)

# Optional: Remove the HTTP listener to force HTTPS only
Remove-Item WSMan:\LocalHost\Listener\Listener_* -Force
# Then recreate only the HTTPS listener as above

Enforce HTTPS via Group Policy: Computer Configuration > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Service

• Allow Basic authentication: Disabled
• Allow unencrypted traffic: Disabled

For certificates at scale, use an internal CA with auto-enrollment via Group Policy -- computer certificates enrolled to all domain members provide the HTTPS listener certificates without manual steps.

Windows Firewall rule to restrict WinRM source IPs:

# Allow WinRM HTTPS only from management server IPs
New-NetFirewallRule -Name 'WinRM-HTTPS-Management' `
    -DisplayName 'WinRM HTTPS from management servers only' `
    -Direction Inbound -Protocol TCP -LocalPort 5986 `
    -RemoteAddress @('10.10.1.50', '10.10.1.51', '10.10.1.0/24') `
    -Action Allow -Profile Domain

# Block WinRM from all other sources (default deny posture)
New-NetFirewallRule -Name 'WinRM-BLOCK-OTHER' `
    -DisplayName 'Block WinRM from non-management sources' `
    -Direction Inbound -Protocol TCP -LocalPort 5985,5986 `
    -Action Block -Profile Domain

Deploy these rules via GPO for the Server and Workstation OUs.

Fix LocalAccountTokenFilterPolicy:

# Check current setting (1 = local admins have full WinRM access, 0 = restricted)
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System' `
    -Name LocalAccountTokenFilterPolicy -ErrorAction SilentlyContinue

# Disable local admin WinRM full access (set to 0)
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System' `
    -Name LocalAccountTokenFilterPolicy -Type DWord -Value 0

Set TrustedHosts to a specific list (or empty):

# View current TrustedHosts
Get-Item WSMan:\LocalHost\Client\TrustedHosts

# Set to empty (safest for domain-joined machines that use Kerberos)
Set-Item WSMan:\LocalHost\Client\TrustedHosts -Value '' -Force

# Or restrict to specific jump server IPs
Set-Item WSMan:\LocalHost\Client\TrustedHosts -Value '10.10.1.50,10.10.1.51' -Force

# Deploy via Group Policy:
# Computer Configuration > Administrative Templates > Windows Components > WRM (WinRM) > WinRM Client
# Trusted Hosts: specify the allowed list

Workstations generally do not need inbound WinRM. Disabling it removes a lateral movement target.

Disable via Group Policy (applied to Workstations OU): Computer Configuration > Windows Settings > Security Settings > System Services

• Windows Remote Management (WS-Management): Disabled

Or via Administrative Templates: Computer Configuration > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Service

• Allow remote server management through WinRM: Disabled

Verify WinRM status on workstations:

# Check WinRM service status across workstation fleet (run from management server)
$workstations = Get-ADComputer -SearchBase 'OU=Workstations,DC=domain,DC=com' -Filter *
foreach ($ws in $workstations) {
    try {
        $svc = Get-Service -ComputerName $ws.Name -Name WinRM -ErrorAction Stop
        if ($svc.Status -eq 'Running') {
            Write-Output "$($ws.Name) - WinRM RUNNING"
        }
    } catch {
        Write-Output "$($ws.Name) - UNREACHABLE"
    }
}

Exception: If you use Ansible, Intune Proactive Remediation, or custom WinRM-based scripts on workstations, keep WinRM enabled but enforce the HTTPS listener, firewall restrictions, and LocalAccountTokenFilterPolicy = 0.

WinRM lateral movement generates auditable events on both the source and target machines.

On the target machine (where WinRM is connecting to):

# Event ID 4624 (Successful logon) -- Logon Type 3 (network)
# Authentication Package: Kerberos or NTLM
# Source IP: the machine initiating the WinRM connection
# This fires for every WinRM connection

# Event ID 4688 (Process creation) -- Command Line Auditing must be enabled
# A WinRM session spawning wsmprovhost.exe is normal
# wsmprovhost.exe spawning cmd.exe, powershell.exe, or net.exe is suspicious

# Event ID 4103/4104 (PowerShell Script Block Logging)
# These capture commands run in WinRM sessions -- ship to SIEM
# See: PowerShell Script Block Logging guide

On the source machine (initiating the WinRM connection):

# Event ID 4624 with Logon Type 3 from the machine account or user
# to a remote destination is the source-side indicator

# Microsoft-Windows-WinRM/Operational log:
# Event ID 6 (WSMan Session initialized) -- every new WinRM session
# Event ID 91 (Creating WSMan Session) -- captures destination hostname/IP

Alert on:

// Sentinel/KQL: WinRM connections from workstations to workstations
SecurityEvent
| where EventID == 4624 and LogonType == 3
| where Computer !contains 'server' // filter out server-to-server (adjust for your naming)
| where AccountName !endswith '$'    // filter machine account logins
| where IpAddress !in ('known-mgmt-IPs')