The visible part of a hack is the part the attacker wants to be found eventually: the redirect, the spam, the warning. The part they want to keep is the backdoor, a quiet way back into the site that survives a password change and a malware scan. If a cleaned site was reinfected within days, that is almost always what was missed.
This page explains what WordPress backdoors look like, where they are planted and how we go about finding all of them. It is one of the services under our hacked website repair and emergency help, and it is the step that decides whether a cleanup holds.
What counts as a backdoor
A backdoor is anything that lets the attacker regain control without going through the front door you just locked. On WordPress sites they fall into a few groups.
Web shells and file managers
A web shell is a PHP file that gives whoever opens it in a browser a control panel for the server: browse folders, edit files, upload more code, sometimes run commands. Some are large and obvious once opened. Many are tiny, a single line that takes code from a request parameter or cookie and runs it. A few characters hidden in a long file are easy to overlook.
Code tucked into legitimate files
Instead of a new file, the attacker adds a few lines to one you trust: the theme’s functions.php, a plugin’s main file, or a WordPress core file. The site keeps working normally, and the file name gives nothing away.
Accounts and credentials
Not every backdoor is code. An extra administrator, an application password attached to a real user, an additional FTP account in the hosting panel, or an SSH key added to the server all give the attacker a way in that looks legitimate. Some infections also hide their administrator account from the Users screen, which is why our post on finding an admin user you did not create covers more than just reading that list.
Things that reinstall themselves
The most frustrating kind does nothing until you clean the site. A scheduled task, either inside WordPress or in the hosting account’s cron settings, checks whether the malware is present and puts it back if it is not. Code stored in the database can do the same job when a page loads.
Where we look
Knowing the usual hiding places is most of the work. A careful search on a WordPress site covers all of these:
- The uploads folder. It should hold images and documents. A PHP file in
wp-content/uploadsis a strong warning sign, and our article on why PHP files in uploads are a red flag explains why. - The must-use plugins folder. Files in
wp-content/mu-pluginsload automatically and cannot be switched off from the normal Plugins screen, so attackers like it. - Plugins that hide from the list. A plugin can be written to remove itself from the Plugins screen, so we compare the folder on disk with what the dashboard shows.
- The site root. Extra files beside
wp-config.phpandindex.php, often with names chosen to look like core files. - PHP configuration files. A
.user.iniorphp.inithat tells PHP to load an extra file before every request. .htaccessfiles in any folder. Rewrite rules that send certain requests to a hidden script.- The database. Options, widgets and post content holding code, plus scheduled events in WordPress’s cron list.
- The hosting account. Cron jobs, FTP users, SSH keys and any other sites on the same account that could reinfect this one.
Why scanners alone are not enough
Security plugins and server scanners are useful, and we use them. They are good at spotting known malware by its pattern. They are weaker at spotting something new, something lightly disguised, or something that is not malicious code at all, like an extra administrator or an SSH key.
Backdoor authors know which patterns scanners look for and write around them. They split suspicious functions across variables, encode the payload several times, or store it in the database where a file scanner never reads. A clean scan report is a good sign, not a proof.
So we combine scanning with comparison. WordPress publishes checksums for its core files, and plugins from the official directory can be checked the same way, so any changed or extra file stands out. Our article on checking WordPress core files against official checksums shows how that comparison works. For premium themes and plugins with no published checksums, we replace them with fresh copies from the vendor rather than trusting what is on the server.
How we work through a backdoor removal
We start with a full backup of files and database, because some of what we find may be needed later to understand the attack. Then we work outward from the most dangerous access.
- Cut off live access. Passwords for hosting, database, FTP or SFTP and WordPress administrators are changed, unknown accounts and application passwords removed, and WordPress’s secret keys and salts renewed so existing logins stop working.
- Replace rather than repair. Core files, plugins and themes are swapped for clean copies wherever possible. Only your own uploads and custom code are reviewed line by line.
- Search what cannot be replaced. The uploads folder, custom theme code, configuration files and every
.htaccessare read and checked. - Clean the database and schedules. Injected code, rogue users and unexpected cron events are removed, and the hosting cron list is checked too.
- Watch for return. After the cleanup, file changes are monitored for a period. A file that reappears tells us something was missed and where to look.
Where the database holds a lot of injected material, that part follows the method on our hacked WordPress database cleanup page.
Finding the first way in
A backdoor is something the attacker left after getting in. It is not usually how they got in. If the original entry point, such as an outdated plugin with a known flaw or a leaked password, is still open, they can create new backdoors as fast as we remove them.
So every backdoor removal ends with the question of how it started. Often the evidence is clear: one plugin version with a published vulnerability, a nulled theme, or a login from an unexpected place. When it is not, or when you need a written record for a host, insurer or client, our website hack investigation goes further into logs and timelines.
Signs a backdoor is still in place
After a cleanup, a few things suggest the attacker still has a way in. Files you removed come back with the same or similar names. A new administrator appears overnight. The hosting account shows logins or file changes at hours nobody on your side was working. Spam or redirects return in a slightly different form, which often means the attacker logged back in and changed their approach. Any of these is worth reporting straight away rather than waiting to see if it settles.
What to do before we start
- Do not delete suspicious files on your own yet. A copy helps us find their siblings, which often share code or naming patterns.
- Do not reinstall the same nulled or pirated plugin or theme afterwards. Those packages are a common way backdoors arrive in the first place.
- Collect any access details you have: hosting panel, FTP or SFTP, and WordPress administrator login.
- Note the date and time of anything odd you saw. It helps line up file changes later.
If your site has already been cleaned once
A site that keeps coming back infected after cleanups needs a slightly different conversation, about what was done each time and what changed in between. That is the focus of our page on WordPress sites that get reinfected. The backdoor search described here is the core of that work as well.
To get us looking at your site, message us on WhatsApp with HACKED as the first word, along with your domain and what has been happening. We will tell you honestly what we see and when we can start, back up the site before changing anything and keep you posted on WhatsApp. Backdoor removal is part of every job under our WordPress malware removal service; this page explains why we spend so much of our time on it.