Windows 7 and SMB Relay

Lately we have had a number of posts about our training classes, and I said I would put something technical up on the blog. In one of our classes, we teach students how to think like real bad guys and think beyond exploits. We teach how to examine a situation, how to handle that situation, and then how to capitalize on that situation.  Recently on an engagement, I had to figure out how to exploit a domain-based account that could log into all Windows 7 hosts on the network, but there were network ACLs in place that prohibited SMB communications between the hosts. So, I turned to SMB relay to help me out. This vulnerability has plagued Windows networks for years, and with MS08-068 and NTLMv2, MS started to make things difficult. MS08-068 won't allow you to replay the hash back to the initial sender and get a shell, but it doesn’t stop you from being able to replay the hash to another host and get a shell – at least, it doesn’t stop you as long as the host isn't speaking NTMLv2! By default, Vista and up send NTMLv2 response only for the LAN Manager authentication level.  This becomes problematic in newer networks, as seen in this screen shot from my first attempt to do SMB relay between two Windows 7 hosts:

In this scenario, we have host 192.168.0.14, which I have compromised and have discovered that the domain account rgideon can probably authenticate into all Windows 7 hosts. We have applied unique Windows-based recon techniques that we teach in our class to determine this. We see that 192.168.0.13 is also a Windows 7 host, and we will look to authenticate into it, but we can't do it from the .14 host. There is a firewall between .13 and .14; so instead, we will attempt to do SMB Relay with host 192.168.0.15 as the bounce host.

So, what can we do in this scenario? We don't teach too much visual hacking in any of our classes, so everything must be done using shells, scripts, or something inconspicuous. In this situation, I did some research looking into the LAN Manager authentication protocol. I found a nice little registry key that doesn't exist by default in Vista and up, but if we put the registry key in place, then the LAN Manager authentication settings listen to the registry key.  This happens on the fly; there are no reboots, logon/logoff's, etc. There is a caveat with this! You have to have administrator privileges on the first host!  This scenario is about tactically exploiting networks and doing this the smart way.

Since we have a shell on our first host (192.168.0.14) and we have gotten it by migrating into processes, stealing tokens, etc., we can move a reg file with the following contents up to the first host.

This registry key is targeting the following path:  HKLM\SYSTEM\CurrentControlSet\Control\Lsa.

If we drop in a new DWORD value of 00000000, this will toggle the LAN Manager authentication level down to the absolute minimum, which will send LM and NTLM responses across the network. Now that we have the LAN Manager authentication value set to as low as it will go, we can capitalize on this.

Open a metasploit console (you will need admin privileges) on the host that will be set up as a bounce through host (192.168.0.15). With your msfconsole, use the exploit smb_relay and whatever payload you choose. I have chosen to use a reverse_https meterpreter. The screen shot below is an example of my settings:

Once all your settings are selected, exploit and get ready for the hard part.  We need to get this account to attempt authentication to our bounce through the host with LAN Manager authentication. SMB relay in this setting is probably best used by getting the account you are targeting to visit your malicious host (192.168.0.15) through a UNC path (\\mybadhost\\share).  Getting a user to do this is not something we will go into in this post. We reserve that type of thing for teaching at the class, but we have used this tactic, coupled with a few others, to compromise almost a whole Windows domain.

For brevity’s sake, we will just go ahead and simulate this activity by simply typing the following in the run dialogue box on the first victim host:  (192.168.0.14) \\192.168.0.15\share\image.jpg.

I am not really hosting anything as a share on my host. I just need the LAN Manager authentication process to attempt authentication to my host (192.168.0.15). This attempt of authentication actually happens even by just typing \\192.168.0.15.  With just the IP address entered, you will see authentication attempts to your host, but for large scale attacks, or something along those lines, it is best to have a full UNC path.   Once the rgideon account on host 192.168.0.14 starts authentication requests to our relay host 192.168.0.15, things will actually look as though they are being denied by the end host 192.168.0.13:

As you can see, we are receiving LAN Manager authentication requests from 192.168.0.14 and attempting to relay them to 192.168.0.13, but it looks as though they are being denied. This is a false negative.  Type in sessions -l in your metasploit console, and you will see that you have a meterpreter session on 192.168.0.13.

This is a simple demonstration and exploit that we teach in some of our offensive-based classes. Our Offensive Techniques is a class based on trying to show people real-world attacks coupled with unique approaches to compromising both Windows and Unix infrastructures.  Offensive Techniques has various sections in it that we have seen used in APT attacks, and the class also includes custom techniques built and used by Attack Research.

The goal of our training is to get you out of the mindset of traditional pen testing and show students how real offensive attacks really happen.  We are hoping these types of concepts spread to the whole industry.  When this happens we will be able to make an impact at the business level on how companies, governments, etc., make decisions based upon real security threats and a true security landscape.  If you are interested in training that we released yesterday or have questions please visit our site or email us at training@attackresearch.com with any questions. 

R.