Blog

Analysis: Methods and Monetization of a Botnet Attacking WordPress

At Wordfence we see a huge range of infection types every day as we help our customers repair hacked websites. We also find new kinds of malware as we analyze the forensic data we gather from a range of sources. Our normal day involves turning that forensic data into firewall rules and scan signatures which we deploy to your Wordfence firewall and malware scan via our Threat Defense Feed.

Those rules and signatures are then used by Wordfence to protect your site against the newest attacks. Our Premium customers receive those rules in real-time and our free customers have a 30 day delay.

Occasionally, as we examine our forensic data and turn it into threat intelligence, we run across interesting behaviors both in human attackers and the bots they control. Recently our analysts took a closer look at a botnet that is using stolen WordPress usernames and passwords to compromise WordPress sites and generate an income from the hacked sites.

In this post we go into some detail about how this botnet works and how its owners make money. We have given this botnet the codename “ChickenKiev” or CK for short.

Botnet Profile: ChickenKiev

About the botnet: Vital Statistics

Number of attack bots	83
Location:	35 bots in Ukraine, 10 in USA, 8 in UK, includes several other countries.
Networks	Most bots are on: 213.231.44.0/22, 91.210.144.0/22 and 109.200.224.0/19
Time Active:	At least 2 months starting 24 November until present
Responsible for:	A large number of hack attempts and compromised websites.

How the CK Botnet Works

The owner of the CK botnet is feeding CK stolen WordPress administrator credentials which the botnet uses to sign into WordPress websites and perform its malicious activity. The credentials are probably acquired through brute force attacks. The attacker may have performed the attacks themselves or has managed to acquire a database of compromised credentials from someone else.

At the start of its attack, CK logs into WordPress websites and uses the WordPress theme or plugin upload tools to install fake themes or plugins containing malicious code. Once it has the base malicious payload installed, CK installs additional backdoors and code that uses the website for malicious purposes.

The access log below shows a typical series of requests where CK is doing its initial infection of the website. This is a real access log from a website that was infected by CK which we repaired. We have redacted sensitive information to protect our site cleaning customer’s privacy.

As you can see, this bot which is part of the CK botnet visits wp-login.php and signs in as an ordinary user would. It then visits the plugin installation page in the WordPress administrative console. It installs a plugin that is made to look like the popular BB Press forum software.

At this point, infection by CK is complete. The bb_press.php code contains a backdoor that allows the attacker that is controlling CK full and continuous access to the hacked website.

What CK Installs on Hacked WordPress Sites

In addition to the fake BB Press plugin shown in the log above, we have seen CK also install the following fake plugins or themes:

/wp-content/plugins/wp-db-ajax-made
/wp-content/plugins/Akismet3
/wp-content/themes/sketch

CK uses a well known shell as a backdoor which is known as the WSO shell. It stores the backdoor in a file called wp-ajax.php which is made to look like a legitimate WordPress core file.

The backdoor is installed in fake theme and plugin directories and is also inserted by CK into real plugin and theme directories. Here are some of the locations we have found CK’s backdoor. Most of these locations use the filename wp-ajax.php. In some cases a different filename is used.

/wp-content/plugins/wp-db-ajax-made1/wp-ajax.php
/wp-content/plugins/wp-db-ajax-made/wp-ajax.php
/wp-content/plugins/ml-slider/wp-ajax.php
/wp-content/plugins/siteorigin-panels/wp-ajax.php
/wp-content/plugins/wp-db-ajax-made/wp-ajax.php
/wp-content/plugins/Akismet3/wp-ajax.php
/wp-content/plugins/accesspress-twitter-auto-post/wp-ajax.php
/wp-content/plugins/advanced-custom-fields/wp-ajax.php
/wp-content/plugins/ajax-thumbnail-rebuild/wp-ajax.php
/wp-content/plugins/bb_press/wp-ajax.php
/wp-content/plugins/bb_press1/wp-ajax.php
/wp-content/plugins/bb_press2/wp-ajax.php
/wp-content/plugins/oa-social-login/wp-ajax.php
/wp-content/plugins/wp-db-ajax-made-1/wp-ajax.php
/wp-content/plugins/wp-db-ajax-made-2/wp-ajax.php
/wp-content/plugins/wp-db-ajax-made/wp-ajax.php
/wp-content/themes/sketch/404.php
/wp-content/themes/twentyeleven/wp-ajax.php
/wp-content/themes/twentyfourteen/author.php
/wp-content/themes/twentyfourteen/wp-ajax.php
/wp-content/themes/twentyten/wp-ajax.php
/wp-content/themes/twentythirteen/wp-ajax.php
/wp-content/themes/twentytwelve/author.php

How CKs Operators Profit from Hacking Your Site

Once CK has infected your site, we have a seen the operators engage in a range of malicious activity. One of the ways these operators profit is by injecting their own Google ad banners into your site header files.

This causes your website to serve Google ads associated with the CK operator’s Google account. They profit from your website serving Google ads.

The CK operators inject their own Google ad code into your site header by using the WSO shell they installed. They can use the shell to execute any PHP code on your website. To install their ads, they execute the following code via their shell: (We have redacted sensitive content)

The code above searches for files called header.php or header-homepage.php. It looks for the closing tag in those files. It adds the Google ad banner code just before your site’s closing tag.

This causes your site to serve their own Google ads, allowing them to profit from the traffic that is visiting your website.

We have seen CKs operators engage in other malicious activity like installing additional administrative code to help them control hacked sites and installing code that redirects a hacked website’s traffic to other websites that they control.

How to Protect Yourself from CK

CKs owners need to get WordPress administrator logins to be able to install their malicious code. To do this they need to engage in brute force attacks or find another way to steal an administrator username and password.

Here are a few things you can do to keep your admin account safe:

Enable Wordfence on your website. It provides excellent brute force protection in the free and paid version.
If you are a Premium Wordfence user, enable two factor authentication, also called cellphone sign-in.
Ensure you use a long and complex password. 12 characters or more with a random combination of letters, numbers and symbols. Include upper and lower-case letters.
Make sure the Wordfence Firewall is enabled to block exploits that can compromise your admin account.
Don’t use the same password on other WordPress websites or accounts. If one of your sites is hacked this can result in the others getting hacked too.

The Wordfence malware scan detects all of the indicators of compromise that CK leaves behind. If you are worried that you may have been hacked, simply run a Wordfence scan to check your site status. Wordfence also does an excellent job of preventing any compromise from happening in the first place.

What to do if you have been hacked

At Wordfence we have an excellent team of security analysts who respond to incidents many times every day. If you have been hacked, our team can determine why, close any security holes, clean the hack and get you back up and running within a very short time.

Our site cleaning service includes blacklist removal, a 1 year Wordfence Premium license and we provide an in-depth report to help you understand what happened and how to prevent a hack in future.

Wordfence site cleaning is also very reasonably priced at $149 with no surprise fees and we provide excellent customer service.

Stay Safe

I’d like to encourage you to share this post with the community to create awareness and help other site administrators avoid a hack. If you have any questions or comments, please post them below and as always I’ll be around to reply when needed. Have a great week and stay safe!

Mark Maunder – Wordfence Founder/CEO.

Credits: Thanks to Senior Wordfence Security Analyst Brad Haas for doing the forensic analysis in this post. Additional thanks to members of our site cleaning team for their help. Thanks to Dan Moen for editing.

The post Analysis: Methods and Monetization of a Botnet Attacking WordPress appeared first on Wordfence.

February 10, 2017

Do You Need a WordPress Security Plugin?

At Wordfence we are a big team these days with millions of customers, and we think about security all day long. Sometimes we can get deep down the proverbial rabbit hole and forget about the basics.

I recently overheard someone asking “Do I really need a WordPress security plugin?” and I realized this is a perfectly valid question. If you are not in the security industry, you might ask it.

I know that many of you are well versed in security already – and WordPress security in particular. Perhaps that is why you are reading this post or subscribe to our mailing list. What I would like to provide you with in this post is a way to answer the question of “Do I need a WordPress security plugin?” to friends, family and colleagues that is both enlightening and easy to understand.

If you are new to WordPress, I hope this post helps increase your understanding of WordPress security.

Physical Security compared to WordPress Security

Many people think about WordPress security in the same way that they think about physical security in the real world. In the physical world, we might build a facility like a bank that needs to be secured. We build barriers to entry and access controls as part of the construction project.

Once the project is complete, we have a secure facility with walls, gates, secure entry and exit, cameras, access controls and human personnel to implement security procedures as people enter and exit. The physical construction does not change much over time, once the project is completed.

You are unlikely to discover that the concrete you used to build a wall for your bank is now vulnerable and needs to be replaced. A wall is still difficult to penetrate and a locked gate with a guard is going to still be quite effective a few months from now.

It is easy to make the mistake of thinking about WordPress security in the same way. If you install software that is secure to power your WordPress website and you implement good security policy and controls, one might think a website would behave in the same way. In other words, one might think a secure website today should be secure a few months from now if it doesn’t change.

That is not the case and I’m going to explain why. If you build a website using the newest software that has been verified to be secure and you implement good security policy, your website does not change, but the environment it is operating in changes. Attackers continually research the software that powers your website and vulnerabilities are eventually discovered in most popular online software.

Therefore the problem is that, while your website software starts off secure, it almost always ends up being insecure without anything changing on your website. It’s not your fault or the fault of the person who created your website. It is just the way of the online world. This differs from our building metaphor above in that a secure building doesn’t usually end up insecure a couple of months after being built without anything in the building changing. But a website does.

In fact, this is an ongoing cycle. Vulnerabilities are discovered, attackers start using them and ultimately if you are a responsible WordPress site owner, you upgrade your site regularly to fix those vulnerabilities. Then new vulnerabilities are discovered in new versions and the cycle repeats.

The Time Gap Between Vulnerability Knowledge and Installation of a Security Fix

You might build a new website with the latest secure versions of WordPress and all of the relevant plugins and a theme. As time passes, vulnerabilities are discovered in your plugins, theme and the version of WordPress core you are using. Those vulnerabilities (or security holes) become public knowledge at some point.

There is usually a delay between when the vulnerability becomes public knowledge and when you get around to installing a fix. Even when a fix is automatically released by the WordPress security team, the vulnerability may have been public knowledge for some time. This was the case with the recent PHPMailer vulnerability, which took several weeks for a patch to appear in WordPress core and be automatically deployed.

A WordPress security plugin provides many valuable functions, but at its most basic, a WordPress security plugin protects your website from attacks during the time it is vulnerable.

We do this in two ways. Wordfence provides a firewall that has rules that are constantly updated. At Wordfence, when we learn about a new security hole in software that you might use, we release a firewall rule to your site that allows Wordfence to block hackers from exploiting that security hole.

The second way we protect you is by providing a malware scan. Wordfence detects thousands of malware variants. If the worst happens and somehow a hacker does manage to penetrate your website, Wordfence alerts you to the presence of malware on your website and even helps you find it and remove it. Our malware signatures are also continually updated.

As many of you know, our Threat Defense Feed is what distributes new firewall rules and malware signatures to your Wordfence security plugin. Our Premium customers receive these in real-time. Free customers are delayed by 30 days.

Protecting You When You’re Vulnerable is What We Do

Wordfence provides many other security functions including two factor authentication, country blocking, brute force protection, rate limiting and more. But the most important function we provide is this: Wordfence protects your WordPress website once vulnerabilities are discovered in your previously secure website and before you have installed a fix.

Most websites are hacked as a result of an attacker gaining entry by exploiting a vulnerability in the website software. By using an effective WordPress firewall like Wordfence with a real-time Threat Defense Feed, you are protected, even if your website suffers from a vulnerability.

I hope this has helped provide a fundamental understanding of the most important reason you or someone you know needs a WordPress security plugin like Wordfence. As always I welcome your feedback in the comments below.

Stay safe!

Mark Maunder – Wordfence Founder/CEO.

Thanks to Dan Moen for editing this post.

The post Do You Need a WordPress Security Plugin? appeared first on Wordfence.

February 10, 2017
Announcing Wordfence 6.3.0 – Exciting Improvements
This morning I’m very excited to announce the release of Wordfence 6.3.0. This is one of our bigger releases and it includes a few exciting changes to the user interface and the way Wordfence helps you secure your site.

Since 2012, Wordfence has been securing WordPress. We started with a handful of important security features. As Wordfence became successful, as the team grew and as we improved the product, the list of menus in Wordfence kept increasing.

Another side-effect of improvements in Wordfence is that the number of things you need to pay attention to also increased.

In user interface design, as with just about everything else, attention is in short supply. We are all busy with plenty of other important things to do in our day to day lives. Securing our WordPress websites is just one of our many priorities.

With the release of Wordfence 6.3.0, the team started by thinking carefully about what is most important when it comes to security. We also looked at the range of functions that Wordfence provides and how they are related to each other.

Finally, the team considered how best to communicate with our users when they have a security problem or something else important they need to know about.

Introducing the Wordfence Dashboard

The first change we’ve introduced is the new Wordfence Dashboard.

The Wordfence Dashboard appears at the top of the new menu structure on the left in your WordPress admin console. The Dashboard is a way for you to view your security posture at a glance. Some of the data the new Dashboard includes is:
- When your last scan completed.
- If any security problems were detected.
- Important security notifications.
- What security features are enabled and disabled.
- The number of Threat Defense Feed rules you have enabled and protecting your site. These are malware signatures and firewall rules.
- Attacks that have been blocked by Wordfence during the past day, week and month.
- The top IP addresses we have blocked in the past day, week and month.
- Attacks blocked over time (a chart) across the Wordfence network of sites we protect.
- The top countries that attacks on your website are originating from.
- Successful and failed login attempts on your WordPress site.
The Dashboard is completely new, available at the top of your WordPress menu and gives you an instant view of your WordPress site security status.

Menu Redesign

The next thing you will notice in the newest version of Wordfence is the redesign of the menu on the left side of your site.

As you can see the Dashboard is at the top of the new menu and is your “jump off” point because it provides an overview of your website security.

Scan Page Improvements

The next item is the “Scan” menu which combines Scan and Scheduling. We have also introduced a new scan “options” tab which gives you instant access to all the Wordfence options that affect your scan. You no longer need to go to the separate “options” menu to change your scan settings – it’s right where scan is.

Meet Your New Firewall Page

The new ‘Firewall’ option on the menu is one of the most exciting changes in Wordfence 6.3.0 because it consolidates all firewall related security options onto a single page which looks like this:

As you can see above, the new tabs on this page give you tabbed access to:
- Your Web Application Firewall configuration or WAF. This is the most important firewall option available because our WAF provides the best protection available against attacks.
- Country Blocking which allows you to selectively block countries.
- You can view and manage Blocked IPs.
- Advanced Blocking gives you the ability to build blocking patterns based on address ranges, browser, referring site and more.
- Brute Force Protection which lets you prevent login and password guessing attacks.
- Rate Limiting which gives you the ability to limit the rate at which automated crawlers access your site.
Live Traffic is Unchanged and Awesome

The Live Traffic menu option still takes you to the same live traffic page that includes advanced filtering and a real-time view of your website activity. As always, live traffic shows you attacks being blocked in real-time.

Introducing the new ‘Tools’ menu option

The Tools menu option in Wordfence is new. It combines our powerful security tools into a set of tabs that lets you easily find and access them:

As you can see we have combined the following:
- Password Audit is now the default tab visible when you hit the ‘Tools’ page.
- The Whois Lookup lets you get detailed information on an attacking IP address or hostname.
- Cellphone Sign-in gives you the ability to enable and manage two-factor authentication on a per-user basis.
- The Diagnostics page is our page for diagnosing issues with your system. It provides tools and information related to diagnostics.
The Options Page Remains Unchanged

The Wordfence ‘Options’ page at the bottom of our menu gives you the ability to manage all of your Wordfence options in one place. It is also where you install your Wordfence Premium API key if you have purchased one, in order to upgrade to Wordfence Premium.

Always Improving

Improving Wordfence is a collaborative process. I’d like to thank our user community for all the valuable feedback they’ve given us over the past months and years. Whether you have contributed in the comments on this blog, in our public forums or via a Premium support ticket, we appreciate your input.

Wordfence will continue to evolve and improve this year. We have a few exciting new features we will be announcing later this year that will help make your website even safer.

Please leave your feedback in the comments. Because this is a release announcement, I should add that we don’t recommend you post support requests in the comments below. Our support team does not check these comments. They are waiting to help you in our public support forum and in our Premium ticketing system.

Finally, a huge congratulations to all the team members involved in this release. This was a big one with many moving parts and a lot of testing. Congratulations team!

The post Announcing Wordfence 6.3.0 – Exciting Improvements appeared first on Wordfence.
February 10, 2017
XMLRPC or WP-Login: Which do Brute Force Attackers Prefer

At Wordfence we constantly analyze attack patterns to improve the protection our firewall and malware scan provides. We recently took a closer look at brute force attack targets, specifically XMLRPC and wp-login, to gain a deeper understanding of how attackers behave.

In WordPress, there are several ways to authenticate, or sign in to, your website. The two most common ways to authenticate are using the standard login page located at wp-login.php, and by using XMLRPC.

The XMLRPC method is usually used by applications like mobile apps to authenticate before you are able to perform privileged actions on the site.

We analyzed attack data over a 2 week period from January 16th until Janary 29th to determine which target attackers prefer to attack. Here are the results of our analysis.

Which Target Receives More Attacks?

During a two week period we saw almost exactly the same number of attacks on XMLRPC as wp-login. We saw a total of 106 million attacks on wp-login compared to 108 million attacks on XMLRPC.

This result surprised me because I assumed that attackers targeting XMLRPC would be more sophisticated or perhaps creative. But on reflection it takes about the same amount of effort to write an attack script or bot that brute force attacks either target. So this makes sense.

How Many Attackers Hit Both XMLRPC and WP-Login?

The above graph shows the number of unique IP addresses per attack target. Note that this is not the number of attacks, but number of attackers counted as unique IP addresses we saw attacking.

While XMLRPC saw slightly more attacks, wp-login saw slightly more unique attackers, as you can see from the above column chart.

We saw 11,453 attackers only targeting XMLRPC. We saw 38,771 attackers only targeting wp-login. And we saw a whopping 224,461 unique IP addresses targeting both XMLRPC and wp-login.

Clearly most brute force attacks target both XMLRPC and wp-login.

Do Attackers in Different Countries Prefer XMLRPC or WP-Login?

We analyzed attacks from the top attacking countries and saw an interesting trend. As you can see above, most of the attacks come from Russia and the USA is the second most prolific attacker.

What is interesting here is that the attacks originating in Russia have a strong preference for wp-login as a target. And attacks originating in the USA have the opposite preference. They seem to mostly target XMLRPC instead.

Digging Deeper into Brute Force Attacks originating in the USA

As you can see the majority of the total number of attacks originating in the USA come from Amazon.com which provides cloud computing services to developers. We saw a total of over 144 million attacks over two weeks originate from Amazon.

Most of these attacks were targeted at XMLRPC. What is surprising though is that they came from only 36 unique IP addresses hosted at Amazon. All but 3 of these IP addresses appear to be EC2 instances based on their reverse hostnames.

So what is happening here? I’m going to suggest two theories:

One possibility is that 36 servers at Amazon EC2 have been compromised and they have been used to launch a very rapid and wide-spread brute force attack during the past 2 weeks. That attack generated over 144 million failed login attempts across the sites we monitor.

An alternative theory is that a developer may be using EC2 to host an application that is trying to sign into WordPress websites using XMLRPC. The application may not handle bad user credentials correctly and may just keep retrying.

It may be a combination of both bad applications hosted at EC2 and compromised servers engaging in a large scale brute force attack.

Conclusion

The data in this post brings up the old debate about whether or not it’s a good idea to hide your login page. Unless you hide every login method on your site, attackers will still be able to brute force your website.

If you disable or move XMLRPC, you risk breaking various applications, including mobile applications, that rely on XMLRPC to do their job.

If you hide or move your login page, you are going to inconvenience or confuse your users, and XMLRPC is still an attack vector.

Other authentication methods will soon become available in WordPress via, for example, the WP REST API. These will also be exploited by attackers.

So the action we recommend is that you use a security product like Wordfence to intelligently block brute force attacks, no matter what they target. Wordfence counts brute force attacks across all authentication methods and blocks attackers if they violate security policy.

Wordfence can also help you enforce strong passwords and audit your passwords for strength.

We also track attacks across all the sites we protect and take earlier blocking action against known bad IP addresses that have attacked other websites.

As always I welcome your comments below and I’ll be around to join the discussion.

Mark Maunder – Wordfence Founder/CEO

Special thanks to Dan Moen who produced much of the data used in this post and to assistance from our team in analyzing the data.

The post XMLRPC or WP-Login: Which do Brute Force Attackers Prefer appeared first on Wordfence.

February 10, 2017