PowerShell remoting security

This page's changes and edits · All guidance changes

Microsoft's edit · 24 Mar 2025 15:25 UTC

Fix broken link (#11931)

Microsoft's commit message in MicrosoftDocs/PowerShell-Docs · commit e7efecd · +26 ~~−25~~ lines · also on GitHub

11 ---

22 description: This document covers security concerns, recommendations, and best practices when using PowerShell Remoting.

3 −ms.date: 12/07/2024

3 +ms.date: 03/24/2025

44 title: Security considerations for PowerShell Remoting using WinRM

55 ---

⋯ 15 unchanged lines

2222

2323 ## PowerShell Remoting default settings

2424

25 −PowerShell Remoting (and WinRM) listen on the following ports:

25 +PowerShell Remoting with WinRM listens on the following ports:

2626

2727 - HTTP: 5985

2828 - HTTPS: 5986

⋯ 7 unchanged lines

3636 connections only from within the same subnet. You have to explicitly change that rule to open

3737 PowerShell Remoting to all connections on a public network.

3838

39 −> [!Warning]

39 +> [!WARNING]

4040 > The firewall rule for public networks is meant to protect the computer from potentially malicious

4141 > external connection attempts. Use caution when removing this rule.

4242

⋯ 6 unchanged lines

4949

5050 ## Event logs generated by PowerShell Remoting

5151

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].

52 +Researchers from Mandiant presented a session at the BlackHat conference that provides a good

53 +summary of the event logs and other security evidence generated by PowerShell Remoting sessions. For

54 +more information, see [Investigating PowerShell Attacks][06].

5455

5556 ## Encryption and transport protocols

5657

⋯ 23 unchanged lines

8081

8182 The NTLM protocol doesn't, however, guarantee server identity. As with all protocols that use NTLM

8283 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 +invoke the domain controller to compute an NTLM session-key and impersonate the server.

8485

85 −NTLM-based authentication is disabled by default, but may be permitted by either configuring SSL on

86 +NTLM-based authentication is disabled by default. You can enable NTLM by either configuring SSL on

8687 the target server, or by configuring the WinRM TrustedHosts setting on the client.

8788

8889 #### Using SSL certificates to validate server identity during NTLM-based connections

8990

9091 Since the NTLM authentication protocol can't ensure the identity of the target server (only that it

9192 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 +Assigning an SSL certificate to the target server (if issued by a Certificate Authority that the

9394 client also trusts) enables NTLM-based authentication that guarantees both the user identity and

9495 server identity.

9596

9697 #### Ignoring NTLM-based server identity errors

9798

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.

99 +If deploying an SSL certificate to a server for NTLM connections is infeasible, you can suppress the

100 +resulting identity errors by adding the server to the WinRM **TrustedHosts** list. Adding a server

101 +name to the **TrustedHosts** list shouldn't be considered as any form of statement of the

102 +trustworthiness of the hosts themselves - as the NTLM authentication protocol can't guarantee that

103 +you are in fact connecting to the host you're intending to connect to. Instead, you should consider

104 +the TrustedHosts setting to be the list of hosts for which you wish to suppress the error generated

105 +by being unable to verify the server's identity.

105106

106107 ### Ongoing Communication

107108

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.

109 +Once initial authentication is complete, the WinRM encrypts the ongoing communication. When you

110 +connect over HTTPS, WinRM uses the TLS protocol to negotiate the encryption used to transport data.

111 +When you connect over HTTP, WinRM uses the message-level encryption negotiated by the initial

112 +authentication protocol.

112113

113 −- Basic authentication provide no encryption.

114 +- Basic authentication provides no encryption.

114115 - 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 +- The `etype` in the TGS ticket determines Kerberos authentication encryption. This is AES-256

116117 on modern systems.

117 −- CredSSP encryption is uses the TLS cipher suite that was negotiated in the handshake.

118 +- CredSSP encryption uses the TLS cipher suite negotiated in the handshake.

118119

119120 ## Making the second hop

120121

121122 By default, PowerShell Remoting uses Kerberos (if available) or NTLM for authentication. Both of

122123 these protocols authenticate to the remote machine without sending credentials to it. This is the

123124 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".

125 +it can't access other computers and services on the user's behalf. This is known as the _second hop

126 +problem_.

126127

127128 There are several ways to avoid this problem. For descriptions of these methods, and the pros and

128129 cons of each, see [Making the second hop in PowerShell Remoting][07].

⋯ 13 unchanged lines

142143 [03]: /windows/win32/secauthn/microsoft-ntlm

143144 [04]: /windows/win32/winrm/portal

144145 [05]: https://www.dmtf.org/sites/default/files/standards/documents/DSP0226_1.2.0.pdf

145 −[06]: https://www.mandiant.com/sites/default/files/2021-09/wp-lazanciyan-investigating-powershell-attacks.pdf

146 +[06]: https://www.blackhat.com/docs/us-14/materials/us-14-Kazanciyan-Investigating-Powershell-Attacks-WP.pdf

146147 [07]: PS-remoting-second-hop.md

147148 [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 08:53 UTC. The commit date is when the source changed, which can be hours or days before Learn published it.