The website being hacked is an event that every operations and development personnel dreads to face, but one they must be prepared for in advance. Whether due to vulnerabilities, weak passwords, or security issues with third-party components, once a website is compromised, calmly and methodically conducting an investigation is key to minimizing losses and preventing secondary attacks. Therefore, the first thing to do after discovering a website intrusion is to shut down the website and preserve the scene. Never blindly modify or delete files or logs.
To identify vulnerabilities, we first need to determine the hacker's intrusion path in order to narrow down the scope of the investigation. There are three main ways a website can be compromised: file tampering, database tampering, and server tampering. Common issues such as website hijacking, snapshot hijacking, data tampering, backdoors, web trojans, and website title tampering all fall under these three categories.
How do you determine the intrusion path?
It’s very simple. If it involves website backdoors, web trojans, website title tampering, or most cases of website hijacking, these fall under the file tampering path. Any intrusion where the hacker has tampered with website files can be classified under this category.
If the database has been tampered with—such as changes to account balances or user information—it falls under the database tampering path.
In other words, both file tampering and database tampering will leave traces within the website. For cases that do not clearly belong to either of these two paths, you can check the website files (especially the homepage files and configuration files) and the website configuration items in the database to see if malicious code has been injected.
If neither the database nor the website files contain malicious code, then the intrusion belongs to the server tampering path. For example, snapshot hijacking and unauthorized content pages generally fall into this category.
For intrusions involving file tampering, the cause is usually a vulnerability in the online upload module or a leaked FTP password. In rare cases, it may be caused by cross-site intrusion. For database tampering intrusions, the cause is typically an SQL injection vulnerability in the website. As for server tampering intrusions, the possible causes are more numerous.
For file tampering intrusions, the investigation is relatively straightforward. You can use the free [Huweishen Cloud Antivirus] to scan the website and identify web trojans and backdoors. For database tampering intrusions, the investigation is very troublesome because it is difficult to pinpoint the exact entry point. You have to search through massive amounts of website logs for clues, and often you may not find anything. For server tampering intrusions, it is even more difficult because there are many ways to compromise a server—website vulnerabilities, application vulnerabilities, and system vulnerabilities can all lead to an intrusion.
Therefore, unless it is absolutely necessary, it is not recommended to identify vulnerabilities. Directly addressing the intrusion problem is often better and more cost-effective. We also do not recommend fixing vulnerabilities as a solution. Although this approach sounds the most effective, it is very difficult to implement in practice. First, you need to identify the vulnerability points, which is a challenge in itself. Then, once the problem is found, you need to know how to fix it, which requires developers to have extensive security experience and development skills. Even if you fix a vulnerability, fixing it often introduces new vulnerabilities. After all, you’ve probably never heard of a CMS system without any vulnerabilities.
If you have clean backup files, first restore the website from the backup, then deploy the necessary protection systems. As the saying goes, to do a good job, you must first sharpen your tools. You can use [MagiAegis Defense System], an all-in-one solution for all security issues. For database tampering intrusions, the injection protection module easily handles the problem and works for all websites on the server. For file tampering intrusions, the tampering protection module allows you to customize protection rules for various CMS systems, preventing tampering without side effects. For server tampering intrusions, the automatic patch update module addresses system vulnerabilities, the process protection module addresses application vulnerabilities, the WAF module addresses website vulnerabilities, the remote protection module addresses brute-force attacks, and the trojan protection module addresses web trojans and backdoors. With nearly a hundred security modules, the system provides comprehensive protection for your servers and websites, giving you complete peace of mind.