The statistics that 13,000 websites are hacked every day are saying who, and which layer the attack has entered.
About 13,000 sites are hacked every day, who does this statistic refer to? It refers to the fact that in the public site ecosystem with a huge number of installations, being scanned and hit in bulk is the norm rather than an occasional accident, the number is cumulative by day, and the denominator is the entire ecosystem. What is even more worth reading is which layer the attack has reached: malicious code no longer comes only from unfamiliar entry points, but is injected into the core, plugins, and theme files that should exist, with normal paths and owners. Checking for 'whether there are any extra files' will miss a batch. Therefore, the defense line needs to be shifted to change verification, credential management, and the ability to practice recovery.
The applicable scope of the statistical criteria
“Every day, about 13,000 sites are hacked” such numbers come from the overall estimation of the ecosystem, the denominator is the number of publicly available sites of an extremely large magnitude, and the numerator is the cumulative number of hacked events accumulated daily.It describes not the luck of a single site but when the installation volume of a technology stack is sufficiently large, automated scanning will consider it a normal target: the scanning script does not need to target you, just cover you.In the same batch of data, there is another more interesting perspective - the median time for large-scale use is only a few hours, which means that sites that have not been processed after the repair announcement is publicly released will be queued for attempts.These two numbers are enough to judge the priority of risks: don't expect that 'no one will pay attention to my little station', and don't treat it as a certainty that you will have an accident.
What does it mean to inject a legitimate file
The change in the level of risk is here. The traditional intrusion imagination is external requests hitting the login port or upload vulnerabilities, resulting in a file that clearly does not belong to the site; while the common practice now is to write malicious fragments into the core, plugins, or theme files that should exist naturally. Such file paths are normal, the owners are normal, and the timestamps may have been processed together, so checking according to
The defense line should be moved to which layer
The first layer is visible for changes. It can baseline compare content files with templates, so that changes have a chance to be discovered; the document status on the backend distinguishes between formal documents, drafts, pending publication, and recycling bin, with the status and modification records providing clues when the main text is rewritten, and deleted formal documents go to the recycling bin instead of disappearing directly, and also retain the comparison basis.The second layer is about credentials and entry convergence. Login and session are the real targets of the attacker, AnQiCMS fixed the issue of login credentials being forgeable in the v3.6.6 version, the official upgrade suggestion includes rotating the full-site signature key and changing the administrator password: The fix and credential rotation must be done together, otherwise, the path obtained after gaining control remains valid.The third layer is the permission and operation side, actions such as backup and upgrade should be closed by default, and explicitly opened by domain. The fourth layer is the input side, the built-in JWT authentication and content sensitive word filtering handle the submission and verification stages, anti-capture interference code handling content being taken away in bulk, they do not bear the responsibility of backdoor detection.
The order of handling after the event
Follow in order, do not skip steps. First isolate: Limit the entry points that can be triggered externally, to prevent malicious code from being called during the cleaning process. Then collect evidence: Retain Web access logs, file change records, and abnormal request samples to determine the entry point and scope of impact.Then full-scale verification: It is usually not enough to only clean up 'the one found', as the same batch of legitimate files may have been altered in multiple places. It is more effective to check against the list. Subsequently, rotate credentials: The passwords of administrators, interfaces, and site signature-related credentials all need to be updated. Only changing the content and not the credentials will lead to a second entry.Finally, it is time to recover and review: confirm that the site functions and are indexed normally, and supplement this discovery method into the daily inspection.
How to prepare the recovery capability
The cost of backing up decisions for event handling. Only backing up the database will result in missing images and attachments, and the page will be more easily reused after being partially destroyed; data backup should cover static files as well, and a real rehearsal for recovery should be performed. Leave a version that can be rolled back before changing the template, and back up first before upgrading. There is also an often overlooked expense: After the event, you need to check if the collection has been contaminated, attackers may rewrite the text or insert promotional content, which will be read together by search engines, and after the content is restored, it still needs to be reviewed according to the page list, and if necessary, the address that has been changed back needs to be pushed again.
Common questions
Question: Is it necessary for small sites to prepare according to this process?Reorder by cost: backups can be fully restored, credentials can be cleaned up in one go, and file modifications can be seen, and these three things are affordable for sites of any scale.
Question: Why is it not enough to only check for new files?Because malicious segments can be written in legitimate files. It is necessary to compare the content differences of known versions, rather than just looking at whether there are unfamiliar files.
Question: Can changing the password confirm that the cleaning is done?No. Credential rotation prevents re-entry, and the injected code needs to be removed by itself or restored from a clean backup.
Question: Will the hacked page affect search inclusion?Will. The modified main text and promotional content may have been captured, and after restoring the content, you still need to check the index status and resubmit the key address.
Question: Is the file upload function the most dangerous link?It is one of the common entry points, but the risk depends on the permission and validation design: who can upload, where the upload lands after, and whether it can be executed, these three items are more decisive than whether there is an upload function, in terms of the size of the problem.