This issue has been fixed on Windows 8+ as part of MS16-112 issued in September 2016. I haven’t checked this on a Windows 7 machine which isn’t listed on the Microsoft page.
The basic theory behind the attack is same as @mubix ’s discovery - if you connect a network interface to a Windows system and have Responder tool poisoning the network, you can obtain the hashes (NTML responses) from the machine without any user intervention. This works even with the computer in locked state .
In my scenario, I’m using a rogue Open WiFi network to grab the hashes. The result is the same and at times, I had better results than plugging in aPi Zero. The Responder tool captures the hashes which can then be cracked using tools like hashcat .
Note: This only works with a domain joined computer. I haven’t seen a local account sending out hashes without user intervention.
LLMNR / NBT-NS poisoning- I assume this is familiar by now. If not, there are a number of good resources that explain how the Responder tool uses this to capture hashes. Here is a good write-up from Stern Security.
Open WiFi network- A WiFi network that allows clients to connect to it without needing any form of authentication and there is no channel encryption employed when the clients communicate. This includes public networks like Starbucks, Airport WiFi etc. which allows users to access internet either free or after paying a fee.
Rogue WiFi access point- An access point that masquerades as a legitimate access point by advertising the same SSID.
The catch about Open WiFi networks is that they allow clients to connect, get an IP over DHCP and share a common network with other clients. This means that an attacker waiting on the network can do things like ARP spoofing, Man-in-the-middle etc. to compromise the client. An attacker can always connect to a legitimate Open WiFi network and do poisoning attacks. However, in that case, the chances of him getting detected and logged are more. So, what are the options for an attacker?
Create a rogue Open WiFi network and wait for the client to connect.
Why should the client connect to the rogue network anyway?
This is the important bit. On Windows, when a user connects to a WiFi network for the first time, he is presented with an option to ‘remember’ the network so that the machine connects to the WiFi network every time it is in vicinity. So if you bring up a rogue open WiFi network, the client connects to it automatically without any user intervention. Also, it is to be noted that there are no notification pop-ups when the client connects to the rogue network, possibly a way to ensure seamless connectivity in an ESS network.
So, why only Open WiFi networks for this attack?
A rogue Open access network can be created just by knowing the SSID of a legitimate network. This is unlike a WEP/WPA/WPA2 network which requires the attacker to know the WiFi passphrase in order to create a rogue network and make the client connect.
So you are telling me that the client must have connected to an Open WiFi access point. Why do you think anyone will connect a corporate laptop that is part of a Active Directory domain to an unsecure Open network?
Open WiFi networks are all around us. The whole point of enterprises distributing laptops is mobility. Users connect to various networks and establish a VPN connection back to the office network to access the resources. Imagine you are traveling for work. If you need internet access, one or the other time, you will most likely end up connecting to an Open WiFi network - like hotel WiFi, airport WiFi etc. Ask anyone who travels if you are still doubtful. :)
Ok, so if I travel and indeed connect to Open WiFi networks, how does the attacker know the SSID of the network I have connected to?
There are various ways for an attacker to find this:
Monitor the client probes from the client machines that queries for stored WiFi SSIDs
Resources like Wigle.NET that serve as a database of SSIDs with locations. If needed, these SSID’s can be scripted to see which ones elicits a response from client machines
Google !! - basic recon stuff - search for the Hotel WiFi network name where the person has stayed (e.g. Marriott_Guest )
Rogue Open WiFi network
Rogue APs can be of two types:
Software based - E.g. Hostapd, Airbase-ng
Hardware based - E.g. Actual WiFi routers, WiFi Pineapple
I have seen that WiFi Pineapple has a Responder module , but I haven’t tried it yet. I will leave it for another post.
I decided to go with an actual hardware WiFi router, the TP-LINK MR3020 for the following reasons:
WiFi clients are getting smarter and they are able to detect and prevent connecting to software based APs. This can be bypassed using an actual WiFi router to which the clients connect willingly.
MR3020 is a wonderful device that can be powered using a battery pack allowing you to even do a ‘wardriving’ exercise.
It has an OpenWrt firmware with more options. However, I have used the factory firmware in this case.
A Linux machine to run Responder
I used a Raspberry Pi 3 running Raspbian (referred to as RPi here on).
An SSH client to remote into RPi and view the live capture
I connected my laptop to the rogue WiFi and SSH’ed into RPi.
Step1:Clone the Responder tool from GitHub repo on to the RPi.
Step 2:Configure the MR3020 using the SSID ( Z13_guest_wifi in my case) of the Open WiFi network that the user has connected to in the past. Additionally, set the DNS server under DHCP options to the IP of the RPi so that we get all the DNS queries. The RPi can be given a static IP every time by doing an address reservation. Toggle the hardware switch to 3G/4G so that the RPi can be plugged into it’s LAN port.