Restoring a backup without closing the hole
The backup restores the same vulnerable plugin or password the attacker used — and often restores their backdoor with it. Reinfection follows in days, sometimes hours.
ranjan@ranjan.info:~$ man services/malware-removal
Website Malware Removal
Clean the infection, close the door it came through
A hacked website bleeds twice: once through the infection, and again through the reinfection that follows a surface-level cleanup. I remove the malware you can see and the backdoors you can't, identify the entry point, and close it — then get you delisted from Google's blacklist so traffic and mail flow again.
What is website malware removal?
Website malware removal is the process of finding and eliminating malicious code — injected scripts, backdoors, web shells, SEO spam — from a hacked site, then closing the vulnerability it entered through. A proper cleanup has three parts: removing every trace rather than just the visible symptoms, proving the entry point from server logs, and preventing reinfection. Skipping the last two is why most "cleaned" sites are hacked again within weeks.
Written by Ranjan Chatterjee, Infrastructure Consultant · Linux Server Specialist · 15+ years in production Linux · Last reviewed
ranjan@ranjan.info:~$ dmesg | tail
Signs you need this now
A hack rarely announces itself politely. These are the ways it usually shows up — and any one of them justifies acting today.
- Google shows "This site may be hacked" or a red warning page
- Your host suspended the account for malware or outbound spam
- Search results list pages you never created (pharma, casino, spam)
- Visitors get redirected to sites you've never heard of
- Your emails suddenly bounce or land in spam — the IP is blacklisted
- Admin users you didn't create, or files changed at odd hours
- Antivirus warnings when customers open your site
- The site is inexplicably slow while the server works hard on something
ranjan@ranjan.info:~$ cat scope.txt
What this covers
- PHP malware and obfuscated injection cleanup
- Backdoor and web shell detection and removal
- SEO spam / pharma-hack cleanup (spam links, cloaked pages)
- Injected code in themes, plugins, and core files
- WordPress malware removal and core reinstallation
- Laravel and custom PHP application cleanup
- Google Safe Browsing / blacklist removal requests
- Entry-point analysis: how they got in, proven from logs
- Reinfection prevention: patching, permissions, WAF rules
ranjan@ranjan.info:~$ man first-aid
Suspect a hack? Do this first
Five moves that limit the damage and preserve the evidence a proper cleanup depends on.
-
1
Don't delete anything yet
Infected files are also evidence. Their timestamps, correlated with access logs, reveal how the attacker got in — delete them first and the entry point may stay open behind a "clean" site.
-
2
Change credentials from a clean device
Rotate hosting, panel, FTP, database, and CMS admin passwords — from a machine you trust, in case a keylogger on someone's laptop is the actual source.
-
3
Take a full backup of the infected state
It sounds backwards, but a snapshot of the compromised site preserves logs and evidence, and protects you if a cleanup step goes wrong.
-
4
Limit the blast radius
Put the site in maintenance mode if customers are being redirected or data is exposed. If it shares a server with other sites, assume lateral movement until proven otherwise.
-
5
Check Google Search Console
Its Security Issues report tells you what Google detected and where — free triage information, and the same channel used later to request delisting.
ranjan@ranjan.info:~$ grep -i "oops" ~/incidents.log
Mistakes that lead to reinfection
Every one of these comes from a real engagement — usually from before I was called.
Cleaning only the files a scanner flags
Scanners catch known signatures. Attackers leave innocuous-looking loaders — a one-line include in a theme file, a fake image with PHP inside — precisely to survive that cleanup.
Keeping abandoned plugins and themes "just in case"
Deactivated code is still executable code. A large share of the infections I clean entered through a plugin nobody had used in years.
Rotating one password and calling it done
If the database password, an FTP account, or a forgotten admin user survives rotation, the attacker walks back in with credentials — no exploit needed.
Treating the blacklist as the problem
Requesting Google review before the site is verifiably clean burns trust with the reviewer and extends the blacklisting. Clean first, verify, then request — in that order.
ranjan@ranjan.info:~$ diff --options
DIY, provider support, or a specialist?
An honest comparison — each option is right in some situations, including the free ones.
| Option | The right choice when… | Limits & risks |
|---|---|---|
| Security plugin / scanner | Prevention and early warning on a healthy site, or a first opinion on a suspected hack. Free to cheap, runs continuously. | Signature-based: misses custom backdoors and can't do entry-point forensics. "Auto-clean" features sometimes break sites mid-repair. |
| Hosting provider cleanup | The infection is trivial and the host offers cleanup as a service you already pay for. | Typically scanner-driven bulk work: quarantine flagged files, re-enable the account. Entry-point analysis and reinfection prevention are usually not included — which is why suspensions recur. |
| Independent specialist | The site earns money, has been reinfected before, spans multiple sites/accounts, or you need the entry point proven and closed with a written trail. | Costs more than a plugin subscription. Remote work needs hosting access from you, and badly damaged sites may still need a partial rebuild — you'll be told, not billed blindly. |
What you get
- A verified-clean site — scanned, manually reviewed, and monitored after cleanup
- Blacklist delisting submitted and tracked until you're cleared
- A closure report: entry point, files affected, and the hardening applied
Why work with me on this
- 15+ years inside production Linux — this exact work, done at fleet scale
- Founder-operator of two hosting platforms: I've owned the uptime, not just the ticket
- Every change documented and reversible — you keep a written trail, not a mystery
- Plain-language updates and honest timelines you can plan a business around
ranjan@ranjan.info:~$ ./engage --how
How it runs
The same disciplined path on every engagement — scoped, planned, executed with checkpoints, handed off clean.
-
01
Scope
A short brief or call to understand your stack, the real problem, and what a good outcome looks like.
-
02
Plan
A clear architecture plan — steps, risks, rollback and timeline — agreed before anything touches production.
-
03
Execute
Hands-on work with checkpoints. You see progress; nothing changes on your servers silently.
-
04
Handoff
Documentation, access cleanup and a clear path for what comes next. No lock-in, no mystery.
ranjan@ranjan.info:~$ faq --service malware-removal
Common questions
My host suspended the account — can you still clean it?
Yes. Hosts routinely restore access for an active cleanup, and I can work from a backup copy if needed. Suspension is usually the starting point of these engagements, not a blocker.
How long does malware removal take?
Most single-site cleanups complete within 24–48 hours of getting access, including verification scans. Multi-site accounts, heavily obfuscated infections, or servers where lateral movement occurred take longer — you'll get a realistic estimate after the initial scan, not a guess before it.
How much does website malware removal cost?
A fixed price per site for standard cleanups, quoted up front — complex multi-site infections are quoted after a quick scan so the number is grounded in reality. The quote includes entry-point analysis and blacklist delisting; those aren't upsells.
Will you find how they got in?
That's the point of the job. A cleanup without entry-point analysis is a countdown to reinfection — I correlate file timestamps against access logs to establish the vector, then patch it.
How fast can Google blacklist removal happen?
Once the site is verifiably clean, review requests typically clear within 1–3 days. I submit and monitor the request as part of the service rather than leaving it with you.
Will the cleanup break my website?
No — changes are made against a fresh backup, malicious code is removed surgically rather than by mass-deleting, and the site is tested after each stage. Where an infected file is also a functional file (a modified theme, a core file), it's replaced with a clean original, not simply removed.
How do websites get hacked in the first place?
In rough order of frequency: outdated plugins and themes with known vulnerabilities, stolen or weak credentials, abandoned software still installed, and cross-contamination from another site on the same account. Targeted attacks on small sites are rare — automated scanners exploiting known holes are the norm, which is also why prevention works.
Can you guarantee it won't come back?
No honest provider guarantees that — new vulnerabilities appear constantly. What I do stand behind: the current infection fully removed, the entry point it used closed, and hardening plus monitoring that catches any new attempt early. Sites cleaned this way stay clean; the reinfection cycle comes from skipping those steps.
Should I just delete everything and rebuild?
Sometimes — and if that's cheaper or safer for your case, I'll say so in the first assessment. But a rebuild without entry-point analysis often reuses the same vulnerable plugin or password and gets reinfected. Most sites are also recoverable in less time than a faithful rebuild takes.
Do you clean Laravel and custom PHP applications, or just WordPress?
Both. WordPress is the volume leader, but injected code, web shells, and dependency-level compromises in Laravel and bespoke PHP apps are regular work — there the cleanup leans more on version control diffs, composer auditing, and log forensics than on plugin knowledge.
ranjan@ranjan.info:~$ man glossary
Terms you'll hear during a cleanup
Plain-language definitions — so the report reads like information, not incantation.
- Backdoor
- Hidden code that lets an attacker back in after the visible infection is removed — the reason "cleaned" sites get re-hacked.
- Web shell
- A script that gives the attacker a remote control panel on your server: file manager, terminal, database access.
- Obfuscation
- Encoding tricks (base64, gzinflate, hex) that make malicious PHP unreadable to humans and invisible to naive searches.
- SEO spam / pharma hack
- Injected pages and links selling pills, casinos, or knock-offs — invisible to you, indexed by Google, poisoning your rankings.
- Safe Browsing
- Google's blocklist. Landing on it triggers browser warnings and search labels; delisting requires a verified-clean site and a review request.
- Entry point / vector
- The specific vulnerability or credential the attacker used to get in. Finding it is the difference between a cleanup and a countdown.
- WAF
- Web Application Firewall — filters malicious requests before they reach your code. A mitigation layer, not a substitute for patching.
- File integrity monitoring
- Tooling that alerts when files change unexpectedly — how reinfection gets caught in minutes instead of at the next blacklisting.
ranjan@ranjan.info:~$ ls ../related
Related services
Engagements that commonly pair with this one.
Linux Server Security Hardening
SSH, firewall, kernel, PHP, MySQL — locked down in layers, documented, auditable.
View serviceManaged Server Administration
24×7 monitoring, patching, backups, and incident response on a flat monthly retainer.
View serviceEmergency Linux Server Recovery
Boot failures, corrupted filesystems, kernel panics — diagnosed and repaired methodically, fast.
View serviceranjan@ranjan.info:~$ ssh [email protected]
Ready when you are
One paragraph is enough: your stack, the symptom, and when you need it solved. Emergencies are answered first.