Of Phishing Attacks and WordPress 0days

9 minute read

Proxying around 5% of the Internet’s requests gives us an interesting vantage point from which to observe malicious behavior. It also make us a target. Aside from the many, varied denial of service attacks that break against our defenses we also see huge number of phishing campaigns. In this blog post I will dissect a recent phishing attack that we detected and neutralized with the help of our friends at Bluehost.

An attack that is particularly interesting as it appears to be using a brand new WordPress 0day.

A Day Out Phishing

The first sign we typically see that shows a new phishing campaign is underway are the phishing emails themselves. There's general a constant background noise of a few of these emails targeting individual customers every day. However when a larger campaign starts up, typically that trickle turns into a flood of very similar messages.

Messages like this one:
Example Phish Note — We will never send you an email like this. If you see one, its fake and should be reported to our abuse team by forwarding it to support@cloudflare.com.

In terms of the phishing campaign timeline, these emails aren’t the first event. Much like a spider looking to trap flies, a phisher first has to build a web to trap his victims. Looking like the legitimate login page of a target domain, these landing pages have one goal - to collect your credentials. Since these landing pages are quickly identified, the phisher will often go to great lengths to ensure that he can put up tens or even hundreds of pages during the lifetime of a campaign. Taking great lengths to ensure that they can’t be traced back to him. Generally this means compromising a large number of vulnerable websites in order to inject his phishing toolkit.

So it is no surprise then that first step in most phishing campaigns will generally the mass compromise of a large number of vulnerable websites. This is why your will often see a notable uptick in the volume of phishing emails whenever a major vulnerability comes out for one of the popular CMS platforms. This is also why protecting the Internet’s back-office is a critical step in building a better internet. Protect the vulnerable CMS sites and not only do you allow them to flourish but you also protect the thousands of victims that get abused when their infrastructure gets hijacked for malicious purposes.

This is why in Cloudflare we feel that providing free, basic security to every website is such important thing and why ultimately it could be such a game changer in building a better internet.

Back to the phish

Returning to our phishing attack, we see that it is no different. Analyzing the “load.cloudflare.com” hyperlink on the message, we see that it is actually a link pointing to a compromised WordPress site hosted by Bluehost.

Note: This is no reflection on Bluehost, every hosting provider gets targeted at some point. Whats more important is how those hosting providers subsequently respond to reports of compromised sites. In fact Bluehost should be commended for the speed with which they responded to our requests and the way they handled the affected sites we reported.

Every other email in this campaign follows the same pattern. Here is the source for another one of those links that uses “activate.cloudflare.com”:

As you can see, while the message will display that you are going to “activate.cloudflare.com” in reality anyone that clicks on the link will be diverted to the victim website. Which unsurprisingly is running an old, vulnerable version of WordPress.

Every phishing email from this campaign has followed exactly the same pattern. A basic email template addressed to $customer informing them that their site has been locked, inviting them to click on a link that takes you to a compromised WordPress site on hosting provider Bluehost.

What it looks like is this attacker, harvested a large number of target domains using public DNS and email records identifying likely administrative email addresses. This became his victim list. He then targeted a convenient, vulnerable CMS platform and injected his phishing kit into every innocent domain he compromised. Finally, once that was complete he sent out his phishing emails to the victim list.

As phishing attacks go, this one is remarkably unsophisticated. All a savvy user has to do to reveal the true nature of this link is a quick mouseover. As soon as you do mouseover the link you will see that the descriptive destination “activate.cloudflare.com” does not match the true destination.

More advanced phishing techniques

A clever phisher could have used one of the many well known tricks to obfuscate the URL. Below are some of those techniques so you will know them when you see them.

  • Image Maps. Instead of using a traditional hyperlink as above, phishers have been known to put an imagemap in their emails. The image of course is of a link to a trusted site such as “www.safesite.com”. When an unsuspected user clicks within the coordinates of the imagemap, they are diverted to the phishing site.

    Here is an example of this technique taken from an old ebay phishing email:

    In order to fool Bayesian filters looking for phishing spam like this, the phisher also added some legitimate sounding words in white font to keep them from appearing. The user experience however is the same as the earlier phishing email. As soon as you mouseover the image map you will see the true destination.

  • Misspelled domain names and homoglyphs. Misspelled domains can look very similar to their legitimate counterparts and by using a homoglyph - or look-a-like character - an attacker can make a misspelling look even less obvious. Examples include “microsft.com” or “g00gle.com” These domains look so similar to the advertised link in the phishing email that many people will miss the discrepancy when they mouseover the link.

  • Reflection, Redirection and javascript. Many websites - even sites like answers.usa.gov - have search features, offsite links or vulnerable pages that have historically been abused by phishers. If the offsite link can be manipulated - typically with a cross site scripting vulnerability - it is possible for the phisher to present a link from the target domain that takes the victim to a age under the Phisher’s control. Below is an example of a historic flaw of this nature that existed on the answers.usa.gov site

    In this case the URL looks like a legitimate “answers.usa.gov” url but when you clicked on it, you would activate a cross-site scripting flaw that executes the javascript in your browser.

    The attacker could easily turn a page with this sort of flaw into a malicious credential harvester. All while still using a link to the legitimate site.

    Note - All those extra %20’s are encoded spaces to push the javascript far enough away that it won’t be visible on mouseover.

    A slightly different flaw, also on the USA.gov site, involved its URL shortening service. Open to anyone, Phishers quickly discovered that they could use this service to create shortened URLs that looked important because of the .gov prefix. A victim that might be reluctant to click on an unsolicited bit.ly link would be less reluctant faced with a .gov. Here's an example of an email from a campaign that abused that service:

  • URL obfuscation. Historically this has been one of the most popular and varied techniques. The concept is simple, use any of the available URL encoding methods to disguise the true nature of the destination URL. I will describe a couple of historic techniques below. Note: many modern browsers now warn against some of these techniques.

    First is username:password@url abuse. This notation - now deprecated because only an idiot would pass credentials in the HTTP query string these days - was designed to allow seamless access to password protected areas. Abuse is easy, for example:


    Next is IP address obfuscation. You are probably familiar with the IP address as a dotted quad?, well IP addresses can also be expressed in number of other formats which browsers will accept. By combining this with “username:password@” trick above an attacker can effectively hide his true destination. Below are four different methods for presenting one of Google’s IP addresses -

    All of these URLs go to

    Finally we have Punycode and Homoglyph based obfuscation. Punycode was created as a way for international characters to map to valid characters for DNS. For example “café.com”. using punycode this would be represented as xn--caf-dma.com. As mentioned at the start, homoglyphs are symbols which closely resemble other symbols. Examples include 0 and O, or I and l.

    By combining these two methods we can create URLs like —


    The secret to this obfuscated URL is to use a non standard character which happens to be a homoglyph for /. The result? Instead of a page on safesite.com, you are actually taken to a subdomain of the following punycode domain —


    New obfuscation techniques like these appear all the time. Phishing is both the most common and arguably the most effective method of attack for medium to low skill attackers. Staying up to date with these techniques can be extremely useful when it comes to spotting potential phishing attempts.


After further analysis It quickly became clear that all of the endpoints in this campaign were compromised WordPress sites running WordPress 4.0 - 4.1.1.

The most likely scenario is that a new critical vulnerability has surfaced in WordPress 4.1.1 and earlier. Given that 4.1.1 was at the time of writing the most current version of WordPress, this can only mean one thing - a WordPress 0day in the wild.

Checking the WordPress site confirms that that a few hours ago they announced a new critical cross-site scripting vulnerability:

WordPress Security Notice

While we can’t confirm for certain that this is the vulnerability our Phisher was using, it seems highly likely given the version numbers compromised.

Over the last few hours we have worked closely with our friends at Bluehost to identify the remaining affected sites compromised by this phisher so they could take them offline. A quick response like this essentially renders all remaining phishing emails in this current campaign harmless. This need to quickly neutralize Phishing sites is why we in CloudFlare developed our own process for rapidly identifying and tagging suspected compromised sites. When a site on our network is flagged as phishing site we impose an interstitial page that serves to both to warn potential visitors and give the site owner time to fix the issue.

You can read more about our own process in the following blog post - https://blog.cloudflare.com/127760418/

How customers can stay safe

By enabling the CloudFlare WAF, CloudFlare customers have some protection against the sort of cross-site scripting vulnerability involved in this attack. However anyone can still fall victim to a phishing email. Below are 7 tips to help you stay safe.

  • NEVER click on links in unsolicited emails or advertisements.
  • Be vigilant, poor spelling and strange URLs are dead giveaways.
  • Mouseover the URL and see if it matches the what’s presented in the email.
  • Type URLs in manually where possible.
  • Stay up to date on your software and make sure you are running a current up-to-date antivirus client — yes, even if you're using Mac.
  • It’s possible to set traps for phishers: Use unique, specific email addresses for each account you set up. That way if you get an email to you Bank of America email address asking for your Capital One password you immediately know it's a phishing attack.
  • Finally, where possible enable two-factor authentication. While not fool-proof, it makes it much harder for the attacker.



Spotlight on Women in Cybersecurity

less than 1 minute read

Sucuri is committed to helping women develop their careers in technology. On International Women’s Day, Sucuri team members share their insights into workin...

Hacked Website Trend Report – 2018

less than 1 minute read

We are proud to be releasing our latest Hacked Website Trend Report for 2018. This report is based on data collected and analyzed by the GoDaddy Security / ...