Key takeaways
- The engineering workstation holds program download rights that most PLCs grant to any trusted network peer, with no re-authentication of the operator.
- Modified PLC logic runs while HMI tag values remain in the expected range, so the control room sees no alarm.
- S7comm program download uses three function codes: start download, download block, end download. All three arrive from a trusted IP and carry no cryptographic proof of origin.
- Network segmentation, application allowlisting on the EWS, and periodic logic checksums are the controls a pentest must verify are in place.
- An OT/ICS pentest maps every workstation that can reach a PLC and confirms whether each download path is controlled and logged.
Why the engineering workstation is the highest-value target on a control network
Every PLC on a control network has a program download port. By design, that port accepts connections from a specific set of IP addresses: the engineering workstations that maintenance engineers use to write, deploy and modify control logic. The workstation does not prove to the PLC that a human operator authorised the download. It proves only that it is a trusted network peer. That trust model is what makes the engineering workstation the most consequential machine in any OT environment.
The vendor programming software stores project files on the workstation's local filesystem. Those files contain the full running program, every defined tag, every interlock and setpoint, and the communications parameters for every connected device. Siemens TIA Portal saves them as .ap19 or .ap22 archives; Rockwell Studio 5000 uses .ACD files. An attacker who gains a foothold on the workstation has immediate read access to the process configuration before going anywhere near the network. An OT/ICS pentest maps every workstation that holds those rights and tests whether each download path is controlled.
The programming protocols that carry this trust were designed for reliability in an isolated network, not for authentication in an environment where adversaries can reach the control segment. S7comm defines no credential exchange for program download. CIP over EtherNet/IP similarly relies on network-level access control. Both protocols were specified when the engineering workstation was assumed to be physically separated from untrusted networks, and neither has been substantially redesigned since.
Reaching the engineering workstation from the corporate network
Engineering workstations sit on the OT control network but are reached from the corporate IT network in most architectures based on the Purdue Enterprise Reference Architecture. Remote desktop sessions, shared file services, historian connections and vendor support tunnels all cross the IT-OT boundary. An attacker who holds a corporate endpoint can pivot to the OT segment by following those paths without needing to break the industrial protocols directly. The EWS is a standard Windows machine from the IT side: it runs antivirus, patches on a maintenance schedule and connects to shared infrastructure.
Once inside the control network, the EWS is identifiable by the ports it opens: S7comm on TCP 102 for Siemens networks, EtherNet/IP on TCP 44818 for Rockwell Allen-Bradley. The scan below discovers two controllers on a 192.168.200.0/24 OT segment. An infrastructure pentest maps the IT-OT boundary first, and a penetration testing scope that covers both sides will trace the lateral movement path from a corporate host to the EWS.
nmap -sS -p 102,44818 --script s7-info,enip-info -T2 192.168.200.0/24
Nmap scan report for 192.168.200.11
PORT STATE SERVICE
102/tcp open iso-tsap
| s7-info:
| Module: CPU 315-2 PN/DP
| Serial Number: S C-X2E012345678901
| Module type: CPU 315-2 PN/DP
|_ Version: 2.6, 2.6
Nmap scan report for 192.168.200.21
PORT STATE SERVICE
44818/tcp open EtherNet/IP
| enip-info:
| Vendor ID: 0x0001 (Rockwell Automation / Allen-Bradley)
| Device Type: 0x000C (Communications Adapter)
|_ Product Name: 1769-L33ER LOGIX5333ER
Enumerating reachable controllers and reading the current program
With the engineering workstation under attacker control, the next step is to understand what the PLC is running. The vendor programming software can upload the current program directly from the controller. In offline mode it reads the saved project file from the local filesystem. In online mode it uploads the program from the PLC's flash memory. Either route provides a copy of the logic, including the setpoints, interlocks and tag names that describe the physical process. In practice, the saved project file is usually current: engineers keep the on-disk copy synchronised with the controller as a matter of operational discipline.
The python-snap7 library communicates with Siemens S7 controllers over the same S7comm protocol that TIA Portal uses. The session below connects to 192.168.200.11 and lists program blocks, revealing the structure before any modification. The output shows three organisation blocks, twelve functions and twenty-four data blocks. DB5 is the production setpoint block. Reading it shows the current temperature limit and interlock status field, the exact values the attacker needs before writing a replacement.
python3 -c "
import snap7
client = snap7.client.Client()
client.connect('192.168.200.11', 0, 1)
blocks = client.list_blocks()
for btype, bcount in blocks._asdict().items():
if bcount > 0:
print(f'Block type {btype}: {bcount} blocks')
"
Block type OB: 3 blocks
Block type FC: 12 blocks
Block type FB: 7 blocks
Block type DB: 24 blocksIn
IT network access
Phishing or exposed remote access into the corporate segment
IT-OT pivot
Lateral movement from IT host into the OT control network
Through
EWS foothold
Vendor software and saved project files accessed
PLC enumeration
S7comm or CIP scan identifies reachable controllers
Logic download
Modified program pushed via trusted session
Out
Process shifted
Setpoints or interlocks altered without alarm
HMI blind spot
Tag values unchanged; operators see nothing
Pushing modified logic: the S7comm program download sequence
S7comm defines a three-step sequence for program block download: start download, download block, end download. The PLC accepts each step from any host that can reach TCP port 102, with no cryptographic binding to the original author of the project file. The transaction appears identical whether a maintenance engineer is deploying a legitimate update or an attacker is pushing a modified interlock. The MITRE ATT&CK for ICS technique T0843 (Program Download) documents this as a standard method for altering controller operation.
Organisation Block 1 (OB1) is the main cyclic scan routine on Siemens S7-300 and S7-400 controllers, executing every 10 to 150 milliseconds. Changing OB1 changes what the PLC does on every cycle. The protocol trace below shows a download that raises a temperature setpoint in DB5 from 85.0 to 110.0 and bypasses the interlock check that would otherwise initiate a controlled shutdown. Three frames, no credential exchange, and the controller begins running the new code on the next scan.
Frame 1 Job Request: Start download block (FC 0x1A)
Block type : 0x0A (OB)
Block number: 0x0001 (OB1, main scan cycle)
Frame 2 Job Request: Download block (FC 0x1B)
Payload : 228 bytes modified MC7 bytecode
Changes : DB5.DBD0 setpoint 85.0 -> 110.0
DB5.DBX4.0 interlock check bypassed (forced TRUE)
Frame 3 Job Request: End download block (FC 0x1C)
Acknowledgement from 192.168.200.11:
Download accepted. OB1 reloaded.
Next scan cycle executes modified logic.
Why the HMI shows nothing after the logic change
The HMI reads tag values from PLC data blocks. It does not read the program blocks that contain control logic. If the attacker modifies the program while writing values that fall inside the normal operating range to the data blocks the HMI monitors, the operator's display shows no deviation. The process may be running outside design limits, but the control room cannot see that from the HMI alone. This separation is the property an OT attacker exploits to make a change persist: a deviation that triggers an alarm is noticed and investigated; one that stays within the HMI's expected range is not.
A changed setpoint combined with bypassed interlock logic achieves the attacker's objective without raising an alert. The detection required to catch this sits outside the HMI: What your OT monitoring should catch during an ICS pentest covers what that visibility requires in practice. The table below summarises what each layer of the OT stack can and cannot see after an unauthorised program download.
| Layer | What it shows | What it cannot see |
|---|---|---|
| HMI | Tag values from PLC data blocks | Changes to program blocks (OBs, FCs, FBs) |
| SCADA historian | Process values logged from tag reads | Whether those values reflect real physics or bypassed interlocks |
| Network firewall | Whether S7comm TCP 102 sessions are permitted | Whether the payload inside a permitted session is legitimate |
| EWS filesystem logs | Project files opened and when | Whether a download session was opened to the PLC and what was pushed |
| OT-aware IDS | Anomalous download function codes outside maintenance windows | Logic changes if no program baseline was recorded before the attack |
What an OT/ICS pentest proves and what to check against it
An OT/ICS pentest walks this chain under controlled conditions. The objective is to prove or disprove that the engineering workstation can reach every PLC in scope, that the download path is uncontrolled, and that no detection fires when modified logic is pushed. Each step produces evidence of a real control gap. The path from EWS foothold to silent logic change is one the pentest should confirm is closed, not assumed to be.
The controls that break the chain are specific. Network segmentation restricts which IP addresses can open a programming session to a given PLC: a firewall rule at the switch or security appliance level enforces this. Application allowlisting on the EWS prevents unauthorised software from running, which limits which processes can open an S7comm or CIP session. Logic integrity monitoring compares the program block on the PLC against a known-good hash at regular intervals and alerts on any deviation outside a maintenance window. NIST SP 800-82 revision 3 covers these controls in the context of OT security programme design.
Where the objective is to test the full detection and response chain, an assumed-breach exercise can validate whether the SOC and OT operations team respond correctly once the pentest has confirmed the technical gap is closeable. Modifying controller tasking is documented under MITRE ATT&CK for ICS T0889. Both T0843 and T0889 map to the same root weakness, CWE-284, and to the same remediation family: access control on the download path, verified and logged.
OT security testing in Abu Dhabi and Dubai
Critical infrastructure in the UAE includes oil and gas upstream facilities in Abu Dhabi operated by ADNOC and its subsidiaries, desalination and power generation assets managed by the Abu Dhabi Power Corporation, and water and electricity distribution in Dubai under DEWA. Each of these environments runs PLCs and SCADA systems, some installed when remote connectivity was a future concern rather than a present one. The engineering workstations that manage those controllers are now reachable, directly or indirectly, from corporate IT networks that were not part of the original design.
The UAE Information Assurance Regulation, published by TDRA and applicable federally, requires operators of critical national information infrastructure to implement security controls and conduct periodic assessments. NESA guidelines apply to entities designated as critical infrastructure operators. For Dubai government entities and their suppliers, DESC sets the applicable framework. None of these instruments names a programme download test by name, but a finding that an attacker can replace control logic without authentication is a direct failure of the access control and change management requirements all three frameworks carry.
A security assessment scoped to cover the engineering workstation and PLC download path produces documented evidence of whether those controls are in place. In Abu Dhabi and Dubai, that evidence is increasingly part of what procurement teams and regulators ask for before commissioning new industrial sites, extending vendor support contracts or renewing supplier qualification. The test confirms whether the trust relationship between the workstation and the controllers it manages is bounded by the controls the site security policy says are in place.
Frequently asked questions
What is PLC logic tampering?
PLC logic tampering is the modification of the program running on a programmable logic controller to change how it controls a physical process. An attacker uploads a modified program using the same programming tools a maintenance engineer uses, but with altered setpoints, bypassed interlocks or changed timing. The physical process then behaves differently from what operators expect, without triggering any alarm on the HMI.
How does a PLC logic tamper differ from a denial-of-service attack on a control system?
A denial-of-service attack stops the controller from responding, which triggers alarms and is detected quickly. A logic tamper keeps the controller running but changes what it does, making detection much harder. The HMI continues to show process values and the PLC continues to answer polling requests; the change is in the logic that processes those values, not in the availability of the device.
What is an engineering workstation in an OT environment?
An engineering workstation is a computer that runs the vendor programming software used to write, compile and deploy control logic to PLCs. It sits on the control network and holds the project files for every controller it manages. Because PLCs trust program downloads from the EWS's IP address, it has effective administrative access to every controller it can reach on the network.
What is S7comm and why does it matter for OT security?
S7comm is the Siemens proprietary protocol for communication between engineering software and S7-series PLCs, running over TCP port 102. It supports program upload, download and data block read-write operations. The protocol carries no operator authentication beyond the source IP address, so any host that can reach TCP 102 on a target PLC can issue a program download command. That property is what makes EWS access control so consequential.
Can a PLC detect that its logic has been changed?
PLCs do not natively alert on program changes. A download completes silently and the controller starts executing the new code. Some firmware versions log the event in a diagnostics buffer readable from the programming client, but this is not forwarded to the SCADA or SIEM by default. OT-aware network monitoring tools can detect the S7comm download function code appearing outside a maintenance window.
What network controls prevent unauthorised program download?
The primary control is network segmentation: a firewall rule restricting which IP addresses can open a TCP 102 or TCP 44818 session to each PLC. Secondary controls include application allowlisting on the engineering workstation, change management windows enforced at the network layer, and OT-aware intrusion detection that alerts on download function codes outside approved hours.
What is the difference between a data block and a program block in an S7 controller?
Program blocks contain executable logic: Organisation Blocks define the scan cycle structure, Function Blocks and Functions hold reusable routines, and OB1 runs on every cycle. Data blocks store the values those blocks read and write: setpoints, actual values, status bits and counters. The HMI reads from data blocks, not from program blocks, which is why a change to the logic does not appear on the operator's screen unless the new logic itself writes an anomalous value to a monitored tag.
How does a red team test PLC program download in a live production environment?
A red team engagement against a live OT environment requires explicit written authorisation naming each controller in scope and defining the bounds of any logic modification. Testing is typically limited to confirming the download path is open and reading the current program rather than pushing modified logic to production equipment. For full logic modification testing, a replica or test PLC is used. The engagement plan defines which actions are in scope before any testing begins.
Does NIST SP 800-82 address PLC logic tampering?
NIST SP 800-82 revision 3, the Guide to Operational Technology Security, covers access control, network segmentation and monitoring for OT environments. It addresses the need to control which devices and users can modify controller configurations and programs, and recommends network segmentation between engineering workstations and field devices as a foundational control. It does not describe specific attack techniques but provides the control framework within which a finding about an uncontrolled download path is remediated.
What is MITRE ATT&CK for ICS and which techniques cover logic tampering?
MITRE ATT&CK for ICS is a knowledge base of adversary tactics and techniques specific to industrial control systems. Technique T0843 (Program Download) describes using legitimate programming software to download altered logic to a controller. Technique T0889 (Modify Controller Tasking) covers altering the task schedule or execution order of control programs. Both map to CWE-284 as the underlying weakness and are documented with examples from known ICS incidents.
