Uncovering a Security Compromise with ExtraHop Reveal(x) Advisor Threat Hunting

The Observation

An ExtraHop analyst helped their customer identify a number of failed logins for a certain user, one that happened to be a high-privilege account. Remote logins for this account were disabled by default, so no logins should have been coming from it.

The Problem

Using the Records feature in Reveal(x), the analyst grouped the login failures by client to identify the top offenders. Several machines appeared, but one machine was clearly punching above its weight: one with "kiosk" in its name. Turns out, it was indeed a kiosk.

The customer confirmed the machine had no business connecting to the production servers it was reaching out to, so we pivoted from Records to view the kiosk as a single asset. We found a lot of typical client activity, but we also saw some SSH server activity.

A Compromise Identified

Our next click took us to this kiosk's SSH server metrics to see who had been using SSH to connect to the kiosk. The clients button produced a wall of internet IP addresses, meaning that assets on the internet were logging into this kiosk directly.

Most server operating systems (and the kiosk in this case) come with a native, pre-installed SSH server implementation. Logins occurring over SSH obviously do not guarantee something malicious happened. Plenty of technologies and developers depend on SSH to be active in order to accomplish different tasks. However, in this situation the kiosk should not have been performing any remote logins to other internal systems.

Once an attacker gains access to a system via any means, SSH is a fantastic living-off-the-land technique used for lateral movement in a compromised network.

The Investigation

We broadened our timeframe to twenty-four hours and hit the Geomap button. Reveal(x) determined the originating IP address of each metric event and plotted it to a regional data point on the geomap. It identified that they were coming from China.

Further discussion with the customer revealed that the kiosks weren't built from a standard image, there were just guidelines and suggestions. And the security team didn't have the authority to take the kiosk off the network.

We turned our attention back to the kiosk, and picked the top external IP that was connecting via the SSH server. We needed to know what other connections that IP was making. Now that the bad guys had found one asset, had they found others? How bad was the damage?

We checked Records, "Where else has this external IP address used SSH to attempt a login?" Two clicks in Records got us a long list of customer assets this single, foreign IP was attempting to access via remote login.

A Problem Solved—Quickly

We were able to identify a breach in the kiosk and the customer assets that were being probed by the adversary. As a result the customer was able to create a response plan for disabling the kiosk and for a deeper compromise assessment leveraging their SIEM data.

We were able to scope and triage this event in less than thirty minutes.