Persistent WordPress malware can be difficult to remove because the visible infection is often only the symptom. You may clean the infected file, replace WordPress core, reset a few permissions, and still see the same malware come back minutes later.

This case study covers a WordPress website where the homepage was repeatedly replaced with inappropriate and illegal content. The obvious infection was inside index.php, but the real problem was a hidden running PHP process that kept rewriting the file after cleanup.

The incident is a useful reminder: when malware returns immediately after removal, you are probably dealing with persistence — a backdoor, cron job, hidden process, compromised user, or server-level issue that is restoring the infection.

The Problem

The website owner noticed that the WordPress homepage was no longer loading the normal site. Instead, the homepage displayed malicious and inappropriate content.

During the first review, we found two major issues:

  • The main index.php file had been modified with malicious content.
  • The .htaccess file had been changed in a way that prevented WordPress from loading normally.

This combination effectively hijacked the homepage. WordPress could not load correctly, and visitors were shown the attacker-controlled content from the modified index.php file.

Modified index.php file showing unusual size and permissions

Initial Cleanup

The first response was straightforward:

  • Remove the malicious content from index.php.
  • Restore the original WordPress index.php file.
  • Restore the .htaccess file so WordPress could run normally again.
  • Check the surrounding WordPress files for obvious malware.
  • Apply basic security hardening to reduce immediate risk.

At first, the site appeared to be restored.

But the malicious content returned almost immediately.

That changed the nature of the investigation. This was not just a one-time file injection. Something was actively monitoring or rewriting the homepage file after cleanup.

Why WordPress Malware Comes Back After Cleanup

When malware returns after you remove it, one of these persistence mechanisms is usually still active:

  • A hidden backdoor file
  • A malicious WordPress cron task
  • A server-level cron job
  • A running PHP process
  • A fake plugin
  • A compromised admin account
  • Malware hidden in the database
  • Modified core, theme, or plugin files
  • A compromised hosting, FTP, or SFTP account
  • A vulnerable plugin or theme still present on the site

In this case, the reinfection happened too quickly to treat it as a normal delayed exploit. Something was already running on the server and rewriting the file.

Deeper Investigation

We moved beyond basic file cleanup and started checking for persistence.

1. Malware scan

The first scan identified the infected index.php file, but it did not reveal the process responsible for reinfection.

This is common. File scanners are useful, but they may not always explain why a file keeps changing. If malware is being rewritten by a running process, cron job, or hidden backdoor, the visible infected file is only one part of the incident.

2. WordPress core replacement

We replaced WordPress core files to rule out a compromised core installation.

This included restoring clean copies of core directories and files, while preserving site-specific files such as wp-config.php and wp-content.

The infection still returned, which suggested the source was outside normal WordPress core files.

3. Running PHP process review

The next step was to check active PHP processes.

On the shared hosting environment, command-line access was limited. To work around that restriction, we used a controlled PHP-based process check to inspect running PHP activity.

That revealed a suspicious PHP process associated with a file named icug.php.

Shell output showing suspicious running PHP process and process ID

The strange part was that icug.php was no longer visible on the server.

This suggested the process may have continued running after the original file was removed, or that the malware was using a deleted/hidden process state to continue its work. On Linux servers, a process can continue running even if the file it started from has been deleted, until the process is stopped.

The Important Clue: A Missing File Error

Error logs gave us another clue.

The logs showed that the malware was attempting to write to the homepage file but was failing after file paths changed during investigation.

Error log showing missing file error during malware investigation

This was important because it confirmed that the reinfection was not random. A process was actively trying to locate and overwrite the target file.

Based on the behavior, the malicious process appeared to retrieve or generate malicious content and rewrite the site’s index.php file. The exact original entry point was not confirmed, but the persistence behavior was clear.

Removing the Persistent Malware Process

Once the suspicious PHP process was identified, it had to be stopped.

In this case, the process ID was visible, so the malicious process was terminated. After that, we continued cleanup by removing related malicious files and restoring affected WordPress files.

For safety, this kind of action should only be done when you are confident the process is malicious. Killing the wrong process on a production server can interrupt legitimate tasks, backups, imports, scheduled jobs, or active requests.

A safer process is:

  1. Identify the suspicious process.
  2. Confirm the process owner and command path.
  3. Check whether the related file exists.
  4. Review recent file modifications around the same time.
  5. Stop the process if confirmed malicious.
  6. Remove the malware source file or backdoor.
  7. Restore affected files from clean copies.
  8. Monitor whether the infection returns.

After the malicious process was stopped and the affected files were restored, the homepage remained clean.

Why Basic Scans Can Miss Persistent Malware

Traditional malware scanning is still valuable, but persistent attacks can be difficult when the visible infected file is only the output of a running process.

A scanner may detect the modified index.php, but it may not always detect:

  • A process that started before scanning began
  • A deleted file that still has a running process
  • A server cron job outside the WordPress directory
  • A backdoor hidden in an unrelated folder
  • Malware injected into hosting-level files
  • A compromised FTP/SFTP account rewriting files externally

This is why persistent infections require more than “scan and delete.” You need to understand what is recreating the malware.

What We Could Not Confirm

The immediate threat was removed, and the website was restored. However, the original entry point was not fully confirmed.

Possible causes included:

  • An outdated plugin or theme
  • Compromised FTP/SFTP credentials
  • A vulnerable file upload path
  • A backdoor from a previous infection
  • A weak admin account
  • A hosting-level compromise
  • Nulled or modified software

Because the engagement was focused on emergency recovery and the client chose not to continue with a full forensic investigation, we prioritized restoring the website, stopping the active process, and reducing reinfection risk.

That distinction matters. Malware removal and forensic root-cause analysis are related, but they are not always the same scope of work.

If your WordPress site keeps getting reinfected, use this checklist:

  • Put the site in maintenance mode if visitors are seeing harmful content.
  • Take a full backup of the infected state for investigation.
  • Scan WordPress files for malware, backdoors, and modified core files.
  • Check recently modified files.
  • Review .htaccess, wp-config.php, theme files, and fake plugin folders.
  • Inspect wp-content/uploads for PHP files.
  • Review active PHP processes if server access allows it.
  • Check WordPress cron tasks and server-level cron jobs.
  • Review access logs and error logs around reinfection time.
  • Replace WordPress core files with clean copies.
  • Replace plugin and theme files from trusted sources.
  • Remove unknown admin users.
  • Reset WordPress, hosting, SFTP/FTP, database, and control panel passwords.
  • Update all plugins, themes, and WordPress core.
  • Remove nulled, abandoned, and unused software.
  • Scan again after cleanup.
  • Monitor for reinfection over the next several days.

How SiteFort Helps with Persistent WordPress Malware

SiteFort Security Plugin can help with both detection and prevention in cases like this.

For malware detection, SiteFort can scan for:

  • Backdoors
  • Web shells
  • Malicious PHP
  • Injected scripts
  • Modified core files
  • Suspicious redirects
  • SEO spam
  • Vulnerable plugins and themes
  • Exposed sensitive files

For prevention and monitoring, SiteFort provides:

  • Firewall rules
  • Bot blocking
  • Login security and 2FA
  • Hardening controls
  • Vulnerability alerts
  • Audit logs
  • Firewall logs
  • Cloudflare Sync for selected blocking rules

The audit log is especially useful after cleanup because it can help track plugin changes, user changes, login activity, hardening changes, scan results, and blocked requests.

Role of the Securewp Remote Security Scanner

The Securewp Remote Security Scanner is useful for checking what the outside world can see.

In a case like this, a remote scanner can help identify:

  • Visible malware indicators
  • Public-facing defacement
  • Suspicious redirects
  • Blacklist status
  • Exposed sensitive files
  • Security header issues
  • Other visible signs of compromise

A remote scanner cannot replace a full file-level investigation, but it gives an important outside-in view. Used with SiteFort inside WordPress, it gives site owners both perspectives: what visitors can see and what is happening in the WordPress environment.

Lessons Learned

This incident highlights several important lessons.

1. Cleaning the visible file is not enough

If malware returns quickly, something is restoring it. You need to find the persistence mechanism.

2. Core replacement does not fix every infection

Replacing WordPress core is useful, but malware can live in uploads, themes, plugins, database entries, cron jobs, server processes, or compromised accounts.

3. Running processes can matter

Persistent malware may continue running even after the original file is removed. Process review can be important when reinfection happens immediately.

4. Logs are often more useful than guesses

Error logs and access logs can reveal which files are being touched, which paths are failing, and when reinfection occurs.

5. Prevention must follow cleanup

After restoring a site, update vulnerable software, reset credentials, remove unknown users, apply hardening, add firewall rules, and monitor for changes.

Final Thoughts

This case was not difficult because the visible malware was complex. It was difficult because the malware was persistent.

The homepage could be cleaned, but a hidden PHP process kept rewriting the infection. Once that process was identified and stopped, the site could be restored properly.

If your WordPress site keeps getting reinfected, do not stop at deleting the obvious malicious code. Check for backdoors, cron jobs, suspicious processes, modified core files, fake plugins, compromised users, and exposed server paths.

For ongoing protection, SiteFort can help with malware scanning, hardening, firewall rules, login security, vulnerability alerts, audit logs, and Cloudflare Sync. For quick external checks, use the Securewp Remote Security Scanner to see whether the site still shows public signs of compromise.

If the infection keeps returning or the source is unclear, a deeper WordPress malware removal service may be needed to clean the site and reduce reinfection risk.