Threat Hunt Plan: Panduit IntraVUE Industrial Network Visualization Platform — Unintended Proxy Segmentation Bypass and Credential Exposure

Revision 1.0 — 2026-07-27 (aligned to CISA ICS advisory ICSA-26-204-04, published 2026-07-23)

Scope note on identifiers: every hostname, IP address, subnet, service-account name, rule path, and notification handle in this plan is a generic placeholder. The monitoring host is written as otnetmon, its address as 192.0.2.25 (RFC 5737 documentation range), the control-network range as 198.51.100.0/24, YARA rule paths as /opt/hunt/rules/, and the escalation handle as @ot-soc-oncall. Substitute the real values from the environment inventory before executing any query. No client data appears in this plan.

Hunt Objective and Scope

This hunt looks for evidence that an adversary has abused an unpatched Panduit IntraVUE industrial network visualization server as a reconnaissance source, a credential source, and a relay into operational technology network segments. IntraVUE is deployed to discover, map, and continuously poll automation assets, which means the server is deliberately granted routed or bridged reachability into control-system segments that are otherwise isolated from the enterprise network. Five vulnerabilities disclosed on 2026-07-23 collectively convert that position into an attack path: three unauthenticated information disclosures, one weak-encryption credential-theft issue, and one maximum-severity unintended-proxy weakness that lets a remote attacker relay traffic through the server into the segments it monitors.

The hunt is scoped to the IntraVUE server or servers themselves, the enterprise network segments from which the server is reachable, and the control-network segments the server is permitted to poll. Endpoint telemetry is in scope for the monitoring host, the engineering workstations that administer it, and any host observed communicating with its web or application programming interface listeners. Network telemetry is in scope for both the enterprise-facing and control-facing interfaces of the monitoring host. Control-system assets are in scope for authentication, configuration-change, and industrial-protocol activity attributable to the monitoring host or to credentials the monitoring host holds.

The hunt window is the full period during which an affected version was in service, with a minimum of 90 days back from the hunt start date. Where log retention is shorter than the exposure window, the hunt report must record the actual retention boundary and mark the unexamined period as an explicit coverage gap rather than a negative finding. Where the monitoring host has already been upgraded to version 3.2.1a16 or later, the hunt still runs against the pre-upgrade window, because the upgrade removes the flaws but does not remediate exposure that already occurred.

The hunt is exploratory rather than confirmatory. CISA reported no known public exploitation targeting these vulnerabilities at publication and none of the five identifiers appear in the Known Exploited Vulnerabilities catalog, so the expected outcome is a negative result plus a documented baseline of the monitoring host's legitimate polling profile. That baseline is the durable deliverable: it is what makes any future deviation detectable in minutes rather than weeks.

Hypotheses and Hunt Procedures

Hypothesis 1: An unauthenticated actor with enterprise-network reachability has queried the IntraVUE application programming interface to harvest cleartext credentials, enumerate the monitored control-network asset inventory, and disclose the underlying host and share structure of the server, observable as anomalous inbound sessions to the monitoring host's web and application listeners in endpoint network telemetry and perimeter flow records.

MITRE ATT&CK: Credential Access | T1552 — Unsecured Credentials | The plaintext-storage weakness returns credential material over the API without authentication, which is the textbook unsecured-credentials pattern applied to a network-management platform.

MITRE ATT&CK: Discovery | T1046 — Network Service Discovery | The asset-discovery disclosure hands the attacker the monitored device inventory without the active scanning that OT intrusion detection is tuned to catch.

MITRE ATT&CK for ICS: Discovery | T0840 — Network Connection Enumeration | The IntraVUE topology map is a pre-built enumeration of control-network connectivity.

Collection Queries:

CrowdStrike Falcon LogScale (CQL) — enumerate every listener the monitoring host exposes, to establish which ports the IntraVUE web and application services actually bind:

CrowdStrike Falcon LogScale (CQL) — the same activity viewed from the client side, so hosts without inbound visibility on the monitoring server are still covered:

BPF Packet Capture — rolling capture of all traffic to and from the monitoring host's enterprise-facing interface, rotated hourly with a size ceiling:

Datadog Log Search — inbound authentication and session activity on the monitoring host (Logs > Explorer):

Datadog Live Process Monitoring — identify which process on the monitoring host owns the listening service (Infrastructure > Processes, NOT a log search source):

Windows Event IDs to collect:

• 4624 successful logon, with logon type and source network address
• 4625 failed logon, for credential-guessing against the monitoring host console
• 4648 logon using explicit credentials, which surfaces credential reuse from a foothold host
• 4672 special privileges assigned, to catch administrative sessions on the monitoring host
• 5156 Windows Filtering Platform permitted connection, for inbound socket-level records where the Falcon sensor is absent

PowerShell collection commands:

OT Data Collection: Armis Centrix — baseline which enterprise-side endpoints reach the monitoring host, and separate internal from external sources. Set the time window in the console time-picker rather than in the query body:

Aggregate the results in the Armis results-grid Summarize control or via the search API aggregate parameter. ASQ has no in-query grouping operator.

OT Data Collection: Claroty CTD — on the on-premises sensor, use Investigation, filter to the asset pair formed by the monitoring host and each enterprise peer, select the protocol and time slice, then use Export PCAP. CTD keeps a continuous full packet store on the sensor, typically a rolling 7 to 30 days, and raw packets stay in-perimeter. Export at the local sensor, because the Enterprise Management Console does not aggregate raw packets. The per-event API path is /v1/events/<id>/pcap with a per-site CTD token.

OT Data Collection: Dragos Platform — open Communications Hub, filter source zone to the enterprise level and destination to the monitoring host's zone, and review every session by protocol, port, direction, volume, and baseline status. Pivot each unbaselined session to its asset record and use Export PCAP for window at the SiteStore. Pull the Notifications and Assets collections through the SiteStore REST API and join them on asset identifier rather than on raw IP, because addresses churn in OT.

OT Data Collection: Nozomi Guardian — run N2QL through the OpenAPI query endpoint. Authenticate with POST /api/open/sign_in to obtain a JWT, then issue the queries below. Pagination defaults to 10,000 rows per page:

OT Data Collection: Tenable OT Security — query the GraphQL endpoint at /graphql, which is the only programmatic interface. There are no REST /api/v1/ query paths on OT Security. Retrieve the monitoring host's asset record and its recent events, and note that origins is deprecated in favour of networkAreas in v4.7.44 and later:

OT Data Collection: Forescout eyeInspect — use the Command Center Asset Inventory view filtered to the monitoring host, then the Alerts view filtered by severity and MITRE ATT&CK for ICS technique over the hunt window. eyeInspect has no free-text query language, so forward alerts and asset records over syslog or CEF to the SIEM for the multi-step correlation, and use the eyeInspect REST API for bulk asset and alert export.

YARA file-system scan — sweep the monitoring host and any suspected staging host for harvested API output and credential-handling scripts:

Analysis Queries:

CrowdStrike Falcon LogScale (CQL) — rarest-source analysis. Legitimate access to the monitoring console comes from a small, stable set of engineering hosts, so the tail of this list is where a one-off unauthenticated harvest appears:

CrowdStrike Falcon LogScale (CQL) — process attribution for every host that connected to the monitoring host's API. The join runs in the reverse direction, with ProcessRollup2 as the main query and the tightly filtered connection events as the subquery, because the forward direction exceeds the 100,000-row subquery cap on any real fleet. Run this over 90 days or longer, since long-running services may have no ProcessRollup2 event inside a narrow window:

A browser process from an engineering workstation is expected. A scripting interpreter, a command-line HTTP client, or any process running under a non-interactive account is the finding.

Wireshark display filters and tshark equivalents — isolate unauthenticated API requests and oversized responses in the captured traffic:

Datadog Log Analytics — reproduce the CQL grouping in the Datadog surface:

Datadog Audit Trail — detect credential or account abuse against the Datadog organization itself during the same window, since an attacker holding harvested credentials often tests them broadly (Organization Settings > Audit Trail):

Datadog CloudTrail integration — where the monitoring platform or its backup targets live in AWS, surface credential-driven API activity from non-RFC-1918 sources:

Datadog Monitor:

Windows Event Log PowerShell analysis:

YARA memory scan — sweep the monitoring host's own service processes for relay tooling loaded in memory. Classic YARA 4.5 takes the process identifier as a positional argument:

CrowdStrike Falcon Real Time Response can execute the same YARA sweep on remote hosts without an on-site analyst, and a validated query from this hypothesis can be promoted to a standing NG-SIEM Correlation Rule once the false-positive baseline in Section 7 is applied.

Hypothesis 2: An attacker has used the IntraVUE server as an unintended proxy to relay traffic into control-network segments, observable as connections originating from the monitoring host to control assets on industrial-protocol or remote-access ports that fall outside its baselined polling profile.

MITRE ATT&CK: Command and Control | T1090.001 — Proxy: Internal Proxy | The unintended-proxy weakness makes the monitoring host relay attacker traffic to hosts the attacker cannot address directly.

MITRE ATT&CK for ICS: Lateral Movement | T0886 — Remote Services | Relayed sessions to controllers and field devices reach services that the enterprise network is not supposed to be able to reach at all.

MITRE ATT&CK for ICS: Initial Access | T0866 — Exploitation of Remote Services | The relay is established by exploiting the monitoring platform itself rather than by exploiting a controller.

Collection Queries:

CrowdStrike Falcon LogScale (CQL) — every industrial-protocol connection the monitoring host initiated. EtherNet/IP, Modbus, DNP3, S7comm, OPC UA, and IEC 60870-5-104 are covered:

CrowdStrike Falcon LogScale (CQL) — remote-access and file-share protocols out of the monitoring host. A visualization platform has no legitimate reason to speak these into the control network:

BPF Packet Capture — rolling capture on the monitoring host's control-facing interface, covering the industrial protocol set and the remote-access set:

Datadog Log Search — network activity from the monitoring host where flow logs are forwarded (Logs > Explorer):

Datadog Live Process Monitoring — confirm which process on the monitoring host is generating the control-network flows (Infrastructure > Processes):

Windows Event IDs to collect:

• 5156 Windows Filtering Platform permitted connection, the authoritative host-side record of outbound flows and owning process
• 5157 Windows Filtering Platform blocked connection, which reveals relay attempts the host firewall stopped
• 4688 process creation with command line, to attribute new outbound flows to a newly launched process
• 7045 service installed, since a persistent relay is frequently installed as a service
• 4104 PowerShell script block logging, for relay logic implemented in script rather than a binary

PowerShell collection commands:

OT Data Collection: Armis Centrix — baseline the monitoring host's outbound OT connectivity and then look for the pivot. The OT-protocol filter is itself the OT scoping, so no boundary literal is needed:

OT Data Collection: Claroty CTD — in Investigation, filter the asset pair to the monitoring host against each control-network peer, then Export PCAP for the flagged windows. Use the Network Communications view with Baseline Status set to off-baseline to isolate protocols the monitoring host has never spoken before and peers it has never contacted. Where xDome Secure Access is licensed, left-join every observed remote-access flow against the secure-access session log, since a flow with no matching session record is out-of-band by construction.

OT Data Collection: Dragos Platform — in Communications Hub, set source zone to the monitoring host's zone and destination zone to the control levels, filter protocol to the industrial and remote-access sets, and review baseline status and the ATT&CK for ICS technique on every returned flow. Query the Industrial Protocols Query Focused Dataset for write function codes outside the maintenance window, and check the Server Stats dataset for a producer-consumer ratio trending toward negative one, which marks an exfiltration server. Export the event PCAP on any flagged flow.

OT Data Collection: Nozomi Guardian — enumerate the monitoring host's links and any industrial-protocol sessions it participates in:

OT Data Collection: Tenable OT Security — retrieve events associated with the monitoring host and any controller it touched, through the GraphQL endpoint:

OT Data Collection: Forescout eyeInspect — filter the Alerts view to the monitoring host as source, review any Industrial Threat Library detection on the returned flows, and drill from each alert to the underlying flow or packet capture where sensor PCAP is enabled. Use ICS Patrol on-demand active enrichment only against assets already cleared with plant engineering.

SNMP polling — poll the switch port facing the monitoring host and the control assets it reached, and diff successive samples at 60-second intervals across the hunt window:

Use the 64-bit ifHCInOctets and ifHCOutOctets counters for volumetric baselining, since the 32-bit counters wrap on high-speed links. Prefer SNMPv3 with SHA-2 and AES-256 where the device supports it, provisioning credentials through snmp.conf rather than inline so passphrases do not appear in the process table. SHA-2 requires net-snmp 5.8 or later and AES-192 or AES-256 require a build with the extended AES option; where the target offers only stock crypto, fall back to SHA-1 and AES-128. Treat any surviving v1 or v2c community-string access to control assets as a finding in its own right, because those transit essentially in cleartext.

Collect SNMP trap-receiver logs for the hunt window and filter for traps from the control-network address range. Flag coldStart 1.3.6.1.6.3.1.1.5.1 and warmStart 1.3.6.1.6.3.1.1.5.2 traps indicating unexpected device restarts, linkDown 1.3.6.1.6.3.1.1.5.3 and linkUp 1.3.6.1.6.3.1.1.5.4 traps indicating port flaps, and authenticationFailure 1.3.6.1.6.3.1.1.5.5 traps indicating unauthorized-access attempts against control-network interfaces.

Historian and SCADA alarm correlation — export the alarm and event journal for the hunt window and align it against the relayed-session timeline. Any controller mode change, program download, setpoint write, or communication-loss alarm whose timestamp falls inside a window of relayed activity is a priority escalation, whether or not the change was logged as authorized.

Analysis Queries:

CrowdStrike Falcon LogScale (CQL) — attribute the control-network flows to the process that created them, again using the reverse-direction join. The IntraVUE service itself is the expected owner. Any other process on the monitoring host initiating industrial-protocol or remote-access traffic is the finding:

CrowdStrike Falcon LogScale (CQL) — rarest-peer analysis. A polling platform contacts the same peers on the same ports on a fixed cadence, so a one-time destination sitting at the bottom of this list is exactly the shape a relayed session takes:

Wireshark display filters and tshark equivalents — EtherNet/IP CIP service-code analysis to separate read-class polling from write-class control, plus the equivalent for Modbus, DNP3, and S7comm:

CIP service codes 0x4c and 0x52 are read-class and expected from a monitoring platform. Service codes 0x4d and 0x53, Modbus function codes 5, 6, 15, 16, and 22, and S7comm write and download functions are control-class and must not originate from a visualization server under any circumstances.

Datadog Log Analytics:

Datadog Audit Trail:

An attacker relaying through the monitoring host has an incentive to suppress the monitors that would surface it, so monitor deletion and integration changes inside the hunt window are corroborating signals rather than housekeeping noise.

Datadog CloudTrail integration:

Datadog Monitor:

Windows Event Log PowerShell analysis:

YARA memory scan — sweep the monitoring host for relay and tunnelling tooling resident in memory:

Falcon Real Time Response can run the same sweep across the fleet, and Falcon Network Containment isolates a confirmed relay host while preserving the Real Time Response channel for evidence collection.

Hypothesis 3: An attacker who recovered credentials from the IntraVUE platform, either in cleartext through the application programming interface or by cracking or replaying the weakly protected hash material, has reused them to authenticate to monitored network infrastructure and control assets, observable as logons and management-protocol sessions using monitoring-platform service accounts from unexpected sources.

MITRE ATT&CK: Defense Evasion | T1078 — Valid Accounts | Recovered credentials let the attacker authenticate rather than exploit, which produces telemetry that looks like administration.

MITRE ATT&CK: Lateral Movement | T1550.002 — Use Alternate Authentication Material: Pass the Hash | The inadequate-encryption-strength weakness specifically enables hash replay without recovering the plaintext password.

MITRE ATT&CK for ICS: Lateral Movement | T0859 — Valid Accounts | Monitoring-platform credentials are frequently reused across switches, controllers, and HMIs, so a single disclosure unlocks the fleet.

Collection Queries:

CrowdStrike Falcon LogScale (CQL) — every logon attributable to a monitoring-platform service account, wherever it occurred:

CrowdStrike Falcon LogScale (CQL) — failed authentication across the fleet, which is where credential spraying with a recovered account surfaces:

BPF Packet Capture — capture management-protocol authentication into the control network for offline review:

Datadog Log Search:

Datadog Live Process Monitoring:

Windows Event IDs to collect:

• 4624 successful logon, with logon type 3 for network logons and type 9 for explicit-credential runas
• 4625 failed logon, with the substatus code identifying bad password versus unknown account
• 4648 logon using explicit credentials, the highest-signal single indicator of credential reuse from a foothold
• 4776 NTLM credential validation, which records pass-the-hash authentication that Kerberos events miss
• 4768 and 4769 Kerberos ticket requests, for encryption-type downgrade and anomalous service-ticket patterns

PowerShell collection commands:

OT Data Collection: Armis Centrix — surface repeated authentication failure against control assets, which is the canonical alert type for this shape:

Armis has no native window-correlation operator, so for a failed-then-successful-within-window shape, export the alert set and a parallel ipConnections result to CSV and correlate on the source-address and affected-device tuple externally.

OT Data Collection: Claroty CTD — review authentication-related alerts and any program upload or download, mode change, or firmware download alert on control assets during the hunt window. Pivot each to the secure-access session log for user attribution. A controller change with no matching sanctioned session is out-of-band by construction.

OT Data Collection: Dragos Platform — triage Notifications filtered to ATT&CK for ICS Lateral Movement techniques T0859 and T0886 across the enterprise-to-control boundary, and escalate any notification carrying an Activity Group tag. Pull the Notifications collection through the SiteStore API with severity at or above three and join to the Assets collection on asset identifier.

OT Data Collection: Nozomi Guardian — retrieve authentication and access alerts and any variable changes that follow them:

OT Data Collection: Tenable OT Security — pull policy-violation and access events for the control assets whose credentials the monitoring platform held:

OT Data Collection: Forescout eyeInspect — review the Alerts view for authentication and unauthorized-access detections from the Industrial Threat Library, and export via CEF to the SIEM for correlation with the Windows authentication events collected above.

YARA file-system scan — sweep for credential-handling artefacts left behind on the monitoring host and any foothold host:

Analysis Queries:

CrowdStrike Falcon LogScale (CQL) — remote interactive logons sourced from outside the RFC 1918 ranges. A non-zero result here on a control-adjacent host is immediately escalatable:

CrowdStrike Falcon LogScale (CQL) — credential-dumping and hash-replay tooling on any host in the fleet:

Wireshark display filters and tshark equivalents:

Any SNMP community string visible in cleartext in this capture must be treated as disclosed and rotated alongside the IntraVUE credentials.

Datadog Log Analytics:

Datadog Audit Trail:

Datadog CloudTrail integration:

Datadog Monitor:

Windows Event Log PowerShell analysis:

YARA memory scan — sweep for credential-dumping tooling resident in memory across the engineering workstation pool and the monitoring host:

Scanning LSASS memory requires SeDebugPrivilege, so run the sweep from an elevated context. Falcon Real Time Response executes the same rule set on remote hosts without an on-site analyst, and Falcon Identity Protection provides the richer surface for pass-the-hash and Kerberoast detection where it is licensed.

Hypothesis 4: An attacker who used the host and share disclosure to map the monitoring server's filesystem has staged tooling, modified configuration, or established persistence on that host, observable as anomalous file writes, share enumeration, scheduled-task registration, and service installation on the monitoring platform.

MITRE ATT&CK: Discovery | T1135 — Network Share Discovery | The disclosed share structure removes the need to enumerate noisily, but follow-on access to those shares still generates telemetry.

MITRE ATT&CK: Persistence | T1053.005 — Scheduled Task/Job: Scheduled Task | A relay or collector installed on the monitoring host needs to survive reboot.

MITRE ATT&CK: Persistence | T1543.003 — Create or Modify System Process: Windows Service | Service installation is the most common persistence mechanism on a server-class host.

Collection Queries:

CrowdStrike Falcon LogScale (CQL) — every file write on the monitoring host across the whole write-event family, sorted rarest-first. The bare FileWritten event name does not exist, so the family regex is required:

CrowdStrike Falcon LogScale (CQL) — built-in enumeration binaries across the fleet, which surface the reconnaissance that follows a share disclosure:

BPF Packet Capture — capture SMB traffic to and from the monitoring host for share-access reconstruction:

Datadog Log Search:

Datadog Live Process Monitoring:

Windows Event IDs to collect:

• 5140 network share object accessed, which records each connection to a disclosed share
• 5145 detailed share object access, which records the specific file and the access mask requested
• 4688 process creation with command line, for the enumeration and staging commands themselves
• 4698 scheduled task created and 4702 scheduled task updated, for the persistence check
• 7045 service installed, recorded in the System log rather than Security

PowerShell collection commands:

OT Data Collection: Armis Centrix — check whether the monitoring host has begun speaking file-share protocols it never spoke before, and whether any new device has appeared alongside it:

OT Data Collection: Claroty CTD — review AppDB project-file-change detections for any controller the monitoring host reached, and use the Network Communications off-baseline view to isolate protocols the monitoring host has newly started speaking. Pivot any project-file change to the secure-access session log for user attribution.

OT Data Collection: Dragos Platform — check the Assets view for first-seen dates inside the hunt window in the monitoring host's zone, and query the file-transfer Query Focused Dataset for staged payload movement across the enterprise-to-control boundary.

OT Data Collection: Nozomi Guardian — look for newly appeared nodes and for file-transfer sessions involving the monitoring host:

OT Data Collection: Tenable OT Security — retrieve the monitoring host's asset record and any configuration-change events recorded against it:

OT Data Collection: Forescout eyeInspect — use the Asset Inventory view to compare the monitoring host's fingerprint history across the hunt window, since a changed fingerprint on a server that was not scheduled for change is a durable staging indicator.

YARA file-system scan — sweep the monitoring host's install tree, temporary directories, and disclosed shares:

Analysis Queries:

CrowdStrike Falcon LogScale (CQL) — scheduled tasks registered on the monitoring host, with the executed command:

CrowdStrike Falcon LogScale (CQL) — services started on the monitoring host, rarest-first, so a one-time service start stands out against the recurring platform services:

Wireshark display filters and tshark equivalents:

Datadog Log Analytics:

Datadog Audit Trail:

Datadog CloudTrail integration:

Datadog Monitor:

Windows Event Log PowerShell analysis:

YARA memory scan:

Threat Actor Profile

Opportunistic criminal actors are the most likely first movers. The technical detail in the advisory is sufficient to reconstruct the unauthenticated disclosure paths without reverse engineering, and internet-facing or third-party-reachable monitoring platforms are routinely swept by commodity scanners within days of a disclosure. Sophistication is low to moderate. The access path is straightforward: reach the web or application listener from any network position, retrieve credentials and the asset inventory without authenticating, and sell or reuse the result. The tradecraft is high-volume and low-precision, so the telemetry signature is broad scanning followed by a short burst of API requests from a single unfamiliar source.

Ransomware operators represent the highest-consequence near-term risk. Their standard playbook already includes harvesting credentials from network-management platforms, because those platforms hold reusable access to the exact infrastructure that maximises encryption impact. The IntraVUE disclosures shorten that playbook substantially: the asset inventory identifies the control-network targets, the cleartext credentials provide the access, and the unintended proxy supplies the route. Sophistication is moderate to high, the access path begins with a conventional enterprise foothold, and the observable tradecraft is credential reuse, lateral movement over remote-access protocols, and staging on servers rather than workstations.

State-aligned actors focused on operational technology are the lowest-probability but highest-severity scenario. Groups tracked for pre-positioning against critical infrastructure prize exactly the capability this advisory describes: a durable, low-noise route across a segmentation boundary that survives ordinary security hygiene because the crossing host is a sanctioned tool. Sophistication is high, dwell time is long, and the tradecraft is deliberately quiet. Expect no destructive action, minimal file staging, and traffic that stays within the shapes the monitoring platform already produces. This is the scenario the baselining work in Hypothesis 2 is designed to catch, because volume-based and signature-based detection will not.

Insider and vendor-access scenarios deserve explicit consideration on a platform of this kind. Integrators and support vendors frequently hold standing accounts on network-monitoring servers, and the credential disclosure means any such account may now be held by someone else. Sophistication varies, the access path is legitimate remote access, and the distinguishing signal is timing rather than technique: sanctioned activity aligns to a change record and a maintenance window, and out-of-band activity does not.

Data Sources Required

Network telemetry: full packet capture on both the enterprise-facing and control-facing interfaces of the monitoring host, NetFlow or IPFIX records covering the enterprise-to-control boundary, firewall accept and deny logs for the monitoring host's rule set, and switch interface counters polled over SNMP for the ports facing the monitoring host and the control assets it reached.

Endpoint telemetry: CrowdStrike Falcon sensor coverage on the monitoring host and on every engineering workstation that administers it, Windows Security event logs including 4624, 4625, 4648, 4672, 4688, 4698, 4702, 4776, 5140, 5145, 5156, and 5157, Windows System event log for 7045 service installation, PowerShell Operational log for 4104 script block records, and Sysmon where deployed for process, network, and file event coverage that the native logs do not provide.

OT and industrial telemetry: process historian alarm and event journal for the hunt window, SCADA alarm log, controller diagnostic and audit logs where the platform records them, PLC project-file change records from the engineering software or the OT monitoring platform's application database, and SNMP trap-receiver logs for coldStart, warmStart, linkDown, linkUp, and authenticationFailure traps from control-network devices.

OT monitoring platform data: Armis Centrix connection and activity records plus the alert set, Claroty CTD alerts, network communications with baseline status, application-database project-file change detections and exported packet captures, Dragos Platform notifications, Communications Hub session records, Query Focused Datasets for industrial protocols and file transfer, and exported event packet captures, Nozomi Guardian nodes, links, variables, and alerts through the OpenAPI query endpoint, Tenable OT Security assets, events, and policy violations through the GraphQL endpoint, and Forescout eyeInspect asset inventory, alerts, and CEF-forwarded records.

Vendor and device logs: IntraVUE application and access logs from the monitoring platform itself, including its own record of API requests and console sessions, managed switch authentication and configuration-change logs for every device the platform polled, and remote-access gateway session logs covering vendor and integrator connections into the monitoring host.

Aggregation and analysis platforms: CrowdStrike Falcon LogScale for endpoint and network event correlation, Datadog for log search, analytics, audit trail, and monitor definition, and the offline packet-analysis workstation for Wireshark and tshark protocol dissection of the exported captures.

Detection Signatures

SIGMA rule one targets the core segmentation-bypass behaviour: the monitoring host initiating a connection to an industrial-protocol or remote-access port from a process other than the sanctioned monitoring service. It uses the network_connection logsource category.

SIGMA rule two targets the client side of the credential harvest: a scripting interpreter or command-line HTTP client requesting the monitoring platform's application programming interface. Legitimate console access comes from a browser, so a non-browser process reaching the API is the signal. It uses the process_creation logsource category, giving the rule set coverage across a second, independent telemetry source.

SIGMA rule three targets staging on the monitoring host after the filesystem and share structure disclosure. It uses the file_event logsource category, giving the rule set a third distinct telemetry source.

SIGMA rule four targets relay logic implemented in PowerShell rather than a compiled binary. It uses the ps_script logsource, which maps to PowerShell script block logging event 4104 and represents a fourth independent telemetry source.

Snort and Suricata rule one alerts on unauthenticated requests to the monitoring platform's API from outside the engineering address range, using a detection_filter so that a single stray request does not fire but a harvesting burst does. Local SIDs begin at 1,000,000.

Snort and Suricata rule two alerts on any industrial-protocol session originating from the monitoring server toward the control network, which is the wire-level signature of the unintended-proxy relay. It fires on session establishment rather than on payload, because the relay is defined by who is talking rather than by what is said.

Snort and Suricata rule three alerts on remote-access protocol sessions from the monitoring server into the control network, which no visualization platform should ever generate.

YARA rule one targets disk artefacts left by credential harvesting against the monitoring platform: saved API responses containing credential structures, and the scripts written to retrieve them. The condition requires an IntraVUE-specific anchor together with at least one credential-bearing token, so a file merely mentioning the product name does not match. The file-size ceiling keeps the rule off large binaries and database files where these strings appear incidentally.

YARA rule two is the standing credential-dumping memory rule, included because Hypothesis 3 covers credential access and lateral movement. Five branches cover mimikatz, Windows Credentials Editor, gsecdump, the comsvcs MiniDump technique, and a catch-all pairing a memory-read API with an LSASS reference and any tool indicator. The branch structure rather than a flat any-of condition prevents a single generic string such as an API name from firing the rule on legitimate software. Scanning LSASS requires SeDebugPrivilege, so the sweep must run elevated. In Linux-only pools such as container hosts this rule will not match Linux credential dumping through the proc filesystem, so it is scoped to Windows hosts and paired with the relay rule below for the Linux side.

YARA rule three targets relay and tunnelling tooling, both on disk and in process memory. This is the rule that answers Hypothesis 2 directly: the unintended proxy gets the attacker across the boundary once, and a relay binary or script makes the crossing persistent. The condition requires a tool-name anchor together with a networking indicator, so a generic mention of a port or an address family does not fire it. It applies to both Windows and Linux hosts, which covers the Linux gap in the credential rule above.

Indicators of Compromise

Network indicators: inbound sessions to the monitoring host's web or application ports from any address outside the engineering workstation set, particularly a single source issuing a short burst of requests and never returning. HTTP requests to the monitoring platform's API path carrying no Authorization header. HTTP responses from the monitoring host exceeding one hundred kilobytes, which is the shape of a full inventory or credential dump rather than a console page. Any connection originating from the monitoring host to a control-network address on an industrial-protocol port that does not appear in its established polling profile. Any connection originating from the monitoring host on SSH, Telnet, RDP, VNC, or SMB into the control network. SNMP community strings observable in cleartext in captured traffic between the monitoring host and control assets. A producer-consumer ratio approaching negative one on any flow involving the monitoring host, indicating bulk outbound transfer.

Host indicators: a listening socket on the monitoring host owned by a process other than the sanctioned monitoring service. A scheduled task or service registered on the monitoring host with no matching change record. Executable, library, or script files written into temporary or world-writable directories on the monitoring host outside a documented upgrade window. Explicit-credential logon events referencing a monitoring-platform service account originating from a host that is not an engineering workstation. NTLM credential validation events for a monitoring-platform service account against control-network infrastructure. Enumeration binaries executed on the monitoring host, particularly against the shares whose structure the platform disclosed.

Operational and OT indicators: a controller mode change, program download or upload, setpoint write, or firmware download whose timestamp falls inside a window of relayed activity from the monitoring host. A first-ever write-class function code on a relationship that has historically been read-only. An SNMP coldStart or warmStart trap from a control asset with no corresponding maintenance record. Authentication-failure traps from control-network device interfaces. A managed switch configuration change made using credentials the monitoring platform held. An off-baseline protocol or peer appearing on the monitoring host in any OT monitoring platform's baseline view. A historian or SCADA alarm for communication loss on an asset that the monitoring host contacted immediately beforehand.

Timing indicators: activity on the monitoring host outside business hours and outside any scheduled maintenance window is the single most useful discriminator in this hunt, because the legitimate behaviour of a polling platform is metronomic. A deviation in polling cadence, an unusual gap followed by a burst, or a change in the set of peers contacted per cycle all warrant investigation even where no individual event is independently suspicious.

False Positive Baseline

The IntraVUE platform's own scheduled polling of control assets is by far the largest source of matching traffic. Establish the polling profile first, recording the exact set of destination addresses, destination ports, protocols, and the polling interval, then suppress that profile as a named baseline rather than suppressing the ports generally. Suppressing by port would blind the hunt to precisely the relay it is looking for.

Engineering workstations browsing the monitoring console generate inbound sessions on the web ports continuously during working hours. Enumerate the engineering workstation set explicitly and treat it as the baseline for Hypothesis 1, with the residual tail rather than the whole result set as the analysis target.

The upgrade to version 3.2.1a16 itself produces a burst of file writes into temporary directories, service stops and starts, and a changed asset fingerprint on the monitoring host. Record the exact upgrade timestamp before running the hunt and exclude that window from the Hypothesis 4 file-write and service-installation analysis, or the remediation will read as the intrusion.

Backup and endpoint-management agents read the monitoring host's file shares and its install tree on a schedule, generating 5140 and 5145 share-access events at volume. Identify the agent accounts and their scheduled windows, and treat share access outside those accounts and windows as the signal.

Scheduled vulnerability scanning from a scanner sitting on the monitoring VLAN produces connections to industrial-protocol ports that look identical to a relay at the flow level. Confirm the scanner's address and its scan calendar with the vulnerability management team, and note that a scanner reaching control assets at all may itself be a finding worth raising separately.

Vendor and integrator support sessions during sanctioned maintenance windows produce remote-access protocol traffic from the monitoring host and explicit-credential logons using platform service accounts. Reconcile every such session against the change calendar and the remote-access gateway session log. A session with a matching change record is baseline; a session without one is out-of-band by construction and escalates.

Other OT monitoring platforms performing their own active queries emit protocol-native probes from their collector addresses, which can be mistaken for relayed reconnaissance. Document the collector address of every OT platform in the environment and exclude it by address, not by behaviour.

Escalation Criteria

1. Any connection originating from the monitoring host to a control-network address on an industrial-protocol port that is not in the documented polling baseline, where the originating process is not the sanctioned monitoring service. Escalate to incident response immediately and treat the monitoring host as compromised until proven otherwise.

2. Any connection originating from the monitoring host to a control-network address on SSH, Telnet, RDP, VNC, or SMB, regardless of process. There is no legitimate baseline for this behaviour on a visualization platform.

3. Any write-class industrial-protocol function code observed from the monitoring host: CIP service code 0x4d or 0x53, Modbus function code 5, 6, 15, 16, or 22, DNP3 operate or direct-operate, or an S7comm write or download function. Escalate to incident response and notify plant operations in parallel, because a write may already have altered process state.

4. Any YARA hit on Network_Relay_Tooling_Memory_Artifacts against any process or file on the monitoring host or on any host with control-network reachability. Preserve the process memory and the file before containment.

5. Any YARA hit on Credential_Dump_Tool_Memory_Artifacts against any process on the monitoring host, an engineering workstation, or a domain controller. Escalate to incident response and begin credential rotation ahead of the investigation conclusion.

6. Any YARA hit on IntraVUE_Credential_Harvest_Artifacts against a saved file on any host. Treat every credential the monitoring platform held as disclosed and initiate the rotation described in the advisory mitigations.

7. Any explicit-credential logon event, Windows event 4648, using a monitoring-platform service account from a host outside the engineering workstation set, or any NTLM credential validation for that account against control-network infrastructure.

8. Any scheduled task or service created on the monitoring host with no matching change record, or any executable, library, or script written into a temporary or world-writable directory on that host outside a documented upgrade window.

9. Any controller mode change, program download or upload, setpoint write, or firmware download whose timestamp falls inside a window of relayed or unexplained activity from the monitoring host, whether or not the change was recorded as authorized.

10. Any inbound session to the monitoring host's API from an external or unmanaged network position, or any HTTP response from the monitoring host exceeding one hundred kilobytes to a source outside the engineering workstation set.

11. Discovery that the monitoring host is reachable from the internet or from a third-party network at any point in the hunt window. This escalates independently of whether exploitation evidence is found, because it converts every finding in this advisory from an internal risk to an external one.

12. Any control-network device found to have accepted authentication using a credential the monitoring platform held, from a source other than the monitoring host itself.

Hunt Completion Criteria and Reporting

The hunt is complete when every hypothesis has been executed against the full available window on every in-scope data source, when every returned result has been dispositioned as either baseline or finding with the reasoning recorded, when the monitoring host's legitimate polling profile has been documented as a named baseline that future detection can reference, and when every coverage gap has been recorded explicitly with the reason and the unexamined period stated.

Coverage gaps must be enumerated rather than absorbed. Where log retention is shorter than the exposure window, state the retention boundary and the length of the unexamined period. Where a data source is absent, for example where Datadog Live Process Monitoring is not enabled, where host-level network telemetry is not forwarded, or where a control asset produces no authentication log at all, name the source, name the hypothesis it would have supported, and state which substitute query was used instead. A hypothesis answered only by substitute telemetry is a partial result, not a negative one.

The hunt report must contain: the scope actually examined including the exact date range and the asset set; the version of IntraVUE in service during the window and the upgrade timestamp if remediation has occurred; the documented polling baseline for the monitoring host; per-hypothesis findings with supporting query output and disposition; every escalation raised with its criterion number and outcome; the coverage gaps described above; the false-positive suppressions applied and their justification; and the detection content promoted to standing rules.

Detection content promotion is part of completion, not a follow-on activity. The four SIGMA rules, the three Snort and Suricata rules, and the Datadog monitors defined in Section 2 should be deployed as standing detection once the Section 7 baseline has been applied to them, with the CrowdStrike queries that produced actionable results promoted to NG-SIEM Correlation Rules or scheduled searches. Record which rules were deployed, which were held back pending tuning, and what tuning each requires.

The report must also state plainly whether the operational mitigations from the advisory have been completed: the upgrade to version 3.2.1a16 or later, the restriction of network reachability to the monitoring host, the rotation of every credential the platform stored or used, and the validation that segmentation between the enterprise and control networks does not depend on the monitoring host behaving correctly. A hunt that returns no findings but leaves the credentials unrotated has not reduced the exposure.

Advisory IoC Reference