X.509 certificates are used to secure communications over both trusted and untrusted networks. Protocols such as Transport Layer Security (TLS) rely on X.509 certificates to keep their communications secure between endpoints. Each X.509 certificate is composed of a public and private key pair. The public key is shared with 3rd parties and the private key is only known to the entity that generated the certificate key pair.
Generally, certificates on the public Internet are signed by a reputable entity known as a Certificate Authority (CA). All modern operating systems include a pre-populated and updatable set of trusted, public CA certificates that allow browsers and other network-enabled applications to establish a trusted, secure connection. When a certificate is signed by a trusted certificate authority, it contains an Authority Key Identifier, which allows systems to attribute the signed certificate with the public key of the signing CA, thereby establishing trust.
Certificates can also be self-signed or signed by an intermediary CA, which could be internal to an organization, but unknown to the general public. Accepting a self-signed certificate from a remote system is generally discouraged due to the lack of ability to establish trust. Although self-signed certificates are used by malware and botnets, they aren’t inherently a sign of a rogue device or presence of a malicious actor within a network. They’re generally used as a means to verify TLS communications within a development or testing environment prior to installing a certificate signed by a trusted CA. Vendors also release software or hardware devices with self-signed certificates installed to allow customers to quickly get up and running with their product (though such products generally display warnings to notify the end-user that the certificate isn’t reputable).
Unfortunately, even certificates signed by well-known CAs aren’t a panacea for secure, encrypted communications without some level of risk. Over the years, several organizations, including certificate authorities, have had their private keys compromised allowing a malicious attacker to perform network attacks including phishing, man in the middle (MITM), and masquerading.
From the runZero Console, teams can hunt for:
- [Certificates that have expired]({{< ref "#certificates-that-have-already-expired" >}}) or [will expire within a user-defined window]({{< ref "#certificates-about-to-expire" >}})
- [Self-signed certificates]({{< ref "#self-signed-certificates" >}})
- [Certificates signed by certificate authorities that aren’t well known]({{< ref "#certificates-signed-by-an-untrusted-ca" >}})
- [Certificates that were compromised or revoked]({{< ref "#certificates-signed-by-an-intermediate-or-root-ca-that-was-compromised-or-revoked" >}})
- [Rogue certificates]({{< ref "#rogue-or-revoked-certificates" >}})
- [Certificates with duplicate serial numbers]({{< ref "#certificates-with-duplicate-serial-numbers" >}})
Certificates that have already expired #
If a certificate has lapsed the expiration date, it can lead to a host of issues, including the disruption of business continuity. Alerts and tickets usually soon follow once a certificate expires if the business depends on the system hosting the certificate, which could lead to loss of revenue and the ability to deliver on SLAs. If a certificate has expired and is severely out-of-date, it could hint at whether a system is in use any longer by the organization or a potentially nefarious service.
The following query will help find certificates that have expired:
_asset.protocol:tls AND protocol:tls AND has:tls.expired
Certificates about to expire #
It’s generally considered good practice to refresh any infrastructure certificates a few weeks prior to their expiration date. The extra time helps to ensure that the certificate can be put in place before the expiration date; otherwise, business operations may be disrupted. This allows for any back and forth communication with the CA, as well as any required internal processes prior to deploying the new certificate.
The following query will help find certificates that will expire in the next month:
_asset.protocol:tls AND protocol:tls AND tls.notAfterTS:<1month
Self-signed certificates #
It’s a good practice to have an understanding on whether or not self-signed certificates exist within the network and the purpose of the underlying system where they’re deployed.
The following query will help find certificates that are self-signed:
_asset.protocol:tls AND protocol:tls AND has:tls.selfSigned
Certificates signed by an untrusted CA #
In addition to self-signed certificates, certificates signed by CAs that aren’t well-known are also worth investigating to gain a better understanding of the purpose for the system and determine whether rogue assets exist within the network.
The following query will help find certificates signed by an untrusted CA:
_asset.protocol:tls AND protocol:tls AND has:tls.caUnknown
Certificates signed by an intermediate or root CA that was compromised or revoked #
CA certificates are also rotated as a general practice. This could be due to maintenance (i.e. certificate expiration) or it could be because the certificate was compromised. A search for all certificates signed by the CA certificate can be executed if one of the: serial number, authorized key identifier, or SHA1 hash of the CA are known by filtering the service inventory with a query similar to the following:
_asset.protocol:tls AND protocol:tls AND tls.fp.sha1:"XYZ"
Rogue or revoked certificates #
Certificates identified as Indicators of Compromise (IoC) are generally available as a hash in one form or another (e.g., MD5, SHA1, etc). By default, runZero computes the SHA1 and SHA256 hashes for the certificate and CA certificates associated with each discovered TLS service. After running a quick scan against a list of malicious certificates provided by sslbl.abuse.ch, we can quickly search the runZero Console for certificates matching malware samples that are attributable to Dridex C2.
The following query will help find rogue or revoked certificates:
_asset.protocol:tls AND protocol:tls AND tls.fp.sha1:"7669103ea0a2e900179e5220a13bf3415438b665"
Certificates with duplicate serial numbers #
Although the serial number of a certificate is not globally unique, duplicate serial numbers could indicate an issue with the CA. For example, this could indicate that the CA certificate was compromised, the CA is purposely issuing certificates using the same serial number, or a potential misconfiguration (e.g., a default setting that wasn’t overridden). In any case, runZero provides a customizable Service attributes report that can enumerate the count for any of an asset’s service attributes.
After launching the report, the console will perform an aggregate query using the tls.serial attribute and render the results in a tabular format. Alternatively, access the report directly here.
The results show that there are several duplicate serial numbers in the environment. Of note, the serial numbers 0 and 1 look like a potential misconfiguration to dig into. Clicking on the 0 link displays all matching services that exist within the selected organization. Alternatively, the search results can be directly accessed via query string alive:t AND _asset.protocol:tls AND protocol:tls AND tls.serial:=0 .
The search results show that there are protocols assigned to odd ports (e.g., 21-22/http+tls), which the runZero Console allows us to dig a bit further into the details to better understand. For example, a network device may be port forwarding one or more services through a NAT using mismatched ports.
The search results can be exported to a CSV file, and duplicate results can be removed by filtering on the asset_id column with a tool like Excel. From there, we can continue our investigation.
In summary #
X.509 certificates are an important component of modern secure network communications. Maintaining good security posture can include locating assets and services which are using revoked or expired certificates, or those using certificates signed by an unexpected CA. Identifying certificates before they expire can allow for time to get new certificates created and deployed, avoiding unexpected business disruption. runZero's search and reporting features can help keep on top of your X.509 certificates.
