An OSINT Analysis of x509 Certificates, Part One: Something Seems Phishy

Editor’s note: This article is the first of two blog posts on analyzing x509 certificates using open-source intelligence. Read Part 2 here.

I’ve spent a lot of time over the past few years collecting, analyzing, and in general thinking about how x509 certificates can be used by threat actors. I’ve pored over certificates used by phishing domains, malware command and control (C2) servers, and certificates from small, medium, and large corporations. The one thing I have learned is there is no cyber threat intelligence (CTI) silver bullet buried inside x509 certificates — nothing that stands out and screams, “I’m a C2 beacon!” or “I’m a phishing domain!” You might think it would be easy to spot a malicious domain from its certificate, but just like everything else in InfoSec, it’s not that easy.

That doesn’t mean there isn’t any value in investigating x509 certificates. It turns out you can gain context about how a domain operates and is managed from its certificate. These posts will describe distinct characteristics of x509 certificates that have proven useful from an open-source intelligence (OSINT) perspective and discuss each in relation to phishers, C2 servers, and legitimate corporations.

Issuer and Subject Fields

The issuer field in an x509 certificate contains information about the identity of the entity that issued the certificate, usually a publicly trusted certificate authority (CA). The subject field contains information about the identity of the entity the certificate was issued to. Both fields are made up of a set of attributes that describe the entity, like its country, state, city, organization name, and common name (Figure 1).

There usually isn’t much useful information in the issuer and subject fields outside of the organization and common name, which can give you insight into the company behind the certificate. The thing to look out for are outliers: values or patterns that are different from the majority of the certificates you see. For example, per RFC 2459, the subject field isn’t actually required to be populated if the same information is included in the subject alternative name (SAN). If you saw a certificate like this, what would this tell you? Not much, other than that certificate was custom-made by a corporation, most likely for internal traffic or product use. I’ve never seen a trusted CA issue an x509 certificate with a blank subject to a domain.

Another thing to look for is x509 subjects containing multiple attributes of the same type. The organizational unit name (OU) and domain component (DC) attributes are the only attributes that are allowed to appear multiple times in the issuer or subject. But just because the specification says that doesn’t mean other attributes aren’t duplicated in practice. Microsoft has a certificate I often see that has multiple common name attributes for whatever reason (Figure 2).

Again, does this tell you much? Not really, other than certificates like this were created with care for a specific purpose, so they were most likely issued by corporations for internal traffic or product usage. There just isn’t a good reason for a threat actor to go through extra steps to make their certificates stand out for no reason.

The main takeaway when looking at issuer and subject fields is to look for values that are outside of the norm. Since these fields are free text, look for obvious suspicious values, base64 or other encodings, or maybe some kind of sub-field delimiters within an attribute. For example, another Microsoft certificate that I’ve seen has multiple comma-delimited key-value pairs inside the common name…for reasons (Figure 3).

Tip: Many certificates used for malware C2 have only the common name attribute in the issuer and subject fields.

Self-Signed Certificates

The easiest way to check if an x509 certificate is self-signed is to look and see if the issuer and subject are the same (Figure 4). This isn’t totally foolproof, as someone could set their subject attributes to be the same as the issuer attributes from the CA’s signing certificate, but no trustworthy CA would allow this, not even Let’s Encrypt.

No self-respecting phisher would ever try to use a self-signed certificate. This is because the whole goal of phishing is to make your domain look as legitimate as possible, and a self-signed certificate would cause a TLS security alert in the browser when it tries to load the web page.

Malware C2 servers that use TLS to encrypt traffic don’t have this same requirement since browsers aren’t used for C2 communication. This means that self-signed certificates work just fine, but that also means these certificates will easily stand out in your network logs.

Just because a certificate is self-signed doesn’t mean that it isn’t trustworthy, though. You will see a lot of self-signed certificates issued by corporations used in both North-South and East-West network traffic.

Expired Certificates

An expired x509 certificate is one where the Not Valid After date is before the date the certificate is currently being used.

Tip: When looking at historical network logs, make sure to take note the date the traffic was captured to determine if the certificate was expired.

Much like self-signed certificates, expired certificates have little value to phishers because browsers will not load the web page for any domain with an expired certificate. As the goal of a phishing domain is to look as legitimate as possible, they should always have a valid x509 certificate, which is why many phishers prefer CAs that support automation. Any phish domain with an expired certificate has most likely been burned (put on blocklists) and abandoned by the phisher.

Certificates used by C2 servers are less picky about this as they don’t need a browser to validate the certificate, so expired certificates are not that uncommon in C2 traffic.

You will also see a fair number of expired certificates issued by corporations used in legitimate traffic. Most likely, these certificates were issued and installed on hardware years ago and now are either forgotten about or too logistically difficult or expensive to update.

Invalid Validity Period

The validity period of an x509 certificate is the duration between the Not Valid Before and the Not Valid After date. So, how could this period ever be invalid? Some certificates are issued with the Not Valid After date before the Not Valid Before date (Figure 5). This might sound surprising, but it happens more often than you think. There are two different scenarios where certificates end up in this state.

Most tools or APIs that can generate x509 certificates have error-checking logic to detect scenarios like this when issuing certificates and will throw an error instead of generating the certificate. But there are APIs, such as the Python cryptography library, that will generate an x509 certificate if all the fields can be correctly byte encoded.

There are several companies that have been observed to generate internal certificates in this manner, but none were issued by a trusted certificate authority, as CAs are required to only issue valid certificates. As to why certificates like these are generated, one can only guess: internal standard, product team Easter egg, for the LULZ — who knows?

A second reason certificates can have invalid validity periods is what is called the “year 2038 problem.” There is an issue where certain systems that represent datetimes as 32 bits have a maximum possible date of January 19, 2038. When generating an x509 certificate, you tell it how many days in the future the certificate should expire. On such a system, if that duration exceeds January 19, 2038, the Not Valid After date will roll back to December 13, 1901, and then continue forward.

From a phishing perspective, this again is a non-starter, as the certificate would be invalidated by any browser. For malware C2 communication, such a certificate could be used, but we have not observed any in our collected data.

Other Invalid x509 Values

There’s a suite of other invalid or just really odd values we’ve observed in x509 certificates, such as:

• Not Valid Before date 100 years in the future
• An x509 version number of 4 (which is not a thing)
• Signature algorithm of Sha1 (because why not?)
• Negative serial numbers
• Subject or issuer country code with more than two characters

The key takeaways when coming across invalid values:

• A trusted certificate authority will only issue certificates with valid values
• Phishers are trying their best to appear like legitimate target domains
• Malware C2 doesn’t have the same browser constraints phishing does and can use invalid certificates
• Corporations generate certificates with what seems like YOLO abandon for a variety of uses

Watch for part two of this series, which will show the wealth of information that a certificate’s subject alternate name (SAN) can reveal.