SSL certificates are what enable encrypted communications on a network.
They contain a lot of useful information that can be audited.
Trusted third parties known as certificate authorities signed these
certificates to provide additional authentication.
Fortunately for us, Zeek can capture these certificates,
as well as the information exchanged during the TLS negotiation phase.
Much like I explained in the previous clip,
we need to have a reference we can look at in order to determine
which certificates on the network are authorized.
The list can be created by combining the trusted certificates from the
global root and intermediate certificate authorities.
The Zeek SSL log captures information about encryption
ciphers and ports using TLS on the network.
The x509 log contains TLS certificate details such as serial number,
expiration, and the certificate authority that signed and issued the certificate.
We will be using this log file for most of our auditing tasks.
Let's look at the SSL log first.
There are a lot of details contained in this file,
and I've only provided a small sample.
I want you to focus on the line containing the cipher.
During the TLS negotiation phase,
this is the cipher that the server chose to use for the encrypted session.
This information can be used to audit for weak
ciphers in use in your environment.
The other line worth mentioning is the cert_chain_fuids line.
If you have Zeek configured to extract the certificates,
these fuids will correspond to a file stored on disk.
Of course, you also have the details of the source host and the destination host.
Those of you that have experience with Zeek will already
understand this naming convention, but for anyone else,
Zeek uses the terms originator for the source host in the
communications and responder for the destination host.
The Filebeat Zeek plugin takes care of translating this in Elasticsearch,
so don't worry too much.
Before we move on,
I will warn you that communications using TLS version 1.3
will not have the cert_chain_fuids present.
I will talk more about TLS version 1.3 later in this module.
Now let us look at the TLS version.
If you decide to monitor the TLS versions being used in your environment,
you can see it is readily available.
Next, we have the port field,
which is sometimes viewed as not important; however,
it can be a key indicator of compromise.
Think about it for a second.
If you happen to see TLS traffic on a port outside of
what is appropriate for your network, then it may be worth investigating.
The last line I will cover is the validation_status.
Zeek can verify that the certificates being used in your
environment are signed by a trusted third party.
It does this by using a local certificate authority store.
This is like the CA store that your browser uses when you visit HTPPS websites.
If you have deployed your own CA infrastructure or have
software using custom self‑signed certificates,
then they most likely will not be verifiable this way.
Okay, so now let's look at the x509 log file.
This file gets created and updated when Zeek sees a
certificate exchanged during a TLS negotiation.
Much like the SSL log file, we can use a lot of the fields to
support continuous monitoring. The field I will discuss in this
lesson will be the certificate. issuer field.
We can use this field to compare with our list of trusted certificate
authorities and quickly identify certificates on the network that are
either self‑signed or anomalous. Even though I will only discuss and
demonstrate the certificate.issuer,
you can adapt what I teach for the other fields, such as
the expiration and encryption key_length.
The certificate.issuer field tells us which certificate
authority authenticated and issued a certificate.
Self‑signed certificates are not signed by a globally recognized and
trusted third party. Using that knowledge, we can use Zeek data in the
Elastic Stack to monitor for deviations and anomalies.
It is worth mentioning that you can forge the issuer to look like
one of the root certificate authorities; however,
the SSL log contains a validation status that will verify
each certificate with a local CA store.
So even if an attacker created a self‑signed
certificate that used a fraudulent issuer,
it would be relatively easy to identify.
There are three areas I would recommend implementing continuous monitoring.
The first one is certificate authority, which is what I mentioned earlier.
The second is ciphers or hashes.
You want to continuously monitor your environment to ensure there are no
weak ciphers or hashes being employed in your environment.
Attackers can exploit the use of weak ciphers and hashes on your network.
Lastly, sometimes certificates expire and are not renewed for various reasons.
Implementing a plan to monitor them can alert system
administrators to these dangling certificates.
In the next clip,
I will demonstrate one way to monitor certificates
in the Globomantics environment.