Ransomware Protection for Websites

Almost every website infection starts with a valid login or old code, not a novel exploit: the attacker signs in as an administrator and writes files exactly the way you would during a theme update. Four doors account for most cases.

• Reused or guessed admin passwords — login pages accept them from anywhere unless you limit attempts or add two-factor.
• An abandoned plugin or theme — old code carrying a known file-upload or permission flaw.
• Secrets in the wrong place — .env files, wp-config.php backups or database dumps left in a public folder.
• Stale FTP or SSH accounts — a former developer's key keeps working until somebody deletes it.

On a self-managed server the same logic applies one level down: internet-exposed remote-administration services, such as RDP on a Windows server or SSH with password login allowed, are the classic route in, usually through guessed, reused or stolen credentials rather than a clever break-in. Closing RDP and SSH to the internet, or wrapping them in a VPN, removes that door.

One distinction that saves confusion: exploit kits delivered through poisoned ads and booby-trapped downloads infect the browsers and desktops of the people who visit bad pages — endpoint ransomware. Your website's server is not infected by a visitor's browser; it is infected through its own logins and unpatched code. Defending a website and defending office desktops are two separate jobs.

A tested, offline backup is the one control that survives every attack path, which is why the US Cybersecurity and Infrastructure Security Agency tells organisations to maintain offline, encrypted backups and test them regularly. Ransomware that reaches your hosting account can also reach a backup stored on the same account, so the surviving copy has to sit outside it.

The test is simple: restore the last backup to a staging directory, load the homepage, log in to admin, and check that an order or a form submission still works. Do it once a quarter and write down how long it took — that number is your real recovery time. Retention matters as much as frequency: if a compromise sat unnoticed for three weeks, a seven-day retention window holds only encrypted copies, so keep at least 30 days and confirm the file backup and the database dump come from the same moment. The 3-2-1 backup rule explained covers the copy strategy, and WordPress backup plugins compared helps you pick the tool that takes the copies.

On the hosting side, WebJi® WordPress plans at ₹400 and ₹500 a month include a daily backup (read from WebJi® billing on 15 November 2026), and server backup solutions keep scheduled copies away from the live account for VPS and cloud customers. A daily copy is a floor, not a strategy — verify it can be restored, not just that it exists.

No — payment buys a promise from someone who has already broken into your site, and the practical alternative is the restore you prepared. There is no guarantee the key works, payment marks you as a payer who may be attacked again, and the money funds the next attack on someone else. Some insurers and jurisdictions also treat ransom payment as a regulated transaction.

If no clean copy exists, rebuild from the last known-good export and treat the gap as lost content — slower, but still cheaper and safer than a second encryption after a first payment. The decision gets easy only when the offline backup exists; that is the real reason this page keeps returning to it.