Rockwell Automation RSLinx Classic EtherNet/IP Denial-of-Service Vulnerability (CVE-2020-13573)

Hunt Objective and Scope

This hunt seeks evidence that an attacker sent crafted Common Industrial Protocol (CIP) requests to the EtherNet/IP server of Rockwell Automation RSLinx Classic to trigger the out-of-bounds read denial-of-service condition described in CVE-2020-13573 (CWE-125), rendering the communication server unresponsive, and to determine whether the resulting loss of communications coincided with reconnaissance of EtherNet/IP services or with unauthorized activity against Allen-Bradley controllers. The vulnerability is network-reachable, requires no authentication or user interaction (CVSS v3.1 7.5, CVSS v4.0 8.7), and does not self-recover — RSLinx Classic must be restarted manually. CISA has no record of public exploitation, so this hunt is a proactive baseline focused on the availability of the communication path and on any activity that a denial-of-service event could screen.

Environment in scope: all Windows hosts running RSLinx Classic in an affected version (4.50.00 and earlier); the EtherNet/IP and CIP listeners on those hosts (TCP/UDP 44818 and TCP 2222); the engineering, HMI, historian, and SCADA systems that legitimately communicate with RSLinx; and the Allen-Bradley controller network (ControlLogix / CompactLogix / Logix) reached through RSLinx over EtherNet/IP. All hostnames, IP ranges, zone names, and notification handles in this plan are generic placeholders — substitute the values for the environment under test. Time window: the trailing 90 days, extended backward to whenever the host first ran an affected RSLinx Classic release.

Hypotheses and Hunt Procedures

Hypothesis 1: An attacker sent crafted CIP/EtherNet/IP requests to the RSLinx Classic server (TCP 44818 / TCP 2222) that triggered the out-of-bounds read, observable as RSLinx Classic (RSLINX.EXE) application crashes and hangs in the Windows event logs and as anomalous or malformed CIP traffic to the host around the crash time.

MITRE ATT&CK: Impact | T1499.004 — Endpoint Denial of Service: Application or System Exploitation | The crafted CIP request drives the EtherNet/IP server to crash, denying the communication service.

MITRE ATT&CK: Initial Access | T1190 — Exploit Public-Facing Application | The network-reachable EtherNet/IP service is the exploited entry point.

Collection Queries:

CrowdStrike Falcon FQL — RSLinx Classic process terminations and restarts on the affected hosts (Windows sensor):

#event_simpleName = "EndOfProcess"

| ImageFileName = /RSLINX\.EXE/i

| table([ComputerName, ImageFileName, RawProcessId, ContextTimeStamp])

#event_simpleName = "ProcessRollup2"

| FileName = /^RSLINX\.EXE$/i

| table([ComputerName, AuthenticationId, ImageFileName, CommandLine, ParentBaseFileName])

BPF packet capture — capture inbound EtherNet/IP to the RSLinx host for offline reconstruction of the crafted requests (RSLinx host placeholder 10.40.0.15):

tcpdump -i eth0 -s 0 -w /opt/hunt/pcap/rslinx_enip_%Y%m%d_%H%M%S.pcap -G 3600 -C 100 'host 10.40.0.15 and (tcp port 44818 or udp port 44818 or tcp port 2222)'

tcpdump -i eth0 -w /opt/hunt/pcap/rslinx_rst.pcap 'host 10.40.0.15 and tcp port 44818 and tcp[tcpflags] & tcp-rst != 0'

Windows Event IDs — collect application-crash and service-failure events from the RSLinx host (these are the primary on-host evidence of the DoS):

- 1000 (Application Error) — faulting application RSLINX.EXE, with faulting module and offset

- 1002 (Application Hang) — RSLINX.EXE stopped responding

- 7031 / 7034 (Service Control Manager) — RSLinx service terminated unexpectedly and restart action

PowerShell collection:

Get-WinEvent -FilterHashtable @{LogName='Application'; Id=1000,1002; StartTime=(Get-Date).AddDays(-90)} | Where-Object { $_.Message -match 'RSLINX' } | Select-Object TimeCreated, Id, Message | Export-Csv C:\hunt\rslinx_crashes.csv -NoTypeInformation

Get-WinEvent -FilterHashtable @{LogName='System'; Id=7031,7034; StartTime=(Get-Date).AddDays(-90)} | Where-Object { $_.Message -match 'RSLinx' } | Export-Csv C:\hunt\rslinx_svc_failures.csv -NoTypeInformation

Datadog Log Search — RSLinx crash/hang and service-failure events forwarded from the Windows host (source:windows via the Datadog Windows Event Log integration):

source:windows (@evt.id:1000 OR @evt.id:1002 OR @evt.id:7031 OR @evt.id:7034) message:RSLinx

// time range: last 90 days

// Analytics: Table view, group by host; time range: last 90 days

Datadog Live Process Monitoring (Infrastructure > Processes — NOT a log source; requires the Datadog Agent with Live Process Monitoring enabled on the Windows host): confirm RSLinx presence and restarts:

command:RSLINX.EXE

// Free text: type "RSLinx" to match the communication server process

OT Data Collection: Armis — baseline the RSLinx host's EtherNet/IP peers and the Allen-Bradley controllers it serves (ASQ; aggregation is performed in the results grid or via the API, never inside the query string):

in:devices name:RSLinx,RSLinx-Classic

in:devices type:PLC,Controller vendor:Rockwell,Allen-Bradley

Analysis Queries:

CrowdStrike Falcon FQL — count RSLinx terminations per host over the window to surface crash clusters consistent with a DoS attempt:

#event_simpleName = "EndOfProcess"

| ImageFileName = /RSLINX\.EXE/i

| groupBy([ComputerName], function=count(), limit=100000)

| sort(_count, order=desc, limit=50)

Wireshark display filters — isolate EtherNet/IP/CIP traffic to the RSLinx host and flag malformed or error-laden CIP responses around the crash window (tshark equivalents included):

enip && ip.dst == 10.40.0.15

cip.genstat != 0x00

tshark -r /opt/hunt/pcap/rslinx_enip.pcap -Y 'enip' -T fields -e ip.src -e enip.command -e cip.service -e cip.genstat

Datadog Log Analytics — top source IPs communicating with the RSLinx EtherNet/IP service (correlate the busiest or newest peers with crash times):

source:windows message:RSLinx (@evt.id:1000 OR @evt.id:1002)

// Analytics: Top List view, group by host; time range: last 90 days

// Correlate crash timestamps against the EtherNet/IP source IPs from PCAP / OT sensors

Datadog Monitor:

Type: Log Alert

Query: source:windows message:RSLinx (@evt.id:1000 OR @evt.id:1002 OR @evt.id:7031)

Evaluation window: last 10 minutes

Alert condition: count > 2

Message: "ALERT: Repeated RSLinx Classic crashes/hangs — possible CVE-2020-13573 EtherNet/IP denial of service @soc-oncall @ot-oncall"

Prerequisites: RSLinx host Application and System event logs forwarded to Datadog via the Windows Event Log integration

Create via: Monitors > New Monitor > Log Alert OR POST /api/v1/monitors

OT Data Collection: Claroty CTD — Investigation tab, filter for EtherNet/IP (44818/2222) sessions to the RSLinx host; identify any source outside the sanctioned engineering/HMI baseline and export PCAP per alert to inspect the CIP request sequence.

YARA file-system scan — scan the RSLinx host and staging shares for exploit tooling or PoC scripts targeting CVE-2020-13573:

yara -r C:\hunt\rules\rslinx_dos_exploit.yar C:\Users C:\ProgramData C:\Temp >> C:\hunt\out\rslinx_exploit_hits.txt

Hypothesis 2: The denial-of-service attempt was preceded by reconnaissance of EtherNet/IP services, observable as EtherNet/IP List Identity requests and CIP enumeration from a source that is not part of the normal engineering/HMI baseline.

MITRE ATT&CK: Discovery | T1046 — Network Service Discovery | The attacker enumerates the EtherNet/IP service before crafting the crash request.

MITRE ATT&CK: Collection (ICS) | T0846 — Remote System Discovery | CIP List Identity / device enumeration maps the OT environment.

Collection Queries:

BPF packet capture — capture EtherNet/IP List Identity (UDP 44818 broadcast/unicast) and enumeration probes to the control subnet:

tcpdump -i eth0 -w /opt/hunt/pcap/enip_scan_%Y%m%d.pcap 'udp port 44818 or (tcp port 44818 and tcp[tcpflags] & tcp-syn != 0)'

CrowdStrike Falcon FQL — inbound EtherNet/IP connection acceptance on the RSLinx host from distinct remote sources (network-scan indicator):

#event_simpleName = "NetworkReceiveAcceptIP4"

| LocalPort = /^(44818|2222)$/

| table([ComputerName, RemoteAddressIP4, LocalPort, ContextTimeStamp])

Datadog Log Search — firewall/flow logs showing new sources reaching the EtherNet/IP ports (source:<firewall_integration> — substitute the deployed firewall source):

source:firewall (@destination.port:44818 OR @destination.port:2222) @destination.ip:10.40.0.15

// time range: last 90 days

// Analytics: Top List view, group by @source.ip; time range: last 90 days

Windows Event IDs — collect Windows Filtering Platform connection events on the RSLinx host if WFP auditing is enabled:

- 5156 (The Windows Filtering Platform has permitted a connection) — inbound to 44818/2222

PowerShell collection:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=5156; StartTime=(Get-Date).AddDays(-90)} | Where-Object { $_.Message -match '44818|2222' } | Export-Csv C:\hunt\rslinx_wfp_conn.csv -NoTypeInformation

Analysis Queries:

Wireshark display filters — EtherNet/IP List Identity and session enumeration (tshark equivalent included):

enip.command == 0x0063 || enip.command == 0x0004

tshark -r /opt/hunt/pcap/enip_scan.pcap -Y 'enip.command == 0x0063' -T fields -e ip.src -e ip.dst

CrowdStrike Falcon FQL — rarity analysis of remote sources touching the EtherNet/IP ports (rare/new sources are candidate scanners):

#event_simpleName = "NetworkReceiveAcceptIP4"

| LocalPort = /^(44818|2222)$/

| groupBy([ComputerName, RemoteAddressIP4], function=count(), limit=100000)

| sort(_count, order=asc, limit=50)

Datadog Log Analytics — new EtherNet/IP source IPs not seen in the prior baseline window:

source:firewall @destination.port:44818 @destination.ip:10.40.0.15

// Analytics: Table view, group by @source.ip; time range: last 90 days

Datadog Monitor:

Type: Log Alert

Query: source:firewall @destination.port:44818 @destination.ip:10.40.0.15 -@source.ip:10.40.0.0/24

Evaluation window: last 15 minutes

Alert condition: count > 0

Message: "ALERT: EtherNet/IP access to RSLinx host from a non-baseline source — possible reconnaissance ahead of CVE-2020-13573 DoS @ot-oncall"

Prerequisites: Firewall/flow logs for the control segment forwarded to Datadog with source.ip and destination.port parsed

Create via: Monitors > New Monitor > Log Alert OR POST /api/v1/monitors

OT Data Collection: Nozomi Networks — query links for new EtherNet/IP sources into the control zone (N2QL; token via POST /api/open/sign_in, then GET /api/open/query/do):

links | where protocol == "enip" and to_zone == "Control" and from_zone != "Engineering"

OT Data Collection: Tenable OT Security — Inventory > All Assets, filter to EtherNet/IP-speaking assets, Export; programmatic pulls are GraphQL only via the single /graphql endpoint (no REST asset/event endpoints).

Hypothesis 3: The RSLinx denial of service coincided with or screened unauthorized activity against Allen-Bradley controllers — the loss of the communication server removing operator visibility while an attacker issued CIP writes, mode changes, or program downloads to Logix controllers.

MITRE ATT&CK: Impact (ICS) | T0815 — Denial of View | The RSLinx outage removes operator visibility of the process.

MITRE ATT&CK: Impact (ICS) | T0843 — Program Download | An attacker downloads or modifies controller logic during the outage.

Collection Queries:

BPF packet capture — capture CIP traffic to Allen-Bradley controllers during and around the RSLinx outage window (controller subnet 10.40.1.0/24):

tcpdump -i eth1 -w /opt/hunt/pcap/logix_cip_%Y%m%d.pcap 'net 10.40.1.0/24 and (tcp port 44818 or tcp port 2222)'

CrowdStrike Falcon FQL — connections from engineering hosts to controllers during the outage window (identify who talked to the PLCs while RSLinx was down):

#event_simpleName = "NetworkConnectIP4"

| RemotePort = /^(44818|2222)$/

| cidr(RemoteAddressIP4, subnet=["10.40.1.0/24"])

| table([ComputerName, RemoteAddressIP4, RemotePort, LocalAddressIP4, ContextTimeStamp])

OT Data Collection: Dragos Platform — Communications Hub, filter zone-to-zone for CIP program-download and mode-change activity to Logix controllers during the RSLinx outage window; export event-based PCAP with asset context on both endpoints and correlate against Dragos detections for controller state changes.

Analysis Queries:

Wireshark display filters — CIP service codes associated with controller writes, mode changes, and program download (tshark equivalent included):

cip.service == 0x4d || cip.service == 0x53

cip.service == 0x06 || cip.service == 0x07

tshark -r /opt/hunt/pcap/logix_cip.pcap -Y 'cip.service in {0x4d 0x53 0x4c 0x06 0x07}' -T fields -e ip.src -e ip.dst -e cip.service

Datadog Log Analytics — correlate RSLinx crash timestamps with any controller-change events captured by OT monitoring forwarded to Datadog:

source:otsensor @event.type:(program_download OR mode_change OR tag_write) @device.vendor:Rockwell

// Analytics: Table view, group by @device.id, @source.ip; time range: aligned to RSLinx outage windows

Datadog Monitor:

Type: Log Alert

Query: source:otsensor @event.type:(program_download OR mode_change) @device.vendor:Rockwell

Evaluation window: last 15 minutes

Alert condition: count > 0

Message: "ALERT: Logix program download / mode change detected — verify change control; correlate with any RSLinx outage @ot-oncall"

Prerequisites: OT monitoring platform forwarding CIP controller-change events to Datadog with event.type and device.vendor parsed

Create via: Monitors > New Monitor > Log Alert OR POST /api/v1/monitors

SNMP polling — baseline and diff the switch port facing the RSLinx host and the controller-facing uplinks to detect traffic/error anomalies during the outage window:

snmpwalk -v3 -l authPriv -u hunt_ro -a SHA-256 -A <authpass> -x AES-256 -X <privpass> 10.40.0.1 IF-MIB::ifTable

snmpget -v3 -l authPriv -u hunt_ro -a SHA-256 -A <authpass> -x AES-256 -X <privpass> 10.40.0.1 IF-MIB::ifHCInOctets.13 IF-MIB::ifHCOutOctets.13 IF-MIB::ifInErrors.13 IF-MIB::ifOutErrors.13

OT Data Collection: Armis — surface policy violations on Allen-Bradley controllers whose new peer is outside the sanctioned engineering baseline during the outage (ASQ; aggregation via results grid/API):

in:devices type:PLC,Controller vendor:Rockwell,Allen-Bradley riskLevel:High,Critical

in:alerts type:"Policy Violation" severity:High,Critical

YARA memory scan — scan the RSLinx process (before it crashes, or a restarted instance) and any engineering-tool processes for injected code or exploit artifacts (classic YARA 4.5; PID is positional — there is no -p flag):

for /f %p in ('powershell -c "(Get-Process RSLINX).Id"') do yara C:\hunt\rules\rslinx_process_memory.yar %p >> C:\hunt\out\rslinx_mem_hits.txt

Threat Actor Profile

CVE-2020-13573 is a well-documented denial-of-service vulnerability with no reported public exploitation. The realistic threat comes from actors who can reach the OT network and choose to disrupt the RSLinx communication path, either as an end in itself or to screen other activity. Two actor classes are relevant.

Opportunistic or disruptive actor: A low-to-moderate sophistication attacker or an insider with OT network access who fires a known crash technique against the EtherNet/IP service to interrupt operations. This actor is noisy — repeated RSLinx crashes and restarts — and their objective is disruption or nuisance rather than stealthy control. Because the attack is unauthenticated and low-complexity, even a limited foothold on the control network or an exposed EtherNet/IP service is sufficient.

Targeted OT actor: A capable, industrially focused adversary who understands that RSLinx Classic is the visibility and control chokepoint for Allen-Bradley environments. Such an actor may use the denial of service deliberately — to blind operators (Denial of View) while issuing CIP writes, mode changes, or program downloads to Logix controllers, or to test the resilience and recovery behavior of the control environment ahead of a larger operation. This actor demonstrates OT protocol fluency, times the disruption to operational windows, and pairs the DoS with controller-level activity. The hunt therefore treats an RSLinx outage not only as an availability event but as a potential cover for controller manipulation, and correlates the two.

Data Sources Required

Network: full-packet capture at the RSLinx host and the controller-facing uplinks (PCAP), NetFlow/IPFIX from the control segment, firewall/flow logs for the EtherNet/IP ports (44818/2222), OT IDS EtherNet/IP and CIP events.

Endpoint (RSLinx host): CrowdStrike Falcon Windows sensor telemetry (ProcessRollup2, EndOfProcess, NetworkReceiveAcceptIP4, NetworkConnectIP4), Windows Application and System event logs (1000/1002/7031/7034), Windows Filtering Platform events (5156) where enabled.

Application: RSLinx Classic diagnostic/event logs and the installed version inventory.

OT/ICS: Claroty CTD, Dragos Platform, Nozomi Networks, Armis, and Tenable OT exports; historian and HMI alarm logs for the affected process (to confirm loss of view); SNMP interface counters and trap logs from the switches facing the RSLinx host and controllers.

Detection Signatures

SIGMA rules span the Windows application, network_connection, and process_creation logsource categories.

title: RSLinx Classic Application Crash or Hang (Possible CVE-2020-13573)

id: 7d2a4c81-3b96-4e15-9f24-1a6c8e2b5d30

status: experimental

description: Detects RSLinx Classic (RSLINX.EXE) application-error or hang events, consistent with the EtherNet/IP out-of-bounds read denial of service in CVE-2020-13573.

references:

- https://www.rockwellautomation.com/en-us/trust-center/security-advisories/advisory.SD1774.html

author: 1898 & Co. Threat Hunt Team

date: 2026/07/08

logsource:

product: windows

service: application

detection:

selection:

EventID:

- 1000

- 1002

Data|contains: 'RSLINX.EXE'

condition: selection

falsepositives:

- Genuine RSLinx crashes from unrelated software faults or resource exhaustion — correlate with EtherNet/IP source

level: high

title: EtherNet/IP Access to RSLinx Host From Non-Baseline Source

id: 2b8f1e46-5c73-4a29-b6d1-9e0a7c34f8b2

status: experimental

description: Detects inbound EtherNet/IP/CIP connections to the RSLinx Classic host from a source outside the sanctioned engineering/HMI baseline, indicating reconnaissance or the crafted-request DoS of CVE-2020-13573.

references:

- https://nvd.nist.gov/vuln/detail/CVE-2020-13573

author: 1898 & Co. Threat Hunt Team

date: 2026/07/08

logsource:

product: windows

category: network_connection

detection:

selection:

DestinationIp: '10.40.0.15'

DestinationPort:

- 44818

- 2222

filter_baseline:

SourceIp|cidr: '10.40.0.0/24'

condition: selection and not filter_baseline

falsepositives:

- Additional approved engineering/HMI subnets — add each to filter_baseline

level: medium

title: Unexpected Process Spawned on RSLinx Host

id: 4f9c0a73-6d18-4b52-8e30-2c7b1a5f9d64

status: experimental

description: Detects the RSLinx host spawning command interpreters or scripting tools not associated with normal operation, indicating follow-on activity after an EtherNet/IP exploitation attempt.

references:

- https://www.rockwellautomation.com/en-us/trust-center/security-advisories/advisory.SD1774.html

author: 1898 & Co. Threat Hunt Team

date: 2026/07/08

logsource:

product: windows

category: process_creation

detection:

selection:

Image|endswith:

- '\cmd.exe'

- '\powershell.exe'

- '\wscript.exe'

- '\cscript.exe'

- '\mshta.exe'

selection_host:

Computer: 'RSLINX-HOST'

condition: selection and selection_host

falsepositives:

- Administrative scripts run on the RSLinx host during maintenance — baseline and allowlist

level: medium

Snort/Suricata rules detect EtherNet/IP enumeration and anomalous CIP request rates against the RSLinx host. Local SIDs start at 1,000,000.

alert udp any any -> $RSLINX_HOST 44818 (msg:"1898 CVE-2020-13573 EtherNet/IP List Identity enumeration of RSLinx host"; content:"|63 00|"; offset:0; depth:2; threshold:type limit, track by_src, count 1, seconds 60; classtype:attempted-recon; sid:1000007; rev:1; reference:url,nvd.nist.gov/vuln/detail/CVE-2020-13573;)

alert tcp any any -> $RSLINX_HOST 44818 (msg:"1898 CVE-2020-13573 High-rate CIP requests to RSLinx EtherNet/IP server (possible DoS)"; flow:to_server,established; detection_filter:track by_src, count 100, seconds 10; classtype:attempted-dos; sid:1000008; rev:1; reference:url,rockwellautomation.com/en-us/trust-center/security-advisories/advisory.SD1774.html;)

YARA rules cover exploit tooling on disk, artifacts in the RSLinx process memory, and (for the controller-pivot path) credential-dump tooling on the RSLinx and engineering hosts.

The rslinx_dos_exploit.yar rule targets scripts or tools staged to exploit CVE-2020-13573. It anchors on the co-occurrence of EtherNet/IP/CIP crafting primitives (the 44818 port, the ENIP/CIP keywords, common Python OT libraries) with references to RSLinx or the CVE, so a benign OT engineering script that merely talks EtherNet/IP does not match without the exploit-specific context.

rule rslinx_dos_exploit

{

meta:

description = "Exploit/PoC tooling targeting RSLinx Classic EtherNet/IP DoS (CVE-2020-13573)"

author = "1898 & Co. Threat Hunt Team"

date = "2026-07-08"

reference = "SD1774"

strings:

$enip1 = "44818" ascii wide // EtherNet/IP port

$enip2 = "EtherNet/IP" nocase ascii wide // protocol name

$enip3 = "cip" nocase ascii wide // CIP keyword

$lib = "cpppo" nocase ascii wide // common OT/ENIP python library

$t1 = "RSLinx" nocase ascii wide // target product

$t2 = "CVE-2020-13573" ascii wide // target CVE

condition:

(1 of ($t1, $t2)) and (2 of ($enip1, $enip2, $enip3, $lib))

}

The rslinx_process_memory.yar rule targets in-memory artifacts in a running or restarted RSLINX.EXE — shellcode egg markers and reverse-shell command strings that would indicate the out-of-bounds condition was leveraged beyond a simple crash. The condition requires a memory-execution or shell indicator so that ordinary CIP data buffers in memory do not match.

rule rslinx_process_memory

{

meta:

description = "In-memory shellcode/reverse-shell artifacts in RSLINX.EXE (CVE-2020-13573 post-exploitation)"

author = "1898 & Co. Threat Hunt Team"

date = "2026-07-08"

strings:

$sh1 = "cmd.exe /c" nocase ascii wide // spawned shell

$sh2 = "powershell -nop -w hidden" nocase ascii wide // hidden PowerShell

$rev = "WSASocket" ascii wide // reverse-shell socket API

$egg = { 90 90 90 90 90 90 90 90 } // NOP sled marker

$ws = "ws2_32" nocase ascii wide // winsock loaded into RSLinx unexpectedly

condition:

1 of ($sh1, $sh2) or ($rev and $ws) or ($egg and $ws)

}

The creddump.yar rule is the standing credential-access rule, included because the controller-pivot hypothesis (H3) can involve lateral movement to and from the RSLinx and engineering hosts. On these Windows hosts the LSASS-focused branches apply directly; the Linux branches are retained per standard for any Linux jump host in the path. SeDebugPrivilege is required for the LSASS branches; CrowdStrike RTR can execute this rule remotely.

rule creddump

{

meta:

description = "Windows LSASS credential-dump tooling + Linux secrets access (standing rule)"

author = "1898 & Co. Threat Hunt Team"

date = "2026-07-08"

strings:

$mk1 = "sekurlsa::logonpasswords" nocase // mimikatz

$mk2 = "lsadump::sam" nocase // mimikatz

$mk3 = "privilege::debug" nocase // mimikatz

$mk4 = "mimikatz" nocase // mimikatz name

$wce = "wce.exe" nocase // WCE

$gs = "gsecdump" nocase // gsecdump

$md1 = "MiniDump" nocase // comsvcs minidump

$md2 = "comsvcs" nocase // comsvcs.dll

$api1 = "NtReadVirtualMemory" nocase // memory-read API

$api2 = "ReadProcessMemory" nocase // memory-read API

$lsass = "lsass.exe" nocase // target process

$lx_shadow = "/etc/shadow" nocase // Linux hashed-credential store

condition:

any of ($mk1, $mk2, $mk3, $mk4) or

($wce and $lsass) or

$gs or

($md1 and $md2 and $lsass) or

(1 of ($api1, $api2) and $lsass and 1 of ($mk4, $wce, $gs)) or

$lx_shadow

}

Indicators of Compromise

Network IOCs (behavioral, scoped to this hunt):

EtherNet/IP/CIP traffic to the RSLinx host (TCP/UDP 44818, TCP 2222) from a source outside the sanctioned engineering/HMI baseline.

EtherNet/IP List Identity (command 0x63) or session enumeration from a non-baseline source.

High-rate or malformed CIP requests to the RSLinx EtherNet/IP server correlated with a crash; CIP responses carrying non-zero general status around the crash window.

CIP write / mode-change / program-download service codes to Allen-Bradley controllers during an RSLinx outage.

Host IOCs (behavioral):

RSLINX.EXE Application Error (EID 1000) or Application Hang (EID 1002); RSLinx service failure/restart (SCM 7031/7034) without a corresponding maintenance action.

Unexpected interpreters (cmd/powershell/wscript/cscript/mshta) spawned on the RSLinx host.

YARA hits for EtherNet/IP DoS exploit tooling or in-memory shellcode in RSLINX.EXE.

OT/operational IOCs (behavioral):

Loss of view / stale data on HMIs and historians coinciding with an RSLinx outage.

Logix program download, mode change, or tag write to controllers not mapped to authorized change control, especially during an RSLinx outage.

Armis policy violations on Allen-Bradley controllers whose new peer is outside the engineering baseline; unexpected interface error bursts on the RSLinx-facing switch port.

False Positive Baseline

At least five known-good patterns to characterize and suppress:

1. Legitimate RSLinx Classic restarts during host patching, RSLinx upgrades, or scheduled reboots — correlate to change windows and maintenance events.

2. Genuine RSLinx crashes from unrelated software faults, driver issues, or resource exhaustion — inspect the faulting module in the EID 1000 detail before attributing to CVE-2020-13573.

3. Authorized engineering and HMI systems polling the EtherNet/IP service and controllers over 44818/2222 — baseline these sources so only non-baseline peers alert.

4. Asset-inventory and OT monitoring tools that issue EtherNet/IP List Identity and CIP enumeration as part of normal discovery — allowlist the sanctioned scanner sources.

5. Scheduled Logix program downloads and tag writes performed by named engineers during approved change windows — baseline the operators, controllers, and windows.

6. Administrative scripts (PowerShell/cmd) run on the RSLinx host by IT during maintenance — baseline by command line and account.

Escalation Criteria

Engage incident response immediately when any of the following are met:

1. Any YARA hit from rslinx_dos_exploit.yar against files on the RSLinx host or staging shares.

2. Any YARA hit from rslinx_process_memory.yar against a running or restarted RSLINX.EXE.

3. Any YARA hit from creddump.yar on the RSLinx host or an engineering host in the controller-access path.

4. Repeated RSLINX.EXE crashes/hangs (EID 1000/1002) or service failures (SCM 7031/7034) traceable to EtherNet/IP traffic from a single non-baseline source.

5. EtherNet/IP access to the RSLinx host, or CIP enumeration of the control subnet, from a source outside the sanctioned engineering/HMI baseline.

6. Logix program download, mode change, or tag write to a controller not mapped to authorized change control — particularly if it coincides with an RSLinx outage.

7. Confirmation that the host runs an affected RSLinx Classic release (4.50.00 or earlier) without the corrected version or patch BF31213 applied, while any of the above are observed.

Hunt Completion Criteria and Reporting

The hunt is complete when: every in-scope RSLinx Classic host has been checked for affected-release status and patch/upgrade state; the Windows application/system logs, host and network telemetry, EtherNet/IP traffic, and controller-facing activity for each host have been reviewed across the full time window; all YARA, SIGMA, and network signatures have been run and their hits triaged; and OT-side collection has confirmed whether any RSLinx outage coincided with unauthorized controller activity or loss of view. Each escalation criterion tied to a YARA rule (rslinx_dos_exploit.yar, rslinx_process_memory.yar, creddump.yar) must have been evaluated and either cleared or escalated.

The report must document: RSLinx Classic hosts in scope and their release/patch status; the exact queries and signatures run with time ranges; all findings with supporting log/PCAP/telemetry evidence; any confirmed or suspected denial-of-service events, reconnaissance, or controller manipulation, with a timeline correlating RSLinx outages to EtherNet/IP sources and controller changes; process/operational impact assessment (loss of view/control); and remediation and hardening recommendations (upgrade to RSLinx Classic 4.60.00 or apply patch BF31213, restrict access to the EtherNet/IP service, validate segmentation, and confirm recovery procedures). Where no evidence of compromise was found, the report should state the scope covered and residual gaps (for example, EtherNet/IP PCAP not captured or event logs not forwarded).

Advisory IoC Reference