While working on cleaning up a hacked WordPress website recently we found a hacker had tried to disguise some of what they were doing by making it seem like it was coming from GoDaddy. GoDaddy, possibly not coincidentally, was the web host for the hacked website we were dealing with.
The first element of this we found was a malicious plugin with the slug gd-stats. If you were looking at the Installed Plugins page in the WordPress admin area, you would see this information for that plugin:
That labels the plugin as being named GD-Stats and being from GoDaddy, Inc, though the link is to wordpress.com.
The description is weird:
Most leading CMS platforms like WordPress use Ajax in their architecture.
In looking to see if others had encountered a malicious plugin with the same name, we found a topic on WordPress’ forum from early in February where someone else hosted with GoDaddy had run into this:
This morning, I found that our WordPress website has been hacked by someone in Moscow. They uploaded the file “gd-stats.zip” then installed the plugin. Now when I go to our wordpress.org log in page, I put in my credentials, it takes me to a completely blank screen. When I went to our website, it doesn’t have the dashboard option available to log into. We’re hosted through GoDaddy. I’m waiting on their support team as well.
In a follow up they wrote this:
No it wasn’t Godaddy. It was from someone in Moscow who hacked our site at 4:30 AM. They installed the gd-stats.zip and the plug in but I finally got into our Godaddy account and deleted the plug in so we’re good now.
There was a reply from someone else with the same plugin, but no mention of the web host of the affected website.
For a hacker to add that plugin to the website they would already have to have access to the website in some way. In trying to determine what that was, we ran across a major problem, it appeared that GoDaddy had about a week before moved the website to a new cPanel account. That meant that among things, the last modified dates on malicious files were not meaningful, since it just listed the time of the move. It isn’t clear why that happened because of the partially unmanaged nature of the website at the time. Whatever was the case, the malicious plugin appeared to exist from before there was logging available that could have shed light on that. So we hit a dead end there.
Another piece of the hack might help to further explain how the hack happened. In the WordPress database table storing the users of the website, _users, we found two non-legitimate Administrators accounts.
Both accounts were listed as being listed as being registered at 0000-00-00 00:00:00, which shows that they were not created through the normal registration process, since if they were, the time they were registered would be there.
Both of the accounts were also meant to look like they came from GoDaddy, with the usernames being:
Curiously the email address for them doesn’t use a GoDaddy-like domain, instead opting for wordpress.org.com:
Again we ran into a problem, since the logging isn’t available to see what it would show about how the hacker created those accounts.
There are several routes that could have occurred through. They could have been added through a SQL injection vulnerability on the website that allowed for adding things to the database, but most SQL injection vulnerabilities don’t permit that type of action, so that seems unlikely.
More likely would be that the hacker was able to get direct access to the database. That could be because of a security issue with the website, with the web host, or combination of the two. GoDaddy has had issues with improper security of database access, we posted about another hacked website where that came in to play in April.
February Time Frame
Looking at the session_tokens entries in the WordPress database’s _usermeta table, we found that one of those accounts was logged in to from a Russian IP address, 220.127.116.11, on February 4. That matches up with what was described in that WordPress forum topic.
We are going to contact GoDaddy’s security team to let them know about this impersonation and maybe they can check if other websites they host still contain that plugin.