1.Spectrum of Intrusion Detection System (IDSs)
Different people have varying expectations of an intrusion detection system (IDS). Some prefer a system that provides explicit tasks such as “disable this user’s account,” “remove this device from the network,” or “delete this file from that computer.” This approach presents clear, actionable tasks, and we refer to this design as a “tasking system.”
On the other hand, some people prefer a system that supports the exploration of their network, enabling the search for anomalies that could indicate malicious activity, and facilitating the testing of different hypotheses. We refer to this design as a “threat-hunting system.”
xVisor is a solution that straddles these two design philosophies but leans more towards a threat-hunting system (see Figure 1).
Figure 1: Spectrum of Intrusion Detection System (IDSs).
Critics argue that tasking systems can become redundant in a well-managed enterprise network where software updates are regularly applied, firewalls are optimized, robust authentication is mandatory, and administrators maintain strict control over the installation of applications on devices. In such a scenario, a tasking-centric IDS might have little to do as it could only flag issues that have already been addressed.
Conversely, the criticism against threat-hunting systems is that they demand a high level of expertise and substantial time commitment from the user, who needs to sift through large volumes of data, seeking potential threats.
In reality, few enterprise networks are managed perfectly, and few organizations have the necessary in-house expertise with ample time to continuously scan for threats. That’s why xVisor positions itself between these two design extremes.
2.Threat Hunting: Introduction and Illustration
Threat hunting is a task performed by skilled cybersecurity professionals who prefer to access low-level data with minimal interpretation by intermediate tools. For them, the ideal situation is to have all the low-level information (connection logs, audit data, login information, IP geolocation data, etc.) stored in a database. This allows them to query directly and perform statistical analyses on demand on specific data that seems relevant now.
The following scenario illustrates some of the actions a threat hunter may take on various types of data to uncover a potential compromise.
The threat hunter performs one of their regular queries, checking which addresses in the enterprise generated the most outbound traffic in, say, the past 24 hours. One address may stand out significantly from the others. The hunter now performs a second query to retrieve all outbound connections by that address, sorts the list of connections by the amount of outbound data, and displays the top-ten connections. One connection may stand out markedly from the others. This is the initial indicator that something might be wrong. The threat hunter pulls on this thread to see where it might lead. The hunter submits the remote IP address to the Shodan
service, and Shodan responds that the IP address has several known vulnerabilities. The hunter develops the hypothesis that an attacker is exfiltrating enterprise data to this intermediate address, perhaps intending to move the data from this intermediate address at a later time.
The threat hunter then looks for the original device in the enterprise responsible for the outbound connection. The hunter discovers that the enterprise IP address for the outbound connection log is a Network Address Translation (NAT) router, meaning that the IP address represents multiple devices behind the NAT router. From the suspicious connection record, the threat hunter cannot determine which device in the enterprise initiated the connection.
The threat hunter then queries the audit logs of any devices behind the NAT router for connection records to the external IP address. Fortunately, the device that initiated the outbound connection was collecting audit logs and capturing the connection in an audit record.
The audit record identifies the device that initiated the connection, the program that initiated the connection, and the parent program that started that program.
The threat hunter does not recognize the name of the program that initiated the connection. The hunter googles the name, but the search comes up empty. The hunter then queries the audit logs across the enterprise for any other instances of this program running, and again comes up empty.
The threat hunter then checks the parent program, and its parent, to determine how the program was started. It turns out the program was started in the middle of the night when the computer screen was locked (meaning the device’s user was not using it), and an automatically scheduled daemon started up, which, through a sequence of additional programs, started the program of interest. In other words, something was running in the background that the user did not initiate.
At this point, the threat hunter is suspicious enough to request that the device be quarantined. A network administrator receives the hunter’s request and places the device on a blacklist. This prevents the computer from connecting to the enterprise’s network. The device’s owner is called and told to bring their laptop in for a careful forensic examination.
3. xVisor’s Threat Hunting Capabilities
xVisor already supports key threat-hunting capabilities. Important to the threat hunter is the ability to examine the data about the enterprise network from different angles and focus on different aspects of the data. To support this, xVisor provides the user the ability to focus on traffic associated with different protocols, focus on addresses performing specific roles (client vs. server), and focus on entities from different locations [enterprise (i.e., within the enterprise) vs. Internet (i.e., outside the enterprise)].
This section shows how a user can use these capabilities in xVisor to support the hunt for threats in the network.
3.1 Focusing on Enterprise Clients
The xVisor user can view a list of enterprise clients for various protocols (e.g., SSH and HTTP) and then look up the BPS (bits per second) column to identify the devices that had the
highest sustained traffic rates over some specified time window. xVisor, by default, sorts the list of addresses by transactions per second (TPS), but the user can click on the bits per second (BPS) column to surface the addresses with the highest traffic rates. Furthermore, for each address, xVisor shows the remote address that the enterprise computer exchanged the most amount of traffic with. This remote address is in the server column.
In the following real-world example (see Figure 2), the enterprise IP address x.x.6.169 (1) peaked at a traffic rate of 56,741,188 bits per second (56.7 Gbps) (2). The remote IP address with the largest amount traffic exchanged was 8.240.216.126 (3). A quick query with Shodan showed this IP address did not have any known vulnerabilities.
3.2 Focusing on Internet Servers
xVisor also lets the user pivot to looking at the remote addresses that was responsible for the most amount of traffic. Pivoting to view the data from a different perspective is important for threat hunters.
In the following example (see Figure 3), we have pivoted to look at Internet servers (1), ordered by bits per second (2), and see the top remote server peaked at a sustained traffic rate of 69,398,967 (69.4 Gbps) (3). By scanning the other servers’ traffic rates, we see that numerous addresses had similarly high traffic rates. More interestingly, looking at the hostnames associated with the remote servers and the organizations hosting the addresses (4), we see that they all had had names that included “windows update” (5) and were hosted in major content delivery network (CDN) providers such as Level 3. Our interpretation is that xVisor is showing a moment in time when the enterprise’s Microsoft Windows computers were performing software updates.
Figure 3: Internet server activity.
3.3 Focusing on Internet Servers of Known Threat Feeds
xVisor also allows the user to focus on remote servers that are on known threat feeds (see Figure 4). That is, we are essentially looking for any computers in the enterprise that are connecting to servers suspected of being threats (e.g., command-and-control servers). This would suggest the enterprise computer was compromised. The user can perform this search by selecting “Internet Servers” (1), checking the “Threats” box (2), and reviewing the list of servers that enterprise computers are connecting to (3). In this case, the list is empty, which is a good thing, i.e., no enterprise computers are reaching out to servers on a threat list.
Figure 4: List of potentially compromised clients (list is empty).
3.4 Focusing on Internet Threats Probing the Enterprise
xVisor allows the user to look for remote addresses on threat feeds that are probing the enterprise (see Figure 5). The hunter selects “Internet Clients” (1), checks the “Threats” box (2), and sorts on BPS (3) to focus on threats with the highest traffic volumes.
Because we checked the “Threats” box, only addresses that appeared on one of the threat feeds are displayed. In the “Threat” column, we see the icon for the CINS Score threat intelligence feed (4). We see that most of these addresses also triggered the “HTTP scan” behavior (5). xVisor can flag an address by its presence on a threat feed or just by its behavior regardless of whether it is a known threat or not. In the “Country” column, we see these addresses are from all over the world (6).
Figure 5: Internet clients on known threat feeds.
For the threat hunter, the traffic volume column (3) shows the highest amount of traffic was only 7,552 bits per second (or 7.5 kbps) (7). This is an extremely low rate of traffic, so the enterprise can be comfortable knowing that none of these external threats are exfiltrating large amounts of data from the enterprise.
3.5 Next Steps in Enterprise Threat Hunting
Ennetix also has extensive capabilities for endpoint monitoring, which significantly augments xVisor’s threat-hunting capabilities. This set of xVisor capabilities will be elaborated in Part 2 of this threat-hunting white paper. xVisor has a suite of endpoint sensors, called xTend, designed to run on individual Windows, Linux, and macOS computers. xTend facilitates the shift from a network-centric view to a comprehensive view of activity across both the network and individual computers.
For instance, if xVisor flags an enterprise IP address for connecting to a known suspicious server on the Internet, data gathered by xTend enables xVisor to inform the user about the specific program that initiated the connection on the enterprise computer, how that program was launched, and what files the program might have accessed. Incorporating xTend into xVisor’s collection of sensors offers profound threat-hunting capabilities. This enables the system to trace an activity from a suspicious address on the Internet to the potentially-compromised client within the enterprise, and further to the specific process within the client responsible for the suspicious connection, and even to any files that may be involved in the suspicious activity. This chaining together of diverse data to create a comprehensive picture of an activity is what we refer to as “establishing provenance” of an event.
Stay tuned for Part 2 of this Blog!
