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.
Note that the only security configuration on the site was our WordPress Security plugin for auditing. It did NOT include our Website AntiVirus or Website Firewall products. The idea was to encourage attackers to penetrate the website so that we can analyze their actions and impacts to the website, not to stop them.
The free Sucuri WordPress Security plugin is not a preventive tool, it falls into the detection / monitoring realm of security. It’s designed to support your administration tasks. If you are looking for a security utility plugin, one that allows you to configure every aspect of your site then you will want to consider other security plugins that fit into that category.
Security Tools Enable Actions
It was my Activity Monitor that notified us to the problem. The activity monitor is part of our free WordPress Security plugin. Embedded within the plugin is a robust feature that logs every activity, based on your needs, and those activities are synchronized within the Sucuri Security Operations Center (SOC) server clusters. This ensures that, even after a compromise, an attacker is unable to modify or remove the forensic evidence required to understand what happened.
Good crackers are very intelligent and follow strict procedures after they successfully gain entry to your website. One of those steps is to look for security plugins, or monitoring tools, and disable them or purge the databases in an effort to cover their tracks.
If you’re wondering how I knew I was hacked, the answer is simple. I’m a responsible website owner. When I received a notification of someone logging in as Admin and I was not currently logged in, and no one else was supposed to log in, the signs were clear as day that something was wrong. This is one reason I always recommend you know who is logged in to your website. If you’re the only one with privileges, then no one else should ever be logged in. You can learn more about this feature of our plugin in a blog post from last month.
Shortly after that, we began to receive a series of notifications notifying us of changes. For us, the most important information the notifications gave to us was in knowing the method they were using to make their changes. In this case, they were leveraging the Theme Editor. If you’re not familiar with the Theme Editor, it’s a feature that allows you to manipulate the core files of Themes and Plugins. It’s on by default on all installations, and it encourages designers and developers to make modifications to their themes / plugins right in their WordPress administrations panel. It’s also something every cracker on the web knows, and looks to exploit (as demonstrated below).
This is why one of the most effective tips I can give to any new user of WordPress is to disable Theme / Plugin editing via their WordPress administrator panel.
If you’re a designer or developer and you depend on editing your theme / plugin via the WordPress administrator panel, you’re doing it wrong. You’re doing yourself and your clients a disservice. And yes, I realize it’s easier. And yes, I realize it helps save time. And no, it still isn’t worth it.
Fortunately for everyone, disabling the feature is very simple. Copy and paste the following into your wp-config.php
#DISABLE EDITING IN ADMINISTRATION PANEL define('DISALLOW_FILE_EDIT', true);
As well, many of the available Security utility plugins, like iThemes Security, and our own plugin offer you features to address this as well:
Analyzing the Impacts of a Compromise
Understanding that an attacker logged in is just one piece of the puzzle. We now look to see what changes occurred. The first reaction for everyone is to open the site, which is where we were presented with the defacement shared above.
The next obvious question is, “What else changed?” We leveraged the auditing tools to understand if the integrity of any files changed.
Looking at our logs we can see that the attacker modified two files:
- twentythirteen/page.php
- twentythirteen/index.php
The last index.php was modified twice. This is a good place for us to start.
Logging into our handy dandy Secure File Transfer Protocol (SFTP) application (in this case FileZilla), I am able to confirm the files were just modified today.
The next logical step is to see the changes made in those files. I used my code editor, in this case Coda 2, and I opened one of the files:
You could also see how they did it by opening the administrator panel, clicking on Administrator > Editor and selecting the index.php or page.php:
Looking through the other files on the server, it was evident that the attacker did not change anything else. Whether it was the timely response, or whether the attacker was satisfied, we’ll likely never know.
The attacker did change our password though. We tried logging in when we got the incident report and were blocked by an incorrect password.
What we do know, however, is that the attacker logged in successfully 3 days prior to the actual attack, which is a very common practice because it verifies that they have access without arousing suspicion. They then waited until the right time to log in and make changes. I know this because I am able to go backwards in time using the auditing feature in the Sucuri WordPress Security plugin.
We also know that in both instances the attacker was coming from IPs originating in Russia and Turkey, but then again that’s pretty easy to configure these days. They can really be anywhere.
#193.150.120.167 person: Michael Morozov address: 301840, Russia, Tula district, Slovatskogo vosstania, 18 phone: +37369405042 #78.170.58.47 descr: TurkTelecom
While that doesn’t tell us much, we do know the group as well:
They also seem to be fairly new to the game with a brand new FB group – they’re likely a bunch of script kiddies. However, that is pure speculation. What isn’t speculation is that lately, it seems that they are on a roll, showing their ability to deface websites.
Improving the Website’s Security Posture
That is as far down the rabbit hole as we’re going to go for one blog post. It illustrates a normal cycle in attacks as of late. Although these attacks are often automated, they don’t need to be. In this case, the attack was manual. However, this doesn’t mean that that the attack itself, exploiting the access control mechanism (i.e., wp-admin log in), was not automated. It probably was. It is likely that it was a script that identified the weak credentials, saved the website name and allowed the attacker to come back at their leisure to initiate the second phase of the attack.
When we look at the sequence of events, we have to ask ourselves..
What could we have done to prevent this?
In this specific sequence this is what we would recommend:
Most Effective Option: Employ WhiteListing Access Control
This is a concept that blocks all users by default and only allows specific users based on specific IPs. It’s very powerful, and some of today’s most popular Website Firewalls support this sort of access control. This would have stopped the attack outright, whether using the admin user or any other number of hardening techniques.
Employing a Website Firewall, although most effective, is not always an option and in some cases is too complex a solution. In those instances, you can leverage application level security utility plugins to assist you in the process. One such plugin, we recommend is the iThemes Security utility plugin.
Alternative 1: Throttle Access Attempts
This is a very common feature these days. You’ll find a wide range of toolsets offering to do it at the application layer, but few do it right. Many will work for the average attack scenario, but the more complex ones require a very different approach. It also requires constant review and updates to maintain the intelligence as attacks evolve (remember, they are constantly evolving).
Alternative 2: Employ Complex Long Unique (CLU) Passwords
In terms of access control, this is, by far, the simplest task you can employ as an end-user. It’s actually not hard at all, but can often feel impossible because of our own laziness. We too often feel our approach is unique enough, when in reality almost any simple word-based password can be broken. My simple solution to CLU is to leverage a password manager, something like Lastpass will do nicely. Have it generate the password and save it for when you need it.
Alternative 3: Employ Two Factor Authentication
Ipstenu wrote a very good article on the subject of Two-Factor Authentication last year around May. I’d encourage you to take some time to read it, it’s well structured and still applies today. Many of the security utility plugins today offer some form of it. Alternatively, you can also always go straight to the source, Google Authenticator. Seems to be what all the cool kids want to employ these days.
It’s good to understand that this attack began with the employment of a concept known as Brute Force, a concept that is designed to gain entry to your website. Be sure to make a distinction between Brute Force attacks and Denial of Service attacks, but also know that BF attacks can contribute to a DOS attack if the server fails.
Lastly, once you have done everything you can to clean your environment be sure to take a few post-hack measures. This includes forcing all users to reset their passwords and resetting your API salts / keys in your wp-config.php. If you’re unclear what this is, then don’t worry because our Free WordPress Security plugin has a feature designed to help you with it.
If all else fails, you can always look for more instructions online, seek free help on the forums, or seek professional support.