Threat Hunting IoT and IIoT Devices

Intro

One of the challenges of agent-based security solutions is that they leave you with blind spots. They will help to lock down any operating system that the agent supports, at the expense of ignoring all other devices. This can take the form of unsupported operating systems, network hardware, mobile devices, as well as both Internet of Things (IoT) and Industrial Internet of Things (IIoT) devices. In this blog, I’ll discuss how to ensure you get threat hunting coverage of every device on your network, regardless of platform.

 

IoT and IIoT Threat Hunting Challenges

IoT and IIoT are arguably some of the most difficult devices to secure. While a desktop or server operating system is designed to incorporate a wide range of functions (Web, DNS, mail, etc), IoT and IIoT devices are typically dedicated to a specific task. For example, a device may only measure temperature or atmospheric pressure. This places a high priority on efficiency, so IoT and IIoT operating systems tend to be optimized to reduce power, memory, and CPU requirements.

This focus on efficiency makes it difficult if not impossible to run a security agent. In fact, many devices do not support Syslog so they do not even have the ability to collect system events onto a remote logging server. This means we cannot rely on the devices themselves to provide a proper forensic trail to identify when they have been compromised. This forces us to perform our threat hunting activities outside of the device and on the network itself.

 

Network Threat Hunting IoT and IIoT Devices

One of the nice things about threat hunting IoT and IIoT devices on the network is that the process is identical to how you would threat hunt desktops and servers. In fact, we can run through our network threat hunting process without regard for the type of endpoints. The process will be identical regardless of the platform being evaluated.

For example, in a network threat hunt, you first want to check for persistent connections. We want to see if any of our internal systems are in constant communication with a host on the Internet. These connections could be an indication of an active Command and Control (C2) channel. Consider the graph in Figure 1:

Figure 1: The number of connections from an internal host to a system on the Internet graphed in 15-minute increments over a 24 hour period of time.

Figure 1 shows the connection frequency between one of our internal hosts and a host on the Internet. This has been graphed over a 24 hour period of time. Every bar in the chart represents the number of connections that took place in a 15 minute time period. We are not so much concerned with the quantity of connections in each 15-minute interval, so much as each 15-minute interval showing a consistent number of connections taking place. This consistency in timing could be an indication of a C2 connection that is beaconing.

We can also analyze the communications based on the amount of data being transmitted each time the internal system connects to the external host. Consider the graph in Figure 2:

Figure 2: The number of connections graphed based on the amount of data that was transferred. Consistency in session size can be an indicator of a C2 activity.

Figure 2 is indicating that over the 24 hour period that is being analyzed, approximately 42,000 connections transferred 52 bytes of data. This consistency in session size could also be an indicator of a C2 connection that is beaconing. It is indicative of a compromised system calling out to a C2 server looking for commands to execute but finding none in the queue. Note that we do have one session with 104 bytes that were transferred. This could be an indication that over the 24 hour period of time there was one set of commands waiting in queue, and the execution of those commands resulted in 104 bytes being transferred instead of the usual 52 bytes.

 

Applying Network Threat Hunting to IoT and IIoT Devices

Note that in the above two examples we made no mention of the operating system or whether Syslog was available to collect forensic data. This is because these data sources did not matter. By watching the network connection to the Internet we are able to see all instances of suspect C2 traffic, regardless of the operating system involved. The internal system could be a user’s desktop, or it could be an IIoT device. It does not matter, as we would perform the same initial steps regardless of the platforms in use. Now that we know a potential C2 channel is present, we would want to dig deeper to identify the platform and see what other forensic evidence (if any) is available. However, our ability to detect the C2 channel was not impacted by these factors.

 

Lessons Learned

We tend to rely heavily on agent-based endpoint security software as well as system logs collected with Syslog. The reality is that not all systems are capable of running a security agent, or logging to a Syslog server. This is especially true for IoT and IIoT devices. The result is blind spots as we hunt our network for indicators of compromise. By first threat hunting the network, we can incorporate all platforms, including IoT and IIoT devices.