Let’s Encrypt Now Being Abused By Malvertisers

Let’s Encrypt Now Being Abused By Malvertisers 

Encrypting all HTTP traffic has long been considered a key security goal, but 

there have been two key obstacles to this. First, certificates are not free and many 
owners  are  unwilling  to  pay;  secondly  the  certificates  themselves  are  not  always 
something that could be set up by a site owner. 

The Let’s  Encrypt project  was  founded  with  the  goal  of  eliminating  these 

obstacles.  The  project’s  goal  is  to  provide  free  certificates  to  all  site  owners;  in 
addition, software could be set up on a web server to make the process as automated 
as  possible.  It  is  backed  by  many  major  Internet  companies  and  non-profit 
organizations – Akamai, Cisco, the Electronic Frontier Foundation (EFF), Facebook, 
and Mozilla to name a few. Let’s Encrypt only issues domain-validated certificates 
and  not  extended  validation  (EV)  certificates,  which  include  additional  checks 
regarding the identity of the site owner. 

Unfortunately, the potential for Let’s Encrypt being abused has always been 

present. Because of this, we have kept an eye out for malicious sites that would use 
a  Let’s  Encrypt  certificate.  Starting  on  December  21,  we  saw  activity  going  to  a 
malvertising server, with traffic coming from users in Japan. This campaign led to 
sites  hosting  the  Angler  Exploit  Kit,  which  would  download  a  banking  Trojan 
(BKDR_VAWTRAK.AAAFV) onto the affected machine. 

Figure 1. Daily hits to malvertising server 

We believe that this attack is a continuation of the same malvertising campaign 
we first identified in September that also targeted Japanese users. 

How was this attack carried out? The malvertisers used a technique called 

“domain shadowing”. Attackers who have gained the ability to create subdomains 
under a legitimate domain do so, but the created subdomain leads to a server under 
the control of the attackers. In this particular case, the attackers created 
ad.{legitimate domain}.com under the legitimate site. Note that we are disguising 
the name of this site until its webmasters are able to fix this problem appropriately 

Traffic to this created subdomain was protected with HTTPS and a Let’s 

Encrypt certificate, as shown below: 

Figure 2. Let’s Encrypt SSL certificate 

The domain hosted an ad which appeared to be related to the legitimate 

domain to disguise its traffic. Parts of its redirection script have also been moved 
from a JavaScript file into a .GIF file to make identifying the payload more 
difficult. Anti-AV code similar to what we found in the September attack is still 
present. In addition, it uses an open DoubleClick redirect – a tactic previously 
discussed by Kafeine of Malware don’t need Coffee. 

Figure 3. Code used by malvertising 

Any technology that is meant for good can be abused by cybercriminals, and 

Let’s Encrypt is no exception. As a certificate authority ourselves we are aware of 
how the SSL system of trust can be abused. Cases like this one where an attacker is 
able to create subdomains under a legitimate domain name demonstrate a problem. 
A certificate authority that automatically issues certificates specific to these 
subdomains may inadvertently help cybercriminals, all with the domain owner 
being unaware of the problem and unable to prevent it. These DV certificates can 
help the hacker gain legitimacy with the public. 

Let’s Encrypt only checks domains that it issues against the Google safe 

browsing API; in addition, they have stated that they do not believe CAs should act 
as a content filter. Security on the infrastructure is only possible when all critical 
players – browsers, CAs, and anti-virus companies – play an active role in weeding 
out bad actors. 

CAs should be willing to cancel certificates issued to illicit parties that have 

been abused by various threat actors. Website owners should ensure that they 
secure their own website control panels, to ensure that new subdomains beyond 
their control are not created without their knowledge. Users should also be aware 
that

 a 

“secure” site is not necessarily a safe site, and we also note that the best 

defense against exploit kits is still keeping software up-to-date to minimize the 
number of vulnerabilities that may be exploited.