This week, two big vulnerabilities are in the news. The first one is the PHP2Shell vulnerability, for which a Zeek® detector was published yesterday. The second, equally important, vulnerability is the compromise of some intermediate certificates of the eMudhra Certificate Authority (CA).
Background and impact
For reasons that remain unclear, the Indian eMudhra Certificate Authority accidentally issued 8 intermediate certificates with insecure private keys in April 2025. One of the private keys is, for example, the number 4. Six of these intermediate certificates were valid for use in TLS; the two others were valid for code signing.
Because the private keys of these CA certificates are now known, everyone can issue certificates for any of these CAs. So it is trivially possible to create a valid certificate for any hostname on the internet.
Upon discovery, major browsers immediately distrusted these intermediate certificates. Chrome included the certificates in its CRLSet, and Mozilla included them in OneCRL. Operating system vendors and other software are also quickly being updated.
However, devices that don’t automatically get updates will, by default, remain vulnerable. This could include embedded devices, devices running old operating systems or distributions that no longer receive updates, offline devices, etc.
The affected root certificate was added to the Mozilla certificate database in 2019. This database is not only used by Firefox; it is also the source of trusted root certificates used by most Linux distributions and other software. This includes Zeek.
Thus, there is a high risk that this will be used in the future to exploit network-based clients.
Zeek detection
Zeek provides excellent support for TLS and X.509 parsing, enabling the Corelight Open Source team to create a Zeek package that detects when the affected eMudhra intermediate certificates are encountered in TLS connections. The package is available in Corelight’s emudhra-weak-keys repository.
The detector works for TLS connections using SSL/TLS versions up to 1.2. TLS 1.3 encrypts certificates in the handshake. They are thus no longer visible to passive network observers. However, as long as one client connects that uses TLS 1.2 or below, the certificate will still appear in the clear.
The Zeek package adds four possible notices to notice.log:
Compromised_Intermediate_Cert
This notice is raised when one of the compromised intermediate CA certificates is seen in the handshake. The certificates are detected by matching the Subject Public Key Info (SPKI) hash. We will go into more detail about that choice below.Compromised_Intermediate_Cert_Established
This notice is raised when one of the compromised intermediate CA certificates is encountered, and the handshake completes. This can indicate that the client accepted the certificate.Compromised_Intermediate_Issuer
This notice is raised for connections that reference one of the compromised intermediate CA certificates in a certificate's issuer field, without directly containing it. Web browsers (and some other clients) cache intermediate CA certificates and can still use them, even when they are not sent in the handshake itself.Compromised_Intermediate_Issuer_Established
This notice is raised for connections that refer to one of the compromised intermediate CA certificates in the issuer field that finished the handshake. This can indicate that the client accepted the certificate.
We use an SHA-256 hash of the Subject Public Key Info (SPKI) of the affected CA certificates to identify them. The SPKI is the data structure in a certificate that contains the public key, plus some metadata. Thus, an SPKI hash uniquely identifies a public key, not just an individual certificate.
Matching the SPKI not only detects the certificate; it also detects any cross-signed certificates. Cross-signing is a common occurrence in Web PKI, where several variations of intermediate certificates are signed by different Certificate Authorities. This can be used to ensure that the certificates are accepted by a wide variety of clients, chaining to different root CAs.
This, in fact, was used by eMudhra. There is one cross-signed certificate variant for each of the TLS CA intermediates.
Furthermore, matching against the SPKI instead of against a certificate fingerprint prevents some common evasion tactics. For example, the affected intermediate certificates use ECDSA signatures. ECDSA signatures are malleable and can be represented in two different ways, both of which are, in principle, valid. Thus, instead of just matching the SPKI, for fingerprints you must match all certificates and all cross-signs, making sure you cover all possible legal encodings. Furthermore, attackers can try to exploit leniencies in X.509 parsing libraries to create more variations.
As noted above, the TLS handshake does not necessarily need to contain the intermediate CAs. To understand this, let’s take a small step back. Each X.509 certificate has a Subject field identifying the entity (e.g., a website) for which the certificate is valid. It also has an issuer field, which identifies the entity that issues the certificate.
A TLS handshake can include a certificate that simply states it was issued by one of the affected eMudhra CAs, without sending the intermediate certificate. While this limits the possibility of validation, some clients have lists of possible intermediate CA certificates, or cache previously encountered valid intermediate CA certificates. Such clients can validate and accept these end-host certificates even when the intermediate CA certificate, which is needed for validation, was not present in the connection.
Our second set of notices (Compromised_Intermediate_Issuer and Compromised_Intermediate_Issuer_Established) covers exactly these cases.
Detecting exploitation in SIEM data
If you are running a SIEM, you can check old Zeek data for exploit attempts. Zeek, by default, does not log the SPKI hash (though there now is a package for it) – so you have to fall back to the less-optimal certificate hashes.
You can get a list of all SHA-256 hashes from this dataset by using jq:
curl -fsSL https://emudhra.we-have-a-problem.com/impacted-intermediates.json |
jq -r '.[] | [.name, .issued_by, (.sha256 | ascii_downcase)] | @tsv'
The hashes will be contained in the cert_chain_fps column of ssl.log, and (if you are not loading policy/protocols/ssl/log-hostcerts-only.zeek) in the fingerprint column of x509.log.
Alternatively, you can look at the issuer field of ssl.log, using the names from this list.
For more helpful information like this, check out our blog and subscribe to our newsletter at the bottom of the page.