Backdoor
A backdoor is a way back into a site that an attacker leaves behind, so that they can return without the login and without the hole they first used. It is why a WordPress site that was cleaned gets infected again.
- By
- WP Ministry
- Published
In short
- A backdoor is separate from the hole the attacker came in through. Updating the plugin that was exploited does not remove it.
- Look where code runs without being activated, in mu-plugins, drop-ins and uploads. Then check accounts, application passwords and scheduled tasks.
- Finding one does not show there is no second. Rebuilding from clean sources is surer than hunting.
A backdoor is a way back in. Google's glossary for hacked sites defines it as a program installed on a system to get around its login and keep a hacker's access to it. A backdoor written as a script is also called a web shell.
It matters because it does not depend on how the attacker first got in. Update the plugin they exploited and change every password, and a backdoor still answers. Google's guidance says an attacker may leave back doors that let them re-enter, or that put back the malicious code you removed. It is the usual reason a site is infected again after a cleanup.
Where you meet it
A backdoor has no screen of its own. On a WordPress site it sits where code runs without anyone activating it, or it is not a file at all.
wp-content/mu-plugins. WordPress enables every must-use plugin automatically. They are left out of the default list on the Plugins screen and cannot be disabled from the dashboard.- Drop-ins. Single files with set names, directly in
wp-content, that WordPress loads by name.db.phpandobject-cache.phpare loaded whenever they exist. - The uploads folder. The web server has to be able to write here, and nobody reads the thousands of files in it. A PHP file among the images does not belong.
- WordPress's own folders. WordPress's documentation notes that hacks often introduce new files, which a reinstall from the dashboard does not remove.
.htaccess. The same documentation calls it one of the files most often changed in a hack, and says copies can sit in several folders.- A rogue account or an application password. An application password signs a program in through the REST API, with no login form involved. They are listed on each user's profile under "Application Passwords".
- A scheduled task. A WP-Cron event runs code at set times, and can put a removed file back.
What goes wrong
- The site is cleaned and infected again. What a scanner flagged was removed and the backdoor was not. Why your WordPress site keeps getting hacked goes through each place to check.
- A scan passes it. Google's glossary describes how attackers disguise code with encodings such as base64 to hide entire web shells. How to remove malware from a hacked WordPress site replaces files from clean sources, which does not depend on recognizing anything.
- An administrator nobody created is simply deleted. The account goes and the way it was made stays. See unknown admin user in WordPress.
- Passwords are changed once, too early. WordPress's documentation says to change them again after the site is clean.
How to look at yours
Go to Plugins. Above the list, after "All", WordPress adds a "Must-Use" link and a "Drop-ins" link ("Drop-in" when there is one) if such files exist. Neither link is there on a site that has none. Open each and account for every file. Your host or a caching plugin may have put one there for good reason. One that nobody can explain needs reading.
This shows two of the places above and no others.
Common questions
Is every file in mu-plugins a backdoor?
No. WordPress's documentation describes must-use plugins as the place for code that should always run and should not be switched off by accident, and gives a host's own caching or monitoring code as a common use. The question for each file is whether someone can say who put it there and what it does.
Will restoring a backup remove a backdoor?
Only if the backup is older than the break-in, which can be well before the day you noticed. WordPress's hardening guide gives the example of a site compromised on May 1st and not detected until May 12th.