Threat Hunt Plan: Pilz IndustrialPI 4 Industrial Computers — Unauthenticated Node-RED Command Execution and Webstatus Authentication Bypass

Version 1.0 — 6 August 2026

Hunt Objective and Scope

This hunt seeks evidence that an attacker has located, reached, and exploited a Pilz IndustrialPI 4 industrial computer through either of two unauthenticated network-reachable defects disclosed by CERT@VDE on 1 July 2025. CVE-2025-41656 (CVSS v3.1 10.0, CWE-306) leaves the Node-RED flow-programming service on Firmware Bullseye 2024-08 and earlier reachable with no authentication configured, giving any attacker who can open a TCP session to it the ability to run arbitrary operating system commands with privileged rights on the underlying Debian platform. CVE-2025-41648 (CVSS v3.1 9.8, CWE-704) is an incorrect type conversion in the IndustrialPI webstatus web application below version 2.4.6 that allows the login to be bypassed outright, exposing every configuration setting the device holds.

The hunt population is every Pilz IndustrialPI unit and every Raspberry Pi-derived industrial computer of the same class in the environment, together with the network segments from which those devices are reachable. Because these units are frequently installed by machine builders and system integrators as protocol gateways or edge data collectors, the hunt explicitly includes discovery: any device answering on the Node-RED port or presenting the webstatus interface is in scope whether or not it appears in the asset management system. Adjacent hosts matter as much as the devices themselves — engineering workstations, jump hosts, historians, and SCADA servers on the same or neighbouring segments are both the plausible source of an exploitation attempt and the plausible next hop after one succeeds.

The recommended time window is 90 days of endpoint and network telemetry, extended to the full retention period for any OT monitoring platform that holds longer history. The disclosure is over a year old, patching of embedded industrial computers is routinely deferred, and both flaws leave an unauthenticated attacker in a position to persist quietly, so a short window risks reading a dormant implant as a clean result. Where a platform retains only 30 days, state that limit explicitly in the hunt report rather than reporting an unqualified negative.

Out of scope: active scanning or probing of the IndustrialPI devices themselves. Every collection step in this plan is passive or executed against telemetry already held by the organisation. Any active interrogation of a device in a running process cell requires plant engineering sign-off and is handled as a separate, ticketed activity.

Hypotheses and Hunt Procedures

Hypothesis 1: An unauthenticated external or internal actor has reached the Node-RED service on an IndustrialPI 4 and used it to execute operating system commands with privileged rights, observable as inbound sessions to the Node-RED administrative port followed by shell or interpreter execution descending from the Node-RED process in endpoint and network telemetry.

MITRE ATT&CK: Initial Access | T1190 — Exploit Public-Facing Application | the Node-RED admin interface is an unauthenticated application surface reachable over the network, which is precisely the access path this technique describes. Execution | T1059.004 — Command and Scripting Interpreter: Unix Shell | Node-RED exec nodes invoke the underlying shell, so successful abuse surfaces as shell children of the Node-RED runtime. ICS | T0819 — Exploit Public-Facing Application and ICS | T0871 — Execution through API | the flow-deployment API is the control surface an attacker drives to reach the operating system.

Collection Queries

CrowdStrike Falcon LogScale (CQL) — enumerate every endpoint that opened a session to the Node-RED administrative port. Run each query as a separate search; CQL supports one pipeline per search.

CrowdStrike Falcon LogScale (CQL) — attribute those connections to the initiating process. NetworkConnectIP4 does not carry ImageFileName, so ProcessRollup2 is the main query and the heavily-filtered connection event is the subquery (reverse-direction join); run over 90 days so long-running daemons still resolve.

CrowdStrike Falcon LogScale (CQL) — where a Falcon Linux sensor is deployed on an IndustrialPI-class host, enumerate the listening sockets that expose Node-RED and webstatus.

BPF packet capture — rolling capture of all traffic to and from the Node-RED and webstatus ports on the segment carrying the affected devices. The strftime format in the output filename is mandatory with -G or each rotation overwrites the previous file.

Datadog Log Search — parallel to the CQL connection queries above, for environments forwarding host or container logs rather than EDR telemetry.

Datadog Live Process Monitoring (Infrastructure > Processes — not a log source, no source: filter; requires process_config.process_collection.enabled: true on the Agent):

Datadog data source gap — if Live Process Monitoring is not enabled on OT-adjacent hosts, or if VPC/flow logs are not forwarded, fall back to the log search below and note the gap in the hunt report.

Windows Event IDs to collect — from any Windows host on a segment able to reach an IndustrialPI:

• 5156 — Windows Filtering Platform permitted a connection (destination port 1880, 80, 443, 8080)
• 4688 — Process creation, for the web-client tooling used to drive the Node-RED API
• 4104 — PowerShell script block logging, for Invoke-WebRequest / Invoke-RestMethod against the device
• 4624 / 4625 — Logon success and failure, for accounts used from or against the device address range

OT Data Collection: Armis Centrix — inventory the affected devices and every connection into their management ports using ASQ. Set the time window in the UI time-picker; do not embed it in the query body.

OT Data Collection: Claroty xDome — Devices > All Devices > Advanced Filters, set Manufacturer = "Pilz" and OS Category = "Linux" to build the device population, then export. For the flow leg use Network > Communication > Communication Analysis: leave Side A empty, set Communication > Port = 1880 (add 80, 443, 8080 as OR rows), set Side B > Manufacturer = "Pilz", and set Time Frame = Past Quarter. Export the result set. Remember the 100,000-row export ceiling and batch by site if the estate is large.

OT Data Collection: Claroty CTD — on-prem CTD retains continuous full PCAP where xDome does not. Pull the packet capture for every session to port 1880 in the hunt window via the CTD event PCAP endpoint and carry it into the offline analysis step below.

OT Data Collection: Dragos Platform — in Assets, scope to Purdue Level 2 and 3 Linux-based industrial computers and gateways to define the hunt population. In the Communications Hub, filter destination port 1880 with any source zone over the hunt window and pivot each session to its asset record and event PCAP. Query the Industrial Protocols QFD and the Server Stats/PCR QFD for any IndustrialPI asset trending toward a producer-consumer ratio near -0.99, which indicates outbound data movement.

OT Data Collection: Nozomi Guardian and Vantage — N2QL queries; note that head without an argument silently returns 10 rows, so bound every exploratory query explicitly.

OT Data Collection: Tenable OT Security — in Inventory > All Assets, filter on asset type OtWorkstation and IndustrialGateway plus vendor Pilz and export the selection. In Risks > Findings, filter by affected asset to enumerate CVE-2025-41656 and CVE-2025-41648 matches against the discovered firmware and package versions. Programmatic sweeps use the GraphQL endpoint at /graphql (there are no REST /api/v1 query endpoints for OT Security); note that origins is deprecated in favour of networkAreas in v4.7.44.

OT Data Collection: Forescout eyeInspect — in the Command Center asset inventory, filter by Purdue level and role to surface Linux-based gateways and industrial PCs, then use the alerts view filtered to MITRE ATT&CK for ICS Initial Access techniques. Forward the alert and asset data via CEF/syslog to the SIEM for free-text hunting, since eyeInspect has no analyst-facing query language.

SNMP polling — poll the switch port facing each IndustrialPI and the device itself where an SNMP agent is exposed.

Repeat the counter poll at 60-second intervals across the hunt window and diff successive values; a sustained rise in ifHCOutOctets on the device-facing port without a corresponding production change is a data-movement signal. Treat any SNMPv1 or SNMPv2c community-string access to an OT asset as a finding in its own right — those transit essentially in the clear.

YARA file-system scan — where a Falcon Linux sensor, Nozomi Arc agent, or vendor-sanctioned shell access exists on an IndustrialPI, scan the Node-RED flow store and user directories for implanted exec flows.

Analysis Queries

CrowdStrike Falcon LogScale (CQL) — rarity analysis. Sort ascending so the single-session sources surface first; an engineering workstation that touched the Node-RED port once in 90 days is far more interesting than the SCADA server that touches it hourly.

CrowdStrike Falcon LogScale (CQL) — shell and interpreter children of the Node-RED runtime on any Linux host carrying a Falcon sensor. This is the single highest-signal query in the hunt: Node-RED legitimately spawns very few operating system children in a production flow.

CrowdStrike Falcon LogScale (CQL) — reverse-shell command patterns on Linux OT hosts.

Wireshark display filters — applied to the captures collected above.

Datadog Log Analytics — the analysis counterpart to the CQL rarity query.

Datadog Audit Trail — surface configuration or access changes made through Datadog itself during the hunt window, so a monitoring blind spot is not mistaken for absence of activity.

Datadog CloudTrail integration — for any cloud-hosted historian or data-collection endpoint the IndustrialPI forwards to.

Datadog Monitor definition — Hypothesis 1

Windows Event Log PowerShell analysis — connection hunting from the collected 5156 set.

OT network and protocol analysis — the IndustrialPI 4 is commonly deployed as a Modbus TCP or OPC UA gateway. Compare the device's protocol profile before and after any suspicious Node-RED session: a gateway that begins issuing Modbus write function codes (5, 6, 15, 16, 22, 23) it never issued in the baseline period, or that begins speaking a protocol absent from its baseline, is a strong Stage 2 indicator. Correlate against historian tag writes and SCADA alarm records for the same interval, and involve plant operations before dispositioning any process-affecting change.

YARA memory scan — scan the Node-RED runtime process for injected or staged payloads. Classic YARA 4.5 takes the PID as a positional argument; there is no -p flag for process scanning (-p sets directory-scan thread count), and YARA-X yr scan cannot scan process memory at all.

CrowdStrike Falcon Real Time Response can execute these scans on remote hosts where a Falcon Linux sensor is deployed; use the put and run commands to stage the rule file and invoke YARA, and the get command to retrieve the hit output for offline review.

Hypothesis 2: An unauthenticated actor has bypassed the IndustrialPI webstatus login via the incorrect-type-conversion defect and read or altered device configuration, observable as web sessions reaching authenticated configuration paths with no preceding successful authentication event, followed by configuration state changes with no matching change ticket.

MITRE ATT&CK: Initial Access | T1190 — Exploit Public-Facing Application | the webstatus login bypass is exploited purely by reaching the application over the network. Discovery | T1082 — System Information Discovery | the authenticated configuration surface exposes network, service, and device parameters an attacker enumerates first. ICS | T0836 — Modify Parameter | the bypass grants write access to every device setting, which is the mechanism by which a process-affecting change would be made.

Collection Queries

CrowdStrike Falcon LogScale (CQL) — sessions to the webstatus HTTP and HTTPS interfaces from managed endpoints. Narrow the CIDR list to the subnets that actually host IndustrialPI units before running at scale.

CrowdStrike Falcon LogScale (CQL) — command-line tooling driving the device management interfaces, which distinguishes scripted exploitation from an engineer clicking through a browser.

BPF packet capture — capture the webstatus interface conversation in full so the request sequence can be replayed offline. The authentication bypass is visible as a request to a post-login path without a preceding successful login response.

Datadog Log Search — proxy, reverse-proxy, or web-gateway logs covering the OT segment.

Datadog Live Process Monitoring:

Datadog data source gap — most environments do not forward web-server access logs from an embedded industrial device, because the device has no log-shipping agent and often no syslog target configured. Where that is the case, packet capture is the only reliable collection path for this hypothesis; record the gap explicitly in the hunt report and treat the PCAP leg as mandatory rather than supplementary.

Windows Event IDs to collect:

• 5156 — permitted connections to ports 80, 443, and 8080 on the device address range
• 4688 — process creation for curl.exe, powershell.exe, and python.exe with device addresses on the command line
• 4104 — PowerShell script block content referencing the device address or webstatus paths

OT Data Collection: Armis Centrix — the connection leg for the webstatus interface.

OT Data Collection: Claroty xDome — Communication Analysis with Communication > Port = 80 (OR 443, OR 8080), Side B > Manufacturer = "Pilz", Time Frame = Past Quarter. Cross-check Alerts & Threats > Alerts > All Alerts filtered to Alert Category = Threat Alert and Policy Deviation Alert for the same device set; note that the alert surface has no time-frame selector, so sort by ALERT UPDATED descending and scan, or use the API detected_time filter for a hard window.

OT Data Collection: Dragos Platform — Communications Hub filtered to destination ports 80, 443, and 8080 with destination asset in the IndustrialPI population; triage Notifications filtered to ATT&CK for ICS Initial Access (T0819, T0866) and export the event PCAP for any session that fired an analytic.

OT Data Collection: Nozomi Guardian and Vantage:

OT Data Collection: Tenable OT Security — Events view filtered to policy violations of the Intrusion Detection and Configuration Change classes for the device population; Risks > Findings filtered by affected asset to confirm which units still carry a vulnerable webstatus package version. Where Code Snapshot or Details Query has been enabled and signed off for this asset class, diff the stored configuration snapshots across the hunt window; a configuration delta with no network-observed engineering session implies local or bypassed access.

OT Data Collection: Forescout eyeInspect — filter the alerts view to the Industrial Threat Library checks covering engineering-protocol abuse and unauthorised web administration, and use ICS Patrol only in low-cadence scoped mode and never against a safety-rated asset without engineering sign-off.

SNMP polling — a webstatus configuration change frequently restarts network services or the device itself. Collect trap-receiver records for the hunt window and flag:

• coldStart, OID 1.3.6.1.6.3.1.1.5.1 — device restart
• warmStart, OID 1.3.6.1.6.3.1.1.5.2 — service restart
• linkDown / linkUp, OIDs 1.3.6.1.6.3.1.1.5.3 and 1.3.6.1.6.3.1.1.5.4 — port flap consistent with a network reconfiguration
• authenticationFailure, OID 1.3.6.1.6.3.1.1.5.5 — unauthorised access attempts against the SNMP agent

An unexplained sysUpTime reset on an IndustrialPI is a first-order finding: these devices are not routinely rebooted, and a reboot outside a change window aligns with either a configuration write or an exploitation attempt that destabilised the host.

YARA file-system scan — the webstatus package directory and the device's web root, where a bypassed session would stage content.

Analysis Queries

CrowdStrike Falcon LogScale (CQL) — temporal distribution of web sessions to the device set. Configuration access outside the plant's engineering hours is the discriminator that separates an engineer from an attacker.

Wireshark display filters — the definitive test for the authentication bypass is a request to an authenticated path with no preceding successful login response in the same TCP stream.

Datadog Log Analytics:

Datadog Audit Trail:

Datadog CloudTrail integration:

Datadog Monitor definition — Hypothesis 2

Windows Event Log PowerShell analysis — scheduled task hunting on the peer hosts, since an attacker who has confirmed the bypass typically automates re-entry.

OT network and protocol analysis — reconcile every configuration-affecting event against the change record. Export the device's protocol and port profile from the OT monitoring platform for a baseline window preceding the earliest suspicious web session and for the window following it, and diff the two. New listening ports, a changed default gateway, a new NTP or DNS target, or a new outbound peer are all reachable through the bypassed configuration interface and all constitute confirmation.

YARA memory scan — where the webstatus process is instrumented, scan its address space for staged shell content.

Hypothesis 3: Following successful exploitation of either defect, the attacker has used the IndustrialPI as a foothold to move laterally into adjacent OT and IT systems or to establish outbound command and control, observable as inbound remote-service sessions and authentications originating from the device address range, new listening services on OT hosts, and credential-access tooling on Windows peers.

MITRE ATT&CK: Lateral Movement | T1021.004 — Remote Services: SSH | the compromised Debian host has native SSH tooling and reaches adjacent OT hosts without crossing a firewall. Credential Access | T1003 — OS Credential Dumping | an attacker who reaches a Windows engineering workstation from the device pivots to credential material to widen access. Command and Control | T1071.001 — Application Layer Protocol: Web Protocols | Node-RED's HTTP request nodes provide a native, low-suspicion egress channel. ICS | T0867 — Lateral Tool Transfer | moving tooling from the compromised gateway onto control-network hosts is the step that converts a device compromise into a process risk.

Collection Queries

CrowdStrike Falcon LogScale (CQL) — inbound remote-service sessions accepted by managed hosts. Correlate the RemoteAddressIP4 values against the IndustrialPI address inventory produced in Hypothesis 1.

CrowdStrike Falcon LogScale (CQL) — logon events carrying a source address, for correlation against the same device inventory. UserLogon exposes both RemoteIP and RemoteAddressIP4; use the IPv4-typed field where cidr filtering is wanted.

BPF packet capture — capture lateral-movement protocols sourced from the device.

Datadog Log Search:

Datadog Live Process Monitoring:

Datadog data source gap — SSH authentication on an embedded industrial device is written to the local journal and is rarely forwarded anywhere. Where no syslog target is configured on the IndustrialPI, treat the peer-side collection (Falcon NetworkReceiveAcceptIP4, Windows 4624, and the OT platform flow record) as the authoritative evidence and state in the report that device-side authentication logs were unavailable.

Windows Event IDs to collect:

• 4624 — successful logon, filtered to Logon Type 3 (network) and Logon Type 10 (remote interactive) with a source address in the device range
• 4625 — failed logon, which frequently precedes a successful one during credential spraying from a foothold
• 4688 — process creation, for lateral-movement tooling
• 7045 — service installation, the classic remote-execution artefact
• 4104 — PowerShell script block, for remoting payload content

OT Data Collection: Armis Centrix — outbound remote-service flows sourced from the device population.

OT Data Collection: Claroty xDome — Communication Analysis with Side A > Manufacturer = "Pilz" and the Communication bucket left broad, Time Frame = Past Quarter, to enumerate every peer the device has spoken to. Compare the peer set against the device's documented function; a protocol gateway that has begun speaking SSH or SMB to an engineering workstation is outside its role. Use Network > Network Security > Zones & Policies to confirm whether the observed flow crosses a defined zone boundary.

OT Data Collection: Claroty CTD — export the full PCAP for any cross-zone session sourced from the device and carry it into offline analysis; CTD's continuous full-packet retention is what makes a retrospective lateral-movement question answerable at all.

OT Data Collection: Dragos Platform — Communications Hub with source zone set to the IndustrialPI's Purdue level and destination zone set to any other, protocol filter SSH, SMB, RDP, and VNC, over the hunt window. Pivot each cross-Purdue session to its asset record and event PCAP, and open a Case with the attached Dragos playbook on any confirmed hit. Check the SSH-sessions and DNS QFDs for the same asset.

OT Data Collection: Nozomi Guardian and Vantage:

Adapt the vendor's TrafficCrossingPurdueLevels, TrafficToPublicInternet, and TrafficOverVNCorRDP queries from the published query library rather than writing these from scratch; several contain environment-specific field names and must be adjusted and re-linted before use.

OT Data Collection: Tenable OT Security — Events view filtered to PLC mode change, project upload or download, and code revision change for the hunt window across the controller population reachable from the device. Any such event without a matching change ticket is a finding regardless of whether the device compromise is confirmed.

OT Data Collection: Forescout eyeInspect — cross-zone violation alerts from eyeSegment's authored matrix, plus Industrial Threat Library checks for engineering-protocol writes outside the maintenance window.

SNMP polling — correlate interface counters on both the device-facing port and the ports facing the pivot targets.

YARA file-system scan — staged tooling on the compromised device and on any pivot target reachable with a sanctioned agent.

Analysis Queries

CrowdStrike Falcon LogScale (CQL) — rarity of listening services on Linux OT hosts. A port that appears on exactly one host is either a legitimate single-purpose service or an attacker's listener; both need an answer.

CrowdStrike Falcon LogScale (CQL) — credential-access tooling on Windows peers reachable from the device.

Wireshark display filters — session and beacon analysis on the lateral and egress captures.

A regular inter-arrival interval on outbound sessions from the device, particularly with low and consistent byte counts, is beaconing. Compute the interval distribution from the conv,tcp output before dismissing periodic traffic as polling; legitimate industrial polling is usually far more frequent and far more consistent in payload size than command-and-control check-in.

Datadog Log Analytics:

Datadog Audit Trail:

Datadog CloudTrail integration:

Datadog Monitor definition — Hypothesis 3

Windows Event Log PowerShell analysis — script block review on any peer that accepted a session from the device range.

OT network and protocol analysis — for every confirmed lateral session, establish whether any control action followed. Pull the historian tag write history and the SCADA alarm log for the interval spanning the session plus four hours, and check for setpoint changes, mode transitions, or alarm suppressions with no operator attribution. On EtherNet/IP segments, decode CIP service codes in the captured traffic and flag Set Attribute Single (0x10), Set Attribute List (0x04), and any write to class 0x6B; on Modbus segments, flag function codes 5, 6, 15, 16, 22, and 23 issued from an address that has never issued a write in the baseline period. Any process-affecting finding is escalated jointly to plant operations and incident response, not to the SOC alone.

YARA memory scan — bulk process enumeration on a Linux OT host under investigation.

On Windows pivot targets, CrowdStrike Custom IOAs can pre-position detection for the same behaviours, and Falcon Real Time Response can stage and execute the YARA binary and rule file on demand; note that scanning LSASS memory requires SeDebugPrivilege.

Threat Actor Profile

Opportunistic financially-motivated actors are the most probable adversary for these vulnerabilities. Sophistication is low to moderate: neither defect requires an exploit chain, custom tooling, or any understanding of the industrial process — a CVSS 10.0 missing-authentication flaw is exploitable with a browser and a text editor. The access path is direct network reachability to the Node-RED port or the webstatus interface, obtained either from an internet-exposed device, a flat plant network reached from a compromised corporate endpoint, or a vendor remote-access session. Typical TTPs are mass scanning for the characteristic Node-RED banner, deployment of a cryptominer or a generic Linux backdoor via an exec flow, and opportunistic credential harvesting; the industrial context is usually incidental to the actor rather than the objective.

Ransomware operators represent the highest-consequence realistic threat. Sophistication is moderate to high, with mature access brokerage, credential-theft tooling, and a well-developed understanding that operational downtime drives payment. For this actor class the IndustrialPI is not the target but the entry point and staging platform: an unauthenticated root-equivalent execution primitive on a Linux host inside the production network is an unusually convenient beachhead, and one that endpoint detection frequently does not cover. Expected TTPs are reconnaissance of the OT segment from the compromised device, credential access on adjacent Windows engineering workstations, and encryption of IT-side systems with deliberate disruption of the operational environment as leverage.

State-aligned actors with an industrial mandate are the least likely but most severe scenario. Sophistication is high, with patient dwell, minimal tooling on disk, and a demonstrated interest in exactly this class of asset — a network-edge Linux device in a control environment that is rarely patched, rarely monitored, and rarely rebooted is an ideal persistence point. Such an actor would use the Node-RED flow store itself as the persistence mechanism rather than dropping a binary, would keep command and control inside HTTP to blend with the device's normal function, and would treat the compromise as pre-positioning rather than as an event to be monetised. Detection depends far more on behavioural anomaly work — a gateway speaking a protocol it has never spoken, an outbound session with no business purpose — than on indicator matching.

Insider and third-party risk deserves separate mention because it is the most common source of unattributed configuration change on this asset class. System integrators and machine builders routinely retain remote access to the equipment they commissioned, and their sessions frequently look identical to an attack in telemetry. Every finding in this hunt should be reconciled against the vendor-access register before escalation, and any vendor session that cannot be tied to a documented work order should be treated as a finding in its own right.

Data Sources Required

Network — full packet capture on the segments hosting IndustrialPI devices, covering TCP 1880, 80, 443, and 8080 inbound and all traffic outbound from the device address range; NetFlow or IPFIX from the distribution and core layers; firewall and NGFW connection logs for any flow crossing a zone boundary; proxy or web-gateway logs where OT-segment traffic is inspected; DNS resolver query logs.

Endpoint — CrowdStrike Falcon telemetry across Windows and Linux hosts in and adjacent to the OT environment, specifically ProcessRollup2 and SyntheticProcessRollup2, NetworkConnectIP4, NetworkReceiveAcceptIP4, NetworkListenIP4, UserLogon, UserLogonFailed2, and ScheduledTaskRegistered; Windows Security, System, PowerShell/Operational, and TaskScheduler/Operational event logs with command-line auditing and script block logging enabled; Sysmon where deployed; Datadog Agent logs and Live Process Monitoring where the Datadog stack is present.

OT and ICS — asset inventory and flow records from every deployed monitoring platform (Claroty xDome, Claroty CTD, Dragos Platform, Nozomi Guardian and Vantage, Armis Centrix, Tenable OT Security, Forescout eyeInspect); process historian tag write history; SCADA alarm and event logs; PLC and controller configuration snapshots or code revision history where the platform captures them; OT platform PCAP exports (Dragos event PCAP, Claroty CTD full capture).

Vendor and device logs — IndustrialPI system journal and authentication log where a syslog target is configured; Node-RED runtime log and the flow store at /root/.node-red/ and /home/pi/.node-red/; webstatus application log; apt history to establish whether and when the webstatus package was updated; SNMP interface counters and trap-receiver records for the device and its access switch port.

Supporting records — the change management ticket queue for the hunt window, the vendor and integrator remote-access register, the plant maintenance schedule, and the engineering-hours profile. Without these the hunt can identify activity but cannot disposition it, and the distinction between an engineer and an attacker on this asset class is almost entirely a question of attribution rather than technique.

Detection Signatures

The following SIGMA rules span process_creation, network_connection, and webserver logsource categories so that detection does not depend on a single telemetry path.

The following Snort and Suricata rules cover the wire signature of both exploitation paths. Local SIDs begin at 1,000,000 per the Suricata local range convention; adjust HOME_NET and the OT_ENGINEERING variable to the environment before deployment.

The first YARA rule targets the Node-RED flow store on disk. Node-RED persists its flows as JSON at a predictable path, and an attacker who exploits CVE-2025-41656 to gain persistence rather than a one-shot command must write an exec-type node into that file. The condition requires both the JSON structure that marks a Node-RED flow file and at least one command-execution indicator, because the flow file itself is expected to exist on every device and matching on its presence alone would fire on every healthy unit. The reverse-shell and download-utility string set is deliberately narrow to keep the rule from matching legitimate flows that invoke a local script by name.

The second YARA rule scans process memory rather than disk, because the most likely outcome of exploiting an unauthenticated command-execution primitive on a Linux gateway is an in-memory reverse shell that leaves nothing on the filesystem. The condition is built as a two-part test — a shell or socket artifact plus a connect-back artifact — so that the presence of a shell string in a legitimate process image does not fire on its own. The rule is scoped to Linux process memory and should be run against the Node-RED runtime, the webstatus process, and any process holding an unexpected listening socket identified in the Hypothesis 3 analysis.

The third YARA rule is the standing credential-dumping rule, included because Hypothesis 3 involves lateral movement into Windows peers and credential access. It covers the four classic tool families plus a catch-all branch pairing a memory-read API with the LSASS process name and a tool indicator, so that renamed or repacked tooling still matches. Executing it against LSASS requires SeDebugPrivilege. Note the platform scope: the IndustrialPI itself is Linux, and this rule will not match Linux credential-dumping through the /proc filesystem (T1003.007); it is scoped to the Windows engineering workstations and servers reachable from the device, and the Linux-side equivalent is covered by the reverse-shell memory rule above together with the CriticalFileAccessed telemetry on /etc/shadow.

Indicators of Compromise

Network indicators — any inbound TCP session to port 1880 from a source outside the defined engineering workstation range; any HTTP POST to /flows or /red/ on an IndustrialPI address; any HTTP request to a webstatus configuration path bearing a scripted user agent (curl, wget, python-requests, Go-http-client); any outbound session from an IndustrialPI address to an internet-routable destination; any SSH, SMB, RDP, or WinRM session sourced from an IndustrialPI address; any DNS query from the device address range to a domain outside the organisation's resolver allowlist; regular-interval outbound sessions with consistent low byte counts from the device address range.

Host indicators — a shell, netcat, curl, wget, python, perl, or chmod process whose parent is the Node-RED runtime; a new listening socket on an IndustrialPI outside the expected set of 22, 80, 443, 502, 1880, 4840, and 8080; a modification to /root/.node-red/flows.json or /home/pi/.node-red/flows.json with no corresponding change ticket; a new cron entry or systemd unit on the device; a sysUpTime reset outside a maintenance window; an apt history showing no webstatus upgrade on a device still reporting a version below 2.4.6; a Windows logon event with a source address in the IndustrialPI range; a service installation (event 7045) on a peer host within the window of an inbound session from the device.

OT and operational indicators — the device beginning to speak a protocol absent from its established baseline; Modbus write function codes (5, 6, 15, 16, 22, 23) or CIP Set Attribute services (0x04, 0x10) issued from the device where the baseline shows read-only behaviour; a controller mode change, project download, or code revision on any controller reachable from the device with no matching change record; a historian tag write or setpoint change with no operator attribution within four hours of a suspicious device session; an alarm suppression on a point the device gateways; a sustained rise in ifHCOutOctets on the device-facing switch port without a corresponding production change; a coldStart or warmStart SNMP trap from the device outside a maintenance window; the appearance of the device as a new peer in a zone it has no documented reason to reach.

False Positive Baseline

System integrator and machine builder remote support. The organisations that commissioned the equipment routinely retain access and use exactly the interfaces this hunt monitors. Suppress by reconciling against the vendor-access register and the work-order queue; do not suppress by source address alone, because a compromised integrator is a real access path and an unregistered session from a known integrator address is a finding rather than noise.

Sanctioned Node-RED flow development. Where Node-RED is the intended programming surface for the device, engineers legitimately deploy flows and some of those flows legitimately invoke local scripts through exec nodes. Enumerate the sanctioned flow set, hash the flow files, and suppress by full command line rather than by binary name — suppressing every shell child of Node-RED discards the highest-signal query in the plan.

Vulnerability scanning and asset discovery. Nessus, Tenable OT active queries, Armis Smart Active Querying, Claroty active queries, and Forescout ICS Patrol all touch device management interfaces on a schedule and will generate connections to ports 1880, 80, 443, and 8080. Suppress by scanner source address and correlate against the scan schedule; note that Tenable's Nessus engine must never be pointed at a controller, so a Nessus signature against a PLC is itself a finding.

Monitoring and health-check polling. Uptime monitors, SCADA availability checks, and network management systems poll the device status page continuously. These produce a high, extremely regular volume from a small set of source addresses and are straightforward to characterise and suppress; verify that the polling source is the documented monitoring host and that the requested path is genuinely a status path rather than a configuration path.

Browser-based engineering access from sanctioned workstations. An engineer administering the device through Chrome, Edge, or Firefox from a defined engineering workstation is the expected pattern. Suppress by the host-plus-user pair rather than by process name, and retain the temporal analysis — the same engineer on the same workstation at three in the morning during an unscheduled window is still worth a question.

DHCP churn and device re-addressing. Embedded devices that acquire addresses dynamically will appear as new assets to OT monitoring platforms after every lease change, generating new-device alerts and apparent new peers. Reconcile by MAC address rather than IP before treating an apparent new device as a finding; IP-keyed correlation is unreliable across the whole OT estate.

Backup, patch, and configuration-management cycles. Scheduled apt runs, configuration pushes, and backup agents produce bursts of process execution and network activity on and around the device that resemble post-exploitation staging. Correlate against the maintenance calendar and the change queue before escalation.

Escalation Criteria

The following conditions trigger immediate incident response engagement. Each is stated as an observable, not as an interpretation.

1. Any shell, netcat, curl, wget, python, perl, or chmod process observed as a child of the Node-RED runtime on any IndustrialPI or equivalent device, where the command line cannot be matched to a documented sanctioned flow.

2. Any YARA hit on NodeRED_Exec_Flow_Implant against /root/.node-red/, /home/pi/.node-red/, or any other Node-RED flow store on a device in the hunt population.

3. Any YARA hit on IndustrialPI_Reverse_Shell_Memory against the Node-RED runtime process, the webstatus process, or any process holding an unexpected listening socket on a Linux industrial host.

4. Any YARA hit on Credential_Dump_Tool_Memory_Artifacts against LSASS or any process on a Windows engineering workstation, server, or jump host reachable from an IndustrialPI address.

5. Any successful Windows logon (event 4624) whose source address falls within the IndustrialPI device range, regardless of logon type or account — this device class has no legitimate reason to authenticate to a Windows host.

6. Any outbound session from an IndustrialPI address to an internet-routable destination that is not an explicitly documented vendor or cloud endpoint.

7. Any new listening socket on an IndustrialPI outside the expected port set, or any modification to the Node-RED flow store, cron table, or systemd unit set with no corresponding change ticket.

8. Any Modbus write function code, CIP Set Attribute service, controller mode change, project download, or code revision issued from or temporally correlated with an IndustrialPI session, where no change record exists — escalate jointly to plant operations and incident response, and do not take unilateral containment action on a device in a running process.

9. Any device confirmed to be running webstatus below version 2.4.6 or Firmware Bullseye 2024-08 or earlier while also showing any connection to ports 1880, 80, 443, or 8080 from outside the defined engineering range within the hunt window.

10. Any IndustrialPI or equivalent device found to be reachable from the enterprise network or from an internet-facing path, whether or not exploitation evidence exists — the exposure alone is a CVSS 10.0 unauthenticated remote code execution condition and warrants immediate containment planning.

Hunt Completion Criteria and Reporting

The hunt is complete when four conditions are satisfied. First, every Pilz IndustrialPI and equivalent Raspberry Pi-derived industrial computer in the environment has been enumerated, with its firmware image date and webstatus package version recorded, and the enumeration has been reconciled against both the asset management system and the OT monitoring platforms' passive discovery output. Second, every hypothesis in Section 2 has been executed across the full hunt window on every platform present in the environment, with the outcome recorded per hypothesis per platform. Third, every collection and analysis query has either returned a dispositioned result or has been recorded as unrunnable with the specific reason — an absent data source, an unavailable retention period, or a platform not deployed. Fourth, every candidate finding has been reconciled against the change management queue, the vendor-access register, and the maintenance calendar, and each has been closed as benign, escalated, or explicitly carried forward as unresolved.

A hypothesis that returns no results is only a negative when the underlying data source is confirmed present and populated for the whole window. Where a query returned zero rows, the report must state whether that reflects absence of activity or absence of telemetry. This distinction matters more than usual here: embedded industrial devices are the archetypal blind spot, and a clean result produced by querying telemetry that was never collected from the device is the most dangerous possible output of this hunt.

The hunt report must contain: the scope statement and the exact time window queried per platform; the full device inventory with firmware and package versions and patch status per unit; per-hypothesis findings with supporting query output and the platform each came from; every escalation triggered under Section 8 with its disposition and incident ticket reference; every data source gap identified, with the hypotheses it degraded and the residual risk that remains unaddressed; the false-positive suppressions applied, with the justification and the reviewing analyst for each; recommended detection content to promote to standing coverage, specifically which SIGMA, Snort/Suricata, and YARA rules from Section 5 should be deployed and to which platform; and a remediation status summary covering webstatus package updates, Node-RED authentication enablement, and segmentation changes, with owners and target dates for each device not yet remediated.

Validated hunt content should not be discarded at the end of the engagement. The connection queries for port 1880 and the Node-RED child-process query are strong candidates for CrowdStrike NG-SIEM correlation rules or scheduled searches; the Datadog monitor definitions in Section 2 are written to be deployed as-is; and the Snort/Suricata rules belong on the sensor covering the OT boundary. Where the environment runs Dragos, register the validated hypothesis as a custom analytic through the analytic manager so that it becomes a standing detection rather than a point-in-time exercise.

Advisory IoC Reference