Using Certificate Transparency as an Attack / Defense Tool

Published: 2018-09-18
Last Updated: 2018-09-18 12:00:47 UTC
by Rob VandenBrink (Version: 1)
2 comment(s)

Certificate Transparency is a program that we've all heard about, but might not have had direct contact with.  We do hear about it from time to time, for instance when Google (or someone else) busts a CA for generating certificates that should not exist  (which is what eventually led to the Symantec CA implosion event ..).  I kinda knew about mostly from mentions in the ISC Stormcast.

Anyway, the Cert Transparency program has Certifficate Authorities keeping a transparent log of EV certificates since Jan 1, 2015, and logs for DV and OV certificates as of May 2, 2018 (more here: ).  This means that there are central, queriable repo's for all SSL certificates.  As soon as I hear "central database" and "API", I tend to ask "how can I use that for other purposes" - for instance, how I use that in Penetration Tests?

One of the truisms of of pentests is that you can only test/attack hosts or services that you know are there - that's what the recon phase of your pentest is all about.  Certificate Transparency logs gives you a whole new method of assembling a list of targets during recon.

Let's take a look at a few of the vendor interfaces to the data.  Starting with Comodo's CT interface - making a query gets us a nice list of certs:

Though that API approach is very simple to use, I found this GUI interface a bit clumsy to navigate to the info you really want.  The Entrust interface at is a bit easier to navigate, but doesn't have that easy ability to translate a browser based query to a curl or other script based approach.

SSL mate allows you to monitor for any new certificates in your list of domains - which is handy if you've maybe got a marketing group that's active in AWS but isn't telling IT everything that's going on over there :-)

Whatever interface you use, clicking on anything on a results page will get you more and more (and more) detail. What can we use in these listings?

First, start with the domain that you know about.  Query that, and you'll get the list of all certs issued to that domain.  How can you use that?  Grab the CN's (Common Name) for the certificates, and you'll have a starter host list.  Add the SAN fields (Subject Alternative Names) and you'll generally have a longer list of hosts.

What do do next?  Look at the "not after" list for expired certificates.  Why those you ask?  Well, if you have an expired certificate for a host, and a valid cert isn't in the list, I'll always start with these.  If the host still exists, this is a great indication that it's not well maintained - maybe it's a forgotten lab or dev machine for instance, or part of a marketing program that has run its course.  In either case, it's likely not well patched and is often easy pickings for the penetration tester.  Look for any outliers - if all certts were issued by one CA, look for any certs that were issued by a different CA for instance.  That's another indicator of "credit card IT" practices (often by non-IT or non-infosec folks).

So we have a host list, and a list of hosts that are either no longer active or are perhaps easily exploitable.  Are we done yet?  Nope, let's pivot through this information to get MOAR information - look a the "O" (Organization) field.  This should be the same for all the certificates in the domain.  Query using the contents of that field, and you'll get all the **other** domains that the organization has certificates for.  Use the exact, full contents of the field, then repeat by removing any  trailing periods, then try removing any "Corp" or "Inc" words.  Now repeat the entire process for any new domains that you've found, you'll now have anywhere from 1-4-5-or more domains worth of hosts and possible easy target hosts.  If you're lucky, some of these will have been stood up by interns, coop students or other "good with computers" folks who didn't neccessarily follow IT's procedures in building or maintaining hosts.

Where else can you find a decent interface to a certificate transparency feed?  So far, I've been using:
Nice API, with lots of examples
This one is very complete.  I can't seem to find "O" records, but that's easily obtainable from any of the certificates once you have some hostnames.
This gives you pretty much everything, including the ability to download the certificates themselves, export to excel or csv.
Of course there's a Google interface to search certificates.  And of course it's extremely complete - if there's info to find, it'll be easy to find in this one!
Yup, there's a Facebook iterface too!  Authentication is required so I don't use it so much.  It does allow you to pull the PEM for each certificate if you want to do some offline information mining (using OpenSSL or CertUtil or even PowerShell for instance).

Every CA has their own interface.  It's all the same data (or it's supposed to be anyway), so poke around and see which one suits your style of searching best.

With all of these tools at your disposal and some good red-team approaches, what about the blue team?  the SSLmate interface allows you to monitor for new certificates being issued to your domains - - perhaps certificates requested by folks in your organization that you don't want purchasing certificates.  Or perhaps attackers that have social engineered their way into purchasing a certificate.

With some creative coding, you can also use certificate transparency to monitor for typosquatting or punycode attacks against your domains - track for "0 for o", "1 for l", but then also add some of the other unicode "look-a-like" alternatives for o, a, i etc.  Also add a few "typo" alternatives - "gooogle" for "google", or try a version of your domain name that uses an adjacent key - "amazom" for "amazon" for instance.

The more I type, the more that this sounds like a project or two - Look for code in the next few weeks.  Or if you know of folks who have gone further down this path of coding to use Cert Transparency for either attack or defense, please share in our comment form!  Or if I've missed a really nice CA interface, API or an attack/defense method using this data, please also share!

Rob VandenBrink

2 comment(s)
iOS 12 is out today - Updates for Safari, watchOS, tvOS, iOS. Full details here
ISC Stormcast For Tuesday, September 18th 2018


What's this all about ..?
password reveal .
<a hreaf="">the social network</a> is described as follows because they respect your privacy and keep your data secure:

<a hreaf="">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.

<a hreaf="">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
<a hreaf=""> public bathroom near me</a>
<a hreaf=""> nearest public toilet to me</a>
<a hreaf=""> public bathroom near me</a>
<a hreaf=""> public bathroom near me</a>
<a hreaf=""> nearest public toilet to me</a>
<a hreaf=""> public bathroom near me</a>
Enter comment here... a fake TeamViewer page, and that page led to a different type of malware. This week's infection involved a downloaded JavaScript (.js) file that led to Microsoft Installer packages (.msi files) containing other script that used free or open source programs.
distribute malware. Even if the URL listed on the ad shows a legitimate website, subsequent ad traffic can easily lead to a fake page. Different types of malware are distributed in this manner. I've seen IcedID (Bokbot), Gozi/ISFB, and various information stealers distributed through fake software websites that were provided through Google ad traffic. I submitted malicious files from this example to VirusTotal and found a low rate of detection, with some files not showing as malware at all. Additionally, domains associated with this infection frequently change. That might make it hard to detect.
Enter corthrthmment here...

Diary Archives