---
title: "Threat Hunt Plan: Hitachi Energy CoreTec — Command Injection and Kernel Privilege Escalation"
description: 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:
---

[Advisories | 1898 & Co.](https://1898advisories.burnsmcd.com)

# [Threat Hunt Plan: Hitachi Energy CoreTec — Command Injection and Kernel Privilege Escalation](https://1898advisories.burnsmcd.com/threat-hunt-plan-hitachi-energy-coretec-command-injection-and-kernel-privilege-escalation)

 Written by [The 1898 & Co. Team](https://1898advisories.burnsmcd.com/author/1898-co-team) | November 2, 2026

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:

`#event_simpleName=/^(NetworkConnectIP4|NetworkReceiveAcceptIP4|ProcessRollup2|DnsRequest)$/ | groupBy([#event_simpleName], function=min(@timestamp, as=oldest), limit=max)`

 

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.

`Shodan: http.title:"CoreTec"`

 

`http.html:"Hitachi Energy" http.html:"CoreTec"`

 

`port:443,80 http.component:"CoreTec" // scope with ANY ONE of (never AND two ownership anchors into one query): // net:<your_public_CIDR> | org:"<Your Org Name>" | asn:AS<your_ASN> // Shodan has no ip: search filter — use net: for address-space scoping.`

 

`Censys (CenQL — current host.services.* form; do NOT use legacy services.*): host.services.software.product: "CoreTec"`

 

`host.services: (port = "443" and endpoints.http.html_title: "CoreTec") // scope: and (host.autonomous_system.asn = <your_ASN> or host.ip: "<your_public_CIDR>")`

 

`Netlas: http.title:"CoreTec"`

 

`host:<your_public_CIDR> AND port:(443 OR 80)`

 

`// Cross-reference every exposed service + version banner against the CISA Known Exploited // Vulnerabilities catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) and // the advisory CVEs; a KEV match on an in-range instance is presumptive actor-associated risk.`

 

→ 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):

`- Attribute each hit with >=2 independent ownership signals (PTR, ASN, cert CN/SAN, WHOIS/RDAP, the org's own cloud/IP inventory) before reporting. A hit that cannot be attributed is Non-Conclusive, not a finding; shared hosting and CDN break attribution both ways. - Version-triage each banner against the affected ranges (CoreTec5 <=3.4.0, CoreTec4 <=3.4.0) and record the index scan timestamp — a banner is stale in both directions. - Favicon-hash pivot for stripped banners / non-standard ports: derive the hash passively from an instance you own (reuse an index-computed hash); never fetch /favicon.ico from a target and never copy a hash from a blog. - Historical pivot: establish whether the exposure spans the disclosure window; continuous exposure across it means presumptively enumerated.`

 

**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):

`#event_simpleName=NetworkConnectIP4 event_platform=Lin | cidr(RemoteAddressIP4, subnet=["10.20.30.0/24"]) | in(RemotePort, values=["22","443"]) | groupBy([aid, ComputerName, RemoteAddressIP4, RemotePort], function=count(as=conns), limit=max) | sort(conns, order=desc, limit=max)`

 

→ 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):

`#event_simpleName=NetworkConnectIP4 event_platform=Lin | cidr(RemoteAddressIP4, subnet=["10.20.30.0/24"]) | in(RemotePort, values=["22","443"]) | join(query=`

[View full post](https://1898advisories.burnsmcd.com/threat-hunt-plan-hitachi-energy-coretec-command-injection-and-kernel-privilege-escalation)

```json
{
  "@context" : "http://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "The 1898 & Co. Team"
  },
  "dateModified" : "2026-11-02T17:51:25.663Z",
  "datePublished" : "2026-11-02T17:51:25Z",
  "headline" : "Threat Hunt Plan: Hitachi Energy CoreTec — Command Injection and Kernel Privilege Escalation",
  "image" : {
    "@type" : "ImageObject",
    "height" : 60,
    "url" : "/hs/hsstatic/content_shared_assets/static-1.4092/img/default-amp-logo.png",
    "width" : 60
  },
  "mainEntityOfPage" : "https://1898advisories.burnsmcd.com/threat-hunt-plan-hitachi-energy-coretec-command-injection-and-kernel-privilege-escalation",
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "height" : 60,
      "url" : "/hs/hsstatic/content_shared_assets/static-1.4092/img/default-amp-logo.png",
      "width" : 60
    },
    "name" : "Advisories | 1898 & Co."
  }
}
```