Port 102 – Siemens S7 / ISO-TSAP (S7comm over ISO-on-TCP)

Port 102 is the default port for ISO-TSAP, the ISO Transport Service on top of TCP (RFC 1006, “ISO-on-TCP”) that carries the COTP and S7comm protocols to Siemens SIMATIC PLCs — the S7-300, S7-400, S7-1200, and S7-1500 controllers that run factory lines, power substations, water plants, and building systems. When a Siemens engineering workstation running STEP 7 / TIA Portal talks to a PLC, or an HMI or SCADA master polls one, the conversation rides ISO-TSAP on port 102. The catch is what S7comm lets that conversation do: on the classic controllers it is unauthenticated by design (with, at most, an optional weak “protection level” password), so anyone who can route a packet to port 102 can read the PLC’s memory and data blocks, pull down the control logic, and — the part that matters — start or stop the CPU, changing the state of a physical process. An open port 102 is not a web service to fuzz; it is a direct line to an operational-technology (OT) device that moves things in the real world, and it is one of the most recognisable finds on Shodan and Censys.

Why It’s Open

Port 102 is open because a Siemens S7 PLC is doing its job. ISO-TSAP is how the SIMATIC ecosystem communicates: STEP 7 / TIA Portal engineering stations download and monitor programs over it, HMIs and SCADA historians poll live process values through it, and PLC-to-PLC “GET/PUT” links use it too. Every S7-300, S7-400, S7-1200, and S7-1500 CPU with a PROFINET/Ethernet interface ships with an S7comm server listening on 102 out of the box, because without it you cannot program or supervise the controller.

The problem is where that port ends up reachable. S7comm was designed for a trusted, isolated automation cell where every node was inside the same locked cabinet. Flat OT networks, remote-maintenance requirements, cellular routers at unmanned sites, badly drawn firewall rules, and the general collision of IT and OT have pushed thousands of these controllers onto routable networks — a search for port:102 on Shodan reliably returns SIMATIC CPUs answering directly, banner and all (basic hardware order number, module type, serial, firmware version). On the classic S7-300/400 there is usually no login to fail; if the port answers, the PLC is talking.

Common Risks

• Weak or absent authentication by design. Classic S7comm (S7-300/400) has no user or session concept — reaching port 102 is the authorization. The optional access-protection levels are a coarse, easily-bypassed password check, not real authentication.
• Reading and writing PLC memory and data blocks. An unauthenticated peer can read inputs, outputs, markers/flags, and data blocks — live process state — and write new values into them, driving actuators, setpoints, and configuration on running hardware.
• CPU start/stop and program manipulation. S7comm exposes PLC control functions: an attacker can issue a stop to halt the CPU (an instant denial of service against a physical process) or upload/download logic blocks to read or reprogram the control logic itself.
• Control-logic and IP disclosure. The running program (STL/LAD blocks) and project metadata can be pulled off the device, handing an attacker both a blueprint of the process and the engineering know-how baked into it.
• No transport confidentiality or integrity on classic S7comm. Traffic is cleartext and forgeable, so an on-path attacker can sniff, replay, or man-in-the-middle the exchange — including feeding an HMI fake “normal” readings while manipulating the process underneath.
• S7comm-plus is harder, not immune. The S7-1200/1500 family added S7comm-plus with integrity and anti-replay protection, but researchers have repeatedly bypassed those checks (see CVEs below), so a newer controller is not automatically a safe one.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

S7 testing is unlike testing an IT service: read/enumerate operations are usually safe, but stop-CPU and write/download operations can physically disrupt or damage equipment and endanger people. Only ever touch controllers you are explicitly authorized to test, and keep any stop or write operation to a lab or an agreed maintenance window — never a live production PLC. Capture every finding as you go so it lands in the pentest report rather than a scratch terminal.

Confirm ISO-TSAP is answering

nmap -Pn -p 102 <target>

Enumerate the PLC with the official s7-info NSE

s7-info speaks COTP/S7comm on 102 and returns the device’s basic hardware, module type, serial number, firmware version, and system name — the same data plcscan pulls, inside Nmap.

nmap -sV -p 102 --script s7-info <target>

Deeper enumeration with Digital Bond’s Redpoint NSE

The community s7-enumerate script (from the Digital Bond Redpoint project) walks additional S7 identification fields:

nmap --script s7-enumerate -p 102 <target>

Scan and fingerprint with plcscan / s7scan

plcscan (Dmitry Efanov / Positive Research) and s7scan (Kaspersky Lab ICS CERT) identify S7 devices and dump their info records over ISO-TSAP:

python plcscan.py <target>
python s7scan.py --hosts <target>

Read device and CPU state with python-snap7

The snap7 suite (and its pure-Python python-snap7 wrapper) speaks S7comm natively. Reading CPU info and run/stop state is non-intrusive; use rack=0, slot=1 for S7-1200/1500 and slot=2 for many S7-300/400 CPUs.

import snap7

client = snap7.client.Client()
client.connect("<target>", rack=0, slot=1)   # slot=2 for many S7-300/400
print(client.get_cpu_info())                 # module type, serial, firmware
print(client.get_cpu_state())                # 'S7CpuStatusRun' / 'S7CpuStatusStop'

Inspect the traffic in Wireshark

Wireshark ships a built-in S7comm dissector — capture the exchange and filter on cotp and s7comm (and s7comm-plus for S7-1200/1500) to see function codes, data-block reads/writes, and CPU control commands on the wire.

Offensive S7 tooling exists too — PLCinject (SCADACS) lists and patches code blocks by injecting a call instruction, and snap7 can download blocks — but those write to the controller and must be confined to authorized lab testing. Log every reachable port 102, the CPU model and firmware you fingerprinted, and any protection level you observed, so the evidence lands in the pentest report instead of a terminal you’ll lose.

What to Look For

Known CVEs and Exploits

Be honest about the risk model here: the biggest exposure on port 102 is design-level, not a single patchable bug. Classic S7comm on the S7-300/400 has no real authentication, so an unauthenticated read/write/stop is expected behaviour, not a CVE. That said, several verified, correctly-scoped Siemens advisories do apply directly to S7comm on 102:

• CVE-2016-9159 — An attacker with network access to port 102/tcp (ISO-TSAP) (or via PROFIBUS) can obtain credentials from a SIMATIC S7-300 or S7-400 CPU when access-protection level 2 is configured. Confirmed on NVD against the S7-300/400 CPU families; CVSS 5.9. This is the canonical “the protection password doesn’t really protect you” flaw.
• CVE-2015-2177 — Crafted packets to TCP port 102 (or PROFIBUS) put a SIMATIC S7-300 CPU into a denial-of-service “defect mode,” requiring a manual restart. Verified on NVD as an S7-300 CPU defect (CVSS 7.5) — despite occasionally being mislabeled as a WinCC issue, the NVD record scopes it squarely to the S7-300 controller on port 102.
• CVE-2019-10929 — A message-protection (integrity) bypass in S7comm-plus on the SIMATIC S7-1200/1500 family: a man-in-the-middle on port 102/tcp between an engineering station and the PLC can modify the communication despite the integrity protection. Verified on NVD against the S7-1200/1500 CPUs and STEP 7 (TIA Portal); CVSS 5.9. This is the “newer controllers aren’t immune” data point — the anti-replay/integrity layer added for S7comm-plus was shown to be defeatable.

A note on scoping, because Siemens’ catalogue is easy to conflate: the S7-1200 web-server CSRF issue CVE-2015-5698 was deliberately left off this page — it targets the controller’s HTTP web interface, not ISO-TSAP/S7comm on 102, so it belongs on a web-service writeup, not here. As always, verify every CVE against its NVD record and confirm it maps to this protocol and port before you trust it. There is no dedicated core Metasploit S7comm enumeration module (the scanner/scada tree carries profinet_siemens, a PROFINET/DCP discovery module — a different protocol), so s7-info, plcscan/s7scan, and snap7 are the real go-to tools rather than an invented msf path.

Mitigation

• Get port 102 off any untrusted network. Segment OT from IT, and never expose S7comm to the internet. Put the controllers behind a firewall or data diode and allow 102 only from the specific engineering stations and SCADA hosts that need it.
• Use the strongest protection level the CPU supports, and on S7-1500 enable the access-protection / password and communication-protection features — but treat them as defence-in-depth, not a substitute for network isolation, given CVE-2016-9159.
• Prefer the S7-1500 family with S7comm-plus where you can, patch controller firmware to the fixed versions in the Siemens advisories (including the CVE-2019-10929 fixes), and keep STEP 7 / TIA Portal current.
• Monitor for S7 stop/download commands and unexpected ISO-TSAP connections — an unauthenticated CPU stop or block download from an unusual host is a serious event.
• Compartmentalise the engineering workstation. Because the Windows engineering PC (STEP 7 / WinCC) is the classic path onto the PLC, harden and isolate it, and control removable media — that is exactly where Stuxnet got in.
• Firewall and rescan. After locking 102 down, rescan with nmap -p 102 <target> to confirm the controller is only reachable from where it should be.

Real-World Example

The canonical attack on Siemens S7 is Stuxnet — the malware discovered in 2010 that sabotaged Iran’s Natanz uranium-enrichment plant. Framed accurately: Stuxnet did not speak Modbus and did not attack port 102 directly across the internet. Instead it spread through Windows and hunted for engineering workstations running Siemens STEP 7 / WinCC. On an infected station it replaced Siemens’ own s7otbxdx.dll — the library STEP 7 uses to talk to the PLC — with a malicious wrapper, giving it a man-in-the-middle on exactly the S7comm exchange that rides ISO-TSAP. From there it downloaded rogue STL logic blocks into the targeted SIMATIC S7-300 (and, via a second sequence, S7-400/417) CPUs, subtly manipulating the centrifuge drives while replaying recorded “normal” readings back to the operators so the HMIs showed nothing wrong.

The lesson maps straight onto an open port 102: the thing that made Stuxnet devastating was that programming an S7 PLC over S7comm carries no meaningful authentication or integrity guarantee, so whoever controls that channel — whether by owning the engineering PC or by simply routing a packet to an exposed controller — can reprogram the process and lie to the humans watching it. Every unauthenticated, internet-reachable SIMATIC CPU answering on 102 is a smaller, easier version of the same problem.

FAQ

What is port 102 used for?

Port 102 is the default port for ISO-TSAP (ISO Transport over TCP, RFC 1006). In practice it carries the COTP and S7comm protocols that Siemens SIMATIC S7-300/400/1200/1500 PLCs use to talk to STEP 7 / TIA Portal engineering stations, HMIs, and SCADA masters — for programming the controller and reading or writing its memory, data blocks, and CPU state.

Is port 102 dangerous to leave exposed?

Yes, on any untrusted network. Classic S7comm has no real authentication, so reaching port 102 is often enough to read process data, download the control logic, and stop the CPU — directly affecting physical equipment. An internet-facing port 102 should be treated as something to segment off and firewall, not to harden in place.

What service or protocol runs on port 102?

ISO-TSAP at the transport layer, with Siemens S7comm (classic, on S7-300/400) or S7comm-plus (on S7-1200/1500) layered on top via COTP. It is the native programming and supervision protocol of the SIMATIC S7 PLC family — not to be confused with Modbus on port 502, which is a different ICS protocol used by many other controllers.

Can an attacker really start or stop a PLC over port 102?

On classic S7comm (S7-300/400) with no effective protection, yes — the protocol exposes CPU control functions, so an unauthenticated peer who can reach 102 can issue a stop and halt the process, or download logic blocks. S7comm-plus on the S7-1200/1500 adds integrity protection, but researchers have bypassed it (CVE-2019-10929), so newer controllers reduce the risk without eliminating it.

Was Stuxnet a port 102 / Modbus attack?

Stuxnet targeted Siemens S7 PLCs, not Modbus. It infected the Windows STEP 7 / WinCC engineering workstation and hijacked the s7otbxdx.dll that STEP 7 uses to communicate S7comm with the PLC, then reprogrammed S7-300/400 controllers. So it is an S7comm/ISO-TSAP story (via the engineering PC), and explicitly not a Modbus one.

How do I secure or close port 102?

Segment the controller into an isolated OT zone, firewall port 102 so only the engineering and SCADA hosts that need it can connect, enable the strongest protection/communication level the CPU supports, patch controller firmware and STEP 7 to the fixed versions, and harden the engineering workstation. Then rescan with nmap -p 102 <target> to confirm the PLC is only reachable from where it should be.

TL;DR

• Service: Siemens S7comm / S7comm-plus over ISO-TSAP (ISO-on-TCP, COTP) to SIMATIC S7-300/400/1200/1500 PLCs
• Default port: 102/TCP
• Biggest risk: largely unauthenticated by design — a reachable 102 lets an attacker read/write PLC memory and data blocks, pull the control logic, and start/stop the CPU, directly affecting a physical process (the Stuxnet class of attack)
• Mitigation: isolate OT from IT, firewall 102 to specific engineering/SCADA hosts, use the strongest protection level, patch firmware and STEP 7 (CVE-2019-10929), harden the engineering workstation, and rescan to confirm

Related ICS and device-management ports worth reviewing alongside this one: Modbus on port 502 (the other flagship unauthenticated fieldbus protocol), EtherNet/IP on port 44818 (the dominant fieldbus on North American plant floors), IEC-104 on port 2404 (the analogous telecontrol protocol on power grids), SNMP on port 161 (device management and info disclosure on the same OT networks), and Telnet on port 23 (cleartext management still common on legacy industrial gear). Fold every reachable controller and finding into your pentest report as you go.