𝗛𝗼𝘄 𝗜 𝗧𝗿𝗮𝗰𝗸𝗲𝗱 𝗮 𝗦𝘁𝗲𝗮𝗹𝘁𝗵𝘆 𝗜𝗻𝗷𝗲𝗰𝘁𝗶𝗼𝗻 𝗮𝗻𝗱 𝗛𝗮𝗿𝗱𝗲𝗻𝗲𝗱 𝘁𝗵𝗲 𝗘𝗻𝘃𝗶𝗿𝗼𝗻𝗺𝗲𝗻𝘁
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:
• Protección perimetral: Utilicé Cloudflare WAF para bloquear solicitudes POST sospechosas a directorios sensibles. • Permisos de archivos: Bloqueé la estructura de directorios. Los directorios pasaron a ser 755 y los archivos a 644. Configuré wp-config.php como de solo lectura. • Desactivar la edición: Añadí DISALLOW_FILE_EDIT y DISALLOW_FILE_MODS a wp-config.php. Esto evita que cualquier persona cambie el código a través del panel de control.
No confíes en la marca de verificación verde de un plugin. Asume que ha ocurrido una brecha de seguridad. Protege tu sitio de adentro hacia afuera.
Fuente: https://dev.to/jahidshah/how-i-tracked-a-stealthy-injection-and-hardened-the-environment-4clm