Every attack leaves a trail behind, and these trails are used by those of us on the Blue Team to discover the threat actors. Sometimes, though, it can be difficult to extract network-based indicators because of the complex and distributed nature of an organization’s ICS network.
Intrusion detection systems (IDS) are an ideal solution to detect and collect indicators of compromise for today’s complex ICS networks. A passive IDS does not introduce any traffic into the network, a necessity for ICS networks, and can monitor both east-west and north-south traffic, versus boundary devices such as firewalls that only analyze traffic passing through the boundaries. Furthermore, if a passive network IDS fails, the network continues to work. This is critical for OT networks, as availability is the most important component of the “Confidentiality, Integrity, and Availability” (CIA) triad. Although certain active network security solutions (see ICS Patrol™), are showing a lot of promise, to receive buy-in from the operators of ICS networks, it is best to start with a completely passive solution.
When implementing a network intrusion detection system, organizations need to decide whether to have a centralized or distributed sensor model. Distributed is typically better due to the minimal traffic necessary between the IDS solution and the main log aggregator. Centralized models increase network bandwidth in already limited bandwidth environments because of the need to feed all data to a central system that performs all the analysis. When you want to monitor a remote site, which may only have a microwave uplink or an old T1 line for connectivity, then having the intelligence and analysis at the distributed sensors becomes even more important.
Network Logs vs. Host Logs
There are two types of logs which an organization can collect and use for threat hunting, network logs and host logs. Network logs include everything done over Ethernet or wireless. This is the examination of traffic sent between devices, including the protocols and function codes used. Another way to think about this is the interaction between devices. Host logs are activities done on a single host.
Consider the following scenario: Host A communicates with Host B using Protocol X. The conversation happens back and forth and ends. This is an example of network logs. Host B takes some action based on what Host A told it, such as restarting or a user logging off. Host B will usually log that it took those activities and save those logs on itself. Those logs, located on Host B, are host logs.
Host logs can record activities performed either remotely or while physically present. Network logs can include remotely based activities of the host but do not include physical activities such as a user being present on a keyboard in front of the device.
Neither log type is better than the other. Actually, both logs are necessary for complete visibility of the whole operational network. Let’s go through a use case of GreyEnergy, which ESET recently released information about. GreyEnergy is known to target ICS workstations and servers running SCADA software. The malware uses multiple modules to complete its tasks, including open-source tools such as PSexec and mimikatz.
The following shows a common attack path this malware would use:
- The malware infects a host in the network (compromised host #1)
- The malware uses mimikatz to extract passwords from Windows operating system running on compromised host #1
- It then uses PSexec to laterally move from a compromised host #1 to another host (compromised host #2)
- Uses file operations to move necessary modules from compromised host #1 to compromised host #2
- Rinse and repeat
Log correlation could help identify this attack chain. Network logs would help identify malware performing lateral movement and remote file operations. The tool PSexec can use a protocol like SMB and DCOM. When executing lateral movement the tool uses DCOM, although it encrypts the data layer, still shows the function codes. Function codes utilized by PSexec are uncommon in practice, both in IT and OT networks. Remote file operations are generally plain text. Protocols such as SMB and FTP are a quick and easy way to move files between Windows operating systems. Generally, when developing malware, the goal is “Living off the LAN” (LOTL). The malware will use tools that are commonly found on the operating system. The need to compile new libraries is limited when using LOTL. Using a network IDS allows a defender to identify and correlate this activity.
At the same time, host logs would identify the extraction of passwords from memory and binaries being injected into memory. These event logs will show commands being executed in PowerShell and processes starting and stopping.
If a security analyst was to examine just host-based logs or network logs, the practitioner would only see half of the conversation. By correlating across both types of logs, the practitioner would identify the compromised system and the path the malware used, allowing for immediate incident response and containment.
Is one better than the other? No! They both have their place, but to increase visibility of operational networks, the security team needs both. Most operational networks do not have an integrated system that uses both host- and network-based logs. The lack of visibility into these operational networks needs to end. Over the last couple years, there have been multiple examples of malware and APT groups targeting ICS networks, and they seem to be happening more frequently.
We’d love to continue the discussion with you. To learn more about how SilentDefense and ICS Patrol™ help you gain visibility into your ICS network with enhanced log correlation, connect with us here.