Monitoring with Windows Remote Management (WinRM) and Powershell Part II

For the first installment of this series, click here. This is yet another post that required hours of research and testing and resulted in me learning way more about various tangential things than I realized I wanted to know.

Ready to wrap this up with some real security goodness? Me too.

When you operate a small network or LAN, passing your credentials over the wire via easy-to-crack hashes and sending other traffic as clear text might be acceptable to you - or more accurately, you don't spend any time thinking about it. But when your network is large, heterogeneous and spans dozens of cities and continents, and has hundreds of internet-facing nodes and thousands of employees and external users... you need to start paying more attention to security. Well actually you needed to have started paying more attention to security way before you got to that point, but you get my meaning. You never know who might be listening with an intent to uncover privileged information - whether outside hackers or internal employees.

When I first set out writing this post, I didn't realize that all WinRM traffic is already encrypted by default. Even when sent over the HTTP protocol and even when Negotiate/NTLM authentication is used. It's still encrypted. But I don't mean to conflate authentication and data encryption right off the bat. Let's start with encryption. Here is an example of the header of an HTTP packet sent to a WinRM server:

POST /wsman?PSVersion=2.0 HTTP/1.1
Connection: Keep-Alive
Content-Type: multipart/encrypted;protocol="application/HTTP-SPNEGO-session-encrypted";boundary="Encrypted Boundary"
User-Agent: Microsoft WinRM Client
Content-Length: 1662
Host: server1:5985

SPNEGO is used to negotiate the strongest authentication type available to both nodes, and then everything in the payload of the packet between the "--Encrypted Boundary--" tags... is gibberish. There is no clear text in the packets. I've looked. The only bit of useful information I could find so far while sniffing on the wire was the domain\username used for authentication. I'm guessing that this encrypted data sent over HTTP must be new to WinRM 2.0, because this Technet article implies that data sent over HTTP was clear text at some point.

*Click for larger*

Since the nodes are using the Negotiate protocol, they will settle on the best authentication mechanism that they can both agree upon. (Kerberos > NTLMv2 > NTLMv1, etc.) In this case it's going to be NTLMv2 authentication since they can't use Kerberos since they aren't in the same AD domain. Windows machines haven't used the old easy-to-crack LAN Manager or NTLMv1 password hashes in over 10 years. If you search through your packet capture, (use the "ntlmssp" display filter in Wireshark to easily find the relevant authentication traffic,) you will find several hashes of varying lengths, including the server challenge, client response, client challenge, HMAC, session key, MIC, etc. What's important though is that nothing that directly exposes the actual password is sent over the wire. If the machine has already been compromised, the attacker could access the local SAM and get an unsalted password hash that, using something like Rainbow Tables, could eventually be decoded into the original password. But that's only if the Security Accounts Manager on the local machine has already been compromised. The hash that's stored there is not sent over the wire.

This guy right here has an ongoing, amazing 6-part (and growing) exposé on getting at those infamous NTLM hashes. It always involves already having access to the machine though, and almost always involves old versions of Windows and exploiting flaws that have since been fixed.

In the first part of this tutorial, we did a basic set up of the WinRM service on a standalone computer named SERVER1. Then we connected to that computer from a domain-joined machine named DC01 to demonstrate using the Negotiate authentication protocol to connect to machines that are outside of your Active Directory trust boundary. By the way:

It should be noted that even within a domain, for Kerberos authentication to work when using WinRM, an SPN for the service must be registered in AD. As an example, you can find all of the "WSMAN" SPNs currently registered in your forest with this command:

setspn -T yourForest -F -Q WSMAN/*

SPN creation for this should be taken care of automatically, but you know something is wrong (and Kerberos will not be used) if there is no WSMAN SPN for the device that is hosting the WinRM service.

As with last time, when I execute the command on DC01:

$creds = Get-Credential
$server1 = New-PSSession -ComputerName SERVER1 -Credential $creds -Authentication "Negotiate"

A persistent remote connection is made from DC01 to SERVER1 via WinRM.

The following excerpt from this MSDN article is a pretty good description of what's going on. I'll recap, poorly:

  1. The nodes do a classic TCP/IP handshake. (ACK, SYN-ACK, NICE-TO-MEET-YOU-ACK)
  2. Client (DC01) does an HTTP Get for the resource. (Hey can I just access you?)
  3. Server (SERVER1) says "No way, I'm not that easy! (Returns 401 Unauthorized) ... but I am willing to negotiate, here's what I can do..."
  4. Client evaluates the authentication methods on offer, and sends new token with new base64-encoded authentication junk in it.
  5. Server accepts the challenge response by checking the hash against what it has in its own SAM, and allows Client to connect. (Returns HTTP 200)

So like I said, this communication is already pretty well protected. But maybe you want more. You can either set up an IPsec tunnel between the nodes, or you can enable certificate-based SSL encryption between the two nodes if you feel the need to further wrap all your packets in a warm blanket of security. We'll discuss certificate-based SSL encryption here.

First off, remember from Part I that WinRM just won't work with self-signed certificates. So we need a Certificate Authority. Luckily I've got one, but it's an ECA that belongs to a domain of which SERVER1 is not a member. No matter - to issue certificates to non-trusted parties, you simply need to add the web-enrollment junk to your ECA:

Add all of the web role services

I chose "Username and Password" authentication, but Integrated Windows Authentication might have worked as well, since the two computers are on the same network.

The next thing I'm going to do is install the certificate from the ECA into the Trusted Root CA store on SERVER1, so that SERVER1 will implicitly trust any certificate issued by my ECA. Export the certificate from the ECA, move the certificate to SERVER1, then Import the certificate to the correct store, you know the drill. You could also just browse to http://your-ECA/certsrv and download the CA certificate from there. Whatever works for you.

This next part gave me so much heartburn, and I'm hoping I can now save you some. You might remember from the first part of this tutorial that WinRM needs a certificate for "Server Authentication" purposes. The "Web Server" template in a basic set up of Certificate Services is for Server Authentication purposes. So we should just be able to use that one, right?

No one tells you this, but for WinRM to use the certificate, the private key must be marked as exportable when you request it from the CA. However, the original "Web Server" certificate template does not allow exporting private keys. So on your ECA, copy the Web Server template. Make sure you choose the "Windows Server 2003" option and not the "Server 2008" option, or else the new template will not show up in the drop-down menu on your Certsrv webpage. Name the copy something like "Web Server With Private Key." Modify the new template, and on the "Request Handling" tab, click "Allow private key to be exported." Nothing else needs to be changed unless you need to. Then, on the "Certificate Templates" node under your ECA, right click it, select New -> Certificate Template to Issue, and choose the new "Web Server with Private Key" template that you just created.

This article came in handy for me.

Next, on SERVER1, launch Internet Explorer. Make sure that the URL http://your-ECA/certsrv is added to SERVER1's Trusted Sites list, and modify your Internet Explorer security settings as needed so that you're able to run any and all ActiveX scripts that the ECA wants you to run, etc. Now browse to http://your-ECA/certsrv. You should need to provide credentials. (I bet it's through the same SPNEGO process that we witnessed earlier!) Make sure that the credentials you log in with have permissions to enroll in the certificate you will be requesting. You should get a pretty plain web page where you can request a certificate. If you don't, you've already gone astray.

Click on Request a Certificate, then submit an advanced certificate request. Then click Create and submit a request to this CA. Choose the "Web Server With Private Key" Certificate Template from the drop down menu that you created earlier. Yes, I know this is not a web server, but recall from part one of this tutorial that we need a certificate for "Server Authentication" purposes, and this certificate will give us that. You can spend a bunch of time playing around with the file on your CA and customizing the certificate request webpage to provide new templates if you want, but I don't really care about that right now. Also pay attention that as you change the certificate request type in the drop-down menu, you should be seeing the text boxes on the web page change around. This means the ActiveX junk is running successfully in the background.

So submit that request, and the website will either tell you that your certificate request requires approval (go approve it,) or it'll just give it to you right away, depending on the policy you set up on your CA. When you click the link to install your new certificate, the webpage will automatically install your new cert in your Current User > Personal store. Go look at it. It's important that it has the correct name on it (the subject and "CN=" part of the certificate needs to say SERVER1, etc.) and that there are no other validation errors. It should have "Server Authentication" in the Enhanced Key Usage field. Now they say that WinRM should be able to use this certificate whether it resides in the current user store or in the local computer store, but I had to export the certificate from there (including private key!) and then import it into the Local Computer > Personal store to get it to work. Finally, while you're here, open the properties of the certificate, and copy the Thumbprint. You'll need that in a second. (Reference)

Next, delete your old HTTP listener on SERVER1 with this command:

winrm delete winrm/config/Listener?Address=*+Transport=HTTP

You can only have one listener per network interface, from what I understand. Better we keep the config as simple as possible in any case. By the way, you can execute non-Powershell commands like this from within Powershell if you start the command with an ampersand. (& winrm delete winrm/config...)

Create your new HTTPS listener, configured to use your specified certificate, like this:

winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="SERVER1";CertificateThumbprint="1d9256aea461788764cec1904463120f094393f9"}

Where CertificateThumbprint is the thumbprint you copied off of the certificate a minute ago. If all goes well, you will get a "ResourceCreated" response from WinRM. Otherwise, the errors you are likely to see include "Cannot create a WinRM listener on HTTPS because this machine does not have an appropriate certificate. To be used for SSL, a certificate must have a CN matching the hostname, be appropriate for Server Authentication, and not be expired, revoked, or self-signed" or "A specified logon session does not exist. It may already have been terminated." I wrestled with both of those errors, and the only way I've gotten past them is to follow my above steps to the letter.

SERVER1 is now listening on port 5986, waiting for an SSL-protected connection. Keep in mind that since you didn't use quickconfig, it didn't automatically create a Windows Firewall rule for TCP 5986.

And finally - the fruit of our labor... So I've moved back to DC01. Keep in mind that DC01 is already configured to trust certificates that were issued by my ECA. I run this in Powershell:

$creds = Get-Credential
$server1 = New-PSSession SERVER1 -UseSSL -Credential $creds

And magic happens. And by "magic," I mean "no errors!" The connection established successfully with no fuss. And here's the cool part: This is a packet capture of the exact moment when the two nodes start communicating:

I don't even get to see the headers any more. It's all 100% complete gibberish, impervious to prying eyes, thanks to SSL encryption.

One last thing as a bonus for making it all the way through this article: In case you didn't know, Powershell creates "pseudo-drives," for lack of a better term, for certain repositories on your computer. For instance, in Powershell, type "cd cert:" to navigate around your Certificate Stores like a normal directory, and type "cd wsman:" to navigate around your WinRM configuration as if it were a regular file structure! Pretty cool, eh?

Comments (1) -

Thank you, been trying to get it done all day with no luck until I ran into this, it made the most sense of anything I've read on the internet today. Beers on me.

Comments are closed