You open your company website in the morning and find the homepage redirecting to a gambling site, with Baidu snapshots full of garbage keywords—when this happens, the boss's first reaction is usually "delete it now," while the technical lead has to face the question "will it come back after we delete it?" A hacked website, if not handled properly, means repeated compromises, search engine penalties, and client distrust. This article lays out the proper handling sequence and what security testing can do.
Don't Rush to Reinstall—First Figure Out What Was Hacked
A website compromise isn't a single problem. Common types include:
- Page tampering: Homepage or section pages injected with hidden links and redirect scripts, sending visitors off-site.
- Backdoor files: Attackers leave a webshell so they can re-enter anytime—deleting the page won't help.
- Database injection: Content tables stuffed with spam links that are invisible from the normal admin panel.
- Server-level hijacking: Nginx or Apache configs modified, or download scripts hidden in scheduled tasks.
A real scenario: A company website for equipment rental was hacked three months after a redesign. The technician only deleted the redirect code on the homepage, but it recurred within a week. Investigation later revealed the attacker had uploaded a backdoor through an outdated editor upload interface, and the historical directory wasn't cleaned during the redesign. Treating only the symptoms without addressing the entry point is as good as doing nothing.
So the first step isn't deletion—it's preserving evidence and locating the entry point: back up the tampered files, logs, and database first, then determine where the breach occurred.
Handling Sequence: Isolate, Collect Evidence, Clean, Harden
After a website is hacked, follow this order:
1. Isolate: Take the site offline or switch to a maintenance page to prevent search engines from continuing to crawl malicious content and to protect users.
2. Collect evidence: Preserve access logs, error logs, and timestamps of modified files. These are the basis for identifying the entry point later.
3. Clean: Remove backdoors, restore modified files, and clean injected content from the database. Be careful not to use an "overwrite" restore that also overwrites logs.
4. Harden: Change all admin passwords, database passwords, and server SSH keys; disable unused upload interfaces and directory execution permissions.
5. Re-check: Monitor for one to two weeks to confirm there's no recurrence.
Pitfall warning: Don't just change the admin password and call it done. If the backdoor is still there, changing passwords only buys time. Also, many company websites are built by outsourcing vendors, and handovers during redesigns are often incomplete—historical directories, test files, and backup files are left on the server, all common entry points.
What Security Testing Can Actually Uncover
Many people think security testing is just "scanning for vulnerabilities." In fact, for sites that have already been hacked, the value of security testing lies in finding the entry point and residual threats.
It typically includes:
- Vulnerability scanning: Checking for SQL injection, XSS, file upload issues, weak passwords, and other common problems.
- Backdoor detection: Comparing file hashes, finding abnormal webshells, checking scheduled tasks and startup items.
- Permission checks: Directory permissions, database account privileges, and whether backend API authentication is reasonable.
- Logic testing: For example, in a booking mini-program, can someone bypass the frontend and submit illegal data directly? In an admin system, can a regular account access administrator APIs through privilege escalation?
One thing to note: Security testing isn't "test once and you're permanently safe." Website development, mini-program development, and App development—whenever new features go live, new risks can be introduced. A practical approach is test once before launch, and again after any major redesign.
How to Protect Your Company Website Daily So You're Not Always on the Back Foot
Rather than waiting to get hacked, do the daily work well:
- Keep software versions updated: Old versions of CMS, frameworks, and plugins are the hardest-hit areas.
- Minimize admin entry points: Change default paths, add two-factor authentication, restrict login IPs.
- Disable script execution in upload directories: This one measure can block a significant portion of upload-based backdoors.
- Regular backups stored off-site: Backups must be restorable and not stored on the same server.
- Log retention: When something goes wrong, no logs basically means investigating blind.
For company websites, consider separating static assets from the main site to reduce the impact of tampering.
When to Bring in MIC Studio
Not every situation requires an external team. If it's just a few lines of code injected into a page, and you can locate the entry point and confirm there's no backdoor, you can handle it yourself.
But in the following situations, a professional team will save you a lot of trouble:
- Repeated compromises where you can't find the entry point yourself;
- The website involves user data, orders, or payments, and you're worried about data leaks;
- You're planning a website redesign or mini-program development and want security testing done before launch;
- The admin system has complex permissions and you want to verify privilege escalation and logic vulnerabilities.
MIC Studio does website development, mini-program development, App development, and script development, as well as website security testing and reverse engineering testing. Our approach is usually to locate the problem first, then provide handling recommendations—we won't ask you to rebuild the entire site right away.
Final Thoughts: Three Things You Can Do Right Now
1. Back up today: Save a copy of your website files, database, and logs in different locations.
2. Check upload directories and admin entry points: Confirm upload directories can't execute scripts and there are no default weak passwords in the admin panel.
3. Schedule a security test: Especially for company websites that were just redesigned or launched—don't wait for something to happen.
A hacked website isn't scary—what's scary is not knowing where the entry point is and whether it will happen again after you've dealt with it. Getting the sequence right is far more useful than rushing to delete pages.