You remove a suspicious plugin, check your website, and assume the problem is resolved. Then the plugin returns. If WordPress malware keeps coming back, repeated deletion is a signal to investigate what is restoring it.
That was the problem Peonixis encountered during routine maintenance of an otherwise functioning WordPress website. An unfamiliar plugin called “Resilient Backup” appeared legitimate, but deleting it only made it disappear temporarily.
The investigation eventually uncovered a broader compromise. The visible plugin was one part of a mechanism that kept the unwanted behaviour going.
What recurring malware tells you
A returning component raises an important question: what changed after the deletion?
The answer needs evidence. A legitimate deployment process could restore a file. An administrator could reinstall a plugin. Alternatively, malicious code that remains elsewhere could recreate something you removed.
These explanations require different responses. Treating every recurrence as a fresh installation problem can leave the original cause untouched.
In the Peonixis incident, the investigation established a relationship between the fake plugin and underlying malicious components. That finding changed the cleanup from repeatedly deleting a symptom to addressing its persistence.
What Peonixis found beneath the plugin screen
The team moved beyond the ordinary WordPress plugin list and examined the underlying environment. A suspicious MU plugin, MailPoint1360, was identified.
The case study reports that once the underlying component was disabled, the fake Resilient Backup plugin could finally be removed successfully. Further investigation also identified an associated database script, fake gambling-related posts, and an attacker-created WordPress user.
These findings mattered because an infection does not have to be limited to the first suspicious item an administrator notices. Removing that item can leave other unauthorised changes unresolved.
The public case study does not publish the malicious code or the exact commands used. Its documented lesson is the connection between the returning plugin and the broader persistence mechanism.
Persistence and reinfection are different questions
For an investigation, it helps to distinguish two possibilities. Persistence means unwanted components remain capable of sustaining the compromise. Reinfection means an attacker gains access again after a cleanup.
The distinction is useful, but recurrence alone does not establish which happened. Investigators need to compare the affected components, the timing of their return, and the available evidence of access or changes.
This case study describes persistence. It also associates an outdated plugin with unauthorised access, without naming the plugin or publishing a specific vulnerability. Those missing details should not be replaced with assumptions.
What a better cleanup should establish
Instead of asking only whether the suspicious plugin has disappeared, ask:
- What was responsible for recreating it?
- Which other unauthorised components were identified?
- Were unwanted content and accounts addressed?
- What evidence shows that the observed behaviour stopped?
- What follow-up checks will detect its return?
These questions create a clearer basis for judging the result. A successful deletion is one observation. A documented investigation explains why that deletion should now hold.
The outcome of the Peonixis investigation
Peonixis reports removing the identified malicious components, stopping the fake plugin from being recreated, removing the gambling content, and addressing the attacker-created account.
The result is described in relation to the components discovered during the investigation. The case study does not state a monitoring duration or promise permanent immunity from future attacks.
Read the full WordPress infection case study to see how the investigation developed.
