What is PowerShell Remoting?
PowerShell Remoting uses Windows Remote Management (WinRM), which is the Microsoft implementation of the Web Services for Management (WS-Management) protocol, to permit users to run PowerShell commands on remote computers. You’ll be able to see a lot of data regarding the exploitation of PowerShell Remoting for Running Remote Commands.
PowerShell Remoting isn’t the same as the ComputerName parameter of a cmdlet to run it on a remote PC that uses Remote Procedure Call (RPC) as its underlying protocol.
Security Considerations:
Process isolation – Remote PowerShell uses WinRM to communicate between computers. WinRM runs as a service under the network service account, producing isolated processes that act as user accounts for hosting PowerShell instances. An instance of PowerShell running as a user does not have access to a process that is running an instance of PowerShell as another user.
Encryption and transport protocols – It is useful to consider the security of a remote PowerShell connection from two perspectives: initial authentication and persistent connection.
No matter what transport protocol is used (HTTP or HTTPS), WinRM always encrypts all remote PowerShell connections after the initial authentication.
Initial authentication – Authentication confirms the identity of the client on the server and – ideally – the server to the client.
When someone connects to a domain server using its PC name, the default authentication protocol is Kerberos. Kerberos guarantees the identity of the user and the identity of the server without sending any kind of reusable credentials. When someone connects to a domain server using its own IP address, or connects to a workgroup server, Kerberos authentication is not enabled. In this case, the remote PowerShell relies on the NTLM authentication protocol. The NTLM authentication protocol guarantees the identity of the user without sending any kind of delegate credentials. To prove a user’s identity, NTLM requires that both the client and server compute a session key from the user’s password without exchanging the password itself. The server usually does not know the user’s password, so it communicates with the domain controller, which does not know the user’s password and calculates the session key for the server.
SSL certificates with NTLM-based connections for server identity validation – Since the NTLM authentication protocol cannot guarantee the identity of the target server (only because it already knows the password), you can configure target servers to use SSL for remote PowerShell. Assigning an SSL certificate to the target server (if it is issued by a CA that the client also trusts) enables NTLM-based authentication that guarantees the identity of the user and the identity of the server.
Conclusion
It is imperative that best security practices for PowerShell are followed. Anytime ports are opened, you have just increased your attack foot print which comes with associated risks.
References
- https://docs.microsoft.com/en-us/windows/win32/winrm/portal
- https://www.dmtf.org/sites/default/files/standards/documents/DSP0226_1.2.0.pdf
- https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-wsmv/58421aa4-861a-4410-831a-c999f094cdb7
- https://docs.microsoft.com/en-us/windows/win32/secauthn/microsoft-kerberos
- https://docs.microsoft.com/en-us/windows/win32/secauthn/microsoft-ntlm
