Protect / WordPress Malware Removal
Cleanup plus the part that matters: identifying persistence and the entry point, so reinfection does not follow.
TechSteps removes WordPress compromises and establishes how the attacker got in and whether they kept access. Cleaning the malicious files is the straightforward half. Finding the entry point and the persistence, then closing both, is what stops the site being reinfected a fortnight later.
What this solves
A cleanup that removes malicious files and stops there is why sites get infected repeatedly. The files were a symptom. The vulnerability that allowed them and the mechanism the attacker left behind to return are the actual problem.
WordPress persistence is particularly varied because there are two layers to hide in. At the application level there are administrator accounts, must-use plugins that never appear in the plugin list, scheduled events, and modified theme functions. At the server level there are cron entries, SSH keys and system services.
There is also a decision to make early: whether the site can be cleaned or should be rebuilt from a known-good state. Delaying that decision usually makes it more expensive.
When people call us
If more than one of these sounds familiar, the underlying cause is often a single issue rather than several separate ones.
Technical scope
Not every engagement includes all of this. The scope is agreed in writing before we start, and anything excluded is named rather than left ambiguous.
How we approach it
Before cleaning, we capture logs and a copy of the compromised state. Cleaning destroys the evidence needed to establish the entry point, and without that the fix is guesswork.
When it started determines which backups are trustworthy. Restoring from a backup taken after the compromise reinstalls it, which is a very common way to lose a second week.
Usually a known vulnerability in an outdated plugin, a compromised credential, or something at the server level. Access logs generally show the request that first succeeded.
Administrator accounts, must-use plugins, scheduled events, modified theme functions, and at the server level cron entries and SSH keys. Persistence is where reinfection comes from.
For an application-layer compromise on a healthy server, cleaning is defensible. Where the attacker had server-level access, or the timeline cannot be established, rebuilding from known-good sources is the honest recommendation.
Every credential the compromised environment could see is treated as read. Then the vulnerability is patched and the surface reduced.
Monitoring so a recurrence is caught quickly, and a review request where the site was flagged by a search engine or browser.
What goes wrong
These are the patterns we see most often when we are called in to fix someone else's work, or our own from earlier in our careers.
The backup predates the discovery and postdates the compromise, so the malware is reinstalled along with the site. The apparent fix lasts days.
The attacker still has the database password, an API key or an administrator login. They simply return through the front door.
A compromised server keeps reinfecting a clean WordPress install. If the attacker reached the operating system, cleaning WordPress achieves nothing.
The site is clean and the vulnerable plugin is still installed at the same version. This is the most common reason for repeated infection.
Logs deleted and files overwritten during a panicked cleanup, so the entry point can never be established and nobody can say what data was accessed.
Questions we actually get asked
Containment is usually same day. A full cleanup with the entry point identified typically takes longer, because finding how they got in is the part that requires investigation. We would rather take an extra day and close the vulnerability than clean quickly and see you again in three weeks.
Only if you know when the compromise started, and most people do not. Restoring from a backup taken after the initial breach reinstalls it. Even with a clean backup, the vulnerability that allowed the compromise is still present unless it is separately patched.
Often it cannot be established with certainty, and we will tell you that rather than reassure you. If the attacker had database access, assume the data was readable. What logging existed determines how much we can say. This is the strongest practical argument for logging before you need it.
Rebuild if the attacker had server-level access, if the timeline cannot be established, if persistence was found in several distinct mechanisms, or if system files were modified. Cleaning is reasonable when the compromise was clearly confined to the application layer and the timeline is short and known.
Close the entry point, rotate every credential, remove plugins you do not need, establish an update routine you will actually follow, and add logging so a recurrence is visible early. Reinfection almost always traces to one of those being skipped.
Describe the system and what is going wrong with it. A short technical conversation is usually enough for us to tell you whether this is the right work and roughly what it involves.