If you visited my website earlier today, you might have noticed that it was hacked for a short period of time. Fortunately, I received a few emails letting me know, and I was able to investigate the situation immediately and get everything repaired within a few hours of the attack.

For those of you who missed it, all the content on my website was removed and replaced by the fol­low­ing message:

I did some thorough detective work with my friend who owns my website’s hosting company to find out exactly how this happened. One thing I immediately noticed was that all the pages of my website were being forwarded to a suspension page. After seeing this, I had a good feeling that it wasn’t me or my website that got directly hacked, but this was a result of my website’s host getting hacked.

Basically, what the hacker did was hack That Hosting and suspended all the accounts on the server. Then, the hacker set the suspension page to the message above, so it would look as if the hacker was able to hack every single website on the server individually. Once I figured this out, I knew that it would be an easy solution – just log in to the administrative control panel and unsuspend my account. Un­for­tunately, the hacker changed my password and the email address associated with it, so I wasn’t able to log in as an administrator.

I texted my friend, and after a short while, we managed to get everything sorted out and working back to normal. While my friend tried to figure out who the hacker was, I was more concerned about how the hacker gained access to That Hosting, so I traced recent activity on the server to find out what the hacker did. After a little bit of sniffing around, I was able to figure out exactly what the hacker did.

First, the hacker used a security flaw in Web Host Manager Complete Solution (WHMCS) to inject PHP code into our server via the support ticket system. For whatever reason, WHMCS thought it would be a good idea to let people use {php} to start PHP parsing in their ticket. The hacker injected an extremely long chunk of PHP code; a sample of what it looks like is shown below.

Once the support ticket was submitted, the injected code ran on the server and started creating files. When it was done executing, it sent a confirmation to the hacker with the following message:

The hacker could then navigate to the file specified in the confirmation message to find a file that would allow shell access via CGI. The hacker would log in with the password provided in the confirmation message.

Once logged in, the hacker would have complete access to the web server and be able to run any commands as desired. For those of you more familiar with Windows operating systems, this is basically like opening a command prompt and being able to type in whatever you want.

To demonstrate that this works, I ran a command to delete the xa7m3d.evil file (which was the CGI-Telnet file). After I submitted the command, no error messages appeared, which most likely means that the file was successfully deleted.

To confirm that the file was deleted, I refreshed the page, and got a 404 (file not found) error.

Thus, I was able to verify that the commands entered into this program ran successfully and the hacker could do whatever (s)he wanted with the server as long as (s)he knew what the proper commands to use were.

So what was I able to conclude from this? It’s clear that the hacker group 10:01 aren’t really hackers, but a bunch of people who search the Internet for programs and instructions they can use to hack other people. The only real hacker here is xa7m3d, who coded the actual tool and identified the PHP injection method that 10:01 used to hack into That Hosting.

So before you go around being a script kiddie and hack people’s websites, make sure that you only hack unexperienced people, because if you hack someone like me, I’ll call you out on my blog, explain exactly how pathetic you are, and tarnish your reputation.