Threat Hunt Plan: Moxa Industrial Ethernet Switch TLS Renegotiation Denial-of-Service Exposure

Version 1.0 | 2026-08-25 | Classification: TLP:CLEAR

Hunt Objective and Scope

This hunt looks for evidence that the TLS client-initiated renegotiation weakness in Moxa managed industrial Ethernet switches (CVE-2011-1473, addressed by Moxa security enhancement advisory MPSA-262810, published 19 August 2026) has been probed, abused, or is reachable from a population of hosts that should not be able to reach it. The condition allows an unauthenticated party who can open a TCP session to a TLS-protected management service to force the device to perform repeated handshakes within a single connection, consuming disproportionate CPU on constrained embedded hardware and degrading management-plane availability.

In-scope device population: Moxa EDS-510A Series switches running firmware v3.14 and earlier (fixed in v3.14.4), Moxa ICS-G7826A Series switches running firmware v5.13 and earlier (fixed in v5.13.8), and Moxa SDS Series switches — SDS-3006, SDS-3008, SDS-3010, SDS-3016, SDS-G3006, SDS-G3008, SDS-G3010 and SDS-G3016 — running firmware v3.2 and earlier (fixed in v3.3 or later). In-scope network scope: every segment in which those switches sit, the engineering and operations workstations that legitimately administer them, the jump hosts and DMZ systems that bridge into those segments, and the organization's external attack surface.

Time window: 90 days back from hunt start for network flow and endpoint telemetry, extended to 180 days where the platform retains it, because a low-and-slow renegotiation probe leaves a small enough footprint to sit below routine alerting for months. The external attack-surface leg (Hypothesis 1) is a point-in-time determination corroborated against historical index observations spanning the same window.

Out of scope: exploitation of the switches through any other vulnerability class, firmware validation of the switches themselves, and any active probing of the affected devices. Every technique in this plan is passive with respect to the target devices — no port scanning, banner grabbing, or synthetic TLS handshakes against production control-network infrastructure. Where a determination requires touching a device, it is deferred to a coordinated maintenance window under plant change control.

Success criteria: every in-scope switch is inventoried with its running firmware version; the reachable-source population for each switch management interface is enumerated and compared against the authorized administrative population; any external exposure is confirmed or excluded with two-engine corroboration; and any anomalous TLS session volume, device restart, or management-plane outage in the window is either explained or escalated.

Hypotheses and Hunt Procedures

Hypothesis 1: An external actor can reach an internet-facing instance of a Moxa managed industrial Ethernet switch management interface or an OT protocol served from the same estate, observable as an exposed service in passive internet-scan indices. Execute FIRST; its output scopes the internal hypotheses.

MITRE ATT&CK: Reconnaissance | T1595 Active Scanning — defender-side passive discovery of what an actor would enumerate; Initial Access | T1133 External Remote Services — an exposed management interface is the reachable entry point; ICS | T0883 Internet Accessible Device — an industrial switch answering the internet is a maximum-severity finding on discovery.

Collection Queries — passive external indices (STRICTLY passive; never probe target infrastructure). Author each query unscoped first to prove the filter matches the product, then scoped to your own estate. API credentials are referenced by environment-variable name only (SHODAN_API_KEY, CENSYS_API_SECRET, CENSYS_ORG_ID, NETLAS_API_KEY); a missing key is non-blocking — skip that engine and record the coverage gap.

Analysis Queries — attribution, version triage and corroboration:

Hypothesis 2: An unauthenticated actor has directed repeated TLS handshake or renegotiation traffic at the HTTPS management interface of an in-scope Moxa switch, observable as anomalous session volume and repeated ClientHello records within single TCP streams in network flow telemetry and packet capture.

MITRE ATT&CK: Impact | T1499.002 Endpoint Denial of Service: Service Exhaustion Flood — repeated handshakes exhaust the switch CPU budget; ICS | T0814 Denial of Service — the operational effect is loss of management-plane availability on a control-network device; Discovery | T1046 Network Service Discovery — the same traffic shape is produced by TLS posture scanning, which is the most common benign explanation and must be excluded first.

Collection Queries

CrowdStrike Falcon LogScale (CQL) — endpoints connecting to switch management addresses on 443. Substitute your own OT management supernet for the illustrative 10.20.0.0/16 literal:

CrowdStrike Falcon LogScale (CQL) — full management-port reach across the same supernet, to establish the authorized administrative population before judging any single source anomalous:

BPF packet capture — rolling capture of management-plane TLS at the switch uplink or the SPAN aggregation point. The strftime format in the -w filename is mandatory with -G, otherwise each rotation overwrites the previous file:

BPF packet capture — TLS handshake records only, for a low-volume rate baseline (matches TLS content type 0x16 at the first byte of the TCP payload):

BPF packet capture — connection-establishment rate toward the management interfaces:

Datadog Log Search — Windows endpoint network telemetry, the log-based parallel to the CQL collection queries above:

Datadog Log Search — containerized collector or Linux jump-host parallel, for environments where the management workstations are not Windows:

Datadog Live Process Monitoring (Infrastructure > Processes — NOT a log source and NOT log-search syntax; requires the Datadog Agent with process_config.process_collection.enabled: true):

Datadog CloudTrail — cloud-side changes that could have created or widened the exposure found in Hypothesis 1:

Data source gaps to declare explicitly before running this hypothesis: VPC flow logs are frequently not forwarded for OT-adjacent subnets, DNS query logs are rarely available for management-plane traffic that is addressed by IP, and Live Process Monitoring is commonly not enabled on locked-down engineering workstations. Where any of those hold, the source:windows and source:kubernetes log searches above are the fallback, and the coverage gap must be recorded in the Section 9 report rather than left implicit.

Windows Event IDs to collect on the administrative workstations and jump hosts:

PowerShell collection of outbound management-plane connections from the WFP log:

OT Data Collection: Claroty xDome — in Network > Communication > Communication Analysis, build a three-bucket query with Side A empty (matches every source), Communication set to Port = 443 and Protocol = HTTPS, and Side B set to Device Type = Industrial Network Equipment with Manufacturer = Moxa; set Time Frame to Past Quarter, then export. Cross-check the exported session and byte totals against an independent source — xDome is known to under-report both silently.

OT Data Collection: Claroty CTD — the on-premises platform retains continuous full PCAP, which xDome does not. Pull the packet capture for any flagged conversation through the CTD-only per-event PCAP surface and carry it into the Wireshark analysis below; a CTD deployment is the only Claroty variant that can answer a retrospective packet-level question about this hypothesis.

OT Data Collection: Dragos Platform — in the Communications Hub, filter destination asset to the Moxa switch population and flow protocol to HTTPS over a 30-day window, then pivot each candidate session to its asset record and its event-based PCAP. Use the Assets view first to scope the switch population by vendor and Purdue level, and export a time-bounded PCAP window at the Sensor for any conversation that warrants offline analysis.

OT Data Collection: Nozomi Guardian — query the links table, which is where traffic lives, and join back to nodes on each side to make the result readable:

OT Data Collection: Armis Centrix — run each query in the console with the window set in the UI time-picker (do not embed timeFrame in the query body):

OT Data Collection: Tenable One OT Exposure — work in Inventory > All Assets filtered to the Moxa switch population and export the selection, then use Risks > Findings to enumerate CVE matches against the running firmware. Programmatic collection uses the GraphQL endpoint (/graphql) — there are no REST /api/v1 query endpoints on this product — with pyTenable as the supported wrapper for repeatable sweeps; note that origins is deprecated in favour of networkAreas as of v4.7.44.

OT Data Collection: Forescout eyeInspect — use the Command Center asset inventory to enumerate the Moxa switch population and the alerts view to pull LAN CP baseline deviations against those assets, filtered by MITRE ATT&CK for ICS technique. Forward alerts and asset data to the SIEM over CEF/syslog for free-text hunting, because eyeInspect itself is filter-driven and has no analyst query language. Run ICS Patrol active enrichment only in scoped, low-cadence mode and never against safety-rated assets without engineering sign-off.

SNMP polling of the switch-facing infrastructure and the affected devices — repeat at 60-second intervals across the hunt window and diff successive values:

Treat any SNMPv1 or SNMPv2c community-string access to an in-scope OT asset as a finding in its own right — those credentials transit essentially in cleartext, and RFC 3410 recommends v3 authPriv.

YARA file-system scan of the administrative workstations and jump hosts, for staged TLS stress tooling:

Analysis Queries

CrowdStrike Falcon LogScale (CQL) — per-minute session rate against each management address; a legitimate administrator produces single-digit sessions per minute, a renegotiation or handshake flood produces orders of magnitude more:

CrowdStrike Falcon LogScale (CQL) — process attribution for the connecting endpoint. NetworkConnectIP4 does not carry ImageFileName or CommandLine, so the connection must be joined back to ProcessRollup2; the join is written in the reverse direction, with ProcessRollup2 as the streaming main query and the tightly filtered connection set as the subquery, so neither the 100k subquery row cap nor the group cap is reached:

Run that join over Last 90d or longer. A long-running monitoring daemon that started before a narrow window emits no ProcessRollup2 inside it, and a 7-day run will return zero matches even while the connections are plainly active.

Wireshark display filters — renegotiation is visible as more than one ClientHello inside a single TCP stream:

tshark CLI equivalents — count ClientHello records per TCP stream; any stream with a count above one indicates renegotiation, and a stream in the hundreds is the abuse pattern this hunt exists to find:

Note that in TLS 1.2 a renegotiation handshake after the first is encrypted, so the second and subsequent ClientHello records may appear only as encrypted handshake records rather than as parsed ClientHellos. Where that is the case, fall back to counting handshake-type records and to the byte-and-duration profile of the stream: a session carrying many small symmetric exchanges with almost no application data is the signature.

Datadog Log Analytics — the same analysis as the CQL rate query above:

Datadog Audit Trail — confirm that no monitor, integration or access-management change suppressed the visibility this hunt depends on:

Datadog Monitor definition for this hypothesis:

OT network and protocol analysis — correlate any candidate window against the industrial traffic on the same segment. Where the switch carries EtherNet/IP, Modbus or DNP3, confirm whether control traffic degraded during the same interval:

Correlate the SNMP interface-counter deltas collected above against the same intervals. A CPU-exhaustion event on the switch shows as management-interface unresponsiveness while hardware forwarding counters continue to advance normally — that divergence is the discriminator between a switch under resource pressure and a genuine link or forwarding fault.

Historian and SCADA alarm correlation — pull the alarm and event journal for the process cell served by each candidate switch across the same window, and look for communication-loss, poll-timeout, or watchdog alarms that coincide with the flagged TLS session volume. A network event that produced no process-side alarm is a lower-severity finding than one that did, and the historian is the only source that settles the question.

YARA memory scan of any endpoint surfaced by the process-attribution join above. Classic YARA 4.5 takes the PID as a positional argument — there is no -p flag for process scanning, and YARA-X (yr scan) cannot scan process memory at all:

CrowdStrike Custom IOAs can be authored to fire on the tooling command lines below, and Falcon Real Time Response can put the YARA binary and rule file on a remote host and execute the scan there, which is the practical route when the candidate endpoint is a plant-floor workstation that cannot be physically reached.

Hypothesis 3: An in-scope Moxa switch has experienced management-plane unresponsiveness, unexpected restart, or control-plane degradation consistent with CPU exhaustion, observable as SNMP trap activity, interface counter anomalies, syslog gaps and OT platform detections without a corresponding change record.

MITRE ATT&CK: ICS | T0816 Device Restart/Shutdown — an unexplained switch restart is the observable outcome of successful resource exhaustion; ICS | T0814 Denial of Service — loss of management availability on control-network infrastructure; Impact | T1499 Endpoint Denial of Service — the enterprise-side equivalent for the same behaviour.

Collection Queries

SNMP trap collection from the trap receiver for the hunt window — filter to the in-scope device address ranges and extract the four trap classes that matter here:

SNMP direct polling of the affected devices to establish uptime and detect resets:

CrowdStrike Falcon LogScale (CQL) — distinct-source concentration per management address per hour. A single management address suddenly reached by many distinct sources, or by one source at very high volume, is the shape worth pulling on:

Datadog Log Search — switch syslog forwarded through the SIEM collector:

Datadog Log Search — Windows-side view of the monitoring platform losing contact with the switch:

Windows Event IDs to collect from the network monitoring server:

PowerShell collection of unexpected-shutdown and service-failure events on the monitoring infrastructure, so a monitoring-side outage is not mistaken for a switch-side one:

OT Data Collection: Claroty xDome — pull the Alerts surface filtered to Alert Category = Threat Alert and Alert Category = OT Activity Alert, sort by ALERT UPDATED descending, and scan for detections against the Moxa asset population. There is no time-frame selector on this surface; use the API detected_time filter where a hard window is required.

OT Data Collection: Dragos Platform — triage the Notifications queue filtered to ATT&CK for ICS Impact techniques across the switch population, and check the Knowledge Pack version before concluding that an absence of detections is a capability gap rather than a stale pack.

OT Data Collection: Nozomi Guardian — alerts and node liveness for the switch population:

OT Data Collection: Armis Centrix — off-baseline behaviour and repeated authentication against the in-scope assets:

OT Data Collection: Tenable One OT Exposure — review the Events view for policy violations and intrusion-detection events against the Moxa population, and use My Saved Views to persist the filter combination across hunt iterations. Tenable's State Query would answer the device-state question directly, but it is an active query and must not be enabled against in-scope devices without staged non-production validation and written engineering sign-off.

OT Data Collection: Forescout eyeInspect — review LAN CP baseline deviations and Industrial Threat Library matches against the Moxa assets, and check whether a learning-window re-baseline coincided with any apparent detection gap.

Analysis Queries

Correlate the SNMP uptime series against the trap log and against the session-volume timeline from Hypothesis 2. The finding shape that matters is a sysUpTime reset or a management-interface outage whose start falls inside a window of elevated TLS session volume from a single source, with no matching entry in the change-management record.

Datadog Log Analytics — device restart frequency over the window, and whether it clusters:

Datadog Audit Trail — verify no monitor covering these devices was muted or deleted during the window:

Datadog Monitor definition for this hypothesis:

OT protocol analysis — confirm whether the process traffic on the affected segment degraded in the same interval, which is what turns a management-plane finding into an operational one:

Historian correlation — retrieve poll-quality and communication-status tags for the cell served by each candidate switch and overlay them on the restart timeline. Sustained bad-quality intervals aligned to a management-plane event are the operational impact statement the report needs.

YARA memory scan is not applicable to the switch itself, which runs vendor firmware with no analyst-accessible process surface. Where the monitoring server or a jump host is implicated as the traffic source, run the memory rule against its candidate processes as described under Hypothesis 2.

Hypothesis 4: An internal host — an engineering workstation, a jump host, or a contractor laptop — has run TLS posture-scanning or renegotiation stress tooling against control-network infrastructure, observable as tool execution in endpoint process telemetry correlated with connections into the OT management supernet.

MITRE ATT&CK: Discovery | T1046 Network Service Discovery — TLS posture scanning of the management plane; Execution | T1059.001 Command and Scripting Interpreter: PowerShell and T1059.004 Unix Shell — the common delivery vehicles for scripted handshake loops; Impact | T1499.002 Endpoint Denial of Service: Service Exhaustion Flood — the same tooling produces the exhaustion condition whether or not that was the operator's intent.

Collection Queries

CrowdStrike Falcon LogScale (CQL) — TLS assessment and stress tooling by binary name:

CrowdStrike Falcon LogScale (CQL) — the same activity by command-line indicator, which catches the tooling when it has been renamed or invoked through an interpreter:

Datadog Log Search — the log-based parallel for Windows administrative hosts:

Datadog Log Search — containerized scanner or CI runner parallel:

Datadog Live Process Monitoring (Infrastructure > Processes; falls back to the source:windows log search above where the Agent process collection is not enabled):

Windows Event IDs to collect on candidate hosts:

PowerShell collection of tool execution from the process-creation log:

PowerShell review of script block content for scripted handshake loops:

OT Data Collection: Claroty xDome — in Communication Analysis set Side A to Device Type = Industrial Workstation, Communication to Port = 443, and Side B to Manufacturer = Moxa over Past Month, to enumerate which engineering workstations reached the management plane at all. For tenant-legacy coverage cite Device Type IN ("Industrial Workstation","Engineering Workstation").

OT Data Collection: Dragos Platform — query the Industrial Protocols QFD and the SSH-sessions QFD for the same host population, and use the Assets view to confirm whether the source host is a sanctioned engineering workstation or an asset that has no business on that segment.

OT Data Collection: Nozomi Guardian — Arc host telemetry, where deployed, captures process execution on OT-locked engineering workstations that cannot run an IT EDR:

OT Data Collection: Armis Centrix — enumerate the workstation population reaching the management plane, then left-join against the Secure Remote Access session log where that module is licensed; any flow without a matching SRA entry is out-of-band by construction:

OT Data Collection: Tenable One OT Exposure — scope the source-host population using the Eng and OtWorkstation asset types rather than the generic Workstation type, which would miss exactly the hosts that matter here.

OT Data Collection: Forescout eyeInspect — pivot from the LAN CP alert on the workstation to the IT-side EDR record for the same host, which is the cross-domain pattern the CrowdStrike eyeExtend module exists to support.

YARA file-system scan for staged tooling on the candidate hosts:

Analysis Queries

CrowdStrike Falcon LogScale (CQL) — tie the tooling execution to a connection into the OT management supernet, which is what separates a laptop-local posture test from an action against production control infrastructure:

CrowdStrike Falcon LogScale (CQL) — scripted TLS clients invoked through PowerShell, which produce no distinctive binary name:

Datadog Log Analytics — rarity analysis over the tooling population; the rarest command lines are the ones worth reading:

Datadog Audit Trail — where the tooling was run from a Datadog-integrated CI or automation host, confirm which identity triggered it:

Datadog Monitor definition for this hypothesis:

Windows Event Log analysis — reconstruct the operator session around any hit, and establish whether the account, the host and the time align with an approved assessment window:

YARA memory scan of the implicated processes, run through Falcon Real Time Response where the host cannot be reached physically:

Threat Actor Profile

Opportunistic internet-wide scanner — low sophistication, high volume. Access path: direct TCP connection to any management interface reachable from the internet, discovered through the same passive indices used in Hypothesis 1. TTPs: mass TLS posture enumeration, version banner collection, and occasional automated exploitation of whatever the banner reveals. This is the most probable actor class to interact with an exposed Moxa management interface, and the interaction is far more likely to be enumeration than deliberate exhaustion. It matters because enumeration precedes targeting, and because the same exposure that permits enumeration permits the denial-of-service condition.

Commodity ransomware and initial-access broker — moderate sophistication. Access path: internet-exposed edge and management services, then credential reuse and lateral movement toward higher-value systems. TTPs: T1133 External Remote Services, T1190 Exploit Public-Facing Application, followed by enterprise-standard tooling. An industrial switch is not a target of value to this class in itself, but an exposed switch management interface is a strong indicator that the surrounding segmentation posture will yield something that is, and it can serve as a persistence foothold on a device that no endpoint tool watches.

OT-focused state-aligned actor — high sophistication. Access path: patient reconnaissance of the external surface, compromise of an IT-side pivot, then lateral movement to the control network. TTPs: living-off-the-land movement toward engineering workstations, enumeration of control-network infrastructure, and staging of capability against availability rather than immediate use of it. For this actor class the value of the renegotiation condition is not the outage itself but the option to create one at a chosen moment — a management-plane blackout during a concurrent physical or cyber action degrades exactly the visibility responders need. The absence of confirmed exploitation of CVE-2011-1473 in the wild does not reduce this consideration, because the technique requires no tooling development and leaves little distinctive evidence.

Insider and authorized-but-unsanctioned activity — variable sophistication, high access. Access path: legitimate credentials and legitimate network position. TTPs: running assessment tooling outside an approved window, contractor laptops brought onto the control network with a security-testing toolchain installed, and vulnerability-scanner configurations that include aggressive TLS checks pointed at OT ranges. This is the single most likely explanation for any hit that Hypothesis 4 produces, and it must be excluded through the change record before any escalation is raised.

Data Sources Required

Network — full packet capture or SPAN at the OT management aggregation point and at the IT/OT boundary; NetFlow or IPFIX from the routed boundary; firewall session and deny logs for every rule governing access to the management supernet; and the switch configuration backups needed to establish which management services are enabled on each device.

Endpoint — CrowdStrike Falcon telemetry (ProcessRollup2 and SyntheticProcessRollup2, NetworkConnectIP4, UserLogon) from every workstation and jump host with control-network reach; Windows Security and PowerShell Operational event logs (4688, 4104, 4103, 5156, 5158, 4624, 4625, 4634) with command-line auditing and script block logging enabled; Sysmon where deployed; and Datadog Agent logs and Live Process Monitoring where the environment supports it.

OT and ICS — process historian tag history and alarm journal for the cells served by the in-scope switches; SCADA and HMI event logs; the SNMP trap receiver log and interface counter polling series described in Hypothesis 2; and the OT monitoring platform in use, which will be one or more of Claroty xDome or CTD, Dragos Platform, Nozomi Guardian and Vantage, Armis Centrix, Tenable One OT Exposure, and Forescout eyeInspect. Note the platform-specific constraints that bear on this hunt: Armis Centrix forwards metadata only and cannot supply packet capture, so any packet-level question must be answered from a SPAN or TAP feed or from a capture-capable platform; xDome does not retain continuous PCAP while CTD does; and Tenable's device-state active query must not be enabled against in-scope devices without staged validation and written engineering sign-off.

Vendor and device logs — switch syslog forwarded to the SIEM, switch authentication and configuration-change logs, RADIUS or TACACS+ accounting for management-plane authentication, and the firmware inventory export that establishes which devices are in the affected version range.

External attack surface — the passive internet-scan indices queried read-only (Shodan, Censys, Netlas), the CISA Known Exploited Vulnerabilities catalog, and the organization's authoritative public IP allocation and cloud asset inventory. That last source is required: without it, attribution of an index hit to the organization cannot be made, and the exposure determination cannot be completed. Absence of a host from an index is evidence only that the index did not observe it.

Change and process records — the change-management ticket queue, the approved maintenance window schedule, the authorized administrator roster for the switch management plane, and the vulnerability-scanning schedule and target scope. These are what convert a technical observation into a disposition, and a hunt that cannot reach them will produce findings it cannot close.

Detection Signatures

SIGMA rule 1 — TLS renegotiation and posture-stress tooling execution (process_creation):

SIGMA rule 2 — repeated management-plane TLS connections toward OT network equipment (network_connection):

SIGMA rule 3 — scripted TLS client handshake loop in PowerShell (ps_script):

SIGMA rule 4 — unexpected industrial switch restart reported to the collector (file_event on the trap receiver spool, as a portable proxy for syslog ingestion):

Snort/Suricata rule 1 — excessive TLS ClientHello records toward the OT management range. The detection_filter fires only after the threshold is crossed within the window, which is what separates renegotiation abuse from ordinary administration:

Snort/Suricata rule 2 — TLS handshake initiated by a client that advertises no RFC 5746 renegotiation_info extension, toward the same range. Legacy renegotiation support is the precondition for the condition this hunt targets, and a client deliberately negotiating without the extension is worth surfacing on its own:

Snort/Suricata rule 3 — sustained connection establishment toward the switch management plane, a lower-fidelity but protocol-independent backstop that fires even when the TLS payload is not parseable:

YARA rule 1 — file and disk artifacts. This rule targets the staging phase: TLS stress and posture tooling written to disk on a host that has control-network reach. The condition requires either a strong single-tool indicator or two weaker generic indicators, because strings like "s_client" and "renegotiation" appear legitimately in OpenSSL documentation, certificate management scripts and vendor support bundles. The file-size ceiling excludes large vendor archives and documentation sets, which are the dominant false-positive source when the rule is run recursively across a user profile.

YARA rule 2 — process memory artifacts. This rule targets the execution phase rather than the staging phase, and exists because the tooling is frequently run from a removable volume, a network share, or an interpreter that leaves nothing durable on local disk. The condition is deliberately stricter than the disk rule: it requires a TLS-client API indicator together with either an explicit renegotiation string or a loop-construct indicator, because a bare "s_client" string is present in the memory of any process that has merely loaded the OpenSSL library. The private string block holds the industrial-target indicators so a memory hit that also names an in-scope device family is separable in triage.

Indicators of Compromise

Network indicators — more than one TLS ClientHello record inside a single TCP stream toward a switch management address, and any stream carrying tens or hundreds of them; sustained TCP connection establishment toward port 443 on the management supernet from a source that is not on the authorized administrator roster; TLS sessions to the management plane whose byte profile is dominated by handshake exchange with almost no application data; connections to switch management ports (22, 23, 80, 443, 161) originating from a guest network, a contractor VLAN, or any external network location; and management-plane traffic from a host that appears in no change record for the interval.

Host indicators — execution of openssl with an s_client or legacy_renegotiation argument, nmap with ssl-enum-ciphers, sslyze, sslscan, testssl.sh, or thc-ssl-dos on any host with control-network reach; PowerShell script block content constructing an SslStream and calling AuthenticateAsClient inside a loop; TLS assessment tooling present in a user profile, a temporary directory, or on removable media on an engineering workstation; and a YARA hit on either rule defined in Section 5.

OT and operational indicators — a sysUpTime reset on an in-scope switch with no corresponding change record; coldStart or warmStart traps from the switch population outside an approved maintenance window; management-interface unresponsiveness while hardware forwarding counters continue to advance normally, which is the discriminating signature of CPU exhaustion as against a link or forwarding fault; authenticationFailure traps clustering on a single device; SCADA poll-timeout, communication-loss or bad-quality alarms in a cell whose serving switch showed elevated management-plane session volume in the same interval; and OT monitoring platform detections mapping to ATT&CK for ICS T0814 or T0816 against the switch population.

External exposure indicators — any Moxa management interface, any switch web administration surface, or any OT protocol port answering from an IP address attributable to the organization, corroborated in at least two passive indices; a version banner in the affected firmware ranges; continuous observation of the exposure spanning the 19 August 2026 advisory publication date, which means the device should be treated as presumptively enumerated; and a CISA KEV match against any other service on the same host, which reprioritizes the finding upward independent of this advisory.

False Positive Baseline

1. Network management platform polling. NMS products poll switch web and SNMP interfaces on a fixed schedule, producing a steady, highly periodic session count from a small number of known source addresses. Suppress by source host and confirm the cadence is regular; an abrupt rate change from an NMS source is itself worth reading, so suppress the baseline rate rather than the source outright.

2. Scheduled vulnerability scanning. Authorized scanners routinely include aggressive TLS cipher and renegotiation checks, and a scan window will produce exactly the ClientHello concentration this hunt looks for. Correlate every candidate window against the scanning schedule and the scanner source addresses before escalating. Note that a scanner configuration that includes OT ranges is a finding of its own if OT was meant to be excluded from the scan scope.

3. Configuration backup automation. Many environments retrieve switch running configurations over HTTPS on a nightly or weekly cycle. These sessions are short, periodic, and originate from a single automation host; suppress by source and schedule, and verify the retrieved configuration size is stable — a change in that profile can indicate the automation account being used for something else.

4. Browser-based administration. An engineer working in the switch web interface generates a burst of TLS sessions as the UI loads assets and polls status, which can look like a rate anomaly at minute granularity. Suppress by correlating the source host against the authorized administrator roster and the session against an interactive logon on the same host at the same time.

5. Certificate lifecycle tooling. PKI inventory and certificate expiry monitoring scripts connect to every TLS endpoint in an estate on a schedule and are a routine source of s_client and SslStream indicators. Suppress by identifying the tooling host and the recurring cadence; verify that the scope of the tooling was meant to include OT ranges.

6. Site power events and planned maintenance. A power interruption or a scheduled firmware upgrade produces coldStart traps across multiple devices simultaneously. The discriminator is simultaneity and breadth: a genuine resource-exhaustion restart affects one device, while a power event affects everything on the same feed. Check the maintenance calendar and the facility power record before treating a restart cluster as a security finding.

7. External attack-surface misattribution. Shared hosting, CDN fronting, cloud provider address reassignment, and a provider-announced ASN all produce index hits that are not the organization's asset. A hit that cannot be attributed with two independent ownership signals is inconclusive, not a finding — and equally, it must not be recorded as a clean negative. Internet-facing honeypots are heavily deployed against OT protocols specifically; down-weight any hit carrying a honeypot classification or a Conpot fingerprint and never report it as client exposure.

Escalation Criteria

1. Any in-scope Moxa switch management interface is confirmed reachable from the internet in two independent passive indices, with an ownership attribution supported by at least two signals. Engage incident response and initiate exposure removal in parallel; do not wait for evidence of exploitation.

2. Confirmed external exposure whose observation window spans the 19 August 2026 advisory publication date. Treat the device as presumptively enumerated and expand the internal hunt on that device from sampling to an exhaustive pass across the full retention window.

3. A CISA KEV-listed service is found on the same host or the same public address as an exposed switch management interface. Escalate on the KEV entry immediately; it carries a presumptive ransomware and actor-associated initial-access risk independent of this advisory.

4. More than one TLS ClientHello record is observed inside a single TCP stream toward a switch management address, from a source outside the authorized administrator roster, and the activity does not correlate to a scheduled scan or an approved change.

5. Management-plane session volume against a single switch exceeds the established baseline by an order of magnitude for a sustained interval, from a single source, with no change record covering the window.

6. A sysUpTime reset, coldStart trap, or warmStart trap is recorded on an in-scope switch outside an approved maintenance window, and it is not explained by a site power event affecting other devices on the same feed.

7. Management-interface unresponsiveness is observed on an in-scope switch while its hardware forwarding counters continue to advance normally, in a window that also carries elevated management-plane TLS session volume.

8. SCADA or historian records show poll timeouts, communication-loss alarms, or sustained bad-quality intervals in a cell whose serving switch appears in any of the criteria above. This converts a management-plane finding into an operational impact finding and raises the response tier accordingly.

9. Any YARA hit on TLS_Renegotiation_DoS_Tooling_Disk against a file staged on an engineering workstation, a jump host, or any system with control-network reach, where the file is not accounted for by an approved assessment engagement.

10. Any YARA hit on TLS_Renegotiation_DoS_Memory_Artifacts against a live process on a host with control-network reach. A memory hit indicates active execution rather than staging and warrants immediate host containment consideration.

11. TLS renegotiation or posture-stress tooling execution correlates in time with a connection into the OT management supernet from the same host, and the operator, the host, or the window is not covered by an approved change record.

12. Any inbound connection to a switch management port from an external network location, a guest network, or a contractor VLAN, regardless of volume or apparent intent.

13. Discovery that an in-scope switch is reachable from a broad internal population — an entire user VLAN, the general enterprise network, or any segment not intended to carry management traffic. This is a segmentation finding that stands independently of whether the renegotiation condition was ever exercised.

Hunt Completion Criteria and Reporting

The hunt is complete when every in-scope Moxa switch has been inventoried with its running firmware version and classified as in-range or fixed; when the reachable-source population for each management interface has been enumerated from network telemetry and compared against the authorized administrator roster; when the external exposure determination has been made with two-engine corroboration and per-hit attribution, or the coverage gap has been stated where an engine could not be queried; when every anomalous TLS session concentration, device restart, and management-plane outage inside the window has been either explained against the change record or escalated; and when every YARA and tooling hit has been dispositioned against the approved-assessment record.

The report must contain: the full in-scope device inventory with firmware versions and remediation status against the fixed releases (v3.14.4 for EDS-510A, v5.13.8 for ICS-G7826A, v3.3 or later for SDS Series); the enumerated reachable-source population per management interface, with the delta against the authorized roster called out explicitly; the external attack-surface sweep result stated as coverage as well as findings — which engines were queried, which were skipped for a missing credential, what was searched and what could therefore not be concluded — with per-hit provenance recorded as engine, query, index scan timestamp and the attribution signals used; every anomaly examined with its disposition and the evidence behind it; the queries actually run per platform, with their time windows, so a subsequent iteration can reproduce or extend the pass; and an explicit statement of the data-source gaps encountered, because a hunt that ran without VPC flow logs, without command-line auditing, or without Live Process Monitoring has a materially different negative than one that ran with them.

The report must also carry the segmentation and compliance findings this hunt produces as a by-product, independent of whether any malicious activity was found: which management interfaces are reachable from populations that should not reach them, which devices remain on affected firmware after the evaluation window, and the documented decision for each device that will not be updated immediately. Under NERC CIP-007-6 R2 that documented evaluation — applied, mitigated with a dated plan, or assessed as not applicable within thirty-five days of patch availability — is itself the compliance artifact, and it is as important to the audit outcome as the update.

Recommend making the external attack-surface sweep a recurring control rather than a one-time pass. Exposure is created by ordinary change — a firewall rule added under time pressure, a cloud route modified, a device relocated — and a point-in-time clean result decays from the day it is taken. Recommend the same for the management-plane reachable-source enumeration, which is the internal counterpart and decays for the same reasons.

Advisory IoC Reference