If a WordPress plugin keeps reinstalling itself, the first task is to find out what is putting it back. Its name and description are not enough to determine whether it belongs on your website.
Peonixis investigated this exact symptom during routine maintenance. A plugin named “Resilient Backup” appeared in the installation. It looked legitimate, but normal deletion did not resolve the problem. When checked again, it had returned.
The investigation showed that the unfamiliar plugin was a visible sign of a deeper compromise.
Start with ownership and installation history
Before labelling an unfamiliar plugin malicious, establish who maintains the website. A hosting provider, agency, or authorised developer may have added functionality that the owner does not recognise.
Ask who installed the component, what it is intended to do, and whether a maintenance or deployment process manages it. Compare the explanation with the actual installation rather than relying on the displayed plugin name.
A plausible label is only a label. In this incident, “Resilient Backup” sounded like a useful maintenance tool, but the investigation identified the installed component as fake.
That finding relates to this particular installation. It is not evidence that every product with a similar name is malicious.
Record what returns and when
“It came back” is a useful warning, but an investigation benefits from more detail.
Record the plugin’s displayed name, the affected directory, when it was first noticed, when deletion occurred, and when it reappeared. Preserve relevant screenshots and available change records.
WordPress’s incident-response guidance recommends documenting the compromise before proceeding with recovery. Reference: WordPress hacked-site guidance.
The purpose is to preserve a sequence that can be investigated. If several people make changes at once without recording them, it becomes harder to distinguish a restoration process from malicious recreation.
Investigate beyond ordinary plugins
Peonixis did not stop at the default plugin screen. The team identified a suspicious MailPoint1360 MU plugin and its relationship to the returning fake plugin.
That was the turning point. The case study states that addressing the underlying component allowed Resilient Backup to be removed successfully.
For a website with this symptom, a qualified investigator should decide which layers need review. The important question is whether another component can reproduce the observed change, not simply whether the visible plugin can be deleted again.
For background on this layer, see our related article, WordPress MU Plugins: What They Are and Why Security Checks Should Include Them.
Check whether the problem extends to content or accounts
The Peonixis investigation also found fake gambling posts, an associated database script, and an attacker-created user. The user could not simply be removed through the normal WordPress process.
Those findings expanded the scope of the incident. A plugin that returns may be the easiest symptom to notice while other unauthorised changes remain less visible.
This does not mean every recurring-plugin problem involves the same components. It means the scope of a cleanup should follow the evidence discovered on that website.
Define what successful removal means
For this incident, success included the fake plugin no longer being recreated and the other identified malicious components being addressed.
A useful completion report should distinguish the symptom observed, the mechanism identified, the changes made, and the checks performed afterwards. It should also state any limitations or unresolved questions.
The case study does not name the outdated entry-point plugin, provide an exploit identifier, or publish the exact recreation code. It supports a clear explanation of the investigation without those details.
Read the Peonixis case study for the documented findings.
