Codebreak Hotel (part one)

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, but it was one of several initial hypotheses as to why two laptops had the same behaviour. To triage this incident, we needed to gather information off the affected laptops and analyse 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 the employees occupied at the time of the incident and if this may have affected the behaviour of their network traffic.

It turns out they were both at the same hotel on the morning of the incident and both connected to the complimentary hotel Wi-Fi. At this stage, we were waiting for access to the laptops but found it suspicious that both employees experienced the same behaviour while they were out of the office at the same hotel. Was there an attacker on the hotel’s network targeting users of the complimentary Wi-Fi service?

After getting access to the laptops, malware was ruled out early. They 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 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 example. 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 relating to the IP address. Nothing suspicious 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 and found nothing suspicious and none of the domains resolved to the IP address in question.

At this stage, with no obvious signs of why an outbound SMB connection was attempted, the Windows event log files and registry hives were extracted and analysed for any evidence of the IP address. 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.

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. But 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 at the time of the incident. 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 that there were several hostnames resolving to 66.96.162.92 ended with ‘domain.com’. This led us to try to find any evidence of ‘domain.com’ on the laptop.

Eventually, while reanalysing 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 username and password hash 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 such as the one described in this post. This can be done with Sysmon and LogRythm like in our case.
  • Organisations 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 is useful to have a triage strategy for potential incidents and take each suspicious event seriously. Even though the above event turned out to be a false positive, it was still picked up because outbound SMB connections trigger an alarm, and the next time this happens, it could be malicious.

    See part two here.

By Wicus Ross and Lauren Rudman.

  • Share