PayPal Phishing Certificates Far More Prevalent Than Previously Thought
1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)

PayPal Phishing Certificates Far More Prevalent Than Previously Thought

Over 14,000 SSL Certificates issued to PayPal phishing sites.

Earlier this month I discussed the use of Let’s Encrypt certificates on PayPal phishing sites. In that article I asked Let’s Encrypt to stop issuing certificates containing the term “PayPal” because of the high likelihood they would be used for phishing.

That requested stemmed from the fact that PayPal is a high value target and that Let’s Encrypt had already issued nearly 1,000 certificates containing the term “PayPal,” more than 99% of which were intended for phishing sites.

With expanded research, we found our previous claim was a major underestimate. Let’s Encrypt has actually issued 15,270 “PayPal” certificates. This reveals the previously unknown extent of the Let’s Encrypt phishing phenomenon.

The Let’s Encrypt Phishing Connection

One of the primary fears voiced by critics of Let’s Encrypt – a fear that predates the Certificate Authority’s launch – was that the service would become the go-to CA for phishers because its SSL certificates were free. Let’s Encrypt also has an unconventional stance on the role of the CA, arguing that it was not the CA’s job to stop malicious sites from using its certificates. This meant that phishers and malware distributors were free to use Let’s Encrypt without any risk of being banned or having their certificate revoked.

Despite the concerns of many around the industry, Let’s Encrypt’s stance is in full compliance with industry standards. Regardless,  that policy in combination with offering free certificates does create a very attractive environment for phishers.

In my previous article I said Let’s Encrypt had issued 988 certificates containing the word “PayPal” – for example, Typically, CAs would not issue certificates like this due to the likelihood they will be used to aid criminal activity.

Of those 988, 99.5% of the certificates were being used (or had been used) for phishing. While this proved that there was wide-spread abuse, it was not at the scale many had expected when Let’s Encrypt was first announced.

We now have new data that captures the full extent of the “PayPal” certificates that have been issued by Let’s Encrypt. This new data comes from – a search engine for certificate transparency logs – and reveals that the service has been significantly more popular with phishers than previously reported.

Between January 1st, 2016 and March 6th, 2017, Let’s Encrypt has issued a total of 15,270 SSL certificates containing the word “PayPal.”

This figure is more than ten times larger than previous estimates that have been published. The vast majority of this issuance has occurred since November – since then Let’s Encrypt has issued nearly 100 “PayPal” certificates per day.

Based on a random sample, 96.7% of these certificates were intended for use on phishing sites.

The internet is currently moving from HTTP to HTTPS, spurred by a number of initiatives to “encrypt everything.” Encrypting everything includes the bad sites, and the widespread use of HTTPS on malicious sites has been a concern for some.

For many years, the security industry as a whole incorrectly taught users to associate HTTPS and the green padlock with a “safe” site. This is a bad generalization, which may lead users to believe a phishing site is real if it is using SSL.

In addition, Chrome’s new UI displays “Secure” next to every site with a valid SSL certificate and HTTPS configuration. What’s the chance that a user misconstrues the meaning of this and sees a phishing site as legitimate?

PayPal Phishing, Let's Encrypt Phishing

While our research has focused on PayPal phishing, there are many other targets out there including Bank of America, Apple IDs, and Google. Let’s Encrypt has issued thousands more of these certificates.

This new data clearly shows that use of HTTPS on phishing sites is significantly higher than previously thought.

The Data

This section expands on our data and methodology.

Our Source

Let’s Encrypt submits all of the certificates it issues into certificate transparency logs, a mechanism designed to increase public transparency into the activities of CAs. The logs also act as an excellent source for researchers who want to analyze a CA and the SSL certificate ecosystem.

Not all CAs log their certificates, as this is currently an optional practice (though not for long). Because Let’s Encrypt voluntarily logs, it allows us to get very accurate data about its issuance activity.

Last week we reported Let’s Encrypt had issued 988 “PayPal” certificates. That figure came from the methodology used by previous works. Upon further research, we found that method was limited in scope and was capturing only a small portion of the population.

Our new figure of 15,270 certificates comes from, a Certificate Transparency search engine operated by Comodo. That is the total number of certificates issued by Let’s Encrypt that contain the word “PayPal” somewhere in the certificate’s identities (either a Common Name or a SAN) between March 25th, 2016 and March 6th, 2017 (our search covers all of 2016, but no matching certificates were issued until March). This is a sub-string search that includes all hostnames containing “PayPal” anywhere within the name.

Such a complete search is not possible through’s website because of the scale of the query. Rob Stradling, who developed, queried the database directly and provided me with this data upon request.

To compare Let’s Encrypt to other CAs, we ran the same search for the same date range for other CAs included in’s database. During the same time period, all other CAs combined issued 461 “PayPal” certificates that were potentially used for phishing sites. This number excludes results that could be confidently ruled out as legitimate sites and services operated by PayPal.

Because many CAs do not participate in certificate transparency, their certificates only appear in a log if a third-party decides to log them. Thus it is likely some “PayPal” certificates issued by other CAs have not been logged and therefore not counted. However, I believe the number is fairly accurate, and even if we are very generous with our margin of error, all other CAs combined represent less than 1/10th of Let’s Encrypt’s volume of PayPal phishing certificates. This shows that the use of SSL certificates on PayPal phishing sites is directly tied to Let’s Encrypt’s entry into the market.

Rate of Issuance

It took phishers some time to adopt Let’s Encrypt as their CA of choice. Our search covered all certificates issued between January 1st 2016 and March 6th, 2017.

PayPal phishing sites, Let's Encrypt phishingLet’s Encrypt has been issuing certificates since late 2015, when they were in a public beta. However, the first Let’s Encrypt phishing certificate for Paypal was not issued until March 25th, 2016. On the right is a per month breakdown.

The number of PayPal certificates increased substantially in November 2016. There does not appear to be any specific cause for the increase. It may simply be that it took some time for word to spread amongst the phishing communities and for technical expertise to be developed.

The various initiatives encouraging HTTPS are likely to appeal to phishers as well. There are a number of performance benefits (such as HTTP/2) only available to sites using HTTPS. In addition, sites using valid SSL certificates are given trusted UI indicators by browsers (the padlock icon in all browsers, the “Secure” label in Chrome) which make a phishing site look more legitimate.

In November, more than 1,000 “PayPal” certificates were issued for the first time. That number doubled in the following month and has increased month over month since then. February of this year has seen the highest issuance yet, with more than 5,000 certificates.

Since November, when the amount of activity significantly increased, more than 100 “PayPal” certificates have been issued per day, on average.

Based on the data available so far, this month (March 2017) will be the first full-month decline since June of 2016.

Prevalence of Phishing

We estimate that 96.7% of the 15,270 certificates were (or are) used for phishing (that’s 14,766 certificates). Most phishing sites are quickly reported to their web hosts and detected by services such as Safe Browsing and subsequently taken offline. Once flagged as dangerous, a phishing site becomes useless. The majority of the sites are not currently conducting any activity.

To determine the ratio of phishing sites vs. legitimate ones, we took a random sample of 1000 certificates and reviewed them by hand. For the vast majority of certificates, the hostname made the purpose of the site clear. We avoided false positives by labeling sites as “legitimate” when we were unsure, and visited the sites when necessary.

In our previously reported data we performed the same check on all the certificates. In that group of 988, only 4 of the sites were legitimate, giving us a phishing rate of 99.6%.

In our new sample we found a phishing rate of 96.7%.

Both cases show that nearly all “PayPal” certificates being issued by Let’s Encrypt are intended for phishing, and legitimate users make up only a single-digit share.


Assuming that current trends continue, Let’s Encrypt will issue 20,000 additional “PayPal” certificates by the end of this year.

Let’s Encrypt takes a hands-off approach when it comes to moderating issuance and revoking certificates because it does not fit with its goal of encrypting every website.

We do believe there are valid reasons for that approach, but question its indiscriminate application. After publishing our previous article we had a great discussion with the community on our website and on social media. There were many good rebuttals to my request that Let’s Encrypt blacklist “PayPal”, and we now think there are other viable solutions to this problem and other end-goals to pursue.

Our main goal in publishing these expanded figures is to show how popular the use of SSL is on phishing sites. If Let’s Encrypt will issue upwards of 35,000 “PayPal” certificates by the end of 2017, there are likely tens of thousands more targeting other popular sites and services. The security community, and internet users at large, should be aware of the extent of this activity.

The security community has previous speculated about the use of SSL on malicious sites. We hope this data serves as early proof that there is widespread use, at least in the subcategory of phishing. Future studies of phishing should consider the potential benefits and appearance of legitimacy granted to phishing sites using HTTPS instead of HTTP.

  • Good analysis. But the users should not be depending on just the “secure” icon on the browser. Browsers should highlight which website the people are really visiting (or sending their data to) and possibly warn users (or even disable access) by checking well-known spammer’s list for the URLs.

    • Why can’t this be a feature of Firefox? At the very least a plugin could be developed to provide this feature, heck they probably already exist. It wouldn’t provide 100% protection as there would be some corporations who would be too small to be included in the checks, but a company like PayPal could certainly be verified by the browser.

      Still, the only real long term solution is to continue educating people on proper internet practices, especially with regards to security. The tools we need exist already, they’re already user-friendly, users just need to be made aware of how to use them. Computer newbs are scared to click unfamiliar things. Let’s teach them to click the certificate and examine it. That is not beyond their intellect.

  • 1. If you can’t check the URL for the site you’re looking for to make any transaction, you shouldn’t be doing any online transactions…
    2. SSL certificates guarantee private communications between the certified site and the user, it doesn’t certify that the site won’t try to scam you. That’s true for Let’s Encrypt or any other certificate issuing entity.
    3. An SSL certificates store bashing on the free, open certificates organization… No surprise there… Specially with the permalink of the article “lets-encrypt-phishing”, the fall of your greedy business charging ridiculous amounts of money for a simple interaction to certificate encryption keys is making you desperate…

    • 1. Because there are no users out there who could be mislead or make a mistake? Phishing sites go to great lengths to deceive and users have to fend off new scams all the time. You don’t think its conceivable someone sees “Secure” and gets confused about what site they are on?

      If your message is to blame the user because they might slip up once, then you are advocating for the phishers.

      2. That’s true, but how many people know that? Years of misguided advice have given people inaccurate understandings of SSL and the padlock icon. The truth is not all that matters when you have real world users who do not know it.

      While most people are now working to correct that assumption, Google is reinforcing these misconceptions by writing “Secure” on every site with SSL. The semantics of Secure vs Safe are far too nuanced for an everyday audience that is not familiar with the threats of the web.

      3. I am not going to validate this by writing a rebuttal. We are not bashing anyone or any organization. We have presented the facts, and taken the time to note that despite disagreements over policy and practices, Let’s Encrypt has followed every regulation and rule by issuing these certificates.

      • Jakob was right. A person needs to have a basic amount of competence with a tool before they’re allowed to use it without “adult supervision”. The internet is no different, and if you don’t understand the very simple methods to verify the authenticity of a website you’re on then you should not be allowed to handle credit cards and the internet simultaneously.

        We apply the exact same litmus tests to operating cars, firearms, and other tools which can be dangerous in the hands of fools.

        At some point people need to accept personal responsibility for being duped. Slap your forehead and realize the fault is yours, and not groups of well-intentioned people who are working very hard to make all of our lives better.

        • Well Simba, by your logic, we need the government to mandate and supply licensing for basic internet use, just like it does for operating cars and purchasing firearms. But it’s much more complicated than your attitude suggests; those who fall prey to internet scams are not “fools” if they have simply never been educated about the ever-evolving world of online phishing.

          I agree that people should understand these verification methods, but all I have been able to do is personally educate those within my circle, as should everyone who knows these things and actually cares about their grandmas, low-tech friends who just got their first smartphones, etc.. Until some authority finally does begin forcing basic internet safety down citizens’ throats like driver’s ed., it’s up to us who know to teach those who don’t, because they usually aren’t careless, they’re just ignorant.

    • Typical geek response, or possibly that of a hacker making money off of what is going on here. The Internet is for people, not techno-snobs. Not every intelligent person gives enough care regarding technology to be savvy about it. Get over it. I am a techno-geek, and my company is directly impacted by Let’s Encrypt’s incredibly careless policies. I do not use sslstore for my SSL services, and I am not bashing on Let’s Encrypt not because I am an SSL provider, as I pay for my certs. I am bashing on Let’s Encrypt as their attitude and carelessness are directly enabling crime and freely provides certs to allow other companies to ILLEGALLY represent themselves with MY domain name.
      You are either a criminal hacker or a complete moron. Anyone who agrees with you is at the least deluded if not worse.

  • I think what the numbers actually show, if you look at the whole picture, is that Let’s Encrypt has benefited the global internet community on an order of magnitude more than any possible harm caused by their existing model.

    PayPal doesn’t use a domain verified certificate, they use a business verified certificate, as does every single major corporation in existence. Now that we have made the first real step in encrypting the entire web, which is absolutely the 1st and most critical priority, we can shift efforts to educating the masses on recognizing business verified certificates and using their critical thinking skills that all real people must posses to live functional lives, to protect themselves from fraud.

    You can’t save everyone, and if you try you hurt more people than you help. Some people are going to fall.

  • DV certificates(includes Let’s encrypt) doesn’t meet to identify site owner.
    It is only used for encrypting between just server and browser.
    The site owner and users need understand the difference of DV and EV certificates.

  • I could absolutely be wrong but it seems to me these results have to be inflated. I mean, I am sure there are sites that implement the Paypal API and try to match style, url look, etc that AREN’T phishing… The numbers this site claims seems odd, that being said LE SHOULD probably include some subdomain filters that specifically deny this type of request but is it their responsibility to? I dont know… Anyhow, I am a legitimate developer and I use letsencrypt certs. I feel like the more negative information gets put out there the quicker they wont be able to provide this great service. And yes users themselves should be more aware and NEVER submit sensitive information to someone they have not built up trust with THEMSELVES regardless of who says its ok.

    • Hi Jake,

      The phishing sites we came across were 1:1 replicas of the Paypal site. They likely are from a “kit” downloaded from phishing/malware communities. The pages themselves are direct HTML/CSS copies, but are modified so that the user’s login info is saved to a sql database/file on the server.

      I certainly hope their are not sites out there trying to replicate Paypal’s own look – that would encourage some risky behavior from users. I did not find any evidence of sites doing this; and in cases where it was not clear what the site’s purpose was, I labeled those sites as legitimate. My first priority in my methodology was to avoid false-positives.

      The legitimate sites I did find were usually using “paypal.domain.tld” as a dedicated checkout page, and it was obvious when it was the case.

      I got the specific numbers from a random sample, so the 14,766 total count is an estimate. But with a sample of 1000 out of a population of ~15,000, it is a very good estimate. The *VAST* majority were very obvious phishing sites – hostnames such as “” or “” often using an obscure and cheap-to-register ccTLD. It was not uncommon to see 20+ character hostnames and they were just various combinations of “paypal,” “secure,” “account,” “limited” and “review.”

      Our data comes from a public source – Certificate Transparency logs. While the exact query can’t be replicated easily, you can see a similar search result which captures about 75% of the data we used at this link:

      You can flip through a couple pages and see for yourself.

      I similarly found the numbers hard to believe. Thats why I personally believe that “Paypal” falls into a unique case. But, I have discussed that enough for my lifetime 🙂

      Let me know if you have any other questions, and I appreciate you taking the time to read my article and write a comment.

      • Hi Brian,

        No, for this research I kept it simple and just looked at certificates containing “paypal” spelled in english. No IDN homographs. Those are certainly a potent attack vector, but they also fall into the messy problem of parsing the huge number of variations that exist.

        I do think thats worth taking a look at in the future.

  • Up until now, HTTPS was providing two products at once: encryption and validation. I think the best solution would be splitting these products, so possiblility of site validation remains while everything can be encrypted as well.

  • – Sounds like these are no better than trusting self signed certificates. The purpose of most CAs is to include a chain of trust, which means verifying the relationships of the applicants. If you are going to issue certificates with a chain of trust then you either need the expense of checking up on the applicant or you need to automate a system of vouching to create a verifiable web of Trust. PGP and Thawt did that when I last looked but I have not heard much from either recently.

    – One big problem I wonder about is trust revocation. Besides expiration so that re-affirmation is required you have CRL lists provided by for-fee CAs with a hierarchical trust model. However, if you have a Web of Trust do you revoke a cert just because one “trusted” person revoked their trust while several others who also vouched for a cert holder do not revoke their trust? i.e if 5 people vouch for me and one revokes do you revoke my cert?

    -It almost sounds like you need a Trust index – a % of how much some site/person/certificate can be trusted. However, who gets to vote and are they legitimate? i.e. if everyone goes to the trouble of “trusting” WalMart so they get a 100% rating. But then Anti-WalMartians launch a campaign of distrust then should WalMart’s trust rating be reduced when it is actually a legitimate site/cert? Note that the trust I speak of is for the authenticity of the certificate and web site, not the business.

    – Also, CRLs are a pain to maintain and often unreachable. How would you check a trust index provider and who would provide it?

    • I thoroughly disagree with your first statement. The only purpose of a CA is to confirm that yes, the holder of this certificate owns the domain name the certificate is registered for — hence the classification of “Domain Validation”: validating that the domain on the cert belongs to the person requesting the cert, whether that’s “” or “”. Higher levels of validation exist, and consumers need to be educated to look for them when conducting e-commerce.

      For point 2, I’m pretty sure only the issuing CA can revoke a cert, so by design, if a CRL from the issuing CA says a cert is revoked, it is authoritatively revoked. There isn’t even a mechanism for “5 people vouch for me and one revokes”, because the only one vouching or revoking is the CA. Similarly, a CA’s issuing certificate can only be revoked by its issuing root CA. The only time it gets hairy is in the (thankfully rare) situation when a root CA needs to be revoked — at that point, it’s on the OS/browser/SSL implementation vendor to remove the root CA from its product and issue updates.

      I think a trust index is an excellent idea, and should be managed by separate “trust authorities” (with CAs having the option of registering/certifying as trust authorities as well, for “one stop shopping”). Depending on the level of validation you seek (contact info, physical address, business credentials, etc) a site could obtain a correspondingly higher “trust score”. This would be immune to smear campaigns and the like, while providing a form of consumer confidence that (ideally) would be easy to implement and understand at a glance.

  • The certificate authority is supposed to verify the requester of the certificate actually owns the domain/host. Reputable CAs do this, and do it quite thoroughly. Let’s Encrypt issued a certificate for my domain to someone else, and didn’t contact us at all. If they do that, then the certificate process is worthless, as it does provide two services if done correctly: verify the identity of the site, and secondly enable the encryption. It does no one any good to issue free certificates for any old domain and host name they want. Oh, except those who are solemnly up to no good…. If I was a content filter software company, I’d add a filter for all sites that hold a Let’s Encrypt certificate, since such sites cannot be trusted. Expecting users to check whether a site is valid is ridiculous when they’d have to do reverse lookups of IP addresses to host names to verify who the host belongs to, and with cloud services and URL mapping of web hosts to single IP addresses that belong to hosting services, that won’t tell you much in today’s world. We are supposed to be able to trust a site if it has an issued certificate from a legitimate CA. Yes, that does not mean I trust everything on the site, as someone pointed out earlier it could still host nefarious content that attacks me, but at least I know who the site belongs to. With Let’s Encrypt, the model is broken.

  • SSL has never been meant to guarantee the honesty and transparency of any site. It is meant to protect (and does it quite well) the content that is transiting from one point (eg: the browser) to the other (eg: the server), period. That being said, any opinion that rejects all wrongdoing responsibility to the user is itself totally irresponsible, to say the least, not to mention quite suspect in this context.

    Such statement is as ludicrous as saying that anyone who dies in a plane crash caused by a human error (the vast majority of such event) are responsible for their own misfortune since they should have learned to fly an airplane before boarding one. Same for a car: you only have to know how to manipulate the steering wheel, the transmission, and the pedals to drive away. No need to know about the transmission, engine, direction and braking systems internals: for the ones who may wonder, this is called a simple User Interface.

    Let’s Encrypt provided a fantastic stepping stone to improve overall security on the web. It is up to the web-savvy community to leverage this asset to invade new territories such as phishing detection and other security concerns so that anyone who can board an airplane can also use the web with peace of mind.

Leave a Reply

Your email address will not be published. We will only use your email address to respond to your comment and/or notify you of responses. Required fields are marked *

Captcha *