Threat Hunt Plan: Rockwell Automation RSLinx Classic EtherNet/IP Denial-of-Service — Malformed CIP Crash Hunt

Date: 2026-07-21 | Revision 1.0

Hunt Objective and Scope

This hunt seeks evidence that an adversary has probed, targeted, or triggered the EtherNet/IP server denial-of-service condition in Rockwell Automation RSLinx Classic (CVE-2020-13573) within the monitored environment. The vulnerability is an out-of-bounds read in the Common Industrial Protocol (CIP) handling of the EtherNet/IP server: an unauthenticated, network-adjacent attacker sends a Register Session request (ENIP encapsulation command 0x65) followed by a Send Unit Data message (0x70) in which the declared Address Item Length is smaller than the data that follows, driving RSLinx Classic into an unresponsive state that requires manual restart. Affected versions are 4.50.00 and earlier; the fix is 4.60.00 (patch BF31213 for interim relief).

In scope: all Windows hosts running RSLinx Classic (communication servers, engineering workstations, SCADA/HMI gateways) at Purdue Levels 2–3.5; the EtherNet/IP service on TCP 44818 (explicit messaging), UDP 2222 (implicit I/O), and UDP 44818 (ListIdentity discovery); network paths from the enterprise/IT boundary into OT zones; and the OT monitoring, endpoint, and network-telemetry platforms deployed in the environment. Out of scope: exploitation of the deeper Rockwell control stack (Logix controllers) except where RSLinx acts as the pivot.

Recommended time window: 90 days of retrospective review for endpoint and network telemetry, extended to the full retention window for any host that shows a confirmed RSLinx crash or repeated restart. RSLinx is frequently a long-lived process; use the longest available window for process-start attribution.

Hypotheses and Hunt Procedures

Hypothesis 1: An external or non-baseline internal host has sent EtherNet/IP traffic to an RSLinx Classic server on TCP 44818, observable as inbound connections to the RSLinx host on port 44818 from sources outside the normal HMI/SCADA/EWS baseline in network and endpoint telemetry.

MITRE ATT&CK: Initial Access / Execution | T0866 Exploitation of Remote Services | Sending crafted CIP requests to the exposed EtherNet/IP service is the delivery vector for the out-of-bounds-read DoS.

Also relevant: T0814 Denial of Service (ICS) — the intended impact; T0855 Unauthorized Command Message — the malformed CIP sequence on the wire.

Collection Queries:

CrowdStrike Falcon LogScale (CQL) — inbound connections to the RSLinx EtherNet/IP service:

BPF / tcpdump — rolling capture of all EtherNet/IP traffic to/from the RSLinx host (run on a SPAN/TAP-fed sensor or the host itself):

Datadog Log Search (endpoint/network log-based visibility for the same connections):

Datadog Live Process Monitoring (Infrastructure > Processes — confirm RSLinx is present on the host, not a log source):

Windows Event IDs to collect (on the RSLinx host):

OT/ICS data collection:

Analysis Queries:

CrowdStrike Falcon LogScale (CQL) — external / non-RFC1918 sources reaching the RSLinx service (highest priority):

CrowdStrike Falcon LogScale (CQL) — rarest source IPs to the service (surfaces new/first-seen talkers by ascending frequency):

Wireshark / tshark — isolate the malformed CIP sequence (RegisterSession followed by SendUnitData):

Datadog Log Analytics — connection sources to the RSLinx service:

Datadog Monitor (one per hypothesis):

OT network / protocol analysis:

Hypothesis 2: An RSLinx Classic service has crashed or entered a crash-restart loop consistent with successful triggering of the out-of-bounds-read DoS, observable as RSLinx application-error events, Service Control Manager termination events, and repeated RSLINX.exe process starts in endpoint telemetry.

MITRE ATT&CK: Impair Process Control / Inhibit Response Function | T0814 Denial of Service | Loss of the RSLinx communication path severs HMI/SCADA visibility and control of downstream controllers.

Also relevant: T0816 Device Restart/Shutdown — the manual restart required to recover the service.

Collection Queries:

CrowdStrike Falcon LogScale (CQL) — RSLinx Classic process starts (each start after an unexpected stop indicates a recovery/restart):

Windows Event IDs to collect (on the RSLinx host):

Datadog Log Search (Windows event logs for the crash/restart):

OT/ICS data collection:

Analysis Queries:

CrowdStrike Falcon LogScale (CQL) — restart frequency per host (a high start count over the window is a crash-loop signal):

Windows Event Log analysis (PowerShell) — build a crash-and-restart timeline on a suspect host:

Datadog Log Analytics — crash events over time, grouped by host:

Datadog Monitor:

OT network / protocol analysis:

Hypothesis 3: An adversary has performed EtherNet/IP reconnaissance (ListIdentity sweeps / port scanning of 44818) to enumerate Rockwell/RSLinx hosts prior to exploitation, observable as one source touching many OT hosts on the EtherNet/IP ports.

MITRE ATT&CK: Discovery | T0846 Remote System Discovery | ListIdentity (ENIP 0x63) and 44818 sweeps enumerate reachable EtherNet/IP endpoints and their identity/firmware.

Also relevant: T0888 Remote System Information Discovery — the Identity object data returned by ListIdentity.

Collection Queries:

CrowdStrike Falcon LogScale (CQL) — fan-out detection: one remote source reaching many hosts on the EtherNet/IP ports:

BPF / tcpdump — capture ListIdentity discovery (UDP 44818 broadcast + TCP session opens):

Datadog Log Search:

OT/ICS data collection:

Analysis Queries:

Armis Centrix (ASQ) — connections into the OT zone on the EtherNet/IP service (set the time window in the UI picker; substitute the real boundary literal for <ot_boundary>):

Wireshark / tshark — count ListIdentity requests per source (recon volume):

Nozomi N2QL — nodes issuing EtherNet/IP to many peers:

Datadog Monitor:

Threat Actor Profile

Opportunistic / internet-scanning actors: RSLinx Classic instances are discoverable through internet scanning on TCP 44818, and researchers have found many thousands of exposed instances. A low-sophistication actor needs only a reachable service and a short crafted-packet script to trigger the crash; no authentication and no user interaction are required. Motivation is typically disruption or coercion rather than data theft.

ICS-focused threat groups: Rockwell EtherNet/IP is a documented target of OT-capable adversaries. Groups tracked for CIP/EtherNet/IP tradecraft (e.g., the actor cluster behind the 2026 BAUXITE Rockwell Logix campaign, and the PIPEDREAM/CODESYS toolset's CIP reconnaissance and command capabilities) demonstrate the sophistication to combine enumeration (ListIdentity), targeting, and protocol abuse. Such actors would use the DoS as a supporting effect — masking a change, forcing an operator to a fallback state, or degrading visibility during a larger operation.

Insider / third-party: an engineer, contractor, or vendor with legitimate OT network access could trigger the condition accidentally (malformed tooling, misconfigured scanner) or deliberately. Legitimate OT scanning (Tenable, Qualys, Nessus) with scope leaking into OT subnets can produce EtherNet/IP traffic that resembles reconnaissance — treat as a false-positive class to rule out, not to ignore.

Data Sources Required

Network: SPAN/TAP-fed PCAP at the IT/OT boundary and within OT zones; NetFlow; enterprise and OT firewall logs for TCP 44818 / UDP 2222 / UDP 44818.

Endpoint: CrowdStrike Falcon (NetworkConnectIP4, ProcessRollup2) on any Windows host running RSLinx; Windows Event Logs (Application, System, Security/WFP) via forwarder or Sysmon.

OT/ICS monitoring: Claroty xDome/CTD, Dragos Platform, Nozomi Guardian/Vantage, Tenable OT Security, Forescout eyeInspect, Armis Centrix — asset inventory (identify Rockwell/RSLinx hosts and firmware), Communication/flow analysis, and alerting on EtherNet/IP protocol.

Vendor/device: RSLinx Classic host inventory and installed version; switch SNMP interface counters for the RSLinx-facing port; SNMP trap receiver for coldStart/warmStart and linkDown/linkUp on OT network gear.

Detection Signatures

SIGMA rules span three logsource categories (Windows application log, Windows system log, and network_connection).

The first SIGMA rule targets the direct crash artifact — a Windows Application Error naming RSLINX.exe as the faulting application — because a successful out-of-bounds-read DoS terminates the process and generates Event ID 1000. It is scoped tightly to the RSLinx image name to avoid firing on unrelated application faults.

The second SIGMA rule watches the Service Control Manager for unexpected termination of the RSLinx service (7031/7034). The out-of-bounds read leaves the service unresponsive; on hosts where RSLinx runs as a service, the SCM records the unexpected stop before any manual recovery.

The third SIGMA rule targets the delivery vector at the network layer — an inbound connection to TCP 44818 from a source outside the RFC1918 ranges — using a network_connection logsource so it applies to Sysmon EID 3 or equivalent connection telemetry. It pairs with Hypothesis 1 and is deliberately broad on destination but narrow on external source to keep volume manageable.

Snort/Suricata rules (local SID range 1,000,000+):

YARA rules (one file/disk, one process memory):

The first YARA rule targets exploit tooling dropped on disk — a proof-of-concept script or packet-builder that crafts the malformed CIP sequence. The condition requires the EtherNet/IP target port together with either RegisterSession/SendUnitData references or the "Address Item" field name that the exploit must undersize, so it fires on purpose-built RSLinx DoS tooling rather than on any file that merely mentions EtherNet/IP. The 2-of-branch threshold reduces false positives on benign automation scripts.

The second YARA rule scans the memory of a live interpreter or tool process (for example python.exe running a PoC, scanned by PID) for the assembled ENIP encapsulation header bytes and the CIP/EtherNet/IP string constants that a running exploit holds in memory while building or replaying the malformed packet. It is intended for CrowdStrike RTR or Falcon Real Time Response execution against a suspect EWS/jump host, or bulk process scanning on that host; the condition combines the SendUnitData opcode bytes with at least one protocol string to avoid matching unrelated buffers.

Classic YARA 4.5 process-memory scan (pass the PID as the positional target — there is no -p flag for the target):

File-system scan:

Indicators of Compromise

Network IOCs (behavioral, scoped to this hunt):

Host IOCs:

OT/operational IOCs:

False Positive Baseline

1. Sanctioned HMI/SCADA and engineering-workstation polling of RSLinx on TCP 44818 at a steady cadence — the normal traffic baseline; suppress known talker pairs.

2. Authorized OT vulnerability scanning (Tenable OT active query, Nessus against IT-side assets, Qualys) that touches EtherNet/IP ports — verify against the scan schedule and scanner source IPs before escalating.

3. Planned RSLinx service restarts during maintenance windows — correlate SCM 7036 stop/start and process starts against the change calendar.

4. RSLinx crashes from unrelated software faults, driver issues, or resource exhaustion — an Application Error 1000 without any preceding inbound 44818 session from a non-baseline source is likely non-malicious.

5. Backup, asset-management, or monitoring agents (e.g., Rockwell AssetCentre) that enumerate Rockwell devices over EtherNet/IP on a schedule — a known, recurring source pattern rather than an ad-hoc scan.

Escalation Criteria

1. An inbound TCP 44818 session to an RSLinx host from a non-RFC1918 or otherwise non-baseline source immediately followed (within seconds) by an RSLINX.exe crash (Event ID 1000) or SCM 7031/7034 — treat as confirmed exploitation and engage IR.

2. A confirmed malformed CIP sequence in captured traffic (RegisterSession then SendUnitData with an undersized Address Item Length) directed at an RSLinx host.

3. A crash-restart loop: three or more RSLINX.exe process starts and/or Application Error 1000 events on a single host within a short window.

4. A single source touching many OT hosts on 44818/2222 (scan fan-out) combined with any subsequent RSLinx crash.

5. Any YARA hit from RSLinx_ENIP_DoS_Exploit_Tooling against files on an EWS, jump host, or RSLinx server.

6. Any YARA hit from RSLinx_ENIP_DoS_Process_Memory against a running process on an OT-adjacent host.

7. Loss of controller visibility or an operator-confirmed process disruption coinciding with any of the above.

Hunt Completion Criteria and Reporting

The hunt is complete when: all Windows hosts running RSLinx Classic have been inventoried with their installed version (identifying every host at or below 4.50.00); network and endpoint telemetry for inbound 44818 traffic and RSLINX.exe crash/restart events has been reviewed across the 90-day window; the OT monitoring platforms in the environment have been queried for EtherNet/IP flows and RSLinx-host alerts; and every escalation-criterion match has been either dispositioned as a false positive or handed to incident response.

The report must contain: the RSLinx Classic host inventory with versions and patch status (4.60.00 / BF31213); a list of hosts exposed to non-baseline or external sources on 44818; any confirmed crashes or crash-loops with their correlated network sessions; disposition of each finding against the false-positive baseline; the exposure/segmentation gaps identified (any RSLinx service reachable from the enterprise or internet); and prioritized remediation recommendations (upgrade to 4.60.00, apply BF31213 where upgrade is deferred, restrict 44818 to sanctioned sources, and add the detection content from Section 5 as standing detections). Note any monitoring blind spots (zones without sensor coverage, encrypted paths, hosts without endpoint telemetry) as caveats on any negative finding.

Advisory IoC Reference