It all started with a phone call. A web developer I know was running a utility over links on corporate web sites. A corporate subsidiary was returning a bunch of really unusual links, lots of them. He asked what I thought was going on. When I logged into the WordPress dashboard for the site, it became clear. The site had been hacked.
You couldn’t tell by just looking at the web site. It wasn’t defaced. There was no malware, no altered links. But on the inside, there were 2 dozen new accounts. There were a couple dozen new blog posts.
That wasn’t all though. My colleague had said there were a lot of links and images. So I ran a search on Google for images, focused on the impacted site:
.png site:[impacted site domain name]
There they were. Thousands of links to the domain name. None of which were coming from within the WordPress web application.
A Google search result (SERP) showing images that were being hosted by a hacked site
I started to clean up what I could from within WordPress and contacted the web site administrator to let them know of the problem. I deleted the blog posts and the new accounts. I looked at the folders on the web server and saw where the external page templates were sitting and deleted them too.
But it wasn’t enough. Whoever this was, they had access to the file system and database as well as WordPress. They dropped the tables and the WordPress site disappeared.
Understanding Functions
Web sites are a tricky business. They can be hard to explain to someone who only visits them. There are a variety of parts and roles involved. At a minimum, the functions I’ll touch on here are:
- the web server software (Nginx, Apache, IIS, &c.)
- the web server application software (PHP, .Net, &c.)
- the database (MySQL, Postgres, Microsoft SQL, &c.)
- the content
Content’s tricky. A lot of web sites are database-driven now, so the content is a mixture of things saved in a database and things saved on the server. If you use a content management system (CMS) like WordPress or Joomla, your site is partly in a database. But if you upload images or PDFs, those may sit on your web server, outside the database.
If the web site is hosted by a web hosting company, the first 3 functions are probably handled by them. They are universal technologies and everyone on a shared server will utilize the same basic functionality. Your database is different from another web site’s database, but it’s using the same database software.
The CMS may be something you manage or it may be managed by someone else. In addition, a couple of these functions can be backed up. You can backup your database (and export it periodically to your own computer) and you can backup your CMS.
If you have a CMS, it is critical to keep it up to date. Out of date CMS are a common reason for hacked sites. The Federal Depository Library Program (FDLP) was hacked recently while running a very old version of Joomla. A local courthouse library was hacked soon after I arrived in Canada under the same circumstances: old Joomla version.
If you aren’t sure who is responsible for each of these functions for your law library’s web site, you might want to stop and check. For example, my web site (the one you’re reading this blog from) host manages everything up to the CMS (WordPress) I run. I have to make sure WordPress stays up to date. I get nag emails if something is out of date. My host turns on backups by default although I could turn them off.
Additionally, I have access to the database and the file system as well as the CMS application. That extra access can sometimes give you a better window into your environment. It also raises the technical know-how you need. In those cases, a third-party may have the primary responsibility for it.
That was this situation. While I could access the CMS app, the other functions were handled by a third party. And although I could administer the local WordPress install, it was configured so only the consultant could upgrade the application. Unusually, they didn’t keep the CMS up to date, nor the application language (PHP). Unfortunately, they also weren’t performing backups.
No backup. No web site.
Stop right here and go and see if your law library web site has a backup. If it doesn’t, or if it isn’t recent, that would be a good thing to get fixed as the year starts.
Rebuild the Site
This isn’t rocket science. You put back everything that is missing. Except that you may not have anything to put back.
In this case, I recommended that we drop the web host that we’d been using. They had not fulfilled the roles that they’d been expected to fulfill. And it wasn’t clear that they knew how the site had been hacked. That suggested to me that it might still be at risk.
The next step was to rebuild the site. If you have a backup, that can be easy, because you can just recreate the site as it was. However, one thing that nagged at me was whether something in the old site had allowed the hack to happen. The site had been built 10 years ago and some of it was definitely out of date.
A Fresh Start
I decided to start fresh where I could. For one thing, there were 2 or 3 plugins that no longer were supported in WordPress. Another thing was the theme. It was a custom theme, built off one of Automattic’s stock themes.
But it didn’t follow the recommended process of having a child theme. One of the benefits of creating a child theme is that your main theme is updated. If you customize a theme, you have to manually update the entire theme rather than just the bits that you incorporate in a child theme.
Unfortunately, this meant that I would not be recreating the exact look and feel that existed before. I’d be doing a close approximation to get the site up and running.
The content was a silver lining. While whoever had dumped the database table – deleting the WordPress content – could have deleted other things, they didn’t. The PDFs and other content that had been manually uploaded was still there.
Also, the rest of the web site had been archived in the Wayback Machine.
If your site isn’t indexed by the Wayback Machine, you might want to add yourself. It’s not an alternative to a backup. But it was a belt when this site’s suspenders failed.
Do What You Can
One part of the old site had a directory. While I could find the data for the directory in the Wayback Machine, the WordPress plugins were out of date. At first I attempted to recreate the method, using new plugins with similar functionality. But it seemed very kludgy and in one of those moments one has of lateral thinking, I decided to just use a directory plugin.
The rest of the site was largely static WordPress pages with links. These were easy to cut and paste over. The hierarchy of WordPress pages made rebuilding the menus easy.
I ended up going with a recent Automattic theme, TwentySeventeen. It had a similar feel to the original custom theme. It wasn’t exact, however. I ended up making two small adjustments:
- I used an image carousel from Shortcodes Ultimate and added it to the header.php file using the do.shortcodes function. That would show the carousel on every page
- I edited the footer to include the corporate name and address of this subsidiary.
Everything else was mostly the same functionality but it wasn’t all in the same places. Fortunately, I didn’t need to customize anything else behind the scenes. Cascading style sheets (CSS) allows you to move stuff around on the page. In this case, I:
- used positioning styles to bring the menu up in line with the site title, rather than having one above the other;
- used display: none to hide a couple of plugin functions. For example, the business directory plugin had a search bar and tag listing. By using display: none, I was able to just hide it from view since it wasn’t functionality that I needed.
There is a balance between wanting to get back up and running – no-one wants their web site to look broken – and wanting to get things “right”. It took a couple of obstacles and re-attempts before finding each of the solutions. But it was worth it rather than to just fall back on out of date functionality.
The new host has more transparency around roles. I’ll be able to show the web site’s owner how to manage these. The new site will utilize the Let’s Encrypt SSL certificates, which have become standard. Backups will be automated, as will security updates. I’m also taking the precaution of putting the site behind Cloudflare’s firewall. Since we’ll be redirecting the domain name, it’s a good time to add this to the mix.
No-one wants their site to be hacked. If it happens, do the best you can to bring things back online. If there are opportunities to improve your environment – your host, your web application (CMS), your security – take advantage of it as a silver lining.