Brazil Gov website serving up phish and malware… again

A Brazilian government website has been compromised for the third time in less than two months. Each compromise resulted in the site hosting fraudulent content that was used in phishing attacks. One of these attacks also attempted to install drive-by malware on victims' computers.

The first compromise took place in December, when the Prefeitura Municipal de Esperança website was used to host a phishing attack against Wells Fargo bank. The fraudulent content used in this first attack was subsequently removed, but the site was compromised again last week and used to host two more phishing attacks.

The first phishing attack hosted on, which targeted Wells Fargo customers in December 2015.

The second phishing attack, which kicked off last week, was aimed at PayPal customers. This was arguably the most dangerous attack: As well as stealing victims' PayPal credentials and bank details, the phishing kit used in this attack also attempted to inject drive-by malware via hidden iframes.

Fraudsters often use ready-made phishing kits when deploying phishing sites, as it generally makes the process quick and easy. Kits typically consist of a collection of lookalike web pages, scripts and images which simply have to be uploaded to the compromised web server to create a ready-to-go phishing site. In most cases, all the fraudster has to do is edit a simple configuration file to tell the phishing site which email address to send the stolen credentials to.

The PayPal phishing site, which also tried to deliver malware to its victims.

The PayPal phishing site, which also tried to deliver malware to its victims.

The third attack – which is currently still live – uses a phishing kit that is designed to steal webmail credentials. Many slight variations of this kit exist, but all display an error message regardless of the validity of the submitted credentials.

The latest attack attempts to steal webmail credentials.

The latest attack attempts to steal webmail credentials.

Unbeknownst to the victim, the stolen credentials are emailed to the fraudster who deployed the kit; but these webmail phishing kits also contain an additional surprise. The fraudster may not realise that the kit also sends a copy of these stolen credentials to another email address, which presumably belongs to the original author of the kit. This address has been sneakily embedded into the kit in such a way that its presence it unlikely to be spotted by the deploying fraudster.

Webmail credentials are a popular target for phishers, as they can be used to compromised further accounts held by each victim. For example, if the victim's email address has been used to sign up for other services, the attacker might be able to use password resets to gain unauthorised access to those services.

Repeatedly compromised

The second-level domain used by the compromised website is reserved for government entities within Brazil, yet the content of the site is physically hosted by HostGator in Texas. It is not unusual for South American governments to host websites in external countries such as the U.S., especially when the sites do not store or process any sensitive data. The most obvious motivation in this case is that hosting costs in the U.S. are typically lower than those in Brazil.

The fact that the website has been repeatedly compromised suggests there is still a vulnerability that allows remote attackers to upload arbitrary content onto the web server. One possible route of compromise could be the "unsafe" version of WordPress being used on The Prefeitura Municipal de Esperança website uses WordPress 4.0.9 as its content management system, and although this version was released only a week ago (to address a cross-site scripting vulnerability), only the latest release in the 4.4.x series is officially actively maintained. The WordPress website explicitly points out that anything older than the current latest release (4.4.1) is not safe to use.

Another potential risk could be the site's reliance on a shared hosting platform: More than 70 other websites are served from the same IP address as that used by Vulnerabilities exposed by any of these non-government sites could potentially be used to attack the government site. Also, in general, any web server that has previously been compromised could have had a backdoor installed by the attacker, making it trivial to gain unauthorised access at a later time.

The PayPal phishing kit

PayPal is one of the most common phishing targets, with many distinct phishing kits making it easy for even novices to carry out these types of attack. Last month alone, Netcraft blocked more than 60,000 phishing URLs that were designed to steal PayPal credentials.

The PayPal phishing kit used in last week's attack featured a few tricks that made it stand out from a typical kit. Although it exhibits a few tell-tale spelling mistakes, the designer of the phishing kit has been very careful in other respects. For example, the initial login page actually consists of a large background image, with two input fields and a submit button overlaid. This means the textual content of the page does not need to be written in the HTML document, which could in turn reduce the likelihood of the attack being spotted and blocked by certain internet security software.

However, this trick does not work too well in all browsers – if you look closely, you can see that the text fields do not quite line up with the placeholders in the background image:

Misaligned login form, with "Payement" spelling mistake.

Misaligned login form, with "Payement" spelling mistake.

The fact that the spelling mistakes are contained within images, rather than within an easily editable HTML document, could explain why subsequent users of this phishing kit have not corrected them.

Spelling mistakes aside, the developer has also implemented validation checks to prevent the login form being submitted with an invalid email address:


After stealing the victim's PayPal credentials, the phishing site takes the user through a three-stage "update" process. The first stage collates the victim's full address and date of birth, while the second gathers his payment card details, and the final stage steals his bank account numbers.

Each stage of the phishing attack validates the information entered by the victim.

Each stage of the phishing attack validates the information entered by the victim.

Each page validates the victim's input, and like the spoof login page, they also use background images in an attempt to evade detection.

But the nastiest feature is that each page in the phishing kit contains a set of hidden iframes that attempt to silently install malware on the victim's computer. This is a relatively unusual feature for a phishing kit, and was possibly included to the benefit of the phishing kit's author, rather than to the subordinate fraudsters who deploy it.

The PayPal attack also attempted to inject drive-by malware via iframes. This component of the attack did not work, as the domain used for the malware delivery has been sinkholed.

The PayPal attack also attempted to inject drive-by malware via iframes.

However, the malware component of the attack does not work, as the domain used for the malware delivery has been sinkholed. If it had not already been sinkholed and was still serving drive-by malware, any victim visiting the phishing site could have had his computer compromised as soon as the login page was viewed. If the victim was cautious enough to not submit the login form, the malware might still have allowed the attacker to steal the victim's credentials in other ways, or allow for other monetization opportunities, such as making the victim's computer part of a botnet.

After the victim has submitted his bank account details, the PayPal phishing site indicates that the account has been successfully updated, and redirects the victim to the genuine PayPal login page. Being prompted to enter a username and password a second time could ring alarm bells, as the victim has, ostensibly, already logged in. The phishing site explains away this concern by saying the user must re-login to save the changes.


All three of these phishing attacks were added to Netcraft's Phishing Site Feed. This feed is used by all major web browsers and many leading anti-virus and content-filtering companies, so most users are already protected against the latest webmail phishing attack. The fraudulent content used in the first two attacks has been removed from the Prefeitura Municipal de Esperança website.

US military still SHAckled to outdated DoD PKI infrastructure

Despite widespread concerns over the security of the SHA-1 hash algorithm, the US Department of Defense is still issuing SHA-1 signed certificates, and using them to secure connections to .mil websites.

The US DoD issued a SHA-1 signed certificate to on 4 January 2016

The US DoD issued a SHA-1 signed certificate to on 4 January 2016

Since 1 January 2016, the CA/Browser Forum's Baseline Requirements [pdf] have banned the issuance of new SHA-1 certificates. Publicly-trusted certificate authorities are expected to comply with these Baseline Requirements in order to remain trusted by browsers and operating systems.

However, the US DoD is not a publicly-trusted certificate authority per se, and therefore it does not have to abide by the CA/Browser Forum's rules. With the exception of Apple platforms, most browser software does not include the DoD's root certificates by default. This means any secure site that uses a certificate issued by the DoD is unlikely to be trusted by a browser running on Windows or Linux, unless the user has explicitly installed the DoD's root certificates.

Even though the DoD does not have to abide by the CA/Browser Forum's rules, it is arguably a bad idea not to: The SHA-1 algorithm is now thought to be sufficiently weak that a well-funded attacker might be able to find a SHA-1 hash collision and hence impersonate any HTTPS website. It is also particularly surprising to see the DoD still using SHA-1 today when the US National Institute of Standards and Technology banned its use more than two years ago. Since NIST made this decision, the cost projections of finding a SHA-1 hash collision have reduced significantly.

On 4 January 2016, the DoD issued a SHA-1 certificate to [site report], which is a SharePoint portal hosted by the United States Army Information Systems Command. It can be accessed remotely by Common Access Card (CAC) holders. The certificate is marked as being valid until 8 September 2017.

The DoD is America's largest government agency, and is tasked with protecting the security of its country, which makes its continued reliance on SHA-1 particularly remarkable. Besides the well known security implications, this reliance could already prove problematic amongst the DoD's millions of employees. For instance, Mozilla Firefox 43 began rejecting all new SHA-1 certificates issued since 1 January 2016. When it encountered one of these certificates, the browser displayed an Untrusted Connection error, although this could be overridden. If DoD employees become accustomed to ignoring such errors, it could become much easier to carry out man-in-the-middle attacks against them.

However, the latest version of Firefox no longer rejects SHA-1 certificates issued after 1 January 2016. This change was made to cater for users of certain man-in-the-middle products, which generate freshly issued certificates on the fly. Consequently, users of Firefox 43.0.4 who have installed the appropriate DoD root certificates will currently not receive any errors, or even warnings, when browsing to the site:


Google intends to block all SHA-1 certificates issued from 1 January 2016 with the release of Chrome 48. In the meantime, Chrome 47 affirmatively distrusts the SHA-1 certificate used by because it does not expire until 2017.

Chrome regards the certificate as affirmatively insecure, even when the appropriate DoD root certificates are installed.

Chrome regards the certificate as affirmatively insecure, even when the appropriate DoD root certificates are installed.

Firefox will ultimately distrust all SHA-1 certificates by 2017, regardless of when they were issued, but Mozilla considered advancing this deadline to as early as 1 July 2016 when the new cost projections were realised.

More than 650,000 SSL certificates in use on the web are still using SHA-1, but this count has been rapidly falling since 2014. Nearly all of these certificates are due to expire by the end of 2016, in accordance with the Baseline Requirements; however, with most browser vendors contemplating an accelerated deprecation timeline, it is likely that many of these certificates will be replaced before the middle of the year.

With the US DoD PKI infrastructure seemingly still reliant on SHA-1, by the end of 2017, the DoD could account for a significant proportion of all SHA-1 certificates that are intended to be used by modern browsers.

BBC websites back to normal, DDoS mitigation reverted

The BBC's websites are now back to normal, four days after being taken down by an effective DDoS attack on New Year's Eve.

The BBC mitigated the attack within a few hours by moving its main website onto the Akamai content delivery network, which restored access to its millions of users. However, during this mitigation period, some of the BBC's other websites – which were still hosted at the BBC – remained mostly unreachable.

The BBC's DDoS mitigation was only temporary, and last night it moved its main website off Akamai, back onto a netblock owned by the BBC. This move resulted in another short outage on 4th January, followed by several hours of slightly slower response times within the UK. By the 5th January, the response times had settled down to be almost comparable with when it was using Akamai.

The main BBC website experienced another short outage last night as it moved off the Akamai CDN.

The main BBC website experienced another short outage last night as it moved off the Akamai CDN.

However, as expected, response times from other countries are no longer as fast as they were when the BBC's main website was hosted on the Akamai CDN. Response times from the US are notably slower, but currently no worse than they were before the DDoS attacks on New Year's Eve.

Response times from the US are now much slower again (although international visitors would typically visit rather than

Response times from the US are now much slower again (although international visitors would typically visit rather than

During the period in which the BBC's main website was hosted on the Akamai CDN, its legacy News website at remained hosted at the BBC. This was mostly unavailable during this period, with most client connection attempts being reset. is now functioning normally, too. is now functioning normally, too.

This site's availability was restored to normal at the same time that the main BBC website moved off Akamai. This suggests that the connection resets were a deliberate attempt to mitigate basic DDoS attacks, rather than as a direct side effect of a sustained DDoS attack. However, this approach was not ideal – while some browsers (such as Chrome) would automatically retry the connection attempt (often successfully), other browsers would give up at the first failure.

BBC websites still suffering after DDoS attack

Since suffering a crippling DDoS attack on New Year's Eve, some BBC websites are still experiencing significant performance issues.

Around 07:00 UTC on 31 December 2015, the main BBC website at was knocked offline after being subjected to a distributed denial of service attack. For the following few hours, requests to the BBC website either eventually timed out, or were responded to with its 500 Internal Error test card page. A group called New World Hacking later claimed responsibility for the attack, which it carried out as a test of its capabilities.

Requests that did not time out were eventually met with the BBC test card error page.

Requests that did not time out were eventually met with the BBC test card error page.

The British Broadcasting Corporation is the public service broadcaster of the United Kingdom, and the outage had a significant impact on its user base: The BBC's news, sport, weather and iPlayer TV and radio catchup services are all delivered via

Performance chart for, showing the primary outage period.

Performance chart for, showing the primary outage period.

At the time of the attack, was served from a netblock owned by the BBC. It seems that service was restored by migrating the site onto the Akamai content delivery network, after which there were no apparent outages.

OS Server Last seen IP address Netblock Owner
Linux nginx 3-Jan-2016 Akamai
Linux nginx 2-Jan-2016 Akamai Technologies
Linux nginx 31-Dec-2015 Akamai Technologies
Linux nginx 30-Dec-2015 BBC
Linux nginx 29-Dec-2015 BBC
Linux nginx 28-Dec-2015 BBC

Moving onto the Akamai CDN also resulted in some significant performance benefits, particularly from locations outside of the UK. For example, prior to the attack, most requests from Netcraft's New York performance collector took around 0.4-0.6 seconds to receive a response, whereas after the site had migrated to Akamai, all requests were served in well under 0.1 seconds. These performance benefits are typical when using a globally distributed CDN, as cached content can be delivered from an edge server within the client's own country, rather than from a remote server that can only be reached via transatlantic cables.

Performance chart for from  New York, highlighting the improved response times and successful attack  mitigation after switching to Akamai.

Performance chart for from New York, highlighting the improved response times and successful attack mitigation after switching to Akamai.

However, not all of the BBC's websites have migrated to Akamai, and some of these are still exhibiting connectivity issues in the aftermath of the attack. For example, and are still hosted directly at the BBC, and these are still experiencing problems today.

The BBC's News service is currently found at, but up until a few years ago it used to be served from its own dedicated hostname, This legacy hostname is still used by some webpages today, but mostly redirects visitors to the new site at This conveniently collates all of the BBC's main online services under the same hostname, but at the expense of introducing a single point of failure. If each service were still to be found under a different hostname and on different servers, it might have offered further resilience to the initial attack.

The performance chart for shows massive outages long after the DDoS attack on New Year's Eve.

The performance chart for shows massive outages long after the DDoS attack on New Year's Eve.

As shown above, was also affected by the DDoS attack which took down the main BBC website, but eventually came back online later that day without having to relocate the website. However, the following morning (New Year's Day), it started to experience significant connectivity problems.

Most requests to are still failing.

Most requests to are still failing. Some browsers, such as Chrome, may automatically retry the request.

It is unclear whether this indicates a separate ongoing attack, or an attempt at mitigating such attacks, but nonetheless, it is likely to affect lots of users: Many old news articles are still served directly from, and some users habitually reach the news website by typing into their browsers. Some regularly updated pages also continue to be served from, such as horse racing results.

Most Reliable Hosting Company Sites in December 2015

Rank Performance Graph OS Outage
DNS Connect First
1 EveryCity SmartOS 0:00:00 0.000 0.093 0.064 0.128 0.128
2 Lightcrest unknown 0:00:00 0.004 0.276 0.006 0.023 0.027
3 Linux 0:00:00 0.004 0.203 0.037 0.105 0.105
4 Memset Linux 0:00:00 0.004 0.153 0.064 0.157 0.245
5 ServerStack Linux 0:00:00 0.004 0.125 0.067 0.135 0.135
6 Netcetera Linux 0:00:00 0.004 0.075 0.084 0.171 0.171
7 Codero Citrix Netscaler 0:00:00 0.004 0.177 0.092 0.189 0.381
8 Inc Linux 0:00:00 0.008 0.264 0.007 0.018 0.018
9 Datapipe Linux 0:00:00 0.008 0.145 0.012 0.024 0.031
10 Swishmail FreeBSD 0:00:00 0.008 0.144 0.062 0.125 0.168

See full table

EveryCity had the most reliable hosting company site in December 2015. Despite moving into new offices, its website was the only one to respond to all of Netcraft's requests. EveryCity has maintained its 100% uptime record throughout 2015, and has made it into the top ten 11 times during the year. It also had the most reliable hosting company site in May.

In second place in December was Lightcrest, which also appeared in the top ten in November. It experienced only one failed request, with an impressively fast average connection time of 6 milliseconds. Lightcrest operates its cloud services using its own Kahu Compute Fabric infrastructure, without outsourcing any components to third-party cloud providers.

In third place – also with a single failed request, but with a slower average connection time – was Established in 2002, now has over 270 employees with companies registered in Denmark, India and Dubai.

Six of December's top ten hosting company sites ran on Linux operating systems, while Swishmail used FreeBSD, Codero used a Citrix Netscaler device, and EveryCity used SmartOS. The latter is a community fork of OpenSolaris, featuring the ZFS file system, DTrace dynamic tracing, kernel-based virtual machines and Solaris Zones operating system-level virtualisation.

Netcraft measures and makes available the response times of around forty leading hosting providers' sites. The performance measurements are made at fifteen minute intervals from separate points around the internet, and averages are calculated over the immediately preceding 24 hour period.

From a customer's point of view, the percentage of failed requests is more pertinent than outages on hosting companies' own sites, as this gives a pointer to reliability of routing, and this is why we choose to rank our table by fewest failed requests, rather than shortest periods of outage. In the event the number of failed requests are equal then sites are ranked by average connection times.

Information on the measurement process and current measurements is available.

December 2015 Web Server Survey

In the December 2015 survey we received responses from 901,002,770 sites and 5,579,077 web-facing computers, reflecting a loss of 2.0 million sites, but a gain of 39,900 computers.

Apache suffered the largest loss of 13.4 million sites, followed by Microsoft, which lost 5.0 million. A good part of this month's overall losses were caused by expired .xyz domains, which resulted in nearly 9 million .xyz websites disappearing from the internet. Despite the widespread losses caused by the demise of these websites, nginx managed to gain 7.1 million sites overall, which was the largest growth seen by any web server vendor.

The .xyz top-level domain was made available to the general public on 2 June 2014 and immediately received strong support from Network Solutions, which registered nearly 100,000 .xyz domains during the first ten days of operation. Controversially, Network Solutions gave away many .xyz domains for free to customers who already had the corresponding domain under the .com TLD. This was done on an opt-out basis, and the domains were only free for the first year, leaving some customers surprised when each domain became due for renewal at a cost of $38 this year.

Google's parent company, Alphabet Inc, is one of the most notable users of the .xyz TLD with the domain, while some of the other popular .xyz sites include adult sites and torrent search engines. The .xyz TLD has also proven reasonably popular with fraudsters: Netcraft found phishing sites on 150 .xyz domains throughout November 2015.

This month's changes have caused Apache's leading market share to fall by 1.41 points to 35.6%, while nginx's site share has increased to 17.4%. A little over a year ago, Microsoft was in the lead, but has recently been floating around in second place, currently 9.2 percentage points ahead of nginx, and 9.0 behind Apache.

As well as gaining the largest number of sites this month, nginx also showed the largest growth in terms of web-facing computers, growing by 17,000 to reach a total of 765,000. Despite their site losses, Apache and Microsoft also gained a reasonable number of web-facing computers (10,400 and 6,100), while Lighttpd and Google suffered small losses.

A relatively unknown web server, Safedog, was found serving nearly ten times as many websites as last month, making it now the 7th most commonly used web server software with 6.3 million hostnames. However, the number of web-facing computers with Safedog installed is very low – less than 300 – and nearly all of these are running the deprecated Windows Server 2003 operating system. All websites using this Chinese server software claim to be running Safedog 4.0.0, which appears to be a cloud security system.

2015 has been a turbulent year in terms of hostnames, with the total number of sites rising from 877 million in January, to 901 million in December, but dipping as low as 849 million in April. Apache has continued to lead the market throughout the year, with Microsoft following in second place, getting to within 4.1 percentage points of Apache's share in October. In web-facing computers, nginx has shown remarkably consistent growth in its market share, while both Apache and Microsoft have declined. nginx is now installed on 13.71% of all web-facing computers, compared with 11.03% at the start of the year, and its market share within the top million sites has also grown noticeably from 21.09% to 24.29%.

Total number of websites

Web server market share

DeveloperNovember 2015PercentDecember 2015PercentChange
Continue reading