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:
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:
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….
- Back up.
- Apply security updates
- Back up (again. One isn’t enough)
- Test that you can restore from a backup (ideally before you have to)