Hacked/inserted with malicious code/redirected: checklist for quarantine & safe recovery

When the website is hacked/inserted with malicious code/strange redirect, the number 1 goal is not to "make it beautiful immediately" but to isolate - collect evidence - restore safely and then reinforce to avoid re-infection. Below is a real combat playbook you can apply immediately, in order of priority P1 → P2 → P3.

If you need a rescue framework with SLA P1 ≤ 2–4h with a clear responsible person, you can refer to Ho Chi Minh website maintenance service (troubleshooting, recovery and hardening playbook): Ho Chi Minh website maintenance service .

1) Quick identification (5–10 minutes)

Common signs

Automatically redirect to unfamiliar pages (especially when accessing from Google/di dynamic).
Unusual broken interface, strange popup/iframe embedded, Japanese/Pharma link inserted.
Server CPU/IO increase suddenly, email/hosting reports malware.
Google Search Console reports Security issues (Malware/Deceptive content), Safe Browsing warns “Harmful website”.
Log records many unusual 404/5xx, login bruteforce.

Determine scope

Whole site or part (blog, /wp-content/uploads, theme/plugin)?
Only Google/mobile clients or all?
Is it affected by production or staging too?

2) P1 – Isolate & preserve evidence (0–60 minutes)

Goal: prevent spread, preserve status quo for investigation, recovery phục lưu thông an toàn.

Bật chế độ cách ly

Tạm chặn public bằng password trên server/ngăn truy cập IP (nếu có thể).
Hoặc trả 503 Maintenance cho các đường dẫn công cộng (đừng 302/301).
If WordPress: set Maintenance page static (do not run dynamic PHP).

Back up forensics before touching

Snapshot entire source code + DB + logs (web, PHP-FPM, WAF/CDN) to control Check later.
Save copy off-site (off-site).

Change key & invalidate session

Change password (hosting/SSH/DB/CMS/FTP), on 2FA.
Revoke API token (CDN, payment, SMTP), invalidate sessions (all log out).

Isolate strange process

Temporarily stop suspicious cron, kill process PHP/strange command, lock write temporarily to an easily inserted directory (e.g. /uploads).

During phase P1, the goal is to stop bleeding. Don't rush to "clean up" if you don't have a copy to serve the investigation.

3) P2 - Investigate the cause & clean up (2–6 hours)

3.1 Determine the entry point (attack vector)

Unique admin account, login attempt from foreign IP?
Plugin/theme just updated Updated or downloaded from an unreliable source?
Upload PHP in /uploads, /temp, or .htaccess is corrupted?
DB injection: strange content in wp_options, siteurl/home, post meta, menu.

3.2 Checking malicious code signatures (IOC – Indicators of Compromise)

Common PHP patterns: eval(base64_decode(...)), gzinflate, str_rot13, preg_replace('/e', ...), assert($_POST...).
Suspicious files: fake wp-*.php in /wp-includes/, random file name .ico/.jpg but contains PHP, cron/backdoor in /wp-content/mu-plugins/ or /wp-content/sessions/.
.htaccess add redirect rule according to user-agent/referrer (only redirect when coming from Google/mobile).

3.3 Clean up in safe order

Freeze write permissions (only tech has permission).
Replace core (WP core, CMS core) from main source
Remove unused or suspicious plugins/themes.
Cleanly install the remaining plugins/themes (download the original version).
Scan & remove:
- Scan file-level: find malicious code samples, compare checksum with the version clean.
- Scan DB-level: find strange scripts in options/posts/meta/terms.
Delete webshell/backdoor (hidden PHP files, strange file extensions).
Clean .htaccess/nginx conf (remove strange redirect rules, keep basic rewrites). version).
Regenerate salts, keys (WP AUTH_KEY, SECURE_AUTH_KEY…), change all passwords.

3.4 Check “smart” redirect

Access from Google/mobile (using another UA) to detect rules according to UA/Referrer.
Match logs before–after cleanup, ensure HTTP 200 standard for money pages URLs.

4) P3 – Service restore & SEO cleaning (days 1–3)

4.1 Open controlled access

Unload maintenance/503, enable the site partially if necessary.
Keep WAF/CDN in “strict” mode for the first 48–72 hours (blocks attack patterns).

4.2 Restore SEO signals

In Google Search Console, open Security issues and Request Review after cleaning up (brief description “removed malicious code, replaced core/plugin, changed keys, enabled WAF”).
Remove Junk URL (if hacker creates many spam pages) via Removals tool or reasonable 410/301.
Send back Clean Sitemap; check Coverage (404/Soft 404/Alternate canonical).
Recompare robots.txt (make sure not to accidentally block after quarantine).

4.3 Closely monitor 7–14 days

5xx/CPU/IO chart, login number failed, strange country traffic.
Core Web Vitals (avoid malware that pulls heavy scripts), CTR/Impressions in GSC.

For sites with transactions, check payment webhook, test payment (sandbox/real small) to make sure the order cycle is not modified change.

5) Hardening to prevent re-infection (week 1)

Infrastructure layer

WAF/CDN (Cloudflare/…): enable Bot Fight, block attacking countries, rate limit /wp-login.php, /xmlrpc.php, Apply challenge to sensitive path.
Enable TLS 1.2+, HSTS, HTTP/2/3.

Application layer

Process update: staging → test → production, yes rollback.
Uninstall plugin/theme nulled; Minimize the number of plugins.
Disable file edit in dashboard (WP DISALLOW_FILE_EDIT).
Decentralize least privilege for FTP/DB/CMS; separate CI/CD accounts.
Disable/limit XML-RPC, enable 2FA for admin, change login URL (if applicable).

Security configuration layer

Content-Security-Policy (CSP): whitelist domain script/img/font.
X-Frame-Options / Permissions-Policy / Referrer-Policy.

Train content team on phishing, media/script upload rules.

If you need a monthly maintenance roadmap (updated checklist, clean up recurring errors, speed audit/technical SEO) to maintain a clean & stable website, see monthly website maintenance process built by Tan Phat Digital team: Web Maintenance Services.

6) Communication & legal (don't miss it) forget)

Transparent notification to users (level depends on affected data).
Force password change for at-risk user groups; invalidate old login token.
If related to payment/PCI/PII, legal consultation & regulatory reporting compliance.

7) Frequently Asked Questions (FAQ)

Hacked by “Japanese/Pharma”, file cleaning is enough?
Usually not. This form is often insert DB (meta, options, menu). Need to scan file + DB, edit .htaccess, regenerate keys, then turn on WAF.

Should I restore the backup and be done?
Restore helps a clean starting point, but if the attack vector is not covered (faulty plugin, leaked key), the site is easy to re-infect. Always hardening after restore.

How long does it take for Google to remove the "Harmful website" warning?
Usually 24–72h after Request Review and it's really clean.

Only redirect when accessing from Google/mobile, not accessing directly → is it hacking?
Very likely. Attackers often hide using the UA/Referrer condition; Please check .htaccess, insert script and logs.