Threat Hunt Plan: Hitachi Energy CoreTec — Command Injection and Kernel Privilege Escalation

Date: 2026-11-02 | Revision 1

Hunt Objective and Scope

This hunt determines whether an adversary has exploited, or is positioned to exploit, the two vulnerabilities disclosed in CISA advisory ICSA-26-302-03 affecting Hitachi Energy CoreTec4 and CoreTec5 control products: an OS command injection in the configuration daemon's timezone handler (CVE-2026-13162) and the "Dirty Frag" Linux-kernel IPsec ESP privilege-escalation flaw in CoreTec5 (CVE-2026-43284). CoreTec devices are control and protection platforms for grid power-electronics systems (high-voltage direct current and flexible AC transmission), so the in-scope environment is the OT/ICS segment hosting these devices, their management and engineering access paths, the jump hosts and engineering workstations that administer them, and any internet-facing exposure of their management interfaces.

In scope: all CoreTec4 and CoreTec5 devices and their management VLANs; the engineering workstations, jump hosts, and administrative accounts authorized to reach them; the OT network-monitoring sensors covering those segments; and the organization's public IP space for the external-exposure leg. Out of scope: unrelated OT product families and corporate IT assets with no administrative path to a CoreTec device.

Time window and data floor pre-flight. Neither Hitachi Energy nor CISA reports in-the-wild exploitation, and no pre-disclosure exploitation date is known, so this is a proactive hunt. Target window: 90 days back from the hunt start date (covering the pre-disclosure period in case of silent exploitation) through current. A time picker is not retention, so before any event-based leg runs, measure the data floor — the oldest retained event per family — and record the floor DATE, not a duration:

The part of the window earlier than the measured data floor is Non-Conclusive, not clean. Event-based clauses (a management session, an ESP flow, a shell spawn) are bounded by the floor. State-based clauses (current firmware version, a timezone-configuration artifact that persists on the device, a management interface exposed to the internet right now) can be re-queried as current state and are not bounded by the event floor; each hypothesis states which kind it is.

Coverage note carried throughout: CoreTec is an embedded-Linux OT appliance and does not run a CrowdStrike Falcon sensor or a Datadog Agent. CrowdStrike CQL and Datadog therefore see the device only indirectly — the engineering workstations and jump hosts that initiate sessions to it, and any device syslog forwarded to the SIEM/Datadog. Device-local and on-wire evidence comes from the OT monitoring platforms, packet capture, SNMP, and forwarded device logs. Every negative from an endpoint-telemetry leg is bounded by this gap and reports Non-Conclusive for the device itself.

Hypotheses and Hunt Procedures

Hypothesis 1 (execute FIRST): An external actor can reach an internet-facing instance of a CoreTec management interface, observable as an exposed service in passive internet-scan indices. Its output scopes the internal hypotheses: a confirmed-owned, in-range exposed device becomes a priority target hunted exhaustively in Hypotheses 2 and 3. This is a state-based hypothesis (current exposure).

MITRE ATT&CK: Reconnaissance | T1595 Active Scanning (defender-side: passive discovery of what an actor would enumerate) · Initial Access | T1133 External Remote Services · ICS | T0883 Internet Accessible Device — an internet-reachable CoreTec management interface is the entry point the network-exploitable command injection (CVE-2026-13162, AV:N) depends on.

Collection Queries — passive external indices (STRICTLY passive; never probe target infrastructure). Author the filters unscoped first to prove they match the product, then add the ownership scope. The exact UI/banner string should be derived from an instance you own (favicon-hash pivot below), not copied from any third-party write-up.

→ Expected Positive shape: one or more hosts inside owned public IP space returning a CoreTec management UI title / banner on 443 or 80, corroborated in at least two of Shodan / Censys / Netlas.

Analysis Queries (full workflow in easm-reference/easm_methodology.md):

Control — unscoped filter proves the product selector matches before scoping: run each engine's product/title filter with NO ownership scope and confirm it returns CoreTec instances somewhere on the internet. A scoped query that returns zero is interpretable only if its unscoped twin is non-zero (otherwise the filter itself is wrong, a silent false zero). API keys are referenced by env-var name only (SHODAN_API_KEY, CENSYS_API_SECRET, CENSYS_ORG_ID, NETLAS_API_KEY); a missing key is a coverage gap for that engine, not a zero.

Verdict criteria: Positive — a two-engine-corroborated, ownership-attributed, in-range CoreTec management interface exposed to the internet; Negative — no attributed in-range exposure AND the unscoped control non-zero across at least two engines AND the owned public IP inventory was complete; Non-Conclusive — unscoped control zero (filter unproven), single-engine only, unattributable hit, or incomplete IP inventory; missing a complete authoritative public-IP/cloud inventory prevents determining whether an exposed instance is ours.

Hypothesis 2: An adversary holding a CoreTec account with a sufficient role (through credential abuse, an over-provisioned role, or a malicious insider) has injected operating-system commands through the configuration daemon's timezone / time-synchronization handler (CVE-2026-13162), observable as anomalous management sessions, a configuration-daemon process spawning a shell, timezone values carrying shell metacharacters, and dropped tooling on the administering hosts. Event-based for session/process/flow evidence (bounded by the data floor); state-based for a persistent malicious timezone/startup artifact on the device.

MITRE ATT&CK: Execution | T1059.004 Command and Scripting Interpreter: Unix Shell — the injected timezone value is concatenated into a shell command and executed on the device · Initial Access/ICS | T0883 Internet Accessible Device, T0859 Valid Accounts — exploitation requires an authenticated role · ICS | T0821 Modify Controller Tasking (potential follow-on once the device is controlled).

Collection Queries:

CrowdStrike Falcon LogScale (CQL) — management sessions INITIATED BY a Falcon-monitored engineering workstation / jump host toward the CoreTec management IP (the device has no sensor; this sees the originating host only). NetworkConnectIP4 is a connection the Falcon host initiated, so RemoteAddressIP4 is the CoreTec device (10.20.30.0/24 shown as an illustrative management CIDR — substitute the real one):

→ Expected Positive shape: a management session to a CoreTec IP from a host that is NOT in the sanctioned engineering-workstation / jump-host set, or outside a maintenance window.

CrowdStrike Falcon LogScale (CQL) — on the administering host, join the connection to the initiating process (servers/long-lived clients need ProcessRollup2; include aid in every PID join):

→ Expected Positive shape: an unexpected client binary or command line (not the sanctioned management tool) administering a CoreTec device, or an unexpected operator account.

Datadog — forwarded CoreTec device syslog; configuration-daemon activity around a timezone update (positive attribute term required — a negation-only query matches the whole source):

→ Expected Positive shape: a configd/ntpd log line applying a timezone value that contains a shell metacharacter, or a shell/child-process entry logged by the daemon.

Datadog Live Process Monitoring — NOT available on the CoreTec device (no Agent). On a Falcon/Datadog-dual-managed engineering workstation it can show the management client; otherwise use the Log Search fallback:

Windows Event Log (engineering workstations / jump hosts) — process creation of the management client and the outbound session:

OT Data Collection: Claroty xDome — enumerate the CoreTec population, then every management/remote-access flow reaching it; left-anti-join observed remote sessions against the sanctioned SRA session log (any observed session with no SRA record is out-of-band). In Devices -> All Devices -> Advanced Filters scope by network/VLAN (not by Category) to the CoreTec management segment; in Network -> Communication -> Communication Analysis set Side B to the CoreTec devices, Protocol = SSH/HTTPS, Time Frame a custom range (Past Quarter silently exports 30 days). Correlate every hit to its asset_id, never by hostname.

OT Data Collection: Claroty CTD — on-prem equivalent; use its longer PCAP retention to export the session packet capture for any flagged management flow (CTD and xDome are different platforms — do not collapse to generic "Claroty").

OT Data Collection: Dragos Platform — in Assets scope to the Hitachi Energy CoreTec population; in Communications Hub filter source-zone = engineering/L3.5 AND dest-zone = the CoreTec zone AND protocol IN [SSH, HTTPS] over the window, and pivot each cross-zone session to its asset record and event PCAP; triage Notifications for ATT&CK-ICS Initial Access (T0883) / Execution touching those assets.

OT Data Collection: Nozomi Guardian — N2QL for management flows into the CoreTec zone:

OT Data Collection: Tenable OT — in Inventory -> All Assets filter vendor = Hitachi Energy and the CoreTec AssetType; in Events filter Event Category = Configuration Events with event types "Change in state" and "Change in firmware version" across the window and correlate each against the change record.

OT Data Collection: Forescout eyeInspect — first enumerate sensors and module health (a clean result from an unhealthy sensor is Non-Conclusive); scope hosts by purdue_level and main_vendor_model = Hitachi Energy; pull Alerts filtered to SSH/HTTPS (l7_proto) and the window; export the host changelog and escalate any firmware_version / os_version transition on a CoreTec host with no maintenance work order.

Packet capture (BPF, VLAN-aware is required — repeat the whole primitive in each branch; pair with an unscoped control):

YARA file-system scan of engineering workstations / jump hosts for staged injection tooling and reverse-shell payloads (the appliance itself cannot be swept — CrowdStrike RTR does not reach it):

Analysis Queries:

CrowdStrike Falcon LogScale (CQL) — rarity: management sources to CoreTec ranked rarest-first (a one-off source is the anomaly):

Datadog Log Analytics — timezone-configuration activity over time, grouped by device:

Datadog Monitor (one per hypothesis):

Wireshark / tshark — management traffic analysis (the interface is HTTPS; URI/body content is visible only where the sensor sees decrypted traffic — read the negotiated TLS version off the ServerHello, not the record-layer version):

Windows Event Log (PowerShell) — review of script-block / command activity around the session on the administering host:

YARA memory scan of the administering host for in-memory tooling (classic YARA 4.5 takes the PID as the positional target — there is no -p PID flag; -p sets directory-scan threads):

Control — <proves the leg can see the thing it hunts>: run the family/field controls on the same window and scope. (a) Family presence — #event_simpleName=NetworkConnectIP4 event_platform=Lin | head(1) confirms Linux network telemetry exists; (b) field presence for the scoped filter — #event_simpleName=NetworkConnectIP4 | cidr(RemoteAddressIP4, subnet=["10.20.30.0/24"]) | RemoteAddressIP4=/./ | count() confirms any host talks to the management segment at all (a family control does not cover the CIDR filter); (c) Datadog — source:syslog host:<coretec_device_host> confirms the device forwards syslog at all before trusting a zero; (d) OT platforms — confirm the CoreTec devices appear in inventory and the covering sensor is healthy. A zero whose control is 0 or unrun is Non-Conclusive.

Verdict criteria: Positive — a management session from a non-sanctioned source OR a configd/ntpd shell-spawn OR a timezone value with shell metacharacters on a CoreTec device, corroborated on at least one independent surface; Negative — no such evidence AND the family + field + device-forwarding controls all non-zero across the window above the data floor; Non-Conclusive — any control zero/unrun, device syslog not forwarded, or the window extends below the data floor; missing forwarded device logs prevents determining device-local command execution (endpoint telemetry sees only the administering host).

Hypothesis 3: An adversary with local or adjacent network access to a CoreTec5 device has sent crafted IPsec ESP packets to trigger the "Dirty Frag" write-what-where flaw in the kernel esp4 subsystem (CVE-2026-43284) and escalated to root, observable as anomalous ESP (IP protocol 50) traffic to the device, device instability/reboots, and kernel error logs. Event-based for ESP flows and reboot events (bounded by the data floor); state-based for current firmware version.

MITRE ATT&CK: Privilege Escalation | T1068 Exploitation for Privilege Escalation — a crafted ESP packet corrupts kernel memory so injected code runs as root · ICS | T0890 Exploitation for Privilege Escalation, T0814 Denial of Service (device instability as a side effect). The vulnerable esp4 component is compiled built-in and present from boot, so no module load precedes exploitation.

Collection Queries:

Packet capture (BPF, VLAN-aware; ESP is IP protocol 50 — capture it directly; pair with an unscoped control):

→ Expected Positive shape: ESP traffic to the CoreTec5 device from a source that is not a sanctioned IPsec peer, or a burst of malformed/short ESP packets preceding a device reboot.

SNMP — poll the CoreTec5 device and its switch port for uptime resets and interface anomalies, and collect reboot/auth traps for the window (treat any v1/v2c community access to an OT asset as a finding; prefer v3 authPriv, provisioning credentials via snmp.conf rather than inline):

CrowdStrike Falcon LogScale (CQL) — coverage gap stated: CoreTec5 has no Falcon sensor and CQL network families (NetworkConnectIP4/NetworkReceiveAcceptIP4) record TCP/UDP, not IP-protocol-50 ESP, so CQL cannot see the exploit traffic on the device. Its only role here is to surface IPsec tooling invoked FROM a Falcon-monitored host that could be staging crafted ESP (a weak, originator-side signal):

Datadog — forwarded CoreTec5 kernel/syslog for crash and ESP-handling errors (positive attribute anchor; token-matching caveat applies):

OT Data Collection: Claroty xDome — Communication Analysis with Side B = the CoreTec5 devices, IP Protocol = ESP (50), custom time range; correlate new/unexpected ESP peers by asset_id. Claroty CTD — export the PCAP for any flagged ESP flow (longer on-prem retention). Dragos Platform — Communications Hub filtered to the CoreTec5 zone and the ESP/IPsec flow, pivot to event PCAP; triage Notifications for device-reboot / availability events. Nozomi Guardian — N2QL:

OT Data Collection: Tenable OT — Events filtered to the CoreTec5 assets for state-change / reboot event types across the window. Forescout eyeInspect — Alerts filtered to l4_proto = ESP and the window after confirming sensor health; host changelog for any firmware/OS transition with no work order.

Analysis Queries:

Wireshark / tshark — ESP flow and anomaly analysis (count ESP packets per source, surface malformed/short frames and new SPIs):

→ Expected Positive shape: ESP from a source outside the sanctioned IPsec peer set, an unexpected SPI, or a cluster of undersized ESP frames immediately before a device uptime reset.

Datadog Log Analytics — device reboot / kernel-error frequency over time:

Datadog Monitor:

SNMP correlation — diff successive sysUpTime polls at 60-second intervals across the hunt window; any decrease (counter reset) indicates a reboot — correlate the timestamp against the ESP-capture and kernel-log timelines.

Control — <proves the leg can see the thing it hunts>: (a) the unscoped ESP capture control above must return ESP frames, or an empty scoped ESP result means "no ESP visibility here," not "no exploitation"; (b) confirm the CoreTec5 device forwards syslog and that the trap receiver receives traps from its range before trusting a zero; (c) OT platform — confirm the CoreTec5 device is in inventory and the covering sensor is healthy. A zero whose control is 0 or unrun is Non-Conclusive.

Verdict criteria: Positive — unexpected/malformed ESP to a CoreTec5 device correlated with a device reboot or kernel fault, OR a kernel oops/panic indicator in forwarded logs with no maintenance cause; Negative — no anomalous ESP AND no unexplained reboot/kernel fault AND the ESP-capture, syslog-forwarding, and sensor-health controls all non-zero across the window above the data floor; Non-Conclusive — any control zero/unrun, no ESP visibility on the segment, device logs not forwarded, or window below the data floor; missing on-device telemetry (no Falcon/Datadog Agent on the appliance) prevents confirming root-level code execution — the hunt observes the network and log side effects only.

Threat Actor Profile

No threat actor is attributed to CVE-2026-13162 or CVE-2026-43284 in the source material, and there are no public reports of in-the-wild exploitation. The profile below is prospective, drawn from the activity groups that target the electric sector; carry the attribution caveats throughout — a vendor cluster name is a behavioral grouping, not a government attribution, and cross-vendor aliases are assessed overlaps, not identities.

Nation-state, pre-positioning (PRC-nexus). Activity consistent with VOLTZITE (overlaps Volt Typhoon per Microsoft; Dragos assessment) centers on pre-positioning in electric transmission and distribution for future disruption, relying on living-off-the-land technique, valid-account abuse, and exploitation of internet-facing edge and management devices rather than custom malware. This profile maps directly onto both the internet-exposure leg (Hypothesis 1) and the authenticated command injection (Hypothesis 2): an exposed CoreTec management interface is exactly the kind of edge surface this activity enumerates, and a stolen or over-provisioned CoreTec role is the "certain role" the command injection requires. Initial-access brokers such as SYLVANITE and KAMACITE (per Dragos) mass-exploit internet-facing devices and hand access on, sometimes within days — treat an exposed, in-range device as a candidate handoff point.

Nation-state, OT-effects (Russia-nexus). Activity consistent with ELECTRUM (which Dragos assesses as "independent with overlaps" to Sandworm / APT44) is the OT-effects benchmark and is notable here because the group has built Linux ICS-adjacent tooling (the Kapeka variants LOADGRIP and BIASBOAT) and has relied on valid-account abuse on OT hosts without zero-days. CoreTec runs embedded Linux and the Dirty Frag flaw is a kernel-level privilege escalation, so an actor of this profile that reaches a CoreTec5 device through a management path could chain the command injection to the kernel flaw to obtain root on a grid control-and-protection platform. Report any such finding as "activity consistent with" the relevant group only where the evidence supports it; do not assert a government attribution.

Credential-abusing insider or opportunist. Because CVE-2026-13162 requires an authenticated account with a sufficient role, the lowest-sophistication realistic actor is a malicious or compromised insider, or an opportunist who has harvested CoreTec credentials. This actor needs no zero-day and no external infrastructure; the hunt's reliance on sanctioned-session baselines (SRA left-anti-join, maintenance-window correlation) is the primary control against this profile. Give any self-claim or circumstantial attribution appropriate skepticism and judge the finding on the session and command evidence.

Data Sources Required

Network: full-packet capture at the OT monitoring span/tap covering the CoreTec management and IPsec segments (management TCP 22/443 and IP-protocol-50 ESP), NetFlow where available, and firewall/ACL logs for the OT boundary. Endpoint: CrowdStrike Falcon and Windows Event / Sysmon logs from the engineering workstations and jump hosts that administer CoreTec devices (the devices themselves carry no sensor). Device/vendor logs: CoreTec device syslog and kernel logs forwarded to the SIEM/Datadog, SNMP polling and trap data from the devices and their access switches. OT/ICS platforms: whichever of Claroty xDome / CTD, Dragos Platform, Nozomi Guardian, Tenable OT, and Forescout eyeInspect are deployed — asset inventory, communication/flow analysis, OT activity and configuration-change events, per-alert PCAP, and the sanctioned remote-access (SRA) session log for the left-anti-join. External attack surface: the passive internet-scan indices queried read-only (Shodan / Censys / Netlas), the CISA KEV catalog, and the organization's authoritative public IP and cloud asset inventories — the last is required for attribution, and without it the exposure determination in Hypothesis 1 cannot be made.

Detection Signatures

The SIGMA rules span three logsource categories (network_connection, Linux process_creation, file_event). The Snort/Suricata rules cover the management-interface injection and the ESP exploitation traffic. The two YARA rules cover a file/disk artifact and a process-memory artifact respectively. SIDs use the Suricata local range (>=1000000).

The YARA rule CoreTec_Command_Injection_Payload targets the disk artifact of Hypothesis 2: a reverse-shell or stager payload written to a staging path on an administering host, or extracted from a captured injection attempt. It keys on the shell-download-and-execute idiom (wget/curl into a temp path piped to a shell, busybox nc reverse shells, and command-substitution markers) rather than any single literal, because the vendor published no hash; the condition requires any two of these payload markers so a benign timezone string such as "America/New_York" does not match. It is scoped to staging strings to limit false positives on general scripts.

The YARA rule Credential_Dump_Tool_Memory_Artifacts targets the process-memory side of the hunt: credential-dumping tooling resident in memory on a Windows jump host used to obtain the CoreTec account the command injection requires (lateral movement / credential access path). It covers mimikatz, WCE, gsecdump, and comsvcs MiniDump against lsass.exe, plus a catch-all of a memory-read API combined with lsass.exe and one tool indicator, so an unseen wrapper still trips the rule; the branches are OR'd because any one tool family is sufficient. This rule targets Windows LSASS tooling and will not match Linux /proc credential dumping on the OT hosts; keep it scoped to the Windows administering-host pool.

Indicators of Compromise

Network indicators (behavioral, scoped to this hunt): management-interface sessions (SSH/HTTPS) to a CoreTec device from any source outside the sanctioned engineering-workstation / jump-host set or outside an approved maintenance window; IPsec ESP (IP protocol 50) traffic to a CoreTec5 device from a non-sanctioned peer, an unexpected SPI, or a burst of malformed/undersized ESP frames; any remote-access session to a CoreTec device with no matching record in the sanctioned remote-access (SRA) session log.

Host / device indicators: a CoreTec configuration-daemon process (configd/ntpd) spawning a Unix shell; a timezone or time-synchronization configuration value containing shell metacharacters (; | & $() backtick); a CoreTec5 kernel oops/panic or a sysUpTime reset with no corresponding maintenance work order; a firmware or OS-version change on a CoreTec host with no change record; staged reverse-shell / stager payloads in /tmp, /var/tmp, or /dev/shm on an administering host.

OT / operational indicators: an unauthorized configuration or program change on a CoreTec device detected by the OT platform's OT-activity / configuration-event feed; cross-zone management flows from an engineering/IT zone into the CoreTec zone that violate the segmentation model; an internet-facing CoreTec management interface observed in passive scan indices within owned public IP space.

External-exposure indicator: a CoreTec management UI title or banner returned on 443/80 by Shodan, Censys, or Netlas for an address attributable to the organization and in the affected version range — presumptively enumerated by an external actor and the priority target for the internal legs.

False Positive Baseline

1. Scheduled administration from authorized jump hosts during approved maintenance windows — management sessions to CoreTec devices from the sanctioned source set at expected times are expected; suppress by source + window, not by removing the detection.

2. Legitimate NTP/timezone configuration changes applied through the sanctioned workflow — a timezone update with no shell metacharacters and no daemon shell-spawn is benign; the metacharacter/shell-spawn condition is the discriminator.

3. Sanctioned IPsec peers — ESP traffic from the device's configured IPsec gateways/peers is normal; baseline the sanctioned SPI/peer set and alert only on deviations.

4. Planned firmware upgrades and reboots — the upgrade to CoreTec5 5.0.0 (the fix) and its reboot will reset sysUpTime and generate configuration-change events; correlate against the change/work-order record before escalating.

5. OT discovery/monitoring and vulnerability-scan traffic — the OT platform's own active queries and authorized scanners can touch the management interface; exclude the known sensor/scanner addresses.

6. EASM misattribution — a CoreTec banner on shared hosting, a CDN, or a carrier range that is not actually owned by the organization is not a finding; require two independent ownership signals before reporting, and treat honeypot-tagged hosts as non-findings.

Escalation Criteria

Escalate to the incident-response process when any of the following is confirmed:

1. A CoreTec configuration-daemon shell-spawn or a timezone value carrying shell metacharacters is observed on any device (active exploitation of CVE-2026-13162).

2. A management-interface session to a CoreTec device from a non-sanctioned source with no corresponding SRA record and no maintenance work order.

3. Anomalous/malformed IPsec ESP traffic to a CoreTec5 device correlated with a device reboot, sysUpTime reset, or kernel oops/panic (active exploitation attempt of CVE-2026-43284).

4. Any YARA hit on CoreTec_Command_Injection_Payload against a staging path or extracted capture on an administering host.

5. Any YARA hit on Credential_Dump_Tool_Memory_Artifacts against a process on a host that administers CoreTec devices.

6. A two-engine-corroborated, ownership-attributed, in-range CoreTec management interface exposed to the internet, or an exposed instance whose banner version matches the affected range across the disclosure window.

7. An unauthorized configuration or program change on a CoreTec device reported by the OT platform with no change record.

Hunt Completion Criteria and Reporting

The hunt is complete when every hypothesis has a recorded verdict derived from its Verdict criteria, each control query has been run and its result captured, and the data floor date per event family is documented. The report must: give a verdict per hypothesis (a residual finding in a secondary leg does not downgrade a primary verdict; a leg that tests our own collection reports a coverage gap, not a Positive); make every absence claim from a single-predicate filter (filter for the indicator and count), never by reading a distribution table; quote only queries whose LogScale status reads Done (a progressively rendered aggregate looks final before it is — include the status bar in screenshots); and record every limitation with its direction — the device carries no endpoint sensor (device-local code execution is observable only via forwarded logs), an IDS on the HTTPS management interface sees request content only where TLS is decrypted and inbound only, CQL network families do not record IP-protocol-50 ESP, and the xDome Communication Analysis view is capped at roughly one month. Report every leg whose control was zero or unrun as Non-Conclusive, naming the missing input (unforwarded device syslog, no ESP visibility, an unhealthy OT sensor, a window below the data floor, an incomplete public-IP inventory). For the external-exposure leg, record the sweep's coverage (which engines, which owned ranges, which keys were present) and per-hit provenance, and recommend standing the sweep up as a recurring control. Where the fix cannot be applied immediately (CoreTec4 has no fixed version), document the compensating controls in place (segmentation, role restriction, exposure removal) as the interim risk treatment, and map the residual risk to the applicable NERC CIP (CIP-007 patch management, CIP-010 configuration/change management) and IEC 62443 obligations.

Advisory IoC Reference