What order should be followed after the website is found to be planted with backdoor scripts, for cleaning, rollback and reinforcement
After a website is found to have been planted with a backdoor script, what is the correct sequence of cleaning, rollback, and strengthening? The correct sequence is to first cut off the writable channels, then repair the entry, then roll back the entire trusted backup, and finally strengthen and review. Most websites that are repeatedly hacked fail in the first step: delete files first.
The security agency has issued two principles in this round of announcements targeting content management systems: immediately patch affected platforms and extensions (Popular CMS platforms include WordPress, Joomla, and Craft CMS are common targets mentioned in the announcement), and restore compromised websites from known-good backups. These two principles are the basis for the sequence.
Step 1: Confirm the breach surface instead of deleting files first
Before deleting a visible script, fix four things first: file timestamps and paths, Web server and PHP or application process logs for the corresponding time period, the most recent version or configuration changes, and the background account list and scheduled tasks.
The output of this step is 'entry guessing': whether unauthorized uploads are exploited, weak passwords are brute-forced, or known issues have not been patched. Cleaning up without confirming the entry is like changing the furniture without knowing how the door lock is opened.
Step 2: Patch first, then discuss recovery.
The order is reversed and the”After being restored, it will come in through the same door again”. The reason why the immediate repair is placed before the restoration is that as long as the entrance is still open, any cleaning action is only temporary.
The objects to be repaired include the system body and the extension layer, and in practice, the extension layer is more likely to be ignored – system updates are recorded, and the sources and versions of third-party extensions and templates are often ignored. The restoration action is only entered after the repair is completed.
Step 3: Roll back from a good backup known to be good.
“Known good”requires you to clarify three things: this backup time point is before you are sure of the intrusion time, the recovery steps can be repeated, and the recovery content includes data and uploaded static files.
AnQiCMS's backup and recovery is a built-in feature of the background, and data along with static files are included in the backup scope. This design is most valuable in emergencies: only restoring the database backup will leave the articles and attachments empty, while the attachment directory is exactly the high-risk location for script writing.
On what conditions can on-the-spot cleaning be accepted? It is only feasible when you can confirm that there is only one entry point and that the script only appears in a small number of enumerable files. In all other cases, it is recommended to roll back. After cleaning, it is still necessary to do a persistent check: new accounts, scheduled tasks, hidden outputs in template files, and executable files in the upload directory.
| Stage | Action | Completion criteria |
|---|---|---|
| Stop the bleeding | Restricting the background entry and write permissions | The attacker cannot continue to write new files |
| Repair | The system core and extensions are upgraded to the fixed version | The affected component versions can be checked |
| Rollback | Restore the entire site using a trusted backup | Verify the recovery results in an isolated environment |
| Rotation | Change the signature configuration and all admin passwords | All old sessions and credentials are invalid |
| Review | Logs, accounts, tasks, upload directories | All four items have check records |
Step four: strengthen from the credentials
Upgrading to the fixed version only closes new exploit paths, does not revoke the sessions already obtained. The sequence of credential rotation is very important: first rotate the signature keys of all sites, so that all tickets issued before this are invalidated, then change all admin passwords, and require all management accounts to log in again.
AnQiCMS in the v3.6.6 upgrade prompt is written in this order: This version fixed two high-risk issues of list sorting parameter injection and the login credentials of site switching can be forged, and it requires the rotation of signature configurations of all sites and the modification of all administrator passwords. The built-in JWT authentication, content sensitive word filtering, and anti-crawling interference codes belong to the normal protection layer, responsible for narrowing the entry of SQL injection and XSS in daily operations.
Make sure to unify the external statements: The full-site replacement tool can batch replace keywords or links, during the **horse period, the content published often contains external anchor text and wording that should not be left, and it is costly to change each article one by one, and batch replacement followed by random review is more controllable.
Common questions
Question: Can we only do file monitoring without repairing?Answer: No. Monitoring only tells you that it has been changed, but does not prevent it from being changed; when the entry has not been repaired, the alarm will continue to repeat.
Question: How can we confirm that it is clean after recovery?Answer: Look at three points - whether the backup time point is earlier than the intrusion time, whether the same type of files appear after recovery, and whether there are new successful logins in the suspicious period. All three points can be answered to be closed loop.
Question: Should we change the host?Answer: Only when the server layer is taken over is it needed. The basis for judgment is whether there are abnormal processes and accounts outside the site, and it is not enough to draw this conclusion solely based on the on-site script.