Port 44818 – EtherNet/IP (Common Industrial Protocol)

Port 44818 (0xAF12) is the default port for EtherNet/IP explicit messaging — the TCP and UDP channel that carries the Common Industrial Protocol (CIP) to industrial controllers. EtherNet/IP is the dominant factory-floor protocol in North America, and 44818 is where request/response CIP commands land: identity queries, object-model reads, tag reads and writes, program uploads, and controller mode changes. The devices behind it are mostly Allen-Bradley / Rockwell Automation ControlLogix and CompactLogix PLCs, but Omron, Schneider Electric, and any ODVA-conformant drive, HMI, or I/O adapter can answer here too. The protocol was designed for a trusted, isolated control network and has no authentication, so an open port 44818 that anyone can reach is one of the most consequential findings on an OT engagement: reachability is very close to control.

Why It’s Open

EtherNet/IP is the standard way Rockwell and many other vendors network their programmable logic controllers, so 44818 is open on essentially every EtherNet/IP-capable device by default. It carries explicit messaging — the connected and unconnected request/response traffic that engineering workstations (Studio 5000 Logix Designer / RSLogix 5000), SCADA/HMI software, historians, and other PLCs use to read status, download logic, adjust tags, and change controller state.

EtherNet/IP splits its traffic across two ports, and the distinction matters:

• 44818/TCP and 44818/UDP carry explicit messaging — the on-demand CIP request/response used for configuration, diagnostics, and tag access. This is the port that fingerprints and controls the device.
• 2222/UDP carries implicit (cyclic I/O) messaging — the real-time, high-rate producer/consumer data exchange between a controller and its I/O. That sibling port is covered separately.

In a properly segmented plant, 44818 lives on an isolated control VLAN reachable only by engineering stations and peer controllers. The problem is that it frequently isn’t segmented: flat networks, misconfigured firewalls, cellular/VPN gateways, and cloud-connected OT all end up exposing 44818 to networks it was never meant to face. It is one of the most-indexed ICS ports on Shodan for exactly this reason.

Common Risks

• No authentication by design. CIP over EtherNet/IP has no built-in login, session token, or access control on the explicit-messaging surface. If you can reach 44818, the device treats you as a legitimate peer — reachability is authorization.
• Instant device fingerprinting. A single unauthenticated List Identity request returns the vendor ID, product name and code, serial number, firmware/revision, and device type — everything an attacker needs to map exact known-vulnerable models.
• CIP object-model enumeration and tag access. The explicit-messaging surface lets a client walk the controller’s CIP object model and, on many Logix controllers, read and write program tags — reading process values or forcing outputs that drive physical equipment.
• Unauthenticated CPU stop and mode changes. On many Rockwell Logix controllers, a crafted CIP command can stop the CPU, change its run/program mode, or crash the Ethernet interface — a direct denial-of-control against a live process, with no credentials required.
• Program and firmware manipulation. Explicit messaging can be used to upload the running logic (intellectual-property theft) or push modified logic, in some cases without the change being obvious on the engineering workstation.
• Internet exposure. Because 44818 is open by default and OT networks are so often flat or misconfigured, thousands of controllers answer List Identity directly from the public internet, turning a design-level weakness into remote, real-world reach.

Want to save time on reporting?

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

Book a Demo

Enumeration & Testing

Testing on 44818 means confirming the service is EtherNet/IP, pulling identity, and mapping the CIP surface. Anything that stops or writes to a controller is destructive on a live process — only run it against equipment you are authorized to disrupt.

Fingerprint the service and pull device identity

nmap -sV -p 44818 <target>
nmap -p 44818 --script enip-info <target>

The enip-info NSE script sends an EtherNet/IP identity request and returns the vendor, product name, serial number, device type, and revision — the fastest way to identify exactly what is answering. Industrial controllers and their network gear frequently expose SNMP on port 161 as well, so a parallel SNMP sweep often adds firmware, interface, and topology detail to the picture.

Broadcast List Identity over UDP

EtherNet/IP List Identity works over UDP, including broadcast, so one request can enumerate every device on a segment:

nmap -sU -p 44818 --script enip-info <target>
# cpppo's EtherNet/IP client (pip install cpppo)
python -m cpppo.server.enip.client --udp --broadcast --list-identity -a 255.255.255.255

Read and write CIP tags (Logix)

pycomm3 is a Python library for talking to Allen-Bradley/Rockwell Logix controllers over EtherNet/IP CIP — useful for enumerating and reading tags to prove the access is unauthenticated:

from pycomm3 import LogixDriver
with LogixDriver('<target>') as plc:
    print(plc.info)          # identity: product, revision, serial
    print(plc.get_tag_list()) # enumerate controller tags

Demonstrate unauthenticated impact (Metasploit)

The real EtherNet/IP CIP module in Metasploit implements unauthenticated commands drawn from DigitalBond’s Project Basecamp — including CPU STOP and crashing the device’s Ethernet card:

msfconsole -q
use auxiliary/admin/scada/multi_cip_command
set RHOSTS <target>
# choose the CPU STOP / crash action per the module's options — this is destructive
run

Capture full EtherNet/IP traffic in Wireshark (the enip and cip dissectors decode identity, object, and service data) so every request and response is documented. Log each responding controller, its identity fields, and any tag or state you were authorized to touch so the evidence lands in the pentest report instead of a scratch terminal.

What to Look For

Known CVEs and Exploits

The most important thing about port 44818 is that the biggest risk is not a CVE — it is the design of the protocol. CIP explicit messaging has no authentication, so unauthenticated identity disclosure, tag access, and (on many Logix controllers) CPU-stop and mode changes are intended protocol behaviour, not bugs. DigitalBond’s 2012 Project Basecamp demonstrated exactly this against Rockwell ControlLogix, and the technique lives on in the auxiliary/admin/scada/multi_cip_command Metasploit module. Treat “reachable 44818” as the finding.

That said, several verified, genuinely EtherNet/IP/Logix vulnerabilities matter:

• CVE-2021-22681 — Rockwell Automation Studio 5000 Logix Designer / RSLogix 5000 and the Logix controllers use a cryptographic key to verify communications, but the key can be recovered, letting an unauthenticated attacker bypass the verification and authenticate to the controller — enabling connection, download of malicious logic, or a fault. Affects CompactLogix, ControlLogix, GuardLogix, DriveLogix, and SoftLogix. CVSS 9.8 Critical.
• CVE-2022-1161 — On ControlLogix, CompactLogix, and GuardLogix controllers, user-readable program code is stored separately from the compiled code that actually executes, so an attacker able to modify a program can run hidden code the engineering workstation does not display — the “hidden logic” flaw. CVSS 9.8 Critical (NVD).
• CVE-2020-6998 — The connection-establishment algorithm in CompactLogix 5370 and ControlLogix 5570 (v33 and prior) mishandles control flow, so a crafted CIP packet triggers an infinite loop and a denial-of-service on the controller. Scoring was disputed: NVD rates it 8.6 High while the ICS-CERT advisory rates it 5.8 Medium — a reminder to weigh vendor and NVD context, not just the number.

On the commonly-miscited “CIP” CVEs: CVE-2017-6032 and CVE-2017-6034 are sometimes listed as EtherNet/IP/CIP issues. They are not — both are Schneider Electric Modicon Modbus protocol flaws (session brute-force and a capture-replay authentication bypass) and belong on the Modbus / port 502 page, not here. They have been left off this page deliberately. Always confirm the product on NVD before attributing a CVE to a port.

Mitigation

• Segment the control network. 44818 should never be reachable from the enterprise network or the internet. Put controllers on an isolated OT VLAN behind a firewall or data diode, and allow EtherNet/IP only from named engineering stations and peer controllers.
• Never expose 44818 to the internet. If a Shodan-style scan finds your controller, the exposure is already critical. Front any remote OT access with a VPN and strict access control, and audit cellular/4G and cloud gateways for accidental passthrough.
• Use the controller’s protective features. Modern Logix controllers offer a physical mode switch (keep it in RUN), controller-level change detection/audit logging, trusted-slot and source-protection options, and CIP Security (authenticated/encrypted CIP) where the hardware supports it — enable them.
• Patch firmware. Apply Rockwell firmware and Studio 5000 updates that address CVE-2021-22681, CVE-2022-1161, CVE-2020-6998, and later advisories.
• Monitor EtherNet/IP traffic. Deploy OT-aware IDS (e.g. deep-packet inspection of CIP) to alert on List Identity sweeps, mode changes, and program downloads from unexpected sources.
• Alarm on unauthorized state changes. Alert whenever a controller leaves RUN or its program checksum changes outside a maintenance window — an unauthenticated STOP should never go unnoticed.
• Document exposure and re-test. Record every reachable controller, its identity, and its network path in the pentest report so remediation is tracked and re-verified after segmentation or firmware changes.

Real-World Example

At S4 in 2012, DigitalBond’s Project Basecamp put concrete proof behind the design-level risk of port 44818. Researchers showed that a Rockwell/Allen-Bradley ControlLogix PLC, reachable over EtherNet/IP, would accept unauthenticated CIP commands to stop the CPU and crash its Ethernet card — no credentials, no exploit of a memory-corruption bug, just the protocol doing what it was designed to do for a trusted peer. The team released tools (later folded into the auxiliary/admin/scada/multi_cip_command Metasploit module) so anyone could reproduce it, precisely to force the point that “the network is isolated” is not a security control. More than a decade later, internet scans still find thousands of controllers answering List Identity on 44818 — the exposure Basecamp warned about, still live. It is the port-44818 lesson in one line: the danger isn’t a patchable flaw, it’s an unauthenticated control protocol that anyone who can route to it can command.

FAQ

What is port 44818 used for?

Port 44818 is the default port for EtherNet/IP explicit messaging, which carries CIP (Common Industrial Protocol) request/response traffic to industrial controllers — most commonly Allen-Bradley/Rockwell ControlLogix and CompactLogix PLCs, but also Omron, Schneider, and other ODVA-conformant devices. Engineering software, SCADA/HMI systems, and peer controllers use it to read status, access tags, download logic, and change controller state, over both TCP and UDP.

Is EtherNet/IP on port 44818 authenticated?

No. CIP explicit messaging has no built-in authentication, session login, or access control on the standard surface. Any client that can reach 44818 is treated as a legitimate peer, which is why network segmentation — not a password — is the real defense. Newer controllers support CIP Security (authenticated, encrypted CIP), but it must be explicitly enabled and is far from universal.

What is the difference between port 44818 and port 2222 in EtherNet/IP?

They are the two halves of EtherNet/IP. Port 44818 (TCP/UDP) carries explicit messaging — on-demand request/response used for configuration, diagnostics, and tag access. Port 2222/UDP carries implicit (cyclic) I/O messaging — the real-time producer/consumer data exchange between a controller and its I/O. 44818 is the one that fingerprints and controls the device.

Can port 44818 be used to stop a PLC?

Yes. On many Rockwell Logix controllers, an unauthenticated CIP command sent to 44818 can stop the CPU, change its run/program mode, or crash the Ethernet interface — a denial-of-control against a live process. DigitalBond’s Project Basecamp demonstrated this against ControlLogix in 2012, and the capability is built into a public Metasploit module. This is why an internet-reachable 44818 is treated as a critical finding.

Are there patchable CVEs on port 44818, or is it all design risk?

Both. Most of the risk is design-level (the protocol has no authentication), but there are verified, patchable flaws too — CVE-2021-22681 (a recoverable verification key enabling unauthenticated authentication, CVSS 9.8), CVE-2022-1161 (hidden Logix program code, CVSS 9.8), and CVE-2020-6998 (a CIP-packet denial-of-service). Patch firmware for these, but do not assume patching alone secures the port.

How do I secure or close port 44818?

You generally cannot disable EtherNet/IP on a controller that needs it, so security is about reachability: isolate the OT network, firewall 44818 to named engineering stations and peer controllers only, and never expose it to the internet. Enable the controller’s protective mode switch, change-detection logging, and CIP Security where supported, patch firmware, and monitor for List Identity sweeps and mode changes. Then rescan from outside the control VLAN to confirm 44818 is unreachable.

TL;DR

• Service: EtherNet/IP explicit messaging carrying CIP (Common Industrial Protocol) to Allen-Bradley/Rockwell ControlLogix and CompactLogix PLCs and other industrial controllers (44818 = 0xAF12)
• Default port: 44818/TCP and 44818/UDP (explicit messaging); real-time I/O rides 2222/UDP
• Biggest risk: no authentication by design — a reachable 44818 lets an attacker fingerprint the device via List Identity, read/write tags, and on many Logix controllers stop the CPU or change its mode, plus verified CVEs (CVE-2021-22681, CVE-2022-1161, CVE-2020-6998)
• Mitigation: segment the OT network, never expose 44818 to the internet, firewall it to engineering stations and peers, enable CIP Security and controller change-detection, patch Rockwell firmware, and monitor CIP traffic

Related ICS/OT ports worth reviewing on the same engagement: Siemens S7comm on port 102 (the SIMATIC PLC programming and CPU-stop protocol) and BACnet/IP on port 47808 (building-automation controls) — both share EtherNet/IP’s no-authentication-by-design exposure, as does Modbus on port 502 discussed above.