Using NetMon to Detect Modbus-Based SCADA Attacks
With LogRhythm NetMon, you can analyze traffic flow between supervisory control and data acquisition (SCADA) systems, helping prevent major breaches of industrial control grids. As control platforms, SCADA systems are geographically spread across large distances and comprised of vast grids of pipelines.
A few organizations that use SCADA systems are:
- Electric utilities companies
- Water suppliers
- Oil and gas companies
- Automotive manufacturers
- Product manufacturers
- Chemical manufacturers
SCADA Systems Explained
Here we can see the general layout of a SCADA system:
Figure 1: SCADA System Layout
The master server, communicating with Programmable Logic Controllers (PLCs) and Remote Terminal Unit (RTU) field devices through a WAN connection, collects data or acts out conduct functions (e.g., close a valve, alarm for chemical imbalances). The master polls sensors for status constantly in a simple request/response protocol through the somewhat antiquated (developed in 1979), albeit ubiquitous, Modbus SCADA protocol. Modbus is implemented by hundreds of vendors to read the input values and change the output for thousands of industrial control devices.
Identifying Risk and Vulnerability in SCADA Systems
The problem with the Modbus protocol is that there is no security, no encryption, and no authentication! If attackers can gain access to the network where a single master server is talking to thousands of PLCs and RTU devices, they can exploit any of the available tools and send control signals to any of the field devices.
To begin, attackers will typically compromise the Human Machine Interface (HMI) system to visualize the valves and sensors or to understand the process itself. They could also compromise the engineering workstation where the project files are located to obtain information about how the process works. Once the attackers have all this information, they can change values and physical processes.
When talking to a PLC via the master server, digital inputs or outputs are known as coils. Bit level functions are either on or off. Common write functions actions include:
- Turning something on or off, such as a valve.
- Changing some type of analog output.
- Turning multiple coils on or off.
- Changing multiple analogs’ device output.
While writes are less common, they are still part of the real-time process. Whether a company uses writes or not is purely based on how their engineers have designed each process.
Here we can see a major list of write functions:
Figure 2: Write Functions
Using NetMon to Detect SCADA Modbus-Based Attacks
In order to detect indicators of compromise in SCADA systems, traffic flow between the master station and field devices can be spanned and fed into LogRhythm NetMon. NetMon can identify Modbus protocol and decode the packet, and is flexible enough to allow users to choose which function to alert or not.
In our example, write function code 15 is not normal behavior within the SCADA environment, so we can establish alert rules for when this write function is employed. Let’s walk through how to set this up in NetMon.
This DPA rule will extract the write function 15 from the offset of the 62nd byte (DPA rule available in LogRhythm Community).
Figure 3: DPA Packet Rule
When we type the application name ‘Modbus’ into the NetMon dashboard search area, all Modbus traffic is brought forward for visualization.
Figure 4: Modbus Search Results
From this extracted metadata, we are interested in function code 15. With the DPA rule, custom metadata is created for function 15 with the Name ‘Write_Multiple_Coils.’
Figure 5: Extracted Metadata from Search Results
We can then create alarm rules for function 15. If a compromise occurs, an alarm is generated for attacks based on ‘Write_Multiple_Coils’ for function 15 for multiple sessions and PCAPs can be downloaded for that particular session:
Figure 6: PCAPs Available to Download
LogRhythm NetMon implementation into SCADA systems can be a robust tool in detecting and responding to compromises. While Modbus may be a vulnerable protocol as far as its lack of security structure, setting alarms to detect anomalous behavior is a very effective way to help protect access and control of sensitive resource systems.