Cybersecurity Incidents Need Proper Process Like a Sword Needs a Whetstone

As security professionals, we often come across incidents that really reinforce what you learn in your profession, and put it to work. As you’ll see by the end of this article, a mere suspicion can sometimes lead to nothing, but it does serve to ensure skills and process work – skills that we provide to our customers and society at large. It just so happened that last year, one of these incidents took place.

Wicus Ross, Lead Security Researcher, SecureData

Lauren Rudman, Security Researcher, SecureData

We found some unusual activity on two employee laptops, that revealed a strange default configuration on a public WiFi hotspot that they had connected to. Whilst this ended up being benign, it still triggered a Threat Detection response in the SecureData Managed Threat Detection (MTD) team. This alarm related to an outbound Server Message Block (SMB) traffic to an IP address on port 445.

Internet bound SMB traffic on port 445, along with some others, is usually automatically blocked, as attackers can use this to gather usernames and hashed passwords. Windows will try to authenticate to a remote server when it connects to a share, and attackers are known to take advantage of this through sending what is essentially an automatic phishing email with a link to a malicious share. The victim opens the email, and their computer then sends usernames and passwords to the remote server.

This didn’t happen in this particular incident. However, it was the first idea that sprung to mind when we thought about finding a pattern between the behaviours of the two laptops. Our next lead in our investigation would be following and determining the source of the traffic, to see whether the SMB connection had worked. On top of this, determining the physical location of the employees at the time of the incident was imperative to discerning whether this might have affected the network traffic’s behaviour.

A dive into our process

The approach needed was a systematic one that covered all-bases from the very beginning of the investigation. Both employees were in the same hotel the morning of the incident, and both were connected to the complimentary WiFi. This made us ask whether there was an attacker using the hotel’s network to target users.

We ruled out malware early. Both laptops were scanned with fully updated anti-malware software; this detected nothing. Our corporate firewall logs were checked for any outbound connectivity or anything pointing towards blocked SMB traffic; these also came back negative.

“We ruled out malware early. Both laptops were scanned with fully updated anti-malware software; this detected nothing.”

Scratching our heads, we undertook footprinting and some open source intelligence collection, or OSINT, on the IP address in question. The host associated with the IP address didn’t have port 445 open at the time and wasn’t associated with the domain linked to the IP address at the time. However, it turned out that over 4000 hostnames resolved to that IP address.

We ruled out any phishing, after analysing emails on the laptops and searching for links to any remote shares. The next step in the triage was analysing DNS settings, hosts file, prefetch, start-up programmes and host file settings for any indication of the IP address. Nothing.

Browser history was retrieved and run through a script that extracted all domains and URLs, which we ran through one of our tools, IOCparlor, that performs reputational checks. Again, nothing. None of the domains resolved to that IP address.

The small bug that made a big difference

With no signs of why an outbound SMB connection was attempted, we then tried something else. Through analysing the Windows event log files and registry hives, we identified several entities in the SmbClient Connectivity log – a file that contains all events relating to SMB connections and attempts.

In that log we found an entry confirming an SMB connection to the suspect IP address had failed – good news! What was curious, however, was that the server name it was querying was an internal corporate network share that the laptop would, in theory, connect to upon booting up. The morning that the two employees were at the hotel, the corporate mapped network connects to that same IP address.

At the time, both devices were out of the office, and hadn’t yet connected to our VPN, so we needed to figure out why the internal Windows share was resolving to that IP address. To do this, we took a closer look at the domain names associated with it and noticed that there were several hostnames resolving to it, ending with “domain.com”. We then tried to find any evidence of “domain.com” on both laptops.

“Luckily, the cause of this traffic was a badly configured WiFi access point, however it could have been much worse.”

Eventually, after reanalysing the registry, an entry was found for the hotel’s WiFi. The SSID issued a default DNS search suffix of “domain.com” to its users. Normally in Windows, that search list will allow administrators to override the standard Domain Name Resolver (DNR) – however this time the WiFi configuration decided to set a domain suffix.

Typically, these suffixes are used to help resolve hosts that are generally specified without a domain name. As the laptop was trying to connect to an internal network share by using a server name, the configuration obtained by the WiFi attached the “domain.com” suffix to create a fully qualified domain name.

We found that “domain.com” was a wild card domain that would always resolve to that IP address, if given an unmapped hostname. This means that any prefix, such as an internal server name, would also connect to that same IP address.

Luckily, the cause of this traffic was a badly configured WiFi access point, however it could have been much worse. If an attacker was running a tool called Responder on that IP address, the 445 port would be open and ready to capture any Windows SMB authentication attempts. This would then, in turn, mean that laptops would have sent their usernames and password hashes to an attacker– which is bad news.

What we learned

As with all incident response activities, there were things to learn. The first is obvious: accessing WiFi points that are misconfigured is a clear risk. Usually TLS and certificate pinning will guard against man-in-the-middle attacks.

However, to ensure proper safety, a few points can be implemented. Ideally all network traffic must flow over a corporate VPN when devices connect to untrusted networks, and network traffic must be prohibited before the VPN connection is established.

Secondly, endpoint monitoring is be critical. It’s such an important tool for detecting suspicious events. Organisations must combine this with threat detection and incident triage teams in order to respond to alerts swiftly and efficiently.

Attackers are getting more brazen in their ways, but also stealthier. Every organisation, no matter the sector, must have a triage strategy in place, and each suspicious event must be taken seriously.

Finally, despite events perhaps turning out to be minor, or indeed nothing, there is a clear and present need for proper incident response. Small actions that ensure processes are followed can prevent big security problems.

We know that small things can cause big problems, and so acting with the same process for any suspicious activity, no matter the size, is a lesson for all security teams in all organisations.

Share this article