WinRM over SSL/TLS with certificate authentication

WinRM (Windows Remote Management) is the service that allows managing Windows remotely; it is what sits behind PowerShell Remoting. It listens on two ports: 5985/tcp for HTTP (unencrypted) and 5986/tcp for HTTPS (encrypted with SSL/TLS). Seeing 5986 open is a hint the machine supports the secure variant.

The usual way is to authenticate to WinRM with a username and password or with an NT hash (pass-the-hash). But the SSL/TLS variant also supports a different mechanism: client certificate authentication. Instead of a credential, the client presents a certificate and its private key; if the certificate is mapped to a domain account, the server accepts the identity without asking for a password.

Service detection

nmap -p5985,5986 -sV <ip>                          # is WinRM HTTP/HTTPS open?
netexec winrm <ip> -u '' -p ''                     # confirms WinRM and the auth mode

Flow with a .pfx

When a .pfx file appears (a PKCS#12 container packaging private key + certificate, usually protected by a password), it is a direct candidate for this access:

1. Extract the key and certificate with openssl (if the .pfx is protected, first crack its password):

openssl pkcs12 -in user.pfx -nocerts -out priv-key.pem -nodes
openssl pkcs12 -in user.pfx -nokeys  -out certificate.pem

1. Present them to WinRM with evil-winrm, specifying -S (SSL) and the certificate and key paths:

evil-winrm -i <ip> -c certificate.pem -k priv-key.pem -S

If the certificate is mapped to a valid user, you get an interactive PowerShell session as that user, without ever having known their password. (If instead you have the user's password or hash, the same evil-winrm logs in with -u/-p or -H.)

Requirements

WinRM over HTTPS (5986) enabled with client-certificate mapping active, and possessing a client certificate with its private key mapped to a domain account (typically pulled from a .pfx). The certificate is equivalent to that account's credential.

How to detect it. The inbound connection leaves an Event ID 4624 of type 3 (network) on the target host, with Logon Process Kerberos/Schannel and the TLS channel's Authentication Package, toward port 5986. WinRM also logs the activity in the operational log Microsoft-Windows-WinRM/Operational (remote shell creation, Event ID 91/168). The signal is a WinRM/HTTPS logon with a certificate for an account not normally managed that way, or from an IP outside the management range. Since the attacker usually comes from a stolen .pfx, correlating access to the file (a .pfx read from a share) with a later WinRM session for that same user reinforces detection.

Defence. A certificate and its private key are, in practice, a credential: guard them like a password (do not leave .pfx files on shares), restrict which accounts allow certificate mapping to WinRM, and audit the issuance of client certificates. It chains with .pfx cracking and credential reuse.