Ransomware protection for a website means a clean copy you can restore
Ransomware protection for a website is the set of controls that stop an attacker from encrypting your files and database, plus a tested backup that lets you rebuild the site without paying. On a website the attack usually ends with public_html and the database locked, and a ransom note dropped in the web root.
- Prevention — remove the write access an attacker needs: strong logins, patched plugins, no unused FTP accounts.
- Detection — file-integrity alerts and a sudden change in admin users or plugin files.
- Recovery — an offline backup taken before the encryption, with a restore you have already rehearsed.
Recovery is the part that decides the outcome. Most sites that survive without paying do so because a clean copy existed and someone knew how to put it back.
How an attacker gets write access to a website
Almost every website ransomware case starts with a valid login, not a novel exploit. An attacker signs in as an administrator and uses the file manager or a plugin uploader to write files, which is exactly what you do when you update a theme.
- Reused or guessed admin passwords — login pages accept them from anywhere unless you restrict attempts or add two-factor.
- An abandoned plugin or theme — old code with a known file-upload or permission flaw.
- Secrets in the wrong place — .env, wp-config.php backups, or database dumps left in a public folder.
- Stale FTP or SSH accounts — a former developer's key still works until you delete it.
Defending means closing those four doors, not chasing a malware name after the fact.
The controls that block encryption before it starts
Each control below removes one of the paths above. None of them works alone, and none is a complete guarantee.
| Control | What it blocks | How to check it is on |
|---|---|---|
| Two-factor on every admin login | Password-only entry | Log out and confirm a code is requested |
| Automatic core, theme and plugin updates | Known flaws in old code | Plugins screen shows current versions |
| Least privilege | Editors who can install files | Each user's role is the minimum needed |
| File editor disabled | Editing PHP from the dashboard | Appearance, Theme File Editor is absent |
| Login attempt limits and a WAF | Password guessing at scale | The security plugin logs blocked attempts |
| SFTP only, no plain FTP | Credentials sent in clear text | The FTP accounts screen has no plain-FTP users |
Take a fresh backup before you change any of this, because a mis-set permission can take the site down as effectively as an attacker.
A backup counts only if the restore has been tested
An untested backup is a hope. The test is simple: restore the last backup to a staging directory, load the homepage, log in to the admin, and check that an order or form submission still works. Do it once a quarter and write down how long it took.
Keep three copies, on two kinds of media, with one offline or immutable. The offline copy is the one that survives, because ransomware that reaches your hosting account can also reach a backup stored on the same account.
Retention matters as much as frequency. If the compromise sat unnoticed for three weeks, a seven-day retention window holds only encrypted copies. Keep at least 30 days, and check that the database dump and the files come from the same moment.
If your site is encrypted: the first hour
Work in this order. Speed matters less than not destroying the evidence that tells you how they got in.
- Take the site offline with maintenance mode, and ask the host to snapshot the account before you change anything.
- Do not delete the encrypted files yet. Copy the ransom note and the newest access-log lines to your own machine.
- Find the entry point in the access log: a POST to wp-login.php, an unfamiliar FTP login, or a plugin file requested with odd parameters.
- Restore the last clean backup to a staging copy first, and check it for the same entry point before you point the domain at it.
- Rotate every credential: panel password, database password, WordPress admin passwords, FTP and SSH keys, and any API keys stored on the site.
- Update everything, remove unused plugins and users, then watch the logs for 48 hours before you call it finished.
If the same file changes again after the restore, the entry point is still open. Go back to step three rather than restoring a second time.
Do not pay the ransom
Paying buys a promise from someone who has already broken into your site. There is no guarantee the key works, no guarantee of a second attack, and no way to recover the money. Payment also funds the next attack on somebody else, and some insurers and jurisdictions treat it as a regulated transaction.
The practical alternative is the restore you prepared. If no clean copy exists, rebuild from the last known-good export and treat the content as lost, which is still cheaper than a second encryption.
Where WebJi® fits in a website ransomware plan
WebJi® provides the account, the backups and the cleanup, not a decryption service. The server backup solutions page covers scheduled copies kept away from the live account, and website security services covers hardening and malware removal after an incident.
If your site is encrypted now, email support@webji.services with the domain and the time you first saw the note, and ask for an account snapshot before you restore. Support is 24/7 by email in Hindi and English with an average first reply under 60 minutes. For WordPress-specific cleanup, start with the WordPress security service, or use the contact page for a written scope.
Frequently Asked Questions
What does ransomware do to a website?
It encrypts the site files, and often the database, using access the attacker already has, then leaves a ransom note in the web root. The site stops loading and the data is unreadable until a clean copy is restored.
Can a firewall stop website ransomware?
A web application firewall blocks known attack patterns and slows password guessing, but it does not stop an attacker who logs in with a valid admin password. Pair it with two-factor authentication and prompt updates.
How often should I test a backup restore?
Once a quarter, and after any major change to the site. Restore to a staging copy, load the homepage, log in, and submit a test order or form. Record how long it took so you know your real recovery time.
Should I pay the ransom to get my site back?
No. Payment does not guarantee a working key, invites a second attack, and funds further crime. Restore from an offline backup and rotate every credential instead. If no clean copy exists, rebuild from an export.
How do I know the attacker is gone after a restore?
The same file stops changing. Watch the access log and file timestamps for 48 hours after restoring, and confirm there are no new admin users, scheduled tasks or unknown plugins. If anything reappears, the entry point is still open.
Does hosting with WebJi® include ransomware recovery?
WebJi® provides scheduled backups kept away from the live account, hardening help and malware cleanup. It does not decrypt files. Recovery depends on a clean backup existing, which is why the restore test matters before an incident.