Last year, we were faced with some unusual activity on two employees’ laptops, which ended up being benign, but revealed a strange default configuration on a public Wi-Fi hotspot they had connected to. It all started when SecureData’s Managed Threat Detection (MTD) team spotted a Sysmon alarm relating to an outbound Server Message Block (SMB) traffic to ‘66.96.162.92’ on port 445.
Internet bound SMB traffic on port 137, 139 and 445 is blocked as a security precaution, because attackers can use it to harvest usernames and NTLMv2 hashed passwords. This is because Windows automatically tries to authenticate to a remote server when connecting to a share. Attackers can take advantage of this by sending a specially crafted email with a link to a remote Windows share. When the email is opened, the victim’s computer sends their username and hashed password to the remote server, which can be collected by an attacker using a tool like Responder.
This was thankfully not the case, as we later discovered. However, it was one of several initial hypotheses as to why the two laptops had the same behavior. To triage this incident, we needed to gather information from the affected laptops and analyze it to determine the source of the suspicious traffic and if the SMB connection had been successful.
We also had to determine the physical location that the employees occupied at the time of the incident and discern whether this may have affected the behavior of their network traffic.
Logic is the beginning of wisdom, not the end
We needed to have a systematic approach to our response from the very beginning. It turns out they were both at the same hotel the morning of the incident, and both connected to the complimentary Wi-Fi. Was there an attacker on the hotel’s network targeting users of the service?
After getting access to the laptops, malware was ruled out early. The devices were scanned with up to date anti-malware software that detected nothing. The corporate firewall logs were checked for outbound connectivity or evidence of blocked SMB traffic, but with no luck.
Next, we performed footprinting and open source intelligence collection (OSINT) on the IP address in question, 66.96.162.92, to determine why it might have been significant. The host associated with the IP address did not have port 445 open at the time of investigation and was associated with the domain 92.162.96.66.static.eigbox.net, at first glance. However, upon further investigation, it turned out that over 4000 hostnames resolved to the IP address.
To rule out phishing, emails on the laptops were analysed, and searched for any links to remote shares, like UNC paths. For the next part of the triage, the DNS settings, hosts file, prefetch, and start-up programs were analysed for anything suspicious of any sign of the IP address. Nothing was found in the DNS or hosts file settings and no suspicious start-up programs were found either. The browser history was retrieved and run through a script that extracted all the domains and URLs visited, which was subsequently run through an SDLab’s tool called IOCparlor that performed a reputational check. Again, nothing suspicious was found; none of the domains resolved to the IP address in question.
With no obvious signs of why an outbound SMB connection was attempted, the Windows event log files and registry hives were extracted and analyzed. There were several entries in the event log files, particularly in the SmbClient Connectivity log. This is a file that contains all events relating to SMB connections and attempts.
Something small causes a big problem
In the SmbClient Connectivity event log, we found an entry that confirmed that the SMB connection to 66.96.162.92 had failed, which was good news. However, the more curious thing was that the server name it was querying was an internal corporate network share that the laptop would connect to upon booting up according to other event logs.
However, the morning that the two employees were at the hotel, the standard corporate mapped network share resolved to the external IP address in question.
At the time of the incident, both devices were out of office and had not yet connected to the VPN. We needed to figure out why the internal Windows share was resolving to 66.96.162.92. This made us take a closer look at the domain names associated with 66.96.162.92. We noticed there were several hostnames resolving to 66.96.162.92, ending with ‘domain.com’. This led us to try and find any evidence of ‘domain.com’ on the laptop.
Eventually, while reanalyzing the registry, an entry was found in the DHCP configuration, registry key ‘DhcpDomain’, for the hotel’s Wi-Fi. The SSID issued a default DNS search suffix of ‘domain.com’ to its users. In Windows, a domain suffix search list allows administrators to override the standard Domain Name Resolver (DNR). However, in this case the Wi-Fi configuration took it upon itself to set a domain suffix - domain suffixes are used to help resolve hosts that are typically specified without a domain name.
Since the laptop was trying to connect to an internal network share by using a server name, the DHCP configuration obtained by the Wi-Fi appended the suffix ‘domain.com’ to create a fully qualified domain name (FQDN). It turns out that ‘domain.com’ is a wild card domain that would always resolve to 66.96.162.92, given an unmapped hostname. This would mean that any prefix, like an internal server name, would resolve to that same IP.
If an attacker was running a tool called Responder on 66.96.162.92, port 445 would be open and ready to capture SMB authentication attempts. The laptops would have sent their usernames and password hashes to an attacker. Luckily in this case, the cause of the traffic was a misconfigured Wi-Fi access point.
With this in mind, here are a few takeaways:
- Accessing Wi-Fi access points that are misconfigured or malicious is a clear risk. Typically, TLS and certificate pinning, if implemented correctly, will guard against man-in-the-middle attacks on most transports that use it. Ideally, we would not want staff to access public infrastructure that can subvert DNS or capture data such as SMB authentication tokens. All network traffic must flow over a corporate VPN when devices connect to untrusted networks. Network traffic must be prohibited before the VPN connection is established.
- Endpoint monitoring is important to detect suspicious events. Organizations must have access to a threat detection and incident triage team that can respond to an alert quickly and effectively. With attackers becoming increasingly stealthy, it’s useful to have a triage strategy for potential incidents and take each suspicious event seriously.
Even though this event turned out to be nothing, it highlights the need for proper incident response, even in the smallest of scenarios. We know that small things can cause big problems, so erring on the side of caution is perhaps a lesson for all. Getting the basics right can avoid huge problems; something that all companies of all sizes would do well to remember.