My WordPress Website Was Hacked

Before you freak out, allow me to clarify. It was one of several honeypots we have running. The honeypots are spread across the most commonly employed hosting companies. From Virtual Private Servers (VPS) to shared environments, to managed environments. In most instances we pay and configure them like any other consumer would so that we aren’t given any special treatment.

Honey Pot Systems are decoy servers or systems set up to gather information regarding an attacker or intruder into your system… A Honey Pot system is set up to be easier prey for intruders than true production systems but with minor system modifications so that their activity can be logged or traced. The general thought is that once an intruder breaks into a system, they will come back for subsequent visits. During these subsequent visits, additional information can be gathered and additional attempts at file, security and system access on the Honey Pot can be monitored and saved. – SANS

Our goal is simple; we want to better understand the dynamic nature of website security and continue to analyze and interpret attackers’ intentions. Having live sites that we allow to get hacked also keeps us sharp in terms of how we respond to these intrusions and, if we’re being completely honest, helps us to better understand the emotions that a website owner, like yourself, might go through. Between you and I though, it really gets us excited.. almost as excited as a spider when they feel their web vibrating as their prey struggles to free itself.. but I digress..

Sucuri - My Website was Hacked - Defacement

Sucuri – My Website was Hacked – Defacement



Read More

New Brute Force Attacks Exploiting XMLRPC in WordPress

Brute force attacks against WordPress have always been very common. In fact, Brute Force attacks against any CMS these days is a common occurrence, what is always interesting however are the tools employed to make it happen.

You create a website, because it’s super easy these days, publish the content and within a few weeks people try to repeatedly log in. These login attempts come from botnets, they are automated and their goal is simple “break into as many websites as they can by guessing their passwords.” Once they find one that matches, they take over of the site and use it to distribute malware, spam and similar activities.

Here is a small example, from our own honeypots, where we see hundreds of login attempts per day, trying various combinations:

user: admin, pass: admin
user: admin, pass: 123456
user: admin, pass: 123123
user: admin, pass 112233
user: admin, pass: pass123
..

The passwords may seem silly, but after going through the most common 200/300 dictionary passwords, they can get into many web sites.

XMLRPC wp.getUsersBlogs

Originally, these brute force attacks always happened via /wp-login.php attempts, lately however they are evolving and now leveraging the XMLRPC wp.getUsersBlogs method to guess as many passwords as they can. Using XMLRPC is faster and harder to be detected, explaining this change in tactics. This is not to be confused with our post back in March where we reported XMLRPC being used to DDOS websites, oh no, in this instance they are leveraging it to break into websites. Be sure to read up on the differences between Brute Force and Denial of Service attacks.

This attack is being made possible because many calls in the WordPress XMLRPC implementation required a username and password. It these attacks, we are seeing wp.getUsersBlogs being used (and very few times wp.getComments), but it could be other calls as well. If you provide a user and a password to them, it will reply back if the combination is correct or not:

<methodCall><methodName>wp.getUsersBlogs</methodName><params><param><value>
 <string>admin</string></value></param>
  <param><value><string>112233</string></value></param></params>
</methodCall>

In the example above, the attackers tried the user admin with the password 112233.

Large Scale brute force

To examine the scale of this attack, we went back through our logs to get a better sense for the scale of the attacks. The past couple of weeks have been interesting, the attacks have increased ten-fold with almost 2 million attempts since the beginning of July coming from 17,000 different source attacking IPs. Some days we were seeing almost 200k attempts.

wordpress-brute-force

The only reason these numbers are not higher is because we’re killing the logs after block attempts, so all you are seeing is the gradual increase in attacks, but not the complete picture. This is what makes this entire thing very scary for website owners.

Another interesting point about this attack is the user names being tried. Instead of relying only on “admin”, it tries to find the domain name and the real admin of the site and use it instead. These are the top user names tried:

 179005 test
 167147 admin
  32030 sitedomain (domain modified to protect the innocent)
  15850 sitedomain2 (domain modified to protect the innocent)
   9590 realsiteadmin (user name modified to protect the innocent)
   9564 realsiteadmin2 (user name modified ..)

So out of 2 million attempts, only 167k used the user name admin. That shows that just disabling the admin user name, does not help if the attackers can easily find out the real user. One small reason we no longer subscribe to the argument of removing the “Admin” user to be secure.

As for the passwords, they are using the most common passwords found in many dictionaries:

   1dc13d
   admin
   123123
   admin1
   admins
   123456
   12345678
   7777777
   letmein
   121212
   qweqwe
   iloveyou
   administrator
   holysh!t
   55555
   1q2w3e
   qwerty
   wordpress
   wpsite
   internet
   asdfghjkl
   121314
   lollipop
   killer
   pass
   lovers
   hello
   dragon
   admin123
   office
   jerome
   fyfcnfcbz
Brute Force Protection

There are many ways to block brute force attacks. If you have a dedicated server, you can install OSSEC (open source) on it and let it automatically block the IP addresses that miss too many passwords. We automatically include brute force (password guessing) protection on our Website Firewall (CloudProxy), so if you are looking for a 1-click solution, you can leverage it.

There are obviously a number of application level tools (i.e., plugins) many will recommend within the WordPress ecosystem to help with Brute Force attacks. Here is the thing, none of the ones we tried will protect you from the XMLRPC calls, including our own plugin. It’s likely why we’re seeing the shift in attack methods. Blocking at the edge is going to be your preferred method until that gets fixed.

Understanding Denial of Service and Brute Force Attacks – WordPress, Joomla, Drupal, vBulletin

Many are likely getting emails with the following subject header Large Distributed Brute Force WordPress Attack Underway – 40,000 Attacks Per Minute. Just this week we put out a post titled More Than 162,000 WordPress Sites Used for Distributed Denial of Service Attack.

What’s the Big Deal?

Remember life before social media? How quiet and content we seemed to be? How the only place we got our information was from the local news or cable outlet? Maybe a phone call, or via email? Today however, we seem to be inundated with information, with raw unfiltered data, left to our thoughts and perceptions of what they really mean. Every day there is some new tragedy, a plane goes missing, a child is abducted, a school shooting, the brink of WWW III. Is it that we live in a time where we are all losing our mind? Or maybe, could it be that the only difference between now and then, is the insane amount of information at our finger tips?

With this in mind, yes, it’s true, there are ongoing Distributed Denial of Service (DDoS) and Brute Force attacks against WordPress sites. In fact it extends far beyond that specific platform, it’s affecting many other platforms like vBulletin, Joomla, Drupal. The reality is that these attacks have been ongoing for many months now, so much so, that they’ve become part of our daily life and it’s not when they happen that we’re surprised, quite the contrary, when they don’t.

Read More

Big Increase in Distributed Brute Force Attacks Against Joomla Websites

Update: Brute force protection now available: http://cloudproxy.sucuri.net/brute-force-protection


A few months ago, we discussed and published details about a very large brute force attack targeting WordPress sites.

The attackers (bad guys) had thousands of servers at their disposal, and were attempting all types of passwords on wp-admin (WordPress admin panel) to try to get access to as many WordPress sites as possible. The attacks lasted for a few weeks and then it calmed down. I can’t attest to their successes, but knowing how bad people are at choosing passwords, I guess it worked well for them.

Lately, we started to see the same thing happen to Joomla sites. While most of the sites we monitor would get a few brute force attempts per day in the past, the last couple of days all of them are getting thousands of requests daily.

Against one website, we saw 11,349 requests during the course of a few hours coming from 1,737 different IP addresses. Each IP address was trying to log in once or twice. And after a few hours, it would try again, making this type of attack very hard to detect and block.

Joomla Brute force timeline

We have seen an average of 6,000 brute force attempts against Joomla sites daily across our honeypots and CloudProxy networks. Some days the attacks increased to almost 13k, and dipped as low as 3k attempts. However, for the last 3 days, you can see a big increase, reaching almost 269,976 scans yesterday, September 2nd, 2013. That’s a very big increase out of nowhere.

We also started to see customers complaining about excessive resources utilization, similar to what happened with the WordPress attacks.

Joomla Brute Force Chart

Read More

Dissecting a WordPress Brute Force Attack

Update: Brute force protection now available: http://cloudproxy.sucuri.net/brute-force-protection


Over the past few months there has been a lot of discussion about WordPress Brute Force attacks. With that discussion has come a lot of speculation as well. What are they doing? Is it a giant WordPress botnet? Is it going to destroy the internet? Well, as you would expect of any good geeks we set out to find a way to find out.

This is not to be exhaustive case study or meant to be a representative sample of what all attacks look like, but it does have similar characteristics to the types of attacks and infections we deal with on a daily basis.

In this post, my goal is to highlight a hack that occurred this weekend, July 20th to be exact, against one of our several honeypots. In this specific instance, it was setup and configured approximately 2 months ago. It had been hacked about a month and a half ago and silly me I forgot to configure what I needed to do real forensics, oops. In any event, everything was cleared and pushed out again to see what happened, it was nothing more than a matter of sitting back and waiting.

Sure enough, about 30 days later and it was hacked, this time we were ready to see what happened..

Read More

SSH Brute Force – The 10 Year Old Attack That Still Persists

One of the first server-level compromises I had to deal with in my life was around 12 ago, and it was caused by a SSH brute force attack. A co-worker set up a test server and chose a very weak root password for it. A few days later, the box was owned running IRC bots and trying to compromise the rest of the network.

That was just the first of many server-level compromises caused by SSH brute force attacks that I would end up responding to, and even after more than 10 years, quite a few of the server remediations that we do here at Sucuri are actually caused by the same thing.

Read More