PowerShell remoting security
Microsoft's edit ·
Microsoft's commit message in MicrosoftDocs/PowerShell-Docs · commit d2da3d7 · +147 −0 lines · also on GitHub
The file is new at this commit, or was moved here from another path: every line shows as added.
1
+---
2
+description: This document covers security concerns, recommendations, and best practices when using PowerShell Remoting.
3
+ms.date: 10/23/2023
4
+title: Security considerations for PowerShell Remoting using WinRM
5
+---
6
+
7
+# Security Considerations for PowerShell Remoting using WinRM
8
+
9
+PowerShell Remoting is the recommended way to manage Windows systems. PowerShell Remoting is enabled
10
+by default in Windows Server 2012 R2 and higher. This document covers security concerns,
11
+recommendations, and best practices when using PowerShell Remoting.
12
+
13
+## What is PowerShell Remoting?
14
+
15
+PowerShell Remoting uses [Windows Remote Management (WinRM)][04] to allow users to run PowerShell
16
+commands on remote computers. WinRM is the Microsoft implementation of the
17
+[Web Services for Management (WS-Management)][05] protocol. You can find more information about
18
+using PowerShell Remoting at [Running Remote Commands][08].
19
+
20
+PowerShell Remoting isn't the same as using the **ComputerName** parameter of a cmdlet to run it on
21
+a remote computer, which uses Remote Procedure Call (RPC) as its underlying protocol.
22
+
23
+## PowerShell Remoting default settings
24
+
25
+PowerShell Remoting (and WinRM) listen on the following ports:
26
+
27
+- HTTP: 5985
28
+- HTTPS: 5986
29
+
30
+By default, PowerShell Remoting only allows connections from members of the Administrators group.
31
+Sessions are launched under the user's context, so all operating system access controls applied to
32
+individual users and groups continue to apply to them while connected over PowerShell Remoting.
33
+
34
+On private networks, the default Windows Firewall rule for PowerShell Remoting accepts all
35
+connections. On public networks, the default Windows Firewall rule allows PowerShell Remoting
36
+connections only from within the same subnet. You have to explicitly change that rule to open
37
+PowerShell Remoting to all connections on a public network.
38
+
39
+> [!Warning]
40
+> The firewall rule for public networks is meant to protect the computer from potentially malicious
41
+> external connection attempts. Use caution when removing this rule.
42
+
43
+## Process isolation
44
+
45
+PowerShell Remoting uses WinRM for communication between computers. WinRM runs as a service under
46
+the Network Service account, and spawns isolated processes running as user accounts to host
47
+PowerShell instances. An instance of PowerShell running as one user has no access to a process
48
+running an instance of PowerShell as another user.
49
+
50
+## Event logs generated by PowerShell Remoting
51
+
52
+FireEye has provided a good summary of the event logs and other security evidence generated by
53
+PowerShell Remoting sessions, available at [Investigating PowerShell Attacks][06].
54
+
55
+## Encryption and transport protocols
56
+
57
+It's helpful to consider the security of a PowerShell Remoting connection from two perspectives:
58
+initial authentication, and ongoing communication.
59
+
60
+Regardless of the transport protocol used (HTTP or HTTPS), WinRM always encrypts all PowerShell
61
+remoting communication after initial authentication.
62
+
63
+### Initial authentication
64
+
65
+Authentication confirms the identity of the client to the server - and ideally - the server to the
66
+client.
67
+
68
+When a client connects to a domain server using its computer name, the default authentication
69
+protocol is [Kerberos][02]. Kerberos guarantees both the user identity and server identity without
70
+sending any sort of reusable credential.
71
+
72
+When a client connects to a domain server using its IP address, or connects to a workgroup server,
73
+Kerberos authentication isn't possible. In that case, PowerShell Remoting relies on the
74
+[NTLM authentication protocol][03]. The NTLM authentication protocol guarantees the user identity
75
+without sending any sort of delegable credential. To prove user identity, the NTLM protocol requires
76
+that both the client and server compute a session key from the user's password without ever
77
+exchanging the password itself. The server typically doesn't know the user's password, so it
78
+communicates with the domain controller, which does know the user's password and calculates the
79
+session key for the server.
80
+
81
+The NTLM protocol doesn't, however, guarantee server identity. As with all protocols that use NTLM
82
+for authentication, an attacker with access to a domain-joined computer's machine account could
83
+invoke the domain controller to compute an NTLM session-key and thereby impersonate the server.
84
+
85
+NTLM-based authentication is disabled by default, but may be permitted by either configuring SSL on
86
+the target server, or by configuring the WinRM TrustedHosts setting on the client.
87
+
88
+#### Using SSL certificates to validate server identity during NTLM-based connections
89
+
90
+Since the NTLM authentication protocol can't ensure the identity of the target server (only that it
91
+already knows your password), you can configure target servers to use SSL for PowerShell Remoting.
92
+Assigning a SSL certificate to the target server (if issued by a Certificate Authority that the
93
+client also trusts) enables NTLM-based authentication that guarantees both the user identity and
94
+server identity.
95
+
96
+#### Ignoring NTLM-based server identity errors
97
+
98
+If deploying a SSL certificate to a server for NTLM connections is infeasible, you may suppress the
99
+resulting identity errors by adding the server to the WinRM **TrustedHosts** list. Please note that
100
+adding a server name to the **TrustedHosts** list shouldn't be considered as any form of statement
101
+of the trustworthiness of the hosts themselves - as the NTLM authentication protocol can't
102
+guarantee that you are in fact connecting to the host you are intending to connect to. Instead, you
103
+should consider the TrustedHosts setting to be the list of hosts for which you wish to suppress the
104
+error generated by being unable to verify the server's identity.
105
+
106
+### Ongoing Communication
107
+
108
+Once initial authentication is complete, the WinRM encrypts the ongoing communication. When
109
+connecting over HTTPS, the TLS protocol is used to negotiate the encryption used to transport data.
110
+When connecting over HTTP, message-level encryption is determined by initial authentication protocol
111
+used.
112
+
113
+- Basic authentication provide no encryption.
114
+- NTLM authentication uses an RC4 cipher with a 128-bit key.
115
+- Kerberos authentication encryption is determined by the `etype` in the TGS ticket. This is AES-256
116
+ on modern systems.
117
+- CredSSP encryption is uses the TLS cipher suite that was negotiated in the handshake.
118
+
119
+## Making the second hop
120
+
121
+By default, PowerShell Remoting uses Kerberos (if available) or NTLM for authentication. Both of
122
+these protocols authenticate to the remote machine without sending credentials to it. This is the
123
+most secure way to authenticate, but because the remote machine doesn't have the user's credentials,
124
+it can't access other computers and services on the user's behalf. This is known as the "second hop
125
+problem".
126
+
127
+There are several ways to avoid this problem. For descriptions of these methods, and the pros and
128
+cons of each, see [Making the second hop in PowerShell Remoting][07].
129
+
130
+## References
131
+
132
+- [Windows Remote Management (WinRM)][04]
133
+- [Web Services for Management (WS-Management)][05]
134
+- [2.2.9.1 Encrypted Message Types][01]
135
+- [Kerberos][02]
136
+- [NTLM authentication protocol][03]
137
+- [Investigating PowerShell Attacks][06]
138
+
139
+<!-- link references -->
140
+[01]: /openspecs/windows_protocols/ms-wsmv/58421aa4-861a-4410-831a-c999f094cdb7
141
+[02]: /windows/win32/secauthn/microsoft-kerberos
142
+[03]: /windows/win32/secauthn/microsoft-ntlm
143
+[04]: /windows/win32/winrm/portal
144
+[05]: https://www.dmtf.org/sites/default/files/standards/documents/DSP0226_1.2.0.pdf
145
+[06]: https://www.mandiant.com/resources/investigating-powershell-attacks
146
+[07]: PS-remoting-second-hop.md
147
+[08]: running-remote-commands.md
Microsoft's Markdown source from MicrosoftDocs/PowerShell-Docs, © Microsoft Corporation, under CC BY 4.0. Changed lines with up to 3 unchanged lines around each; ChangeIntel kept this copy 10 Oct 18:27 UTC. The commit date is when the source changed, which can be hours or days before Learn published it.