𝗛𝗼𝘄 𝗜 𝗧𝗿𝗮𝗰𝗸𝗲𝗱 𝗮 𝗦𝘁𝗲𝗮𝗹𝘁𝗵𝘆 𝗜𝗻𝗷𝗲𝗰𝘁𝗶𝗼𝗻 𝗮𝗻𝗱 𝗛𝗮𝗿𝗱𝗲𝗻𝗲𝗱 𝘁𝗵𝗲 𝗘𝗻𝘃𝗶𝗿𝗼𝗻𝗺𝗲𝗻𝘁
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:
• Edge Protection: I used Cloudflare WAF to block suspicious POST requests to sensitive directories. • File Permissions: I locked the directory structure. Directories became 755 and files became 644. I set wp-config.php to read-only. • Disable Editing: I added DISALLOW_FILE_EDIT and DISALLOW_FILE_MODS to wp-config.php. This stops anyone from changing code through the dashboard.
Do not trust a green checkmark from a plugin. Assume a breach has happened. Protect your site from the inside out.
Source: https://dev.to/jahidshah/how-i-tracked-a-stealthy-injection-and-hardened-the-environment-4clm