WMkick is a tool we recently released to MITM and capture NetNTLMv2 hashes for some protocols not (yet?) supported by other tools like Responder, such as WMI access to MS-RPC (135/tcp) and Powershell Remoting/WSMan/WinRM (5985/tcp).

We have observed various enterprise software that continues to rely on Microsoft's Windows Management Instrumentation (WMI) for remote authentication, which can be leveraged by attackers, even passively, to steal hashes that can be converted to credentials. There are WMI clients programs that initiate NTLMSSP authentication flow over the WMI access port (tcp/135), which can be redirected in order to gather all the pieces needed to obtain a valid NetNTLMv2 hash. A valid NetNTLMv2 hash can be cracked into plaintext credentials, to gain further access into the network. The accounts used in these applications are often privileged accounts, as WMI remote authentication is often used to perform administrative tasks such as running remote commands, asset inventory management, and scanning.

WMkick is a TCP protocol redirector/MITM tool that targets the Windows NTLM authentication message flow. Anyone with access to an internal network can leverage WMkick to capture administrative hashes if WMI is being used to remotely administer within the network and mitigations have not been enforced, such as disabling NTLM authentication.

We think the security community should give MS-RPC more attention, and others are starting to do so. Eventually we hope to build/add enough of an MS-RPC implementation and impersonation into WMkick that redirecting is no longer needed.

What can enterprises do to reduce their exposure?

• WMI Identity and Access Management: Monitor for remote WMI commands and activity. Note the applications using it. Determine if the application is necessary, and disable it if possible. If not possible, verify that the credentials being used are not domain administrator credentials or any high-privilege credential. Use a separate account specific to the WMI task. Ensure the credential being used is the lowest possible to do its job, and monitor for logins for that user account.
  
  
• Disable NTLM authentication and use Kerberos. Ensure your products are not using NTLM authentication. (Some off the shelf software does not or did not support Kerberos for WMI, for example: https://kb.paessler.com/en/topic/67662-wmi-ntlm-connection)
  
  
• Make the password for the WMI client account extremely complex and long, and rotate it regularly. If you cannot disable NTLM authentication and must rely on the application, assume the attacker can gather the hash.

The details: What is WMI, RPC, and NTLM and how do they all relate?

• WMI - The Windows Management Instrumentation is the infrastructure for management data and operations on Windows-based operating systems, often used by scripts or applications to automate administrative tasks on remote computers.
  
  
• RPC - A Remote Procedure Call is when a program executes a procedure on a different computer. In Wireshark, captured traffic will likely show as 'DCE/RPC', a protocol standard for RPC designed by the Open Group. WMI uses DCOM which uses RPC. RPC can use various transport methods (TCP, UDP, SMB). We explore WMI over RPC over TCP.
  
  
• MS-RPC - Microsoft RPC is Microsoft's proprietary version of DCE/RPC. The RPC endpoint mapper which resolves interface identifiers to transport endpoints listen on Windows machines on TCP port 135 by default.

Example Network Flows

WMI client applications use the RPC/DCOM port tcp/135 on Windows as the WMI access port. Typical flow observed from Wireshark for WMI is as such (this is from a WMIC command or other WMI application):

1. Getting to a ServerAlive2() procedure.
   
   
   1. "Host A" is a WMI client which makes a tcp handshake with a Windows "Host B" on port 135, where the RPC server is hosted.

      A -> B |SYN
      A <- B |SYN,ACK
      A -> B |ACK

   2. "Host A" uses DCE/RPC-MSDCOM, requesting to RPC bind and "Host B" replies to accept the request and agree on the syntax.

      A -> B |DCE/RPC-MSDCOM/DCOM bind
      A <- B |DCE/RPC-MSDCOM/DCOM bind_ack

   3. "IOXIDResolver" is an Interface part of DCOM remote object activation, its identifier is "99fcfec4-5260-101b-bbcb-00aa0021347a". A pentester could use the ServerAlive2 RPC method to collect the network interfaces remotely, which is the current research. The WMI client will not start the NTLMSSP authentication flow if a ServerAlive2 is not returned.

      A -> B |IOXIDResolver ServerAlive2
      A <- B |IOXIDResolver ServerAlive2

2. Now "Host A" starts an NTLMSSP authentication flow!
   
   
   1. Second TCP handshake from "Host A" to "Host B" on port 135.

      A -> B |SYN
      A <- B |SYN,ACK
      A -> B |ACK

   2. WMI clients (tested on Lansweeper, wmic, Spiceworks) open a second RPC/TCP request and authenticate with NTLM.

      AUTH_3 NTLMSSP Auth flow start
      A -> B |NTLM NEG
      A <- B |NTLM CHALL
      A -> B |NTLM AUTH

      This is as much as we care about to get the NTLM.
      
      
   3. This is where we could research and get into more attacks!

      A -> B |ISystemActivator
              (This interface calls RemoteCreateInstance)
              (ObjReference is "MEOW" lol)
      A <- B |ISystemActivator
              (This responds with an IP/hostname and gives an
              ephemeral port for wmi to use [if we are MitM,
              it gives the address of our target machine.])

What WMkick does is waits and listens on TCP port 135 for a WMI connection. You configure it to point at a Windows host or VM running an actual MS-RPC endpoint mapper. There are challenges and it can be time consuming to reverse MSRPC, so the quick solution was to redirect traffic to a real implementation. Redirecting the traffic is necessary to capture the entire authentication flow.

The use case for this is an attacker, red-teamer, penetration tester could plug into an enterprise network with WMkick running and configured and an inventory management tool or other software or script would sweep over the assigned range of the device, exposing the administrative credentials in the form of the NetNTLMv2 hash. Some Network Access Control (NAC) implementations may reach out to any device as soon as it connects, providing you with a NetNTLMv2 hash right away.

Here you can see WMkick in action:







This is why password strength remains important. The hash alone is not valuable until cracked. KoreLogic specializes in password cracking (see our DEF CON contest and Password Recovery Service), so we like hashes. This is low risk technique to potentially grab an administrative hash.

Again, WMkick is not an NTLM relaying tool yet. There is similar research being started in this area.

Other Recent MS-RPC MitM Work

Since starting to look at WMI and RPC, both have been getting more scrutiny from the security community (a good thing), but there is plenty more to analyze. Some related work:

1. Compass security has already published some excellent work on NTLM relaying and the issues with SMB and RPC.
   
   In the article they propose adding more support for the MS-RPC protocol to ntlmrelayx. They mention that integrity requirements have been added by Microsoft for Task Scheduler Service but global integrity requirements for RPC are still missing. They also state: "MS-DCOM is used by MS-WMI and would be a nice attack vector. However, as a typical WMI code execution requires authenticating to several RPC interfaces, it's not the best choice for the NTLM relay attack (without a re-authentication method)." While this is true for relaying, it is fairly trivial with WMkick to get a NetNTLMv2 hash by listening for software to connect to the attacker machine over WMI using MS-RPC TCP/135, as it has been observed that WMI clients will still authenticate to the MS-RPC TCP/135 access port with NTLMSSP.
   
   Initially, I thought to create my own RPC server, which is if not difficult, time consuming. A lot of the current work has been on connecting and interacting with RPC/DCOM/DCERPC/MSRPC from a client perspective and less from the server side.
   
   
2. A favorite open source network penetration tester tool of mine for stealing network hashes is "Responder.py". It attracts various network traffic through poisoning, and functions as a MITM relay in order to steal NetNTLMv2 hashes found in a Windows environment. Once captured, the hashes can then be cracked into useable credentials within the domain. Recently, Responder has begun to add RPC servers, but nothing specific to WMI just yet. In fact the desire to create WMKick came partly inspired by Responder, and spurred by its lack of WMI support.

Why WMkick; aren't there tools to capture NetNTLMv2 already?

• At the time of this writing, Responder did not have a WMI specific RPC server (although it now has RPC servers for other services).
  
  
• WMkick is opportunistic, if a tool or script is scanning over the IP using WMI over MS-RPC (or WSMAN-HTTP), it will capture the NetNTLMv2 hash. And it may be possible to solicit this traffic with Responder or mitm6.
  
  
• WMI over MS-RPC will use NTLM even when domain joined and using a domain user.

Although other tools exist that capture NetNTLMv2 hashes on the network, they are not monitoring the WMI over MS-RPC tcp/135.

Below are some other, existing tools I tried:

• Responder.py - UDP 137, UDP 138, UDP 53, UDP/TCP 389, TCP 1433, TCP 80, TCP 139, TCP 445, TCP 21, TCP 3141,TCP 25, TCP 110, TCP 587 and Multicast UDP 5553. And very recently, some 135.
  
• PCredz - Also by Laurent Gaffie, the author of one of my favorite tools, Responder
  
• net-creds - By Dan McInerney
  
• some others - focus on http, smb, and Responder
  

Not tested yet:

• Inveigh - Captures NTLMv2 Authentication attempts over Windows SMB
  
• NetNTLMv2-Sniffer - Specific to SMB2 datagrams
  

Both PCredz and net-creds.py will capture and extract the NetNTLMv2 hash, but only when you can get the entire NTLMSSP authentication flow via redirection with WMkick.

Issues and next steps

My initial expectation was that all WMI traffic goes through TCP port 135. This is not the case. WMI will use MSRPC tcp/135 to authenticate and the endpoint mapper on that port will tell the victim where to go for the WMI service (which host/IP/dynamic-wmi-port). So I was using WMkick to MitM the WMI access port traffic, but after authenticating with the endpoint mapper, the WMI traffic from the victim went directly to the target WMI machine and used SPNEGO to authenticate. As the MitM, it seems possible to splice and replace the WMI host, WMI port, and preferred authentication scheme with some more reverse engineering.

Goals for further development are to find or build enough MS-RPC support that we can carry out a conversation long enough to not need to redirect to a real Windows stack, and to explore WinRM more.