𝗛𝗼𝘄 𝗜 𝗧𝗿𝗮𝗰𝗸𝗲𝗱 𝗮 𝗦𝘁𝗲𝗮𝗹𝘁𝗵𝘆 𝗜𝗻𝗷𝗲𝗰𝘁𝗶𝗼𝗻 𝗮𝗻𝗱 𝗛𝗮𝗿𝗱𝗲𝗻𝗲𝗱 𝘁𝗵𝗲 𝗘𝗻𝘃𝗶𝗿𝗼𝗻𝗺𝗲𝗻𝘁
You run a malware scan. You replace core files. You update plugins and change passwords. The site looks clean.
Two days later, the client calls. New admin accounts are back. Visitors are being redirected to malicious sites.
This is the nightmare of persistence.
Standard security plugins often fail. Sophisticated attackers do not just drop one payload. They build nested backdoors that hide inside legitimate files.
I recently handled a case where three cleanup attempts failed. The symptoms were specific:
• Ghost Admins: New accounts with random names appeared every 48 hours. • Conditional Redirects: Only new visitors from search engines saw the malicious site. Developers saw nothing.
The team had already overwritten the WordPress core and updated plugins. Scanners showed nothing. The malware regenerated like a hydra.
The attacker had a persistence mechanism in the database or a cron job. Automated scanners missed it because the code was custom.
I used the command line to find the truth.
First, I verified the core files using checksums: wp core verify-checksums
The core was clean. The backdoor lived in wp-content or the database.
I searched for files modified in the last 7 days: find . -type f -mtime -7 -name "*.php"
Then, I searched for suspicious functions like eval() or base64_decode(): grep -rnw './wp-content/' -e 'eval(' -e 'base64_decode('
I found a buried file in an outdated premium plugin. But deleting the plugin did not stop the infection.
The attacker left a trigger in the wp_options table under the cron option. Every time the WordPress cron ran, it fetched a new payload. It re-infected the core files minutes after they were cleaned.
To fix this, you must follow a strict order:
- Database Scrubbing
- Search wp_options for malicious autoload data.
- Check wp_cron for unknown URLs.
- Use SQL to delete unauthorized users directly.
- File System Purge
- Delete everything except wp-config.php and wp-content/uploads/.
- Replace everything with fresh files from the official repository.
- Delete any PHP files inside the uploads folder.
- Credential Rotation
- Regenerate all authentication salts in wp-config.php.
- Reset all database, SSH, and hosting passwords.
I also implemented three guardrails to prevent a repeat:
• 边缘防护：我使用 Cloudflare WAF 来拦截针对敏感目录的可疑 POST 请求。 • 文件权限：我锁定了目录结构。目录权限设为 755，文件权限设为 644。我将 wp-config.php 设置为只读。 • 禁用编辑功能：我在 wp-config.php 中添加了 DISALLOW_FILE_EDIT 和 DISALLOW_FILE_MODS。这可以防止任何人通过仪表盘修改代码。
不要迷信插件显示的绿色对勾。假设入侵已经发生。要从内到外保护你的网站。
来源：https://dev.to/jahidshah/how-i-tracked-a-stealthy-injection-and-hardened-the-environment-4clm