November 1st started like any other day on the web. Billions of requests were being shot virtually between servers in safe and not so safe attempts to access information. After months of waiting, finally one of those not so safe request hit one of our honeypots.

We won’t get into the location of the site because it really doesn’t matter, a fact that most critics don’t realize. As is often the case, the honeypot site was quiet without much traffic and the weakness was access control.

We intentionally left the password to the site to one of the top 10 passwords, with continuous attempts it took about 3 months before it was accessed.

This time though we were ready and this is how it went..

Honeypot Configuration

Category

Description

Content Management System

WordPress 3.6.1

Host

Popular Shared Host

Shared Account

Yes

VPS / Dedicated Box

No

Server Level Hardening

No

Application Hardening

Yes

Security Plugins

Sucuri Premium Plugin [Honeypot Mode]

Custom Hardening

Kill PHP Execution via .htaccess

Strong User

No

Strong, Unique Password

No

Time To Hack

3 months

All in all, it was set up to be like an everyday website install. No special configurations, outside of the one hardening on wp-content to kill PHP execution.

Order of events

On November 6th, as I was enjoying my fine afternoon, I was greeted with the following message from the Sucuri Premium plugin:

If you’re not aware with what it is, it’s telling me that someone is logging into one of our test sites.

A quick lookup and you see that the incoming IP, 188.3.48.163, is coming from a Turkey source:

Obviously not anyone on our development or research team, so it was time to investigate further.

Next step was to understand what else the attacker did. We first started with the auditing feature in the Sucuri plugin, there we found the following line items:

With this we were able to build a timeline for what the attacker was doing, but it was only part of the puzzle.

You can see that the first thing the attacker did was modify the 404.php on the Twenty Twelve theme using the built in Theme Editor. The attacker then switched the active theme to Twenty Thirteen, and proceed to modify the 404.php and index.php files for that theme.

Although interesting, we couldn’t begin to speculate why they switched the active theme. You’d think they’d want to leave the existing theme as to not arise suspicion, but then again, based on what they did, maybe they didn’t care.

Unfortunately, these audit logs weren’t enough to fully understand what the attacker was doing, but it was good enough to start the analysis. With this we were able to dive into the raw access logs, here is what we saw:

Confirm Known Actions

First we want to sync up the audit logs in the plugin with the raw access logs, do things make sense? Are they in sync?

You’re probably wondering why you killed PHP execution. Well, the attackers are abusing an otherwise benign feature. To understand what they are doing, you have to understand how WordPress and many other CMS applications function.

They have a load hierarchy that will execute the PHP files associated with active themes and plugins. So in this instance, as the attacker injected the payload into 404.php and index.php files of the active theme, they were now operational. Good times! Because they put it into the index.php file, they were able to test it by going directly to “/” which is what you see above.

Being this was successful, the attacker was able to proceed passing variables to their payload, each variable causing some level of annoyance to our afternoon.

First variable to be passed:

[01/Nov/2013:13:24:32 -0700] "GET /?webr00t=telnet HTTP/1.1" 200 2805

In part II of this post, I’ll provide you a cheat sheet of the various options the shell offers, but for now, here is what ?webr00t=telnet does at a high level:

?webr00t=telnet creates a .htaccess file that allows to run .root files as cgi scripts and then creates web.root perl file that has a login and logout, can execute shell commands and upload/download files from the server.

If you’re wondering why the files are .root, that’s because they added elements to the .htaccess files that treat any .root file as a CGI file. Here is what the new .htaccess file looked like, the one inside the cgiweb directory that was created by ?webr00t=telnet:

From that variable, they jumped to /?webr00t=config, which does this:

Creates a .htaccess file that allows to run .root files as cgi scripts and then creates config.root perl file that creates a bunch of symlinks for reading all the config files on the server.

/?webr00t=config also created over a thousand symlinks at the root of the account, all to predefined configuration files. If the file existed, it created a text file and made it accessible to the attacker so that they were able to do a quick dump of each one.

In the end, the attacker was able to use the techniques we described in earlier posts about hacking servers with FTP, and were able to download dumps from the shared server, things like /etc/passwd and other files. Each of the variables were designed to create and automate the entire attack sequence, expediting and streamlining the attack to a few clicks. When the attacker was done, they left us a little present, a dead site:

They did this two ways:

First, they deleted our wp-includes and wp-admin killing the site, and then, icing on the cake, they added a new .htaccess file at the root that disabled all PHP in our root account:

Crazy right?

If you’re wondering, our only hypothesis as to why they killed the site was likely nothing more than a need to show off. The name of the honeypot domain is a bit of a tease as well, leading us to think they did it as a virtual LOL. The other option is they really didn’t care.

Based on the variables they executed in the shell, their focus seemed to be to acquire server level information. Things like existing users in the shared account, and killing the site seemed to be nothing more than a big FU at the end of the day. Either way, it’s always fun and exciting to watch as attacks are happening, there is always so much to learn.

In the second part we’ll take a closer look at the shell the attacker used and see if we can’t better understand what all the attacker could have done.

In the interim, if you think or suspect you’ve been hacked but can’t find the issues, be sure to let us know at sales@sucuri.net.

About site

This is experimental project, which search automatically antivirus, security, malware, etc. news and alerts. If you want add/delete source or post, let us know. We will add/delete it. We'd like make place, where you can find security information from various sources with correct backlink back to source.