Hunting for X.509 Certificates
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 or will expire within a user-defined window
- Self-signed certificates
- Certificates signed by certificate authorities that aren’t well known
- Certificates that were compromised or revoked
- Rogue certificates
- Certificates with duplicate serial numbers
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:
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:
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:
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:
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:
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:
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.
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.
February 3, 2023
Finding Lexmark printer assets
Printer manufacturer Lexmark recently published details on a vulnerability that affects over 100 of their printer models. Learn how runZero can help you find potentially affected assets.
December 9, 2022
Finding Cisco 7800 and 8800 series IP phone assets on your network
Cisco 7800 and 8800 IP phones can be found in many companies and organizations. Successful exploitation of this vulnerability can provide an unauthenticated attacker in the same network segment or VLAN with remote code execution or denial-of-service capabilities.
December 5, 2022
Finding MegaRAC BMC assets on your network
MegaRAC can be found in many server manufacturers’ Baseboard Management Controllers (BMCs), including AMD, Ampere Computing, ASRock, Asus, ARM, Dell EMC, Gigabyte, HPE, Huawei, Inspur, Lenovo, Nvidia, Qualcomm, Quanta, and Tyan. Successful exploitation of these …