Skip to content

Fix broken link #11931

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Mar 24, 2025
Merged

Fix broken link #11931

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
51 changes: 26 additions & 25 deletions reference/docs-conceptual/security/remoting/WinRM-Security.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
---
description: This document covers security concerns, recommendations, and best practices when using PowerShell Remoting.
ms.date: 12/07/2024
ms.date: 03/24/2025
title: Security considerations for PowerShell Remoting using WinRM
---

Expand All @@ -22,7 +22,7 @@ a remote computer, which uses Remote Procedure Call (RPC) as its underlying prot

## PowerShell Remoting default settings

PowerShell Remoting (and WinRM) listen on the following ports:
PowerShell Remoting with WinRM listens on the following ports:

- HTTP: 5985
- HTTPS: 5986
Expand All @@ -36,7 +36,7 @@ connections. On public networks, the default Windows Firewall rule allows PowerS
connections only from within the same subnet. You have to explicitly change that rule to open
PowerShell Remoting to all connections on a public network.

> [!Warning]
> [!WARNING]
> The firewall rule for public networks is meant to protect the computer from potentially malicious
> external connection attempts. Use caution when removing this rule.

Expand All @@ -49,8 +49,9 @@ running an instance of PowerShell as another user.

## Event logs generated by PowerShell Remoting

FireEye has provided a good summary of the event logs and other security evidence generated by
PowerShell Remoting sessions, available at [Investigating PowerShell Attacks][06].
Researchers from Mandiant presented a session at the BlackHat conference that provides a good
summary of the event logs and other security evidence generated by PowerShell Remoting sessions. For
more information, see [Investigating PowerShell Attacks][06].

## Encryption and transport protocols

Expand Down Expand Up @@ -80,49 +81,49 @@ session key for the server.

The NTLM protocol doesn't, however, guarantee server identity. As with all protocols that use NTLM
for authentication, an attacker with access to a domain-joined computer's machine account could
invoke the domain controller to compute an NTLM session-key and thereby impersonate the server.
invoke the domain controller to compute an NTLM session-key and impersonate the server.

NTLM-based authentication is disabled by default, but may be permitted by either configuring SSL on
NTLM-based authentication is disabled by default. You can enable NTLM by either configuring SSL on
the target server, or by configuring the WinRM TrustedHosts setting on the client.

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

Since the NTLM authentication protocol can't ensure the identity of the target server (only that it
already knows your password), you can configure target servers to use SSL for PowerShell Remoting.
Assigning a SSL certificate to the target server (if issued by a Certificate Authority that the
Assigning an SSL certificate to the target server (if issued by a Certificate Authority that the
client also trusts) enables NTLM-based authentication that guarantees both the user identity and
server identity.

#### Ignoring NTLM-based server identity errors

If deploying a SSL certificate to a server for NTLM connections is infeasible, you may suppress the
resulting identity errors by adding the server to the WinRM **TrustedHosts** list. Please note that
adding a server name to the **TrustedHosts** list shouldn't be considered as any form of statement
of the trustworthiness of the hosts themselves - as the NTLM authentication protocol can't
guarantee that you are in fact connecting to the host you are intending to connect to. Instead, you
should consider the TrustedHosts setting to be the list of hosts for which you wish to suppress the
error generated by being unable to verify the server's identity.
If deploying an SSL certificate to a server for NTLM connections is infeasible, you can suppress the
resulting identity errors by adding the server to the WinRM **TrustedHosts** list. Adding a server
name to the **TrustedHosts** list shouldn't be considered as any form of statement of the
trustworthiness of the hosts themselves - as the NTLM authentication protocol can't guarantee that
you are in fact connecting to the host you're intending to connect to. Instead, you should consider
the TrustedHosts setting to be the list of hosts for which you wish to suppress the error generated
by being unable to verify the server's identity.

### Ongoing Communication

Once initial authentication is complete, the WinRM encrypts the ongoing communication. When
connecting over HTTPS, the TLS protocol is used to negotiate the encryption used to transport data.
When connecting over HTTP, message-level encryption is determined by initial authentication protocol
used.
Once initial authentication is complete, the WinRM encrypts the ongoing communication. When you
connect over HTTPS, WinRM uses the TLS protocol to negotiate the encryption used to transport data.
When you connect over HTTP, WinRM uses the message-level encryption negotiated by the initial
authentication protocol.

- Basic authentication provide no encryption.
- Basic authentication provides no encryption.
- NTLM authentication uses an RC4 cipher with a 128-bit key.
- Kerberos authentication encryption is determined by the `etype` in the TGS ticket. This is AES-256
- The `etype` in the TGS ticket determines Kerberos authentication encryption. This is AES-256
on modern systems.
- CredSSP encryption is uses the TLS cipher suite that was negotiated in the handshake.
- CredSSP encryption uses the TLS cipher suite negotiated in the handshake.

## Making the second hop

By default, PowerShell Remoting uses Kerberos (if available) or NTLM for authentication. Both of
these protocols authenticate to the remote machine without sending credentials to it. This is the
most secure way to authenticate, but because the remote machine doesn't have the user's credentials,
it can't access other computers and services on the user's behalf. This is known as the "second hop
problem".
it can't access other computers and services on the user's behalf. This is known as the _second hop
problem_.

There are several ways to avoid this problem. For descriptions of these methods, and the pros and
cons of each, see [Making the second hop in PowerShell Remoting][07].
Expand All @@ -142,6 +143,6 @@ cons of each, see [Making the second hop in PowerShell Remoting][07].
[03]: /windows/win32/secauthn/microsoft-ntlm
[04]: /windows/win32/winrm/portal
[05]: https://www.dmtf.org/sites/default/files/standards/documents/DSP0226_1.2.0.pdf
[06]: https://www.mandiant.com/sites/default/files/2021-09/wp-lazanciyan-investigating-powershell-attacks.pdf
[06]: https://www.blackhat.com/docs/us-14/materials/us-14-Kazanciyan-Investigating-Powershell-Attacks-WP.pdf
[07]: PS-remoting-second-hop.md
[08]: running-remote-commands.md