A Beginner’s Struggle: Securing a Compromised ThinkPHP Site Over Several Days

A friend downloaded a VIP‑quality source package, deployed it quickly, and the site was immediately compromised; after logging in the website displayed errors, the author accessed the server via Baota panel and identified it as a malicious "killing‑pig" source.

Opening the database revealed that all configuration values had been altered. Log inspection showed a weak password login (admin/654321). The author restored the database, changed the database and backend passwords, and after a test export the data was modified again.

Scanning the local copy with an antivirus uncovered three image codes, leading the author to suspect an automatically executed script trojan rather than the images themselves.

Despite repeated database restores, the site continued to be altered over several days. A Micro‑Step malware scanner was installed, which detected further tampering, but the modifications persisted.

Because ThinkPHP requires executable files to reside in the /public directory, the author examined that folder, found many files (over 20 MB), deleted suspicious ones, and hypothesized that a process‑injection backdoor was remotely triggering changes.

Checking crontab -l showed no scheduled tasks. Further review of the PHP code revealed hidden scheduled‑task files that could be triggered via the backend, although the backend UI did not expose this feature. The author removed those files and edited sys.php to hide the changes, preventing errors.

After about a day, the data was altered again, this time displaying a $100 ransom message on the backend while the front end remained functional, indicating a partial remediation.

Reviewing Nginx logs showed foreign IPs requesting error paths, suggesting the hidden scheduled‑task code was causing the failures. The author also suggested using commands such as who | awk '{print $1}' or cat /etc/passwd | grep "/bin/bash" to enumerate system accounts.

The notification controller send was disabled to stop the ransomware‑style messages. The author concluded that the malware likely persisted in a running process, recommending continuous monitoring, log analysis, and early detection of code‑related issues.

Finally, the author rebuilt the environment on a fresh CentOS 7.6 system, kept the same IP and domain, and observed no further incidents for ten days. Future work includes installing outbound‑traffic monitoring and fixing a suspected file‑upload vulnerability linked to the image codes.

Remediation steps performed:

Set directory permissions appropriately instead of using 777.

Changed all backend passwords.

Changed the database password and blocked external database access.

Deleted unused PHP files.

Scanned all ThinkPHP framework versions for vulnerabilities.