---
title: "Threat Hunt Plan: eMudhra/emSign Compromised CA Signing Keys — OT/ICS TLS Impersonation and Code-Signing Trust Abuse"
description: This hunt looks for the abuse of eight eMudhra/emSign intermediate Certificate Authority (CA) certificates whose private keys were disclosed as recoverable from their public certificates
---

[Skip to content](https://1898advisories.burnsmcd.com/threat-hunt-plan-emudhra/emsign-compromised-ca-signing-keys-ot/ics-tls-impersonation-and-code-signing-trust-abuse#main-content)

![1898-logo-grey-R-1](https://1898advisories.burnsmcd.com/hs-fs/hubfs/1898-logo-grey-R-1.webp?width=188&height=100&name=1898-logo-grey-R-1.webp)

- [Cyberthreat](https://1898advisories.burnsmcd.com/tag/cyberthreat)
- [Threat Hunt](https://1898advisories.burnsmcd.com/tag/threat-hunt)
- [View All](https://1898advisories.burnsmcd.com/)

Open main navigation

Close main navigation

- [Cyberthreat](https://1898advisories.burnsmcd.com/tag/cyberthreat)
- [Threat Hunt](https://1898advisories.burnsmcd.com/tag/threat-hunt)
- [View All](https://1898advisories.burnsmcd.com/)
- [Contact us](https://1898andco.burnsmcd.com/contact-us)

[Contact us](https://1898andco.burnsmcd.com/contact-us)

 October 23, 2026

# Threat Hunt Plan: eMudhra/emSign Compromised CA Signing Keys — OT/ICS TLS Impersonation and Code-Signing Trust Abuse

![Picture of The 1898 & Co. Team](https://1898advisories.burnsmcd.com/hs-fs/hubfs/1898%20Cyberthreat%20Advisory%20Blog%20Assets/1898-Co-Ampersand.png?width=50&name=1898-Co-Ampersand.png) [The 1898 & Co. Team](https://1898advisories.burnsmcd.com/author/1898-co-team)

Date: 2026-10-23 | Revision: 1.0

#### Hunt Objective and Scope

This hunt looks for the abuse of eight eMudhra/emSign intermediate Certificate Authority (CA) certificates whose private keys were disclosed as recoverable from their public certificates (CERT-In advisory CIAD-2026-0050, 2026-10-21). The affected set is six TLS issuing intermediates in the EM DV/OV/EV TLS CA-G3B and -G3C families, chaining to the emSign ECC Root CA-G3, and two code-signing issuing intermediates, EM OV CS CA-G3B and EM OV CS CA-G3C. Because the matching private key can be reconstructed from any copy of the certificate, an adversary can mint a TLS server certificate or a code-signing signature that chains to a root many systems still trust. The hunt is scoped to operational technology (OT) and industrial control sys​tem (ICS) environments and the engineering and management assets that touch them, because the automatic browser and operating-system revocation does not reach embedded trust stores, long-lived controllers, or air-gapped segments.

Four questions drive the hunt: (1) is any internet-facing asset we own still serving a TLS chain that routes through a compromised emSign CA; (2) has any OT or management TLS session presented a server certificate chaining to a compromised emSign intermediate (adversary-in-the-middle); (3) has any software or firmware signed under the EM OV CS CA-G3B/-G3C code-signing intermediates been installed or executed on an OT or engineering endpoint; and (4) which OT assets still trust the revoked emSign roots or fail open on revocation, and therefore remain exposed to a forged certificate.

Time window: the weak keys were created in a key-generation ceremony on 2025-04-30 and entered browser trust lists in mid-2025, so the exposure window begins 2025-04-30 and runs to the present. Event-based legs (network connections, PE writes, registry writes) are bounded below by the measured data floor; state-based legs (installed binaries present now, trust-store contents now, current internet exposure) are re-queried as current state and are not bounded by the floor.

Data-floor pre-flight (run before any event-based leg; a time picker is not retention). Record the oldest retained event per family as a DATE; the window before that date is Non-Conclusive for event-based clauses:

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

 

CQL CIDR scoping below uses the illustrative OT-zone range 10.10.0.0/16 — replace it with the environment's actual OT/control subnet(s) before running; EASM blocks keep bracketed placeholders, which the reader substitutes at run time.

External attack-surface (EASM) hypothesis is INCLUDED (Hypothesis 1): the affected certificates protect internet-reachable TLS services, so the threat is plausibly internet-reachable. It executes FIRST and scopes the internal hypotheses.

#### Hypotheses and Hunt Procedures

**Hypothesis 1:** an external actor can reach an internet-facing asset we own that serves a TLS chain routing through a compromised emSign CA (emSign ECC Root CA-G3 or an EM \* TLS CA-G3B/-G3C intermediate), 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 · ICS | T0883 Internet Accessible Device — an internet-reachable OT-adjacent service whose trust chain is forgeable.

**Collection Queries** — passive external indices (STRICTLY passive; never probe target infrastructure). API keys are referenced by env-var name only (SHODAN\_API\_KEY, CENSYS\_API\_SECRET, CENSYS\_ORG\_ID, NETLAS\_API\_KEY) and never inlined. Author unscoped first (proves the filter matches the certificate population), then scoped.

`Shodan: ssl.cert.subject.CN:"emSign ECC Root CA-G3"`

 

`ssl.cert.subject.CN:"EM OV CS CA-G3B"`

 

`ssl.cert.issuer.CN:"emSign" // scope with: net:<your_public_CIDR> org:"<Your Org Name>" asn:AS<your_ASN>`

 

`Censys (CenQL — host.services.* form; never the legacy services.* form): host.services.cert.parsed.subject.common_name: "emSign ECC Root CA-G3"`

 

`host.services: (port = "443" and cert.parsed.subject.common_name: "EM OV TLS CA-G3B") // scope with: and (host.autonomous_system.asn = <your_ASN> or host.ip: "<your_public_CIDR>")`

 

`Netlas: certificate.subject.common_name:"emSign ECC Root CA-G3"`

 

`host:<your_public_CIDR> AND port:(443 OR 8443 OR 4840 OR 8883)`

 

→ Expected Positive shape: a host inside your owned ranges whose served TLS chain includes a certificate whose subject (or issuer) common name is one of the compromised emSign roots/intermediates, corroborated in at least two engines.

**Note** — CISA KEV cross-reference is NOT applicable here: this is a CA key-generation failure with no CVE, so there is no KEV entry to match; attribution relies on your authoritative public-IP and cloud asset inventory.

**Analysis Queries:**

`- Attribute each hit with >=2 independent ownership signals (PTR, ASN, cert CN/SAN, WHOIS/RDAP, your own cloud inventory) before reporting; an unattributable hit is Non-Conclusive, not a finding. - Corroborate in >=2 of Shodan / Censys / Netlas before escalating; absence from one index is only evidence that index did not observe the host. - Historical pivot: establish whether the exposure spans 2025-04-30 to present; continuous exposure across the window means the chain was presumptively enumerable the whole time. - Pivot every confirmed-owned in-range host into Hypotheses 2 and 4 as a priority target and hunt it exhaustively; internet reachability of a service whose trust chain is forgeable is a finding in its own right under IEC 62443 and NERC CIP, independent of confirmed exploitation.`

 

**Control** — filter validity (unscoped twin): run each query WITHOUT the net:/org:/asn: scoping first; a non-zero worldwide result proves the certificate-CN filter matches real certificates, so a later zero inside your ranges is a true absence and not a broken filter. A scoped zero with an unrun or zero unscoped control is Non-Conclusive.

**Verdict criteria:** Positive — \>=2 engines show an owned, in-range host serving a chain through a compromised emSign CA; Negative — no owned in-range host across all three engines AND the unscoped control returned a population (filter proven); Non-Conclusive — single-engine-only, honeypot-suspect, or unattributable hits; missing authoritative public-IP + cloud inventory prevents determining ownership.

**Hypothesis 2:** an adversary presents a forged TLS server certificate chaining to a compromised emSign intermediate to impersonate an OT endpoint or management service (HMI/historian web UI, OPC UA server, MQTT broker, remote-access gateway) and intercept or manipulate traffic, observable as an unexpected certificate issuer/subject on OT TLS sessions in packet capture and OT monitoring.

**MITRE ATT&CK:** Collection / Credential Access | T1557 Adversary-in-the-Middle — a forged server certificate lets the adversary terminate and relay a trusted session · ICS | T0830 Adversary-in-the-Middle — the same technique against a control-protocol session wrapped in TLS.

**Collection Queries:**

**CrowdStrike Falcon LogScale** (CQL) — scope OT-segment TLS sessions for inspection (CQL has no certificate-issuer field; this leg identifies which hosts/flows to inspect by PCAP and OT monitoring, it does not itself read the certificate):

`#event_simpleName=/^(NetworkConnectIP4|NetworkReceiveAcceptIP4)$/ event_platform=Win | in(RemotePort, values=["443","8443","4840","8883"]) | cidr(RemoteAddressIP4, subnet=["10.10.0.0/16"]) | groupBy([aid, LocalAddressIP4, RemoteAddressIP4, RemotePort, ContextProcessId], function=count(as=flows), limit=max)`

 

→ Expected Positive shape: an OT-segment host with a TLS session to or from an address that is not the known, legitimate endpoint for that service — the candidate list to inspect at the certificate level. Pivot each (aid, ContextProcessId) to /ProcessRollup2/ (TargetProcessId) over the longest retained window for ImageFileName, since brokers/servers are long-lived.

**tcpdump** — VLAN-aware TLS capture on the OT span port (every primitive repeated in both branches; TLS anchored on record content-type 0x16 plus version byte 0x03, not on port alone):

`tcp​dump -i <mon_if>​ -s 0 -G 3600 -C 100 -w /captures/ot_tls_%Y%m%d_%H%M%S.pcap '((tcp port 443 or tcp port 8443 or tcp port 4840 or tcp port 8883) and (tcp[((tcp[12]&0xf0)>>2)]=0x16) and (tcp[((tcp[12]&0xf0)>>2)+1]=0x03)) or (vlan and ((tcp port 443 or tcp port 8443 or tcp port 4840 or tcp port 8883) and (tcp[((tcp[12]&0xf0)>>2)]=0x16) and (tcp[((tcp[12]&0xf0)>>2)+1]=0x03)))'`

 

**Datadog** — Windows TLS/Schannel scoping where forwarded (certificate issuer is not in standard logs; name the gap and fall back to PCAP):

`source:windows (@evt.name:Schannel OR "schannel") @network.destination.port:(443 OR 8443 OR 4840 OR 8883) // time range: 2025-04-30T00:00Z to current; Analytics: Table view, group by @network.destination.ip; gap: certificate issuer is not logged — this scopes hosts for PCAP inspection only`

 

**Windows Event Logs** — the authentic endpoint certificate-chain telemetry on Windows HMIs/EWS is the CAPI2 operational log (chain-build events carry the issuer):

`Get-WinEvent -FilterHashtable @{ LogName='Microsoft-Windows-CAPI2/Operational'; Id=11,90; StartTime=(Get-Date '2025-04-30') } -EA SilentlyContinue | Where-Object { $_.Message -match 'emSign|EM O?V CS CA|EM [DOE]V TLS CA' } | Select-Object TimeCreated,Id,Message | Export-Csv C:\Temp\capi2_emsign.csv -NoTypeInformation // also System log Schannel EID 36880 (TLS handshake) / 36874 for protocol negotiation on the same hosts`

 

**OT Data Collection: Claroty xDome** — Network \> Communication \> Communication Analysis: Side A OT hosts, Communication Protocol IN (HTTPS, OPC UA, MQTT), Time Frame: Custom range (the surface is capped at ~one month even from an absolute range, so state the month actually obtained; for a named-asset zero lead with the per-device communication map, which is not capped at ~3 months); row-click a suspect pair to export per-alert PCAP (Communication Analysis has no certificate attribute; the certificate determination is the PCAP).

**OT Data Collection: Dragos Platform** — Communications Hub: protocol IN \[HTTPS, OPC UA, MQTT\] across the OT zones over the window; pivot each suspect session to Export PCAP for window from SiteStore and run it offline for JA3/JA4 + certificate decode.

**OT Data Collection: Nozomi Guardian** — Link view: filter TLS sessions for the OT subnets; open Alert detail for any related fire and export the attached PCAP where retention is configured.

**OT Data Collection: Tenable OT** — Network \> Packet Captures (header bar shows the oldest capture retained = the measured floor); pull captures over the window for the OT segment; per-event PCAPs download from Events.

**OT Data Collection: Forescout eyeInspect** — the SSL-client list is keyed on JA3 hash; pull Alerts filtered to the OT protocol and window, group by src\_ip, retrieve each alert\_id PCAP where sensor capture is enabled.

**OT Data Collection: Armis Centrix** — enumerate the TLS sessions touching OT assets:

`in:ipConnections protocol:TLS serverPort:443,8443,4840,8883 networkLocation:Internal`

 

**Analysis Queries:**

**Wireshark / tshark** — extract certificate subject/issuer from served chains and match the compromised CAs (read the negotiated version off the ServerHello; the TLS 1.3 certificate is encrypted, so this recovers certificates for TLS 1.2 and below, or TLS 1.3 only with a key-log):

`tsh​ark -r <pcap>​ -Y 'tls.handshake.type == 11' -T fields -e ip.src -e ip.dst -e x509sat.printableString -e x509sat.uTF8String | gr​ep -iE 'emSign|EM (DV|OV|EV) (TLS|CS) CA'`

 

`tsh​ark -r <pcap>​ -Y 'tls.handshake.extensions_supported_version != 0x0304 and tls.handshake.type == 11' -T fields -e ip.dst -e tls.handshake.extensions_server_name`

 

→ Expected Positive shape: a handshake (type 11) from an OT endpoint whose certificate subject or issuer printable/UTF-8 string contains an emSign root or an EM \* CA intermediate, where that endpoint is not the legitimate issuer for the service.

**CrowdStrike Falcon LogScale** (CQL) — rarity of new TLS peers for OT hosts (a first-seen peer in the window is the pivot target):

`#event_simpleName=/^NetworkConnectIP4$/ event_platform=Win | in(RemotePort, values=["443","8443","4840","8883"]) | cidr(LocalAddressIP4, subnet=["10.10.0.0/16"]) | groupBy([RemoteAddressIP4], function=[count(as=hits), min(@timestamp, as=firstSeen), max(@timestamp, as=lastSeen)], limit=max) | sort(firstSeen, order=desc, limit=200)`

 

**Datadog** — timeseries of OT TLS destinations to spot a new relay endpoint:

`source:windows @network.destination.port:(443 OR 8443 OR 4840 OR 8883) @network.destination.ip:* // time range: 2025-04-30T00:00Z to current; Analytics: Timeseries view, group by @network.destination.ip`

 

**Datadog Monitor:**

`Type: Log Alert Query: source:windows @evt.name:Schannel "emSign" Evaluation window: last 15 minutes Alert condition: count > 0 Message: "ALERT: Schannel chain referencing emSign CA observed on an OT/EWS host — investigate for forged TLS @soc-oncall" Prerequisites: Windows Schannel/CAPI2 event forwarding to Datadog enabled on OT/EWS hosts`

 

OT network and protocol analysis: in xDome/Dragos/Nozomi, compare each OT TLS pair against the learned communication baseline; a new TLS peer for a controller or HMI, or a certificate issuer that differs from the asset's historical issuer, is the deviation to escalate. In Forescout, install the confirmed malicious JA3 hash to the SSL-client blacklist so recurrence alerts natively.

**Control** — event-family and field presence (same family, window, scope): prove the collection is live before trusting a zero —

`#event_simpleName=/^(NetworkConnectIP4|NetworkReceiveAcceptIP4)$/ event_platform=Win | cidr(RemoteAddressIP4, subnet=["10.10.0.0/16"]) | head(1)`

 

`#event_simpleName=/^NetworkConnectIP4$/ | RemotePort = /./ | count(as=withPort)`

 

Capture-depth control: confirm the PCAP actually contains TLS handshakes — tshark -r \<pcap\> -Y 'tls.handshake.type == 11' | wc -l must be non-zero, or an empty issuer result is Non-Conclusive, not Negative.

**Verdict criteria:** Positive — a TLS session to/from an OT asset presents a server certificate whose chain includes a compromised emSign CA and the endpoint is not the legitimate issuer for that service; Negative — all inspected OT TLS sessions present expected issuers AND the capture-depth control proves handshakes were observed AND CAPI2 chain-build logging was enabled; Non-Conclusive — TLS 1.3 certificates encrypted with no key-log, no PCAP retention on the segment, or CAPI2 logging disabled; missing certificate visibility prevents determining the issuer.

**Hypothesis 3:** software or firmware signed under the compromised eMudhra code-signing intermediates (EM OV CS CA-G3B or EM OV CS CA-G3C) was installed or executed on an OT or engineering endpoint, observable as a signed binary whose signer chain includes one of those intermediates.

**MITRE ATT&CK:** Defense Evasion | T1553.002 Subvert Trust Controls: Code Signing — a forged signature makes a malicious binary appear to come from a trusted publisher · Initial Access | T1195.002 Compromise Software Supply Chain · ICS | T0862 Supply Chain Compromise.

**Collection Queries:**

**CrowdStrike Falcon LogScale** (CQL) — enumerate newly written executables on OT/engineering hosts (scope the search to the OT/EWS host group in the sensor picker; CQL has no Authenticode-issuer field, so this list feeds signature inspection below):

`#event_simpleName=/^(PeFileWritten|NewExecutableWritten)$/ event_platform=Win | TargetFileName=/\.(exe|dll|sys|cab|msi)$/i | groupBy([aid, TargetFileName], function=[count(as=writes), min(@timestamp, as=firstWritten)], limit=max) | sort(firstWritten, order=desc, limit=500)`

 

→ Expected Positive shape: a newly written installer/driver/firmware package on an engineering workstation whose Authenticode signer (checked below) chains to EM OV CS CA-G3B/-G3C.

**YARA file-system scan** (rule eMudhra\_Compromised\_CA\_Cert\_OnDisk; matches the compromised CA common names embedded in a certificate file or a signed PE):

`ya​ra -r rules/emudhra_compromised_ca.yar "C:\Program Files" "C:\Program Files (x86)" "D:\OT_Installers" >​>​ C:\Temp\emudhra_hits.txt`

 

**Windows Event Logs / PowerShell** — dump Authenticode signer chains and keep only the emSign-chained ones:

`Get-ChildItem -Path 'C:\Program Files','C:\Program Files (x86)','D:\OT_Installers' -Recurse -Include *.exe,*.dll,*.sys,*.msi -EA SilentlyContinue | ForEach-Object { $s = Get-AuthenticodeSignature $_.FullName if ($s.SignerCertificate -and ($s.SignerCertificate.IssuerName.Name -match 'emSign|EM O?V CS CA')) { [pscustomobject]@{ Path=$_.FullName; Issuer=$s.SignerCertificate.IssuerName.Name; Status=$s.Status; Thumbprint=$s.SignerCertificate.Thumbprint } } } | Export-Csv C:\Temp\emudhra_signed_binaries.csv -NoTypeInformation // also collect service installs and script execution that may carry a signed payload: Get-WinEvent -FilterHashtable @{ LogName='System'; Id=7045; StartTime=(Get-Date '2025-04-30') } -EA SilentlyContinue | Select-Object TimeCreated,Message`

 

**Datadog** — installer/signing-tool execution on Windows OT/EWS hosts:

`source:windows ("signtool.exe" OR "certutil.exe" OR "msiexec.exe") @evt.name:ProcessCreate // time range: 2025-04-30T00:00Z to current; Analytics: Table view, group by host; Live Process fallback: command:msiexec user:*`

 

**OT Data Collection: Tenable OT** — Events: filter Event Category = Configuration Events, event types Change in state and Change in firmware version across the window; correlate each against the change record.

**OT Data Collection: Forescout eyeInspect** — export the host changelog for the controller population and escalate any firmware\_version or os\_version transition with no corresponding maintenance work order (old\_value/new\_value/username give before/after and actor).

**OT Data Collection: Dragos Platform** — Assets: read each controller's firmware state and pivot to the Communications Hub for the download session that delivered it; open a Case on any firmware change with no work order.

**OT Data Collection: Nozomi Guardian** — enumerate node\_firmware\_version changes and correlate with OT Activity program-download events over the window.

**OT Data Collection: Claroty xDome** — Alerts & Threats \> OT Activity: filter program-download / firmware-update events outside approved maintenance windows; correlate each asset\_id to its communication map.

**OT Data Collection: Armis Centrix** — surface firmware/software change activity on OT assets:

`in:activity type:"Software Change" riskLevel:High,Medium`

 

**Analysis Queries:**

**CrowdStrike Falcon LogScale** (CQL) — rarity of newly installed applications across the fleet (a one-off install on a single EWS is the pivot target):

`#event_simpleName=/^InstalledApplication$/ event_platform=Win | groupBy([ApplicationName], function=[count(as=installs), count(aid, as=hosts, distinct=true)], limit=max) | sort(hosts, order=asc, limit=200)`

 

**YARA memory scan** (rule eMudhra\_Compromised\_Signer\_InMemory; a loaded signed module whose embedded certificate chain references the compromised code-signing CAs). SeDebugPrivilege is required; CrowdStrike Falcon RTR can execute this remotely on OT hosts under change control:

`ya​ra rules/emudhra_compromised_ca.yar <pid>​`

 

Out-of-band integrity analysis: for any binary or firmware whose signer chains to EM OV CS CA-G3B/-G3C, compare its hash against the vendor-published hash delivered over an independent channel; do not treat a valid eMudhra-chained signature as evidence of authenticity until the vendor confirms re-signing under a clean hierarchy.

**Control** — event-family and field presence: prove the write telemetry is live before trusting a zero —

`#event_simpleName=/^(PeFileWritten|NewExecutableWritten)$/ event_platform=Win | head(1)`

 

`#event_simpleName=/^PeFileWritten$/ | TargetFileName = /./ | count(as=withName)`

 

YARA-scan control: run the rule against a directory known to contain a legitimate non-emSign-signed binary and (if available) a captured emSign-signed sample, to confirm the rules compile and the scanner reaches the files; a clean scan from a path the scanner could not read is Non-Conclusive, not Negative.

**Verdict criteria:** Positive — a binary or firmware image on an OT/engineering asset carries an Authenticode (or embedded-certificate) signer chaining to EM OV CS CA-G3B/-G3C and has no authorized change record; Negative — no such signer found across the enumerated hosts AND the PeFileWritten family/field controls are non-zero AND the YARA-scan control proves the rules reached the files; Non-Conclusive — signature inspection could not run on embedded/air-gapped devices, or the scan path was unreadable; missing signer visibility prevents determining provenance.

**Hypothesis 4:** OT endpoints and embedded devices continue to trust the revoked emSign roots (emSign ECC Root CA-G3 / emSign Root TLS CA-G3) or fail open on revocation, leaving them exposed to a forged certificate, observable as the affected roots present in a device/host trust store and revocation checking disabled. This is a state-based posture leg: a negative is a coverage/posture result, never proof that no attack occurred.

**MITRE ATT&CK:** Defense Evasion | T1553.004 Subvert Trust Controls: Install Root Certificate — stale trust in a revoked root is the condition this technique abuses; a device that keeps trusting emSign accepts a forged chain without warning.

**Collection Queries:**

**Windows PowerShell** — enumerate machine trust stores for the affected roots and read the revocation policy on OT/EWS hosts:

`Get-ChildItem -Path Cert:\LocalMachine\Root, Cert:\LocalMachine\CA -Recurse | Where-Object { $_.Subject -match 'emSign|EM O?V CS CA|EM [DOE]V TLS CA' } | Select-Object Subject, Thumbprint, NotBefore, NotAfter, PSParentPath | Export-Csv C:\Temp\emsign_truststore.csv -NoTypeInformation // revocation posture (fail-open is common in OT): read the per-machine CertificateRevocation state Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' -Name CertificateRevocation -EA SilentlyContinue`

 

**CrowdStrike Falcon LogScale** (CQL) — certificate-store registry writes (a long-lived service writer returns 0 via ProcessRollup2; use SyntheticProcessRollup2 as the attribution fallback):

`#event_simpleName=/^RegGenericValueUpdate$/ event_platform=Win | RegObjectName = /\\SystemCertificates\\(Root|CA)\\Certificates\\/i | groupBy([aid, RegObjectName], function=[count(as=writes), max(@timestamp, as=lastWrite)], limit=max)`

 

Linux OT hosts (historians, protocol gateways, edge agents) — check the CA bundle and package currency:

`dpkg -l ca-certificates 2>/dev/null; rpm -q ca-certificates 2>/dev/null`

 

`gr​ep -rilE 'emSign|EM (DV|OV|EV) (TLS|CS) CA' /etc/ssl/certs /etc/pki/tls/certs 2>​/dev/null`

 

**OT Data Collection: Tenable OT** — Inventory \> All Assets: export firmware for the controller/HMI population; devices on a baked-in vendor trust bundle that cannot be remotely updated are the assets that will keep trusting emSign until a vendor firmware release.

**OT Data Collection: Forescout eyeInspect** — Command Center \> Asset Inventory: filter by firmware\_version and main\_role to list controllers whose trust store is not remotely enumerable; carry them as Non-Conclusive pending vendor confirmation.

**OT Data Collection: Dragos Platform** — Assets: read firmware per controller and flag any asset whose vendor has not published a trust-bundle or firmware update addressing the emSign roots.

**OT Data Collection: Nozomi Guardian** — enumerate node\_firmware\_version and node\_vendor for the OT estate to seed vendor-engagement tracking.

**OT Data Collection: Claroty xDome** — Devices \> All Devices \> Advanced Filters: Category = OT with sw\_fw\_version exported, to map which device families are on firmware that embeds the affected roots.

**Analysis Queries:**

Build the exposure ledger: join the trust-store/firmware inventory to the Hypothesis-1 internet-exposure result and rank each asset by (internet-facing) x (trusts a revoked emSign root) x (OT-critical / safety function). Go-based edge agents must be rebuilt by their vendor (Go 1.27.3 or 1.26.10) and cannot be cleared from telemetry alone — record them as vendor-attestation items.

`// CQL analysis: count OT/EWS hosts that wrote to an emSign cert-store key AFTER the revocation date #event_simpleName=/^RegGenericValueUpdate$/ event_platform=Win | RegObjectName = /\\SystemCertificates\\(Root|CA)\\Certificates\\/i | test(@timestamp > 1792000000000) | groupBy([aid], function=count(as=writes), limit=max)`

 

**Control** — enumeration validity (field/presence): prove the trust-store query itself works before reading a zero as "no emSign" —

`#event_simpleName=/^RegGenericValueUpdate$/ event_platform=Win | RegObjectName = /\\SystemCertificates\\/i | count(as=certStoreWrites)`

 

The PowerShell leg's control is the baseline root count: Get-ChildItem Cert:\\LocalMachine\\Root | Measure-Object must return the expected dozens of roots; an empty result means the query failed, not that no emSign root is present.

**Verdict criteria:** Positive (posture) — at least one in-scope asset trusts a revoked emSign root (or fails open on revocation) AND cannot receive a vendor trust/firmware update within the window; Negative — every enumerable in-scope asset has removed or blocked the affected roots AND the enumeration control returned the baseline; Non-Conclusive — device trust stores not remotely enumerable (embedded firmware, air-gapped), or revocation posture unreadable; missing trust-store visibility prevents determining exposure for those assets.

#### Threat Actor Profile

This incident is a certificate-issuance failure, not an attributed intrusion. During a key-generation ceremony on 2025-04-30, a flawed script produced a second, weaker set of signing keys whose values were small enough to recover by testing a few hundred candidates; researchers reconstructed a working private key from a public certificate in under one second. As of CERT-In advisory CIAD-2026-0050 (2026-10-21), neither CERT-In nor eMudhra had confirmed malicious exploitation or fraudulent issuance, and no end-entity certificate chaining to the six TLS intermediates had appeared in public Certificate Transparency logs. No threat actor, nation-state cluster, or malware family is attributed, and none should be asserted.

The realistic adversary profile is therefore opportunistic-to-capable rather than a named group. Any actor who retained a copy of one of the eight public certificates since mid-2025 could derive its private key with commodity tooling and no privileged access, which lowers the sophistication bar for a man-in-the-middle or a forged code-signing operation to that of a moderately resourced attacker positioned on a network path or software-distribution channel. The highest-consequence scenario for an OT operator is an actor who uses a forged code-signing signature to make a malicious firmware or engineering-software update appear authentic, or a forged TLS certificate to impersonate an HMI, historian, or remote-access gateway on a segment where revocation is not checked. Because browser revocation reached general-purpose endpoints quickly but does not reach embedded OT trust stores, the window of practical exposure is widest exactly in the control environment. Treat any claim of in-the-wild abuse with skepticism until corroborated by a government or vendor advisory, and record the source of every intel claim.

#### Data Sources Required

**Network:** span/TAP packet capture on OT and management segments (TLS handshakes), NetFlow, firewall logs. Endpoint: CrowdStrike Falcon (ProcessRollup2, PeFileWritten/NewExecutableWritten, NetworkConnectIP4/NetworkReceiveAcceptIP4, RegGenericValueUpdate, InstalledApplication), Windows CAPI2/Operational chain-build events, Windows System-log Schannel events, Security log 7045, Sysmon (process\_creation, network\_connection, file\_event, dns\_query). Certificate/trust: machine certificate stores (Cert:\\LocalMachine\\Root and \\CA), Linux CA bundles (/etc/ssl/certs, /etc/pki/tls/certs), Authenticode signer data via Get-AuthenticodeSignature. OT/ICS: Claroty xDome (Communication Analysis, OT Activity, device firmware), Dragos (Assets, Communications Hub, exported PCAP, Cases), Nozomi Guardian (Link view, node\_firmware\_version, alert PCAP), Tenable OT (Events, Packet Captures, firmware), Forescout eyeInspect (Alerts, host changelog, SSL-client JA3 list), Armis Centrix (ipConnections, activity). External attack surface: the passive internet-scan indices queried read-only (Shodan / Censys / Netlas) and the organization's authoritative public-IP and cloud asset inventories, without which an exposed-host attribution cannot be made — note that the CISA KEV catalog is not applicable here because the incident carries no CVE.

#### Detection Signatures

**SIGMA rule 1** — trust-store manipulation via certutil / cert import on an OT/EWS host (process\_creation):

`title: eMudhra emSign Root or CA Added to a Windows Trust Store id: 7b2d1a64-2f1c-4c9e-9d3a-1e5c0b7a4f21 status: experimental description: Detects use of certutil or PowerShell to add or import a certificate referencing the compromised emSign/EM CA common names into a machine trust store. references: - https://www.cert-in.org.in/ - https://bugzilla.mozilla.org/show_bug.cgi?id=2083449 author: 1898 & Co. Threat Hunt date: 2026-10-23 logsource: category: process_creation product: windows detection: selection_tool: Image|endswith: - '\certutil.exe' - '\powershell.exe' - '\pwsh.exe' selection_action: CommandLine|contains: - '-addstore' - 'Import-Certificate' - 'Add-Content Cert:' selection_ca: CommandLine|contains: - 'emSign' - 'EM OV CS CA' - 'EM DV TLS CA' - 'EM OV TLS CA' - 'EM EV TLS CA' condition: selection_tool and selection_action and selection_ca falsepositives: - Authorized re-provisioning of a re-issued certificate under a clean hierarchy level: high`

 

**SIGMA rule 2** — certificate file dropped to a store/staging path on an OT host (file\_event):

`title: Certificate File Referencing a Compromised emSign CA Written to Disk id: 3c9f8e21-7a44-4b0d-8c12-9f6b2a1d7e03 status: experimental description: Detects a .cer/.crt/.der/.pem file written into a certificate-store or OT installer staging path on an engineering or control host. references: - https://www.cert-in.org.in/ author: 1898 & Co. Threat Hunt date: 2026-10-23 logsource: category: file_event product: windows detection: selection: TargetFilename|endswith: - '.cer' - '.crt' - '.der' - '.pem' TargetFilename|contains: - '\SystemCertificates\' - '\OT_Installers\' - '\Firmware\' condition: selection falsepositives: - Routine certificate deployment by an enterprise configuration-management agent level: medium`

 

**SIGMA rule 3** — PowerShell adding a root certificate or bypassing signature checks (ps\_script):

`title: PowerShell Certificate-Store Write or Authenticode Policy Change Referencing emSign id: a1e4c7d2-5b63-4f88-b2a7-6c0d9e3f1b44 status: experimental description: Detects PowerShell script-block content that writes to a certificate store or references the compromised emSign/EM CA names. references: - https://bugzilla.mozilla.org/show_bug.cgi?id=2083449 author: 1898 & Co. Threat Hunt date: 2026-10-23 logsource: product: windows category: ps_script detection: selection: ScriptBlockText|contains: - 'Cert:\LocalMachine\Root' - 'Import-Certificate' - 'emSign' - 'EM OV CS CA' condition: selection falsepositives: - Sanctioned PKI automation re-deploying re-issued certificates level: medium`

 

**SIGMA rule 4** — new TLS peer for an OT control host on a control-protocol port (network\_connection):

`title: OT Host TLS Connection on a Control-Protocol Port to a New Peer id: f08b6c13-9d27-4a51-8e6f-2b4c7a0d5e19 status: experimental description: Flags TLS connections from OT-segment hosts on OPC UA / MQTTS / HTTPS control ports for certificate inspection; tune DestinationIp to the OT CIDR. references: - https://www.cert-in.org.in/ author: 1898 & Co. Threat Hunt date: 2026-10-23 logsource: category: network_connection product: windows detection: selection: Initiated: 'true' DestinationPort: - 443 - 8443 - 4840 - 8883 condition: selection falsepositives: - Established OT vendor cloud connectors and known HMI/historian endpoints level: low`

 

**Snort/Suricata rule 1** — TLS server certificate issued by a compromised emSign CA (cleartext handshake; TLS 1.3 encrypts the certificate, so this fires on TLS 1.2 and below):

`alert tls any any -> any any (msg:"OT eMudhra emSign-chained TLS server certificate observed"; flow:established,to_client; tls.cert_issuer; content:"emSign"; nocase; classtype:trojan-activity; sid:1000001; rev:1; reference:url,www.cert-in.org.in;)`

 

**Snort/Suricata rule 2** — TLS certificate subject is a compromised emSign code-signing/TLS intermediate:

`alert tls any any -> any any (msg:"OT eMudhra compromised emSign intermediate certificate in chain"; flow:established; tls.cert_subject; content:"EM OV CS CA"; nocase; classtype:trojan-activity; sid:1000002; rev:1; reference:url,bugzilla.mozilla.org;)`

 

**YARA rule 1 targets file/disk artifacts:** a certificate file or a signed PE whose embedded certificate data carries one of the compromised emSign/EM CA common names. The condition ORs the distinct CA name strings so a match on any one is sufficient, and it requires the literal CA common-name text rather than a generic "CA" token so ordinary enterprise or Sectigo certificates (including the legitimate AAA Certificate Services root that cross-signed the hierarchy) do not match. ASCII and wide (UTF-16) forms are both included so the rule works on DER/PEM files and on certificates embedded in a PE.

`rule eMudhra_Compromised_CA_Cert_OnDisk { meta: description = "Certificate or signed binary referencing a compromised eMudhra/emSign CA (CIAD-2026-0050)" author = "1898 & Co. Threat Hunt" date = "2026-10-23" reference = "https://bugzilla.mozilla.org/show_bug.cgi?id=2083449" strings: $root1 = "emSign ECC Root CA-G3" ascii wide nocase // affected root for the six TLS intermediates $root2 = "emSign Root TLS CA-G3" ascii wide nocase // named in some distribution fixes $cs = "EM OV CS CA" ascii wide nocase // code-signing intermediates G3B/G3C $tls1 = "EM DV TLS CA" ascii wide nocase // DV TLS intermediates $tls2 = "EM OV TLS CA" ascii wide nocase // OV TLS intermediates $tls3 = "EM EV TLS CA" ascii wide nocase // EV TLS intermediates condition: any of them }`

 

**YARA rule 2 targets process memory:** a loaded, signed module whose embedded certificate chain references the compromised code-signing or root common names while the process is running. It is structured for a live-process (PID-target) scan because a forged-signed OT/engineering binary reveals its signer chain in memory even when the on-disk file has been removed; the same name-string OR logic and the ASCII/wide pairing keep it from matching generic certificate material.

`rule eMudhra_Compromised_Signer_InMemory { meta: description = "In-memory certificate chain referencing a compromised eMudhra/emSign code-signing or root CA" author = "1898 & Co. Threat Hunt" date = "2026-10-23" reference = "https://www.cert-in.org.in/" strings: $cs = "EM OV CS CA" ascii wide nocase // code-signing intermediates G3B/G3C $root1 = "emSign ECC Root CA-G3" ascii wide nocase // affected root $root2 = "emSign Root TLS CA-G3" ascii wide nocase // distribution-fix root condition: any of them }`

 

#### Indicators of Compromise

Network IoCs (behavioral, scoped to this hunt): a TLS server certificate presented on an OT or management session whose issuer or subject common name contains "emSign ECC Root CA-G3", "emSign Root TLS CA-G3", "EM OV CS CA-G3B/-G3C", or "EM DV/OV/EV TLS CA-G3B/-G3C"; a new TLS peer for a controller/HMI on 443/8443/4840/8883 that is not the asset's historical endpoint.

Host IoCs: a certificate file or signed binary on an OT/engineering host whose embedded certificate carries a compromised emSign/EM CA common name; an emSign root present in Cert:\\LocalMachine\\Root or \\CA after the revocation date; a Windows CAPI2 chain-build event (EID 11/90) naming an emSign CA.

OT/operational IoCs: a firmware or engineering-software install on an OT asset whose Authenticode signer chains to EM OV CS CA-G3B/-G3C; a firmware\_version or os\_version change on a controller with no corresponding maintenance work order; a program-download or firmware-update event outside an approved maintenance window.

The authoritative SHA-256 fingerprints of the eight intermediate certificates are not reproduced here; retrieve them from Mozilla CA-program bug 2083449 and the Go security release commit, then add each fingerprint to the Section-10 block-list as the hunt is operationalized.

#### False Positive Baseline

1\. Legitimate certificates re-issued under a clean (non-emSign) hierarchy after remediation — check NotBefore; a certificate issued after the remediation date is expected, not a finding.

2\. The legitimate AAA Certificate Services (Sectigo) root that cross-signed the emSign hierarchy is a widely used root — the detections anchor on the emSign/EM CA common names, not on AAA Certificate Services, so an ordinary Sectigo-issued certificate is not flagged.

3\. Vendor firmware and software updates with a valid change ticket / work order — expected firmware\_version transitions in the OT platforms.

4\. Internal enterprise-PKI or private-CA certificates whose common names merely contain "CA" — the rules require the literal emSign/EM CA name strings, not a generic "CA" token.

5\. Authorized maintenance-window software installs on engineering workstations by named engineers.

6\. EASM honeypots, which cluster exactly where OT findings look most compelling — attribute every external hit with two ownership signals before treating it as yours.

#### Escalation Criteria

1\. Any YARA hit on eMudhra\_Compromised\_CA\_Cert\_OnDisk against a certificate file or signed binary on an OT or engineering host — engage incident response.

2\. Any YARA hit on eMudhra\_Compromised\_Signer\_InMemory in a loaded module of a running OT/engineering process — engage incident response and isolate the host under OT change control.

3\. Any OT or management TLS session presenting a server certificate chaining to a compromised emSign CA from an endpoint that is not the legitimate issuer for that service.

4\. A firmware or software install on an OT asset signed under EM OV CS CA-G3B/-G3C with no authorized change record.

5\. A two-engine-confirmed internet-facing asset we own that serves a TLS chain routing through a compromised emSign CA (from Hypothesis 1), especially one reachable from or hosting an OT workload.

6\. A certificate-store modification that adds or retains an emSign root on a safety-critical asset after the revocation date, or a controller confirmed to fail open on revocation.

#### Hunt Completion Criteria and Reporting

The hunt is complete when every hypothesis has a verdict rendered against its Verdict criteria. Report a verdict per hypothesis; a residual item in a secondary leg does not downgrade a primary verdict. Make each 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 when it is partial, so capture the status bar in screenshots. Record every limitation with its direction: the inbound IDS/PCAP certificate check sees the handshake only where the sensor observes it and only for TLS 1.2 and below (TLS 1.3 encrypts the certificate); the xDome Communication Analysis export is capped at roughly one month and silently returns 30 days on Past Quarter; embedded-device and air-gapped trust stores are not remotely enumerable; EASM coverage is bounded by the completeness of the public-IP and cloud inventory. Report every leg whose control was zero or unrun as Non-Conclusive, naming the missing input (CAPI2 logging disabled, no PCAP retention, unreadable scan path, incomplete public-IP inventory). Hypothesis 4 reports a posture/coverage result, never an attack-absence. Recommend standing up the EASM certificate sweep and the OT TLS-issuer and code-signing checks as recurring controls, and tracking the vendor-attestation items (embedded trust stores, Go-built edge agents) to closure.

#### Advisory IoC Reference

| IOC Type | IOC |
| --- | --- |
| CVE | None — this is a CA key-generation failure (CIAD-2026-0050); no CVE or CVSS assigned |
| Threat Actor | None attributed — opportunistic/capable actor model only; no nation-state or group attribution |
| Malware | None — no malware family involved; the risk is forged TLS and code-signing trust |
| Network IOC | TLS cert issuer/subject CN: emSign ECC Root CA-G3 (affected root for the six TLS intermediates) |
| Network IOC | TLS cert issuer/subject CN: emSign Root TLS CA-G3 (named in some distribution fixes) |
| Network IOC | TLS cert subject CN: EM OV CS CA-G3B and EM OV CS CA-G3C (compromised code-signing intermediates) |
| Network IOC | TLS cert subject CN: EM DV/OV/EV TLS CA-G3B and -G3C (compromised TLS intermediates) |
| File IOC | Certificate file or signed PE on an OT/engineering host embedding any emSign/EM \* CA common name above |
| File IOC | Authoritative SHA-256 fingerprints of the 8 intermediates — retrieve from Mozilla bug 2083449 and the Go security-release commit, then add to block-list |
| Behavioral | Authenticode signer chaining to EM OV CS CA-G3B/-G3C on an OT/engineering binary or firmware |
| Behavioral | emSign root present in Cert:\\LocalMachine\\Root or \\CA after the revocation date |
| Behavioral | Windows CAPI2 chain-build event (EID 11/90) naming an emSign CA on an OT/EWS host |
| Behavioral | Firmware\_version/os\_version change on a controller with no maintenance work order |
| Behavioral | New TLS peer for a controller/HMI on 443/8443/4840/8883 not matching the asset's historical endpoint |

[Threat Hunt](https://1898advisories.burnsmcd.com/tag/threat-hunt)

*The information in this cybersecurity advisory is provided "as is" for informational purposes only. 1898 & Co. does not provide any warranties or guarantees of any kind regarding this information. You assume all risks if you choose to rely on this information. In no event shall 1898 & Co. or its contractors or subcontractors be liable for any damages including, but not limited to, direct, indirect, special or consequential damages, arising out of, resulting from, or in any way connected with, this information, whether or not based upon warranty, contract, tort, or otherwise, whether or not arising out of negligence, and whether or not injury was sustained from, or arose out of the results of, or reliance upon the information*

*1898 & Co. does not endorse any product or service, except as expressly stated otherwise. Any reference to products or processes does not constitute or imply 1898 & Co.’s endorsement or recommendation.*

Subscribe

✕ Close

 

[Accessibility](https://1898andco.burnsmcd.com/accessibility)  |  [Privacy Statement](https://1898andco.burnsmcd.com/privacy)

© 2026 1898 & Co., a part of Burns & McDonnell. All Rights Reserved.

```json
{
  "@context" : "https://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "The 1898 & Co. Team",
    "url" : "https://1898advisories.burnsmcd.com/author/1898-co-team"
  },
  "dateModified" : "2026-10-23T19:24:44.845Z",
  "datePublished" : "2026-10-23T19:24:44.000Z",
  "headline" : "Threat Hunt Plan: eMudhra/emSign Compromised CA Signing Keys — OT/ICS TLS Impersonation and Code-Signing Trust Abuse",
  "mainEntityOfPage" : {
    "@id" : "https://1898advisories.burnsmcd.com/threat-hunt-plan-emudhra/emsign-compromised-ca-signing-keys-ot/ics-tls-impersonation-and-code-signing-trust-abuse",
    "@type" : "WebPage"
  },
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "url" : "//cdn2.hubspot.net/hub/477837/file-2585615236-jpg/Logo_1_Primary_2Color1.jpg"
    },
    "name" : "Burns & McDonnell Engineering Co"
  }
}
```