Catch that Phish (Marlin or trout)

With the latest breach reported with Indian IT outsourcing major Wipro, it has once again come to prominence on how effective phishing can be for intrusion. Easy availability of SSL certificates from providers like ‘Let’s Encrypt’ and the misconception that ‘https’ implies “safe & trusted”, users can fall easy prey to these phishing scams.

The other part of the problem is that being ‘https’ URLs, detecting such attacks by URL matching is not that easy, unless you route all your traffic thru a proxy that acts as the MITM, and that’s really not that common.

Which leaves the option of monitoring domain names (DNS logs) to be able to determine the Phishing. This has 2 holes.

1. The volume of DNS Logs that need to be stored and scanned thru can be overwhelming and enormously expensive
2. The DNS (local cache or DB of DNS provider) is compromised and therby an hijacked domain is pointed to attacker controlled server that serves the auto-generated SSL cert signed by Let’s Encrypt

Thereby even after the release of the Indicators of Compromise (IoCs) after a phishing detection on one site, it will not be so easy to match, or watch for, those indicators elsewhere and claim a clean chit.

At PolyLogyx we crafted a solution to simplify this problem.

Instead of locating domain names, we decided to use the SSL certificates of the phishing sites as an indicator. The certificate points to a unique identity and is there a much reliable indicator than domain matching.

Thanks to Google’s Certificate Transparency project (CT), this job becomes much more simplified. CT project, in the simplest terms, is a collection of network services that keep a log of SSL certificates, with the following qualities:

• They’re append-only — certificates can only be added to a log; certificates can’t be deleted, modified, or retroactively inserted into a log.
  - They’re cryptographically assured — logs use a special cryptographic mechanism known as Merkle Tree Hashes to prevent tampering and misbehavior.
  - They’re publicly auditable — anyone can query a log and verify that it’s well behaved, or verify that an SSL certificate has been legitimately appended to the log.

Thus once the IoCs of a phishing campaign become public, its easy to identify the certificates (if any) that were used to sign the domains listed in the IoCs.

For e.g. the Wipro breach mentions of the following domains:

xsecuremail[dot]com
secured-mail[dot]com
microsoftonline-secure-login[dot]com

The CT project provides the certificates for these domains

xsecuremail[dot]com (https://crt.sh/?id=1256975722, https://crt.sh/?id=1256975786)
secured-mail[dot]com (https://crt.sh/?id=91363742)
microsoftonline-secure-login[dot]com (https://crt.sh/?id=472349777, https://crt.sh/?id=472349488)

As expected, these certificates are provided by ‘Let’s Encrypt’ and ‘cPanel’, both of which allow for automated DV SSL certificate generation, which only requires the requester to own the domain name. (For more on different SSL certs)

OK, so now that we have a much better indicator for identifying phishing sites, the question is how do we leverage them as majority of the EDRs don’t carry that level of visibility. Given we have our own EDR, we just built the heck out of it.

In the latest release of our osquery extension, we added a new table for SSL events:

osquery> .schema win_ssl_events
CREATE TABLE win_ssl_events(`event_type` TEXT, `action` TEXT, `eid` TEXT, `subject_name` TEXT, `issuer_name` TEXT, `serial_number` TEXT, `dns_names` TEXT, `pid` BIGINT, `process_guid` TEXT, `process_name` TEXT, `remote_address` TEXT, `remote_port` INTEGER, `time` BIGINT, `utc_time` TEXT);

The table gets populated for every SSL connection that is made by the endpoint. Of course it took some back breaking engineering to be able to support various SSL and TLS versions but finally it was “viola”.

osquery> select subject_name, issuer_name, dns_names from win_ssl_events where issuer_name like ‘%Encrypt%’;
+ — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — + — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — + — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -+
| subject_name | issuer_name | dns_names |
+ — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — + — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — + — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -+
| /CN=*.polylogyx.com,/C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3 | /C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3,/O=Digital Signature Trust Co./CN=DST Root CA X3 | DNS:*.polylogyx.com, DNS:polylogyx.com |
| /CN=www.iitgoa.ac.in | /C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3 | DNS:www.iitgoa.ac.in |
| /CN=*.polylogyx.com,/C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3 | /C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3,/O=Digital Signature Trust Co./CN=DST Root CA X3 | DNS:*.polylogyx.com, DNS:polylogyx.com |
| /CN=admin.mutinyhq.com,/C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3 | /C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3,/O=Digital Signature Trust Co./CN=DST Root CA X3 | DNS:admin.mutinyhq.com, DNS:api.mutinyhq.com, DNS:api.mutinyhq.io, DNS:app.mutinyhq.com, DNS:preview.mutinyhq.com, DNS:referrals.mutinyhq.com, DNS:www.mutinyhq.com |
+ — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — + — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — + — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -+
osquery>

There we go. A very easy way of searching for all the certificates issued by Let’s Encrypt that were seen on an endpoint. We can extend the query for certificate’s serial number, domain name, IP address etc.

With the scheduled query mechanism of osquery, all this data can be brought to a central location and now it would be very easy to catch those Phishes, be it the marlin or the trout.