At 11pm on a Tuesday, my phone rang.
It was a client. His company website — a business that had been operating for decades, with thousands of pages of product data, hundreds of blog posts written over years — was completely down. Not “slow” or “throwing a 404.” Down. The kind of down where you try to log into cPanel and find yourself locked out entirely.
The cause: ransomware.
What Ransomware Does to a Website
Most people associate ransomware with corporate networks and hospital systems. But shared hosting accounts are extremely common targets. When ransomware hits a website, it systematically encrypts files — your PHP scripts, your database, your media, your configuration files — and makes them completely unreadable without a decryption key.
In this case, the encryption had already started by the time I was called in.
The attackers wanted money. The website was inaccessible. Years of content were at risk.
Two things are worth knowing before you read what we did. First, US CISA’s #StopRansomware guidance is explicit that paying the ransom is not recommended — it does not guarantee decryption, and it funds the next attack. Second, in India, CERT-In is the national incident response agency, and its 2022 directions require certain classes of cyber incident, ransomware among them, to be reported within six hours of being noticed. Most small businesses hit by this have never heard of either. We did not pay, and we did not need to.
What Every Other Developer Said
Before me, the client had shown the problem to a few developers. The response was consistent:
“The data is encrypted. There’s nothing to be done.”
“You’ll need to start from scratch.”
“This is very complex. It will take weeks and cost significant fees.”
I understand the instinct — ransomware is legitimately serious. But “there’s nothing to be done” is almost never the full truth. It just means the person saying it doesn’t want to look hard enough.
What We Actually Did
Ransomware doesn’t encrypt everything instantly. It works sequentially, file by file. If you catch it early enough, there’s a window — and this time, we did.
Step 1: Stop the spread. The moment I got access, I suspended all processes on the hosting account. No more encryption could occur while we assessed.
Step 2: Map what was intact. I went through the file system methodically — not panicking, just cataloguing. Database files: partially encrypted but recoverable with the right tools. Blog posts (which my client had spent years writing): largely intact. Product catalogue: recoverable. Media (images, videos): encrypted. Gone.
Step 3: Extract the recoverable data. Using database recovery tools, I pulled every blog post. Every product listing. Every category, every tag, every piece of structured content that existed before the encryption reached it. Nothing was left on the table.
Step 4: Diagnose the entry point. Ransomware doesn’t appear from nowhere. We found a vulnerable outdated plugin that had been sitting unpatched for eight months — the attacker’s entry point. That plugin, and all others like it, were identified and quarantined.
Timeline: under 24 hours from first contact to full recovery of all recoverable assets.
What Was Lost vs. What Was Saved
| Asset | Outcome | Why |
|---|---|---|
| Blog content (hundreds of posts, years of writing) | Recovered | Stored as database rows; encryption had not reached the tables |
| Product catalogue | Recovered | Database-resident, extracted with recovery tooling |
| Categories, tags, structured and SEO-relevant content | Recovered | Database-resident |
| Business information, contact details, page copy | Recovered | Database-resident |
| Uploaded media (images, banners, product photos) | Lost | Filesystem-resident; encrypted before we got access |
| Site configuration and PHP source | Discarded | Untrustworthy after compromise — rebuilt clean rather than restored |
The pattern is not luck. Ransomware walks the filesystem, and on a typical hosting account the media directory is large, early in the walk, and encrypted first. Content in the database survives longer. That is why a site whose value lives in written content is more recoverable than one whose value lives in photographs.
The media was painful — but it was replaceable. The written content was not.
The Real Lesson Here
This incident happened because of a chain of small neglects:
- A plugin hadn’t been updated in 8 months
- There were no recent backups
- No monitoring was in place to detect unusual file activity
- No one was watching
Every single one of these is preventable. Monthly maintenance — updating plugins, running backups, monitoring for anomalies — costs a fraction of what an attack like this costs in time, stress, and lost content.
The website is now being rebuilt from scratch at an enterprise level, with proper infrastructure, security hardening, and a backup system that runs automatically every 24 hours.
The client’s content survived. The attackers didn’t win.
If your website is on shared hosting, running WordPress with plugins you haven’t updated in months, and you have no backup from this week — you should be uncomfortable reading this. Because this exact situation can happen to you.
This is the same neglect I described in why Indian business websites fail: the site is treated as a one-time deliverable rather than an ongoing tool. Nobody is watching. The difference here is that the bill arrives all at once.
What To Do In The First Hour
If you are reading this because it is happening to you right now, in this order:
- Do not pay. CISA’s guidance is unambiguous — payment does not guarantee a working decryption key.
- Isolate, don’t delete. Suspend processes and take the site offline. Do not wipe or reinstall: an encrypted file is evidence and, often, still partly recoverable. A reinstall destroys both.
- Snapshot everything as-is. Copy the whole account, encrypted files included, somewhere else before touching anything. Every recovery option depends on this.
- Ask the host for their backup retention. Most shared hosts hold a rolling window of nightly backups. Many clients never ask.
- Report it. In India, CERT-In requires reporting of ransomware incidents within six hours of noticing them.
- Then triage the database. Content usually outlives the filesystem, as it did here.
FAQ: Website Ransomware Recovery
Can an encrypted website ever be recovered without paying? Often, partly. Recovery does not mean decrypting the attacker’s files — it means extracting whatever was not yet encrypted, most commonly the database, and rebuilding around it. In this case that meant hundreds of blog posts and the full product catalogue. Whether it works depends almost entirely on how early the attack is caught.
How long does recovery take? This one took under 24 hours from first contact. That is fast because the client called within hours and the encryption was mid-run. A site discovered days later, fully encrypted, with no host backups, is a rebuild, not a recovery.
Should I pay the ransom? No. Payment funds the next attack, marks you as a paying target, and frequently produces a key that does not fully work. Exhaust host backups, database extraction and clean rebuild first.
How did the attackers get in? An outdated plugin, unpatched for eight months. This is the ordinary case. The entry point is almost never exotic — it is a known vulnerability in software that had a fix available and nobody applied it.
Will my Google rankings survive? If the content is recovered and the site is back quickly, largely yes. Prolonged downtime and Google flagging the domain as compromised are what cause lasting damage — which is why containment speed matters more than a perfect restore.
What actually prevents this? Four things, none of them expensive:
| Control | What it prevents | Rough cost |
|---|---|---|
| Automated off-site backups (daily, retained 30 days) | Total content loss; makes any attack survivable | Low |
| Prompt plugin, theme and core updates | The entry point used in this attack | Low |
| File-integrity and uptime monitoring | Days of undetected encryption | Low |
| Restricted admin access, strong credentials, 2FA | Credential-based compromise | Free |
The client is paying for all four now. Together they cost a fraction of what one night of this cost him.
Klixo Studio offers website maintenance plans that include weekly backups, security monitoring, and plugin management. If you want your site protected, get in touch or read about what we build.