Direct answer: If a company website is defaced or infected with malware, isolate it and preserve evidence first, then change passwords, fix the entry point, restore from a clean backup, and finally handle search-platform review and a post-incident review. Do not just delete pages, reinstall the CMS or overwrite production with a backup—you may lose both the entry point and the evidence.
This report is for owners, marketing/website leads, IT/operations, legal and procurement teams at manufacturers in Changzhou and nearby cities. It covers the first 0–72 hours after website defacement, malware injection, malicious redirects or account takeover. Information is current to 2026-10-29. It is not security forensics, legal or regulatory advice, and does not promise a fixed recovery time; serious incidents should go to a professional security/forensics firm and the relevant authorities.
Preserve the scene before fixing the entry point; confirm the backup is clean before restoring; clean and verify before requesting a search review. “The page opens” does not mean the incident is over.
What should we do in the first 0–72 hours?
Isolate the affected site and accounts, preserve logs/files/screenshots, change CMS, hosting and domain passwords, and confirm the entry point and scope before deciding on recovery, reporting or a police report.
In an enforcement case published by China's Cyberspace Administration on 2026-09-15, a Shanghai electronics company's portal used a weak administrator password for years; in April 2026 the account was brute-forced, malicious code was implanted in the website source files, and search results showed large amounts of illegal and harmful content. The company was ordered to rectify and fined for failing its cybersecurity protection duties (official notice). The first principle is not “delete everything quickly”, but preserve the evidence and the entry-point clues.
| Time | First actions | Evidence to keep | Do not |
|---|---|---|---|
| 0–2 h | Switch the affected site to a maintenance page or take it offline; keep the original files and database, do not wipe them | Page screenshots, URLs, discovery time, visitor/customer reports | Delete files, format or reinstall |
| 2–6 h | Map the scope: pages, database, forms, members, search links, server processes and login records | Logs, file timeline, unusual accounts, malware samples | Fix only the homepage and ignore inner pages/database |
| 6–24 h | Change CMS/hosting/FTP/domain/API passwords, enable MFA, revoke departed or shared accounts and sessions | Password-change record, permission list, session-revocation screenshot | Keep the same password or shared account |
| 24–72 h | Patch the vulnerability, isolate/replace the affected plugin or theme, restore a clean backup in an isolated environment, run regression tests | Patch record, scan result, recovery and test record | Overwrite production with the old backup |
| After 72 h | Search-platform review, incident report/summary, customer communication and post-incident review | Submission record, report, review and remediation list | Repeatedly request review before cleanup |
The timeline is an editorial suggestion, not a regulatory deadline; reporting deadlines depend on the incident level under China's Measures for Reporting Cybersecurity Incidents. NIST SP 800-61r3 also treats incident response as part of risk management, with evidence preservation and post-recovery review.
How do we tell defacement, malware and account takeover apart?
Check page content, file/database changes, server processes and login records; the first action differs by type, so “restore the page” is not enough for every incident.
“The website was hacked” is too broad. A changed homepage, a normal page redirecting to gambling or adult content, a search warning, an unknown administrator in the CMS, or an unusual server process may have different entry points. Classify first, then decide whether to change passwords, remove malware, repair the database or replace the host; otherwise the site may be compromised again soon after recovery.
| Type | Common signs | First action | Key evidence |
|---|---|---|---|
| Defacement | Gambling, adult, betting or unknown outbound links on the homepage/sections; titles/descriptions changed | Take offline/screenshot, keep pages and database, check CMS publishing records | Page snapshot, modification time, publishing account |
| Malware/redirect | Normal pages redirect, pop-ups, mobile redirects; search warning | Check JS/templates/plugins/server, isolate malicious files, do not delete only visible links | Malicious script, file hash, access log |
| Account takeover | Unknown CMS administrator, unusual FTP/hosting/domain logins, password changed | Change passwords, enable MFA, revoke sessions, check login IP/time | Login log, account list, password-change record |
| Database injection | Many pages/titles changed in bulk; normal content carries injected links | Back up the database, find the write path and CMS vulnerability, clean the injected content | Database snapshot, write/slow-query log |
| Plugin/supply chain | Abnormal behaviour after a plugin/theme update, or a third-party script replaced | Roll back the version, isolate the plugin, verify the third-party script source | Version record, script URL/hash |
The classification is an editorial triage framework, not a forensic conclusion; a serious incident should be confirmed by a professional security/forensics team.
How do we validate backup recovery and avoid restoring malware?
Confirm the backup predates the intrusion and is not infected, then restore and scan in an isolated environment; after recovery, test pages, forms, database, permissions and search status.
A backup is not enough just because files exist. Verify the backup time, completeness, location and access permissions; if the backup was taken after the intrusion, or the backup server was also controlled, restoring it may bring the backdoor back. A safer path is: restore in an isolated environment, scan, patch, rotate keys, then switch production; after recovery, run regression tests on pages, forms, database and search status.
| Check | How to verify | Evidence |
|---|---|---|
| Time point | Backup predates the first anomaly; confirm it is not a “poisoned backup” | Backup time, anomaly timeline |
| Completeness | Database, CMS files/media, themes/plugins and configuration can all be restored | Recovery list, checksum result |
| Isolated restore | Restore in a test environment, not directly over production | Test URL, recovery record |
| Malware scan | Scan for backdoors, malicious JS, abnormal PHP/cron/processes | Scan report, quarantined-file list |
| Entry-point fix | Patch CMS/plugin/theme/server vulnerabilities; change all related passwords and keys | Patch record, password-change record |
| Regression test | Pages, forms, search, members, payment/download, mobile and 404/301 | Test sheet, screenshots, owner |
Recovery targets (RTO/RPO) depend on the business and contract; no zero-loss or fixed recovery time is promised. NIST SP 800-61r3 treats recovery and post-incident improvement as part of incident response, not the end of the incident.
How do we handle search blacklists and security warnings?
Clean and verify first, then submit a security review in Search Console or Baidu's webmaster platform; do not repeatedly submit while malicious content is still present.
After a malware infection, search engines may show “dangerous site”, “this site may harm your computer”, or remove/derank some results. The order is: clean malicious content, fix the entry point, confirm the whole site no longer redirects, then check the search platform's security issues and request a review. Google's Security Issues documentation asks site owners to fix the problem before requesting a review; on Baidu, follow the current webmaster-platform prompts. Submission does not mean immediate removal, and no timeline is promised.
| Platform/item | What to do | What to record |
|---|---|---|
| Google Search Console | Check Security Issues; after fixing, request a review | Problem screenshot, fix record, submission time |
| Baidu Search Resource Platform | Submit a review/feedback according to the current security/abnormal-status prompt | Submission record, reply, recheck result |
| Old titles/snippets | Wait for recrawl after recovery; update sitemap/internal links if needed | URL, crawl/index status |
| Sitemap/indexing | Check 200, canonical, noindex, robots and sitemap | Checklist, fix record |
| Spam links/injected pages | Clean, disavow/report, monitor newly added URLs | Link list, handling record |
| Visitor/customer notice | Use a maintenance page or notice to explain impact, recovery progress and contact | Notice version, publication time |
Google's official guidance: Search Central Security Issues; for Baidu, follow the current webmaster-platform prompts. A review request does not guarantee immediate removal, recovery time or rankings.
How do we handle incident reporting, customer communication and contracts?
First classify the incident to see whether it reaches the “relatively major” threshold; if so, report within the regulator's deadline and report suspected crime to police; prepare customer/visitor notices and a supplier responsibility list.
China's Measures for Reporting Cybersecurity Incidents took effect on 2025-11-01 and apply to network operators that build, operate or provide services through networks in mainland China. The Measures require an initial classification under the attached Incident Classification Guide: critical-information-infrastructure operators report to the protection department and public security “at the first opportunity”, no later than 1 hour; other network operators report to the provincial cyberspace administration no later than 4 hours; a summary report is due within 30 days after handling. Whether an incident reaches “relatively major” depends on the official classification and actual impact—do not assume.
| Item | What to do | Evidence/record |
|---|---|---|
| Classification | Use the official guide to decide whether it reaches “relatively major”; consult the authority/professional if unsure | Assessment sheet, basis, owner |
| Reporting | Report to the local cyberspace/protection department/public security within the deadline; report suspected crime to police | Report time, channel, receipt |
| Customers/visitors | Explain impact, actions taken, recovery progress, contact and anti-fraud warning | Notice, email/SMS, customer-service record |
| Suppliers | Require hosting/CMS/plugin/website/operations suppliers to report and cooperate under the contract/SLA | Ticket, logs, fix record |
| Summary | Within 30 days after handling, review cause, measures, harm, responsibility and remediation | Incident summary, remediation list |
Reporting duties and deadlines are governed by the Measures for Reporting Cybersecurity Incidents; this article does not determine the level of a specific incident and is not legal advice. Even below the reporting threshold, keep records and assess customer-data impact.
7/30/90-day acceptance checklist
At 7 days check entry points/backup/search/forms; at 30 days check logs/permissions/patches/review; at 90 days check drills/supply chain/contracts and monitoring; every item needs evidence.
“The site is back” does not close the incident. Within 7 days, confirm there is no second defacement, the form has not been injected, and search warnings are being handled; within 30 days, complete logs, permissions, patches and the incident summary; within 90 days, run a recovery drill and review the supply chain and contract/SLA. The checklist below can be shared by IT, website operations, suppliers and legal.
| Stage | Check | Pass standard/evidence |
|---|---|---|
| 7 days | Pages, forms, downloads, members/payment, mobile | No malicious redirects/links; test record and screenshots |
| 7 days | Backups, accounts, keys, sessions | Clean backup restorable; passwords/MFA/permissions updated |
| 7 days | Search platforms, sitemap, robots, 404/301 | Submission/feedback record; status-code and index checklist |
| 30 days | Logs, monitoring, patches, plugin/theme versions | Logs searchable; alerts; patch record |
| 30 days | Incident report/summary, customer communication | Report receipt, summary, notice record |
| 30 days | Supplier responsibility, SLA, compensation/remediation | Ticket, contract clauses, remediation plan |
| 90 days | Recovery drill, permission review, supply-chain recheck | Drill record, permission matrix, third-party script list |
| 90 days | Monitoring metrics, training, drills and budget | Monitoring report, training record, annual plan |
The checklist is an editorial suggestion, not a substitute for forensics, legal advice or regulatory requirements; NIST CSF 2.0 can be used as a reference for governance, identify, protect, detect, respond and recover.
What can Lingyi do—and not do?
We can help with website-side triage, page cleanup, backup recovery, account handover and acceptance checklists; we do not provide penetration testing, forensics, legal conclusions or regulatory report writing—use a professional security firm for serious incidents.
Lingyi Information is based in Changzhou and is one candidate for website development and operations; we do not claim a local security team or a 24/7 security operations centre. We can help map website/CMS/hosting/domain/form entry points and handover checklists, assist with visible malicious-content cleanup, clean-backup recovery, page/form repair, evidence and remediation lists. We cannot replace professional forensics, penetration testing, legal advice or a regulatory report. If customer data, payments, members or critical business systems are involved, engage a professional security/forensics firm first.
Who should read this, who should not, and what decision does it support?
It fits companies whose website was defaced, infected, has abnormal accounts or search warnings; it does not fit teams with no website/customer data or those seeking a “guaranteed recovery/no penalty” promise.
Who should read: owners, marketing/website leads, IT/operations, legal and procurement at manufacturers in Changzhou and nearby cities; companies using a CMS/plugins, outsourced website/operations, forms/members/downloads, or recently seeing unknown links, redirects or CMS anomalies. Who should not: teams with no website/mini-program/online form; companies already facing ransomware, data breach or payment-system intrusion that need forensics and incident response (engage a professional security firm first); teams looking for a supplier who promises “delete a few links and everything is fine”. Decisions supported: isolate or restore first, whether the backup is usable, how to submit a search review, whether reporting/police involvement is needed, how to hold suppliers/contracts accountable, and how to accept recovery at 7/30/90 days.
FAQ
If the website is defaced, should we delete the malicious page or back up first?
Preserve evidence before cleaning. At minimum keep page screenshots, URLs, discovery time, logs, malicious files and a database snapshot; if you delete files or format the server immediately, the entry point, timing and scope become hard to investigate. Cleanup can be done in an isolated environment or on a backup copy; take production offline or use a maintenance page to stop the damage.
Does reinstalling the CMS solve the problem?
Not necessarily. Reinstalling removes current files, but if the entry point is a weak password, plugin vulnerability, host permission, domain account or third-party script, the site can be compromised again. The order should be: preserve evidence, find the entry point, change passwords/patch, restore in isolation, regression-test, then go live.
What if the site is defaced again after restoring a backup?
It means the entry point was not fixed or the backup was infected. Stop repeated restores, isolate the site, and check hosting/domain/API/plugin/theme/third-party scripts and account permissions; if needed, replace the host, rotate keys, rebuild the environment and engage a professional forensics team. Do not keep overwriting with the same password and the same backup.
How long does it take to remove a “dangerous site” warning?
There is no fixed timeline. Clean the malicious content, fix the entry point, confirm the whole site no longer redirects, then submit a review through Search Console/Baidu's webmaster platform and wait for recrawl and review. Do not submit repeatedly while malicious content remains, and do not treat “submitted” as “removed”.
Must we report to the cyberspace administration?
It depends on whether the incident reaches the applicable “relatively major” or other threshold under China's Measures for Reporting Cybersecurity Incidents and the classification guide. If it does, report through the required channel and deadline; critical-information-infrastructure and major/special-major incidents have tighter deadlines. Even below the reporting threshold, keep records, assess customer-data impact and meet personal-information/data-security duties.
Can we handle it without a security team?
You can do containment and basic triage: take the site offline, preserve evidence, change passwords, enable MFA, check CMS/hosting/domain accounts, restore a clean backup, and check forms and search status. But for server backdoors, database injection, customer-data breach, payment/member systems or persistent attacks, engage a professional security/forensics firm; do not repeatedly reinstall by guesswork.
Bottom line
For a defaced or malware-infected website, preserve the scene and evidence first, fix the entry point, restore from a clean backup, then handle search review, incident reporting and 7/30/90-day acceptance. “The page opens” is not the end of the incident; when unsure, engage a professional security/forensics firm.
Method and limits
This article is public regulation, official enforcement notices, NIST frameworks and editorial research, not security forensics, legal or regulatory advice for any company, website, incident or project. It uses no unpublished client logs, vulnerability details or regulator-internal opinions; the timeline, checklists and 90-day plan are editorial, and handling must be confirmed against the incident facts, contract, authority requirements and professional advice. Regulations, frameworks and platform rules change; the latest official text governs.
Sources
Information is current to 2026-10-29; each official/primary page governs its own scope and version.
- Recent enforcement cases in cybersecurity, data security and personal-information protection: cac.gov.cn. 2026-09-15 notice; includes the Shanghai electronics company case where a weak portal password was brute-forced and source files were implanted with malicious code.
- Measures for Reporting Cybersecurity Incidents: cac.gov.cn. Published 2025-09-15, effective 2025-11-01; reporting entities, classification, deadlines, channels and the 30-day summary requirement.
- NIST SP 800-61r3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: nvlpubs.nist.gov. Reference for incident response, risk management, recovery and post-incident review.
- NIST Cybersecurity Framework (CSF) 2.0: nvlpubs.nist.gov. Reference framework for govern, identify, protect, detect, respond and recover; not a compliance certification.
- Google Search Central, Security Issues: developers.google.com. Official guidance on hacked content, Security Issues checks and requesting review after a fix; no removal timeline or ranking guarantee.