Fix broken link (#11931)

Author: sdwheeler

reference/docs-conceptual/security/remoting/WinRM-Security.md

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