𝗛𝗼𝘄 𝗜 𝗧𝗿𝗮𝗰𝗸𝗲𝗱 𝗮 𝗦𝘁𝗲𝗮𝗹𝘁𝗵𝘆 𝗜𝗻𝗷𝗲𝗰𝘁𝗶𝗼𝗻 𝗮𝗻𝗱 𝗛𝗮𝗿𝗱𝗲𝗻𝗲𝗱 𝘁𝗵𝗲 𝗘𝗻𝘃𝗶𝗿𝗼𝗻𝗺𝗲𝗻𝘁
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