Flexible, cloud-backed Modbus/TCP log collection with NXLog and Python

Modbus is a low-level protocol that effectively uses only two data types: bits (in the form of coils), and 16-bit words (in the form of registers), which are also the only form of data that can be natively addressed with most devices. Other data types are effectively piggy-backed on top of these two data types, in whatever fashion each manufacturer finds most convenient. Thus, even extracting simple application data — such as sensor readings or application requests — out of individual packets requires some post-processing effort, which is often device-specific.

The Modbus protocol also has a number of quirks that can make interaction between devices more difficult to analyze. For example, error responses contain very little information besides the error code itself, and even that is not very informative. Extracting high-level application traffic data often requires correlating data from multiple packets.

NXLog offers several ways to handle and analyze this kind of traffic. The approach that we will explore today will:

In order to illustrate traffic collection and analysis, let us consider a simple process controller device which supervises a temperature-driven process and can emit temperature alerts as soon as the monitored temperature is no longer within a safe range.

This device exposes temperature readings via register 0x04. Reading that register will return the current temperature reading as an unsigned integer in tenths of a degree. For example, a temperature of 38.9 degrees Celsius will be read as 389. Two temperature alert thresholds — a low threshold and a high threshold — can be read and written from/to registers 0x00 and 0x01. The alert mode (disabled, high, low, high/low) can be read and written from/to register 0x02.

In order to modify the temperature threshold, a specific passphrase needs to be written using the Write Multiple Registers command starting at address 0x1F. Writing the wrong passphrase will trigger an exception response, whereas writing the correct passphrase will just trigger a regular Write Multiple Registers confirmation response. The Write Multiple Registers error response does not include the register address or word count of the request that triggered it, but it can be matched to the original request via the transaction ID field.

Most Modbus devices do not natively support encrypted communication, so this is more of a safety feature to guard against accidental writes than a reliable authentication and authorization feature. However, failed "login" attempts and unauthorized temperature threshold modification attempts are typical signs of low-effort, automated attacks.

As an exercise, we will configure NXLog to detect failed login attempts and log them to a Microsoft Azure Sentinel custom table, which can be used by Azure Sentinel or any other SIEM with a log analytics backend.

We will use im_pcap to capture Modbus traffic and a small post-processing routine written in Python that is called using xm_python, to detect failed login attempts. The script will tag security-relevant packets that we will use to build a security alert, which we will then post to Azure Sentinel using om_azure.

Let’s start with a simple prototype that will analyze Modbus traffic and detect failed login attempts. This first version will not issue any alerts to a cloud system. It will only detect failed logins, tag exception responses triggered by bad passphrases with a SecurityAlert field, and add a SecurityDetails field that includes a relevant subset of the original request data.

We have one ingredient left in our Modbus monitoring sauce: we want to log events with tagged packets in an Azure Sentinel table. Fortunately, we can easily send data to Log Analytics workspaces using the Microsoft Azure Sentinel (om_azure) module. All we will need is our Workspace ID, a SharedKey (either the Primary or Secondary key will work), and a name for the Azure Sentinel table.

From our azure output instance we invoke the post-processing function to check for the existence of the SecurityAlert field. If it doesn’t exist, the packet will be dropped. Otherwise, it will be sent as a JSON record.

Of course, we also need to add the correct route:

and we are done! Running with this configuration will give us an entry in a custom Azure Sentinel log called NXLogSCADALog_CL. This is what such an entry would look like, in CSV format:

In our example above, we did gloss over some of the murkier details of processing real-world Modbus traffic. The most obvious fact that we omitted is that entries in the request queue should not stay around forever — they should be dropped if they aren’t retrieved after a while.

As we alluded to before, more advanced setups (such as those which include serial - TCP gateways) may need even more advanced matching rules, too. Transaction IDs are used to track transactions within the scope of the same TCP connection. Consequently, reliably matching queries and replies via transaction IDs also requires tracking TCP connections so that packets are always matched within the scope of the same TCP connections. This is less problematic for small networks though, and well beyond the scope of this article.

Data reassembly rules can also become more complex when it comes to arbitrary data writes. For example, registers can be written via several commands, including Write Single Register and Write Multiple Registers. Extracting the exact data written at a particular address can require handling more request types, and more advanced rules, which have to account for address ranges and possibly for additional data types "tunneled" on top of Modbus registers and coils.

Having uploaded Modbus traffic information to the SIEM’s table, we are now ready to use the data for incident detection, incident management, and response automation purposes.

At this point, the data we have is not actionable: all we have is a set of records about traffic and potential security incidents, but this data is not yet visible in a security context, only in an analytics table. Furthermore, there is no meaning attached to it, no information about its potential security implications, and no way to identify it for investigation and management purposes. In other words, it’s still "raw data".

Azure Sentinel exposes security data using a hierarchy of alerts and incidents. Alerts are the primary means of organizing security information data. One, or several correlated alerts, make up an incident.

An alert is an event generated by examining previously-recorded data based on a set of analytics rules. One or more alerts that are correlated in some manner can be organized into an incident. Alerts effectively "give meaning" to a set of Analytics records: they have names, descriptions, and can be classified in various ways — based on MITRE ATT&CK framework tactics, for example.

An incident is an aggregation of all the relevant evidence for a specific investigation, effectively a labeled token that you can manage. You can assign it to someone, you can use it as the basis for automated response, and you can use it to establish auditing trails.

To illustrate this concept, we are going to create a custom analytics rule that will allow us to trigger alerts whenever an unsuccessful login attempt is detected. Triggering this alert will create an incident that you can then manage according to site-specific incident investigation rules.

The example we just explored was fairly simple, but this technique is a good starting point for many real-world devices and networks. NXLog’s flexible, modular log collection and processing capabilities enable you to easily extend them to handle a wide range of devices and applications. The wealth of output modules and extension options make it easy to integrate a wide range of data sources and endpoints, as well as balance processing tasks between cloud and edge devices in an optimal manner.