Unmasking a Persistent Malware Attack on a WordPress Website

We restored this WordPress site’s infected index.php, but the malicious homepage came back almost immediately.

Replacing WordPress core did not stop it either. Something on the server was actively rewriting the file after cleanup.

The breakthrough came when we found a running PHP process associated with a file named icug.php. The file itself was no longer visible on the server, but the process was still active. Error logs then showed repeated attempts to write back to the affected homepage file.

This case study covers how we followed that evidence, stopped the persistence, and restored the site without claiming a root cause we could not prove.

1. The Homepage Was Reinfected After Cleanup

The incident started with a WordPress homepage displaying malicious and inappropriate content instead of the normal website.

Our first review found two obvious problems:

• the main WordPress index.php had been replaced or modified with malicious content
• the site’s .htaccess had also been changed and WordPress was no longer loading normally

The affected index.php differed from the expected WordPress file. Restoring it fixed the homepage only temporarily.

We restored a clean WordPress index.php and corrected the .htaccess configuration.

The site started working again.

Then the malicious content returned.

That was the point where repeatedly cleaning index.php stopped making sense. The file was the visible result of the infection, but something else was putting the malware back.

2. Restoring WordPress Core Did Not Stop the Reinfection

We scanned the WordPress installation and replaced WordPress core files with clean copies to rule out a modified core installation.

Site-specific files such as wp-config.php and the contents of wp-content were preserved for separate review.

The homepage was reinfected again.

The speed of the reinfection mattered. Instead of continuing to scan and replace the same files, we started looking for something that was already running or scheduled on the server.

3. A Running PHP Process Exposed the Persistence

The hosting environment had limited command-line access, so we used a controlled PHP-based process check to inspect active PHP processes.

One process stood out. It was associated with a PHP file named:

icug.php

The process review exposed a suspicious PHP process associated with icug.php.

But when we looked for icug.php on the server, the file was no longer visible.

That did not mean the activity had stopped. On Linux, removing a pathname does not necessarily make an open file disappear immediately; if a process still has the file open, the underlying file can remain available until that reference is closed. The behavior is documented in the Linux unlink() documentation.

In this incident, the important fact was simpler: the PHP process was still running even though the associated script was no longer visible where we expected it.

We still needed evidence connecting that process to the homepage reinfection.

4. The Error Log Connected the Process to index.php

Error logs provided the next useful clue.

During the investigation, file paths changed as we restored and moved affected files. The logs then showed attempts to write to a path that was no longer available.

After the target path changed, the error log showed continued attempts to write to the affected homepage file.

This connected the running process with the behavior we had been seeing: clean index.php, wait briefly, then find the homepage compromised again.

The evidence supported the conclusion that the active process was part of the persistence mechanism rewriting the site.

We did not need another generic malware scan at that point. We needed to stop the process and see whether the reinfection stopped with it.

5. Stopping the Process Ended the Reinfection

The suspicious process ID was identified and the process was terminated.

We then:

• removed related malicious files we had identified
• restored affected WordPress files from clean copies
• checked the site again for obvious persistence
• monitored the homepage to see whether index.php changed again

The malicious homepage did not return after the process was stopped and the affected files were restored.

That result was important because it matched the investigation: reinfection continued while the process was active and stopped after the process was terminated.

Do not kill an unfamiliar PHP process simply because it looks unusual. Production servers can have legitimate PHP workers, imports, scheduled jobs, backups, queue processors, and other long-running tasks.

Before terminating a suspicious process, check its process ID, owner, command or script path, related file activity, and logs. The goal is to establish that the process is connected to the compromise rather than guessing.

6. What We Could Not Confirm

We did not establish the original entry point used to compromise the site.

The engagement was focused on emergency recovery. We stopped the active persistence, removed the malware we could identify, restored the website, secured the environment, and monitored for reinfection.

A full forensic investigation into the original access path was outside that scope.

That distinction matters. Finding the mechanism that is currently restoring malware is not necessarily the same as proving how the attacker first entered the server.

We therefore would not claim that a particular plugin, account, credential, or server vulnerability caused this incident without evidence supporting it.

7. What to Check When WordPress Malware Keeps Returning

If you clean an infected file and it is recreated almost immediately, stop repeatedly deleting the same file. Find what is writing it back.

The most useful next checks are:

• Compare timestamps. Match the time the file changes with access logs, error logs, cron activity, and other server events.
• Review scheduled tasks. Check both WordPress cron events and server-level cron jobs.
• Inspect active processes. If your hosting environment allows it, look for PHP or other processes connected to suspicious files or unexpected commands.
• Check common persistence locations. Review MU plugins, uploads, configuration files, unfamiliar plugins, and files outside normal WordPress core.
• Review accounts with write access. WordPress administrators, hosting users, SSH/SFTP accounts, and other credentials may be able to modify site files.
• Use the logs. A scanner can tell you which file is infected; logs may tell you what keeps changing it.

Do not assume replacing WordPress core has fixed the site simply because core files are clean. Persistence can exist outside WordPress core or even outside the WordPress directory.

The key lesson from this incident was not that every recurring WordPress infection involves a hidden PHP process. It was that the repeatedly infected file was not the source of the problem.

Once index.php kept returning, the useful question changed from “What is wrong with this file?” to “What keeps writing this file?”

That change in the investigation is what led us to the process responsible for the reinfection.

If your WordPress site keeps being reinfected and you cannot identify what is recreating the malware, Securewp provides a WordPress malware removal service for deeper investigation and cleanup.