Back
Exploiting Trusted Hosts in WinRM
Introduction – What is WinRM?
Windows Remote Management (WinRM) is a SOAP based protocol that can be used to remotely administer machines over the network. This is a handy tool for network admins that can also be used to automate tasks securely across multiple machines. However, it is fairly easy to misconfigure the service and/or abuse the service with legitimate account access.
How to mess up the WinRM configuration
In my personal experience with configuring the WinRM service, I have found it hard to get anything working correctly without completely removing security controls from the configuration. Scale my frustrations up to a domain level and you very quickly have poorly secured configs going out to hosts across a domain. It should be noted that the following commands should not be used for an actual WinRM configuration. These are just examples of the multiple ways that this service can be configured to run insecurely . Quick steps for configuring WinRM insecurely: Note: These are all commands that are run from a command shell with administrative privileges.
- Start the WinRM service. The only requirement to start the service is that none of your network interfaces can be set to “Public” in Windows. This typically isn’t an issue in domain environments. The command itself is not really a security issue, it’s just needed to actually run the WinRM service.winrm quickconfig
- Allow WinRM commands to be accepted through unencrypted channels (HTTP).winrm set winrm/config/service @{AllowUnencrypted=”true”}
- Allow WinRM command to be sent through unencrypted channels (HTTP).winrm set winrm/config/client @{AllowUnencrypted=”true”}
- Enable “Basic” network authentication for inbound WinRM connections to the server.winrm set winrm/config/service/auth @{Basic=”true”}
- Enable “Basic” network authentication for outbound WinRM client connections. So, when you make a WinRM connection to another host with the local WinRM client, you can authenticate using “Basic” authentication.winrm set winrm/config/client/auth @{Basic=”true”}
- Allow credentials to be relayed out to another host using the CredSSP protocol. This allows the host receiving commands to pass incoming credentials on to another host for authentication.winrm set winrm/config/service/auth @{CredSSP=”True”}
In order to authenticate against the service remotely, the authenticating account either has to be the same as the service account running the WinRM service, or a member of the local administrators group. This also means that any service set up to run scripted jobs through WinRM has to have access to credentials for a local administrator account.
What can we do with this?
Let’s assume that you have access to a host on a network and you have domain credentials, but there are no escalation points for you to follow on the host. If the WinRM service is set up to listen on other hosts in the domain, you may have the ability to use the service to gain remote access to the other hosts. Let’s say that you want to gain remote access to host 192.168.0.123 on the domain, but RDP is not enabled (or your account does not have RDP access). The open ports 5985 and 5986 (TCP) indicate that the WinRM service may be running on the remote host. You can identify the service with the following command:
winrm identify -r:https://192.168.0.123:5985 –auth:none
The response should look something like this:
IdentifyResponse ProtocolVersion = https://schemas.dmtf.org/wbem/wsman/1/wsman.xsd ProductVendor = Microsoft Corporation ProductVersion = OS: 6.1.7601 SP: 1.0 Stack: 2.0
Once you’ve determined the service is running, you can try to run commands against the remote host with the Windows Remote Shell (winrs) command:
winrs -r:https://192.168.0.123:5985 -u:domainnameuseraccount “dir c:”
You can also use this with HTTPS on port 5986, as that may be your only option. If you change the “dir c:” to “cmd” you will have a remote shell on the host. That should look something like this:
winrs -r:https://192.168.0.123:5985 -u:domainnameuseraccount “cmd”
While the remote shell will only be running under your account’s privileges, there may be other escalation options on your new host.
Conclusion
As you can see, the WinRM service can be very powerful and useful for legitimately administering systems on the domain. It also can be used by attackers to work their way through the internal network. With any network service, determine your business need for the service before it is implemented. If the service is needed, then ensure that the service is securely configured before it is deployed. If you’re thinking about using WinRM, make sure that you only allow specific trusted hosts and limit users in your local administrators groups.
