If a site's files are encrypted, a recent backup stored outside the hosting account is what brings it back. Keeping the software patched and the passwords strong keeps attackers from getting that far.

A ransom note where the home page was

Most ransomware so far has arrived by email and locked office computers. Since the start of the year, another kind has been turning up more often: attacks that break into a website and encrypt its files on the server.

The site still answers, but every visitor sees the same page: a note where the home page used to be, saying the files are locked and naming a price and a deadline.

The pages, images and code are still on the server, scrambled with a key only the attacker holds. The office computers are untouched, so the first person to notice is often a customer.

What happens next depends on one question: is there a recent copy of the site somewhere the attacker could not reach?

How they get in

These attacks use the same doors as most website break-ins:

The last is the one owners rarely think of. A test copy left in a folder years ago is never updated, yet it sits in the same hosting account as the live site, so a break-in there reaches both.

What the attack does

Once inside, the attacker runs a small program on the server. It works through the site's folders, encrypting pages, images and code, and puts the ransom note in place of the home page.

Anything else the site's login can reach goes too. That usually includes backup files a plugin has been saving in the same account, which is where many sites keep their only copies.

Depending on the attack, the database holding the site's text may survive. Without the files around it, a database alone does not make a working site.

Why paying is a poor bet

Paying is a gamble. There is no guarantee a working key arrives, and the money funds the next round of attacks.

Even a decrypted site is still a compromised site. Whatever let the attacker in is still open, and some leave a back door for a second visit.

Meanwhile, every hour the note is up, customers see it. The quickest way back is nearly always a clean copy, restored and patched.

Backups the attack cannot reach

A backup only protects you if the attacker cannot touch it. That means stored outside the hosting account, in a separate service or the host's own backup system, beyond the reach of the site's logins.

It has to go back far enough. Break-ins often happen days or weeks before anything visible, so keep a run of copies stretching back a month or more, not just last night's.

And it has to be complete. The text of a WordPress or Joomla site lives in its database; images and code live in files. A backup of one without the other restores half a site.

Ask the host before you need it

Most hosts back up their servers, but the details vary: how often, how long copies are kept, whether one site can be restored on its own, and whether there is a charge.

The question to ask is simple. If my site's files were encrypted tonight, what is the newest copy you could restore, and how long would it take?

If the answer is last night's copy only, that is not enough on its own. Add copies of your own, kept elsewhere, for the weeks the host does not cover.

A worked example

A mural artist who paints walls for businesses, schools and homeowners runs a portfolio site on WordPress. It was built several years ago, rarely touched since, and holds photographs and notes on more than a decade of projects.

One morning a client sent a screenshot. The home page had become a ransom note, and so had every gallery page.

The way in was a gallery plugin that had missed two years of updates, including the fix for a published hole. The attacker's program then encrypted everything in the site's folder, weekly backups included.

The host kept its own copies for two weeks, outside the account. A developer restored one from before the break-in, swapped the gallery plugin for a maintained one, updated the rest and reset every password.

Two projects added since that copy were put back by hand, and an old test install found in a subfolder was deleted.

The site now sends a full backup each week to a separate storage service, kept for three months, and its updates are someone's monthly job rather than nobody's.

Keeping them out

Updates are the main defence. Most website break-ins use holes fixed months earlier, in versions the site never installed.

WordPress installs its minor security releases by itself on most sites, but plugins, themes and major versions usually wait for someone to click. Name that someone.

Use different passwords for the hosting account, FTP and the site's admin, and use SFTP, the encrypted version of FTP, where the host offers it. Remove test copies and plugins the site no longer uses.

If it happens to you

Do not pay and do not start deleting. Call the host and whoever maintains the site, and ask for the newest clean backup and the server's logs, which show how the attacker got in.

Put up a simple page with your phone number while the work is done. Then restore onto a clean setup, update everything before it goes live, and change every password.

The counter-case

A small static site, a few pages of plain files with no database, is quicker to restore, especially if the developer kept the original files. The backup question is smaller for it, though not gone.

Some hosting plans already keep long backups outside the account. For those sites, the work is confirming what the plan includes rather than setting anything up.

Either way, the advice stands: recent copies the attacker cannot reach, kept for weeks, and a site kept patched so it never gets that far.

Backups first

  1. Ask your host how far back its copies go.
  2. Find where your own backups are stored.
  3. Move them outside the hosting account.
  4. Keep copies for at least a month.
  5. Restore one backup to a test copy.
  6. Update plugins, themes and WordPress itself.
  7. Delete old test installs from the server.

Step three is the one that decides the day. A backup inside the hosting account is encrypted with everything else; a copy outside it is the whole way back.

The office side of the same problem is covered in ransomware disguised as an invoice.


Frequently asked questions

What does website ransomware actually do?

It runs a program on the server that encrypts the site's pages, images and code, then replaces the home page with a note demanding payment by a deadline.

How do attackers get into the site?

Usually through out-of-date plugins, themes or core software, stolen hosting or FTP passwords, weak admin passwords, or forgotten test copies of the site sharing the same account.

Should we pay the ransom?

Paying is a gamble. A working key may never arrive, the money funds further attacks, and the hole the attacker used is still open afterwards.

Why are backups in the hosting account not enough?

Because the attack encrypts everything the site's login can reach, including backup files a plugin saved in the same account. Copies need to live outside it.

How far back should backups go?

A month or more. Break-ins often happen days or weeks before anything visible, so last night's copy may already contain the attacker's way back in.

What protects the site in the first place?

Updates to plugins, themes and the core system, separate strong passwords for hosting, FTP and admin, encrypted file transfer, and removing test copies and unused plugins.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Not sure where your website backups live?

Ask us for a backup check. We will find out what exists, where it is kept and whether it restores.

Start a Conversation