Hacked Off

Yup, my site was hacked. My own silly fault really, as I forgot to update the underlying CMS when it had a rather nasty security issue a while back. In my defence, I updated all the other instances that my clients use but I forgot my own personal site. Ah well.

It started with a text at 0900 on Sunday morning from my work mate Jonny saying it looks like my site has been hacked. A bleary eyed check via my phone confirmed that whatever my domain was serving up, it wasn’t what I put there. Bugger.

In fact, it looked like this:

Screen Shot 2015-05-10 at 11.58.03 2

Great.

Firing up the laptop and after checking all my other sites with a bit of a sweat on I confirmed it was only my personal site. Ok, not tooooo bad then. I have backups, somewhere.

Poking about on the server, I found a bunch of files that aren’t part of the Drupal installation, and were put there over night:

Screen Shot 2015-05-10 at 09.16.02

 

Yes yes I should have taken a full ‘forensic’ backup, but it was Sunday morning and I was operating in a severely under-caffinated manner. Instead, I deleted the files and hoped for the best. Neither of which made any difference at all.

Ok. I then removed the sub-domain that pointed to the Drupal installation and went in search of coffee (sub domain edits take up to an hour to take effect)

A coffee, some breakfast and a while latter I checked again… no change. Not sure how that can be… There’s nothing pointing to that Drupal install now. Ok, time to contact the hosting company. Which I did, explaining the situation and asking if they could check the sub domain deletion had actually worked.

It seems mentioning the word ‘hacked’ prompts a slightly more dynamic response than the usual support ticket. They (quite rightly) disabled my site and asked that I delete the nasty stuff before they would enable it again.

Fair enough. I backed it all up, then nuked it. Out of interest I poked about in the MySQL database and saw the hack had changed the admin user. No way I using that DB again anyway, but interesting to see.

Once my empty site had been enabled again, I reconstructed it from (not so) recent backups, and here we are.

As far as I can tell, they got in via this SQL Injection exploit –¬†https://www.drupal.org/SA-CORE-2014-005

The morals of the story….

  1. Back up.
  2. Apply security updates
  3. Back up (again. One isn’t enough)
  4. Test that you can restore from a backup (ideally before you have to)

Leave a Reply

Your email address will not be published. Required fields are marked *