S7comm (S7 Communication) is Siemens’ proprietary protocol for communication between engineering workstations and SIMATIC PLCs, and between PLCs themselves. It runs over ISO-TSAP on TCP port 102 and is the native language of the S7-300, S7-400, and older S7-1200 and S7-1500 product lines. In deployments that haven’t migrated to newer firmware versions with S7comm+, it remains the active control plane for PLCs managing physical processes in manufacturing, energy, water treatment, and chemical production.
The fundamental security problem with legacy S7comm: it was designed in the 1990s without authentication, integrity protection, or encryption. An attacker with network access to a PLC running S7comm can read process values, write to memory areas, upload or download PLC programs, and issue control commands including CPU STOP, all without supplying credentials.
Protocol Architecture and Memory Access
S7comm operates over a layered stack: Ethernet, IP, TCP, ISO on TCP (RFC 1006), and then S7comm application messages. The TSAP (Transport Service Access Point) layer identifies the specific CPU and rack/slot being addressed. Connections are established through a sequence: COTP CR (connection request), COTP CC (confirm), then S7 Setup Communication, then data exchange.
Once connected, S7comm provides access to the PLC’s memory areas:
- Process Image Input (I/E): Current state of physical inputs
- Process Image Output (Q/A): Values to be written to physical outputs
- Bit Memory (M/MB/MW/MD): Internal memory flags
- Data Blocks (DB): User-defined data structures (the primary data storage area)
- System Data Blocks (SDB): PLC configuration data
- Program Blocks (OB/FC/FB): Executable PLC program code
An attacker can read any of these areas without authentication on an S7-300 or S7-400 running legacy firmware. Write access to DB blocks and output areas means direct manipulation of process values that physical systems act on. Write access to program blocks means replacement or modification of the PLC’s operational logic.
CPU control functions accessible without authentication on affected devices include:
- STOP: Halts PLC execution, stopping all output processing
- START/RESTART: Resumes or restarts PLC execution
- Hot restart: Restarts execution from the current state
A CPU STOP command sent to a PLC controlling a safety-critical process is equivalent to a physical emergency stop: outputs freeze at their last value or drop to safe state depending on configuration. This is the attack technique Stuxnet exploited at Natanz for its centrifuge manipulation campaign.
SNAP7: The Open-Source S7comm Library
SNAP7 is an open-source library that implements the S7comm protocol, available for Linux, Windows, and embedded platforms. It provides a straightforward API for reading and writing PLC data, uploading and downloading programs, and controlling PLC operation without any proprietary Siemens tooling.
SNAP7 is a legitimate tool used by industrial developers, OT security researchers, and asset inventory platforms. It’s also the tool that makes S7comm exploitation accessible: building a working S7comm client no longer requires reverse-engineering the protocol from scratch. Any developer who can call a library function can read or write to a Siemens PLC.
The availability of SNAP7 means that internet-exposed S7comm devices (discoverable via Shodan with port:102) face automated exploitation attempts rather than exclusively targeted attacks. Organisations with internet-exposed S7comm devices face a threat model that includes opportunistic as well as targeted actors.
S7comm+ and Authentication
Siemens introduced S7comm+ (also called S7commPlus or the S7-1500 protocol) with the S7-1200 (firmware 4.1+) and S7-1500 product lines. S7comm+ includes challenge-response authentication using an asymmetric key scheme and integrity protection for messages. It is substantially harder to attack than legacy S7comm.
The authentication in S7comm+ was analysed by researchers at the Hamburg University of Technology in 2017 (“The Spear to Break the Security Wall of S7CommPlus”), who documented weaknesses in the original implementation. Siemens subsequently updated the protocol in later firmware versions. Current S7-1500 firmware with TIA Portal v16+ uses a revised authentication scheme that has not been publicly broken.
The practical implication for defenders: the security posture depends heavily on device generation and firmware version. S7-300 and S7-400 devices are legacy and have no S7comm+ path. S7-1200 devices running firmware below 4.1 use legacy S7comm. S7-1200 (fw 4.1+) and S7-1500 devices with current firmware use S7comm+ with authentication.
Attack Techniques in Context
Process data manipulation: Writing arbitrary values to DB blocks or output areas that are directly used by physical actuators, drives, or safety interlock systems. Successful attacks on water treatment facilities and power generation equipment have used direct process data manipulation as the primary impact mechanism.
PLC program modification: Uploading a modified program block that adds malicious logic while preserving normal-looking operation. The PIPEDREAM/INCONTROLLER framework, disclosed by CISA and industrial security vendors in 2022, included a Siemens-specific module designed for exactly this capability.
CPU STOP denial of service: The simplest disruptive attack: sending a STOP command to halt PLC execution. In a process that depends on continuous PLC control (continuous chemical processes, HVAC for critical facilities, conveyor systems), a STOP causes immediate process disruption.
Man-in-the-Middle via PLCInject: Researchers documented a technique where an attacker positioned on the OT network can intercept S7comm traffic between a SCADA/HMI system and a PLC, modifying values in transit. The SCADA system displays the manipulated values while the PLC receives different commands, replicating the deception technique that Stuxnet used against Siemens Step 7.
Detection Approaches
OT network visibility is the prerequisite for detecting S7comm abuse. Most OT environments lack the network monitoring that IT environments take for granted. Passive monitoring using network taps on key OT network segments is the foundational control.
Zeek for S7comm Protocol Analysis
The Zeek network security monitor has a community-contributed S7comm plugin available through the Zeek package manager. It produces structured logs of S7comm sessions including:
- Source and destination addresses
- Connection establishment and PDU types
- Read/write operations with target memory areas and byte counts
- CPU control commands (START, STOP, etc.)
Detecting anomalous S7comm activity with Zeek logs:
# Alert on CPU STOP commands
event s7comm_cpu_function(c: connection, function_code: count) {
if (function_code == 0x29) { # CPU STOP function code
NOTICE([$note=S7comm::CPU_STOP_Command,
$conn=c,
$msg=fmt("CPU STOP command from %s to %s", c$id$orig_h, c$id$resp_h)]);
}
}
Baseline normal S7comm communication patterns for each engineering workstation and SCADA/HMI pair, then alert on connections from unexpected sources, read/write operations targeting unexpected memory areas, or program block upload/download events outside maintenance windows.
Suricata Rules
The Emerging Threats ruleset includes S7comm detection rules. Relevant categories:
alert tcp any any -> any 102 (msg:"S7comm Connection Request"; flow:established,to_server; content:"|03 00|"; depth:2; content:"|11 e0|"; offset:5; depth:2; sid:2025000; rev:1;)
alert tcp any any -> any 102 (msg:"S7comm CPU STOP Command"; flow:established,to_server; content:"|03 00|"; depth:2; content:"|29|"; offset:20; sid:2025001; rev:1;)
These rules require signatures tuned to your environment. The specific byte offsets vary across S7comm versions; validate against captured legitimate traffic before deploying with alerting enabled.
Anomaly Detection Rules
High-signal detection rules for OT environments regardless of protocol:
- New source IP making S7comm connections: Engineering workstations and HMI systems should have a fixed, small set of source addresses communicating with each PLC. Any new source IP making TCP/102 connections warrants immediate investigation.
- S7comm connections outside business hours: Production PLCs should not receive new connections at 2am. Time-of-day anomalies are highly reliable in OT environments where change management processes exist.
- Program block upload/download events: DB, OB, FC, and FB read operations with large byte counts (indicative of program block transfers) outside documented maintenance windows.
- Connections from IT-side network segments: S7comm traffic originating from IP ranges outside the designated engineering workstation subnets, particularly from corporate IT segments.
Mitigations
Network segmentation: S7comm devices should not be reachable from corporate IT networks or the internet. Engineering workstation access to PLCs should traverse a firewall with an explicit permit list of source/destination pairs. Document every permitted S7comm flow.
Firmware upgrades: Where feasible, migrate S7-1200 devices to firmware 4.1 or later to enable S7comm+ with authentication. S7-300 and S7-400 devices have no authenticated protocol option; network segmentation and monitoring are the primary mitigations.
Read-only access restriction: Siemens TIA Portal allows configuring access levels on S7-1200 and S7-1500 CPUs. Setting the CPU protection level to restrict write access and program modification to known, password-protected connections reduces the impact of unauthorised S7comm access even where network segmentation is imperfect.
Disable unused communication interfaces: S7-300 and S7-400 CPUs with CP communications cards should have unused ports disabled. Some deployments have enabled Ethernet access that isn’t operationally required.
OT-specific NDR: Commercial platforms including Claroty, Dragos, and Nozomi Networks provide passive S7comm protocol analysis with built-in anomaly detection and asset inventory. For organisations managing significant Siemens PLC fleets, a dedicated OT NDR platform provides better coverage than generic network monitoring.