In this blog post, we will go into detail on how DNS search suffixes can be used maliciously to gather usernames and NTLM password hashes from unsuspecting victims connecting to a Wi-Fi network.
In the previous blog post we mentioned that when two of our employees were connected to the complimentary Wi-Fi at the same hotel, their laptops were assigned a Connection-specific DNS Suffix of ‘domain.com’. These DNS suffixes are used when there is a DNS query without a Fully Qualified Domain Name (FQDN) or if your workstation’s hostname has been registered with the local DNS server.
When our employee’s laptops attempted to connect automatically to a previously mapped network share, it triggered an alarm in the SecureData Managed Threat Detection System highlighting outbound network traffic on port 445. This was because the network shares were not using FQDNs, as they belonged to SecureData’s internal network, so the search suffix ‘domain.com’ was appended to the end in order to create a FQDN. This resulted in the new share names being domain.com subdomains. For example, ‘share.domain.com’, which made the names resolve to one IP address on the internet. This is because ‘domain.com’ is a wild-card resolver and will resolve most sub-domains to a single IP address.
Windows network traffic associated with network shares uses the Server Message Block (SMB) protocol on port 445 and is usually blocked by organisations’ firewalls if the connection is going out to the internet. This is because attackers can use these connection attempts to gather Windows credentials.
We conducted research on domain.com itself and found that it is a legitimate business where domain names can be purchased. They also sell hosting plans, virtual private servers (VPS), SSL certificates, and more. We concluded that there is no easy way to abuse the wildcard resolver for domain.com as we have no ability to influence the sub-domain resolution process. In other words, we could not get domain.com to resolve a host to an IP that is linked to a host under our control.
To demonstrate how an attacker could take advantage of a Connection-specific DNS Suffix, in order to gather usernames and NTLM password hashes, from computers that have connected to a Wi-Fi network, we set up a lab environment. This consisted of four parts: a Wi-Fi access point, a victim laptop, remote server and a domain name. We were trying to simulate a coffee shop or B&B type scenario where a Wi-Fi network was configured to give a malicious DNS suffix to users. This could be set up by an owner of the establishment, or anyone with access to the device’s configuration.
When a user connects to the legitimate Wi-Fi network, they will be assigned an IP address and a Connection-specific DNS suffix. When they reboot their laptop, and were previously connected to a network share without a FQDN, the victim’s laptop would send their username and password hash to the attacker’s server without their knowledge.
For the Wi-Fi network, we created an access point on a laptop using a program called hostapd. It is a host access point daemon program that lets you configure and run an access point on a computer. On the same laptop we also ran dnsmasq, which provided the DNS forwarder and more importantly the highly configurable Dynamic Host Configuration Protocol (DHCP) server. This DHCP server was set up to give a DNS search suffix of ‘tikoloshe.net’, a random domain we previously purchased. A screenshot of the configuration file for dnsmasq can be seen below:
For the victim’s laptop, we used Windows 10 that was on a workgroup and connected to a share. Additionally, we used the purchased domain name and created a wildcard subdomain for it that pointed to a remote server under our control. This meant that someone trying to access any subdomain of our domain name, would be directed to our server.
On the remote server we ran Responder, a program with a built-in SMB rogue authentication server, that opens port 445 onto the internet. Port 445 is used for the SMB protocol, which network shares use. When a computer attempts to connect to a remote share, it tries to authenticate and Responder is able to capture the SMB authentication username and NTLM password hash.
To start the scenario, the victim laptop authenticated to the Wi-Fi network. Below is a screenshot of when ipconfig was run on the Windows machine. As you can see, the Connection-specific DNS suffix is set to a domain under our control.
Wireshark, a network protocol analyser, was run on the victim’s laptop, to capture network traffic, while a remote share called \\server\share was being accessed manually and it resulted in the DNS requests below. These DNS requests were to server.tikoloshe.net because the laptop could not resolve the name ‘server’.
After the DNS requests, the victim’s laptop started to connect to server.tikoloshe.net, which has resolved to an IP address of our malicious server. As shown below a TCP connection is set up and then the SMB protocol negotiation is started.
When the attempts to connect to server.tikoloshe.net via SMB 445 were made, Responder captured the victim’s username and password hash. From here, the hash would need to be cracked by a program like hashcat.
A more realistic scenario is shown below, where a user does not have to manually connect to a share in order for an attacker to steal their password hash. They would just have to connect to a malicious Wi-Fi network with a laptop that has a previously mapped network share and at some stage, restart their computer.
Users of public Wi-Fi networks should always be cautious of the risks involved even in the few seconds after they have connected to a network. Additionally, to mitigate the risk it is recommended that network shares/mapped drives are disconnected before attempting to join any untrusted networks.
In Windows, ‘ipconfig’ can be run in the command line to determine if a suspicious Connection-specific DNS suffix has been assigned. If this is the case, the network may not be considered safe.
See part 1 here.