Suspicious PHP Files in wp-content? I Found a Hidden Backdoor in a Client’s Site

The client did not come to me because the homepage was defaced or the site was completely down.

The site still worked. It just felt wrong.

That is how a lot of modern WordPress infections behave. They stay quiet long enough to avoid attention, then give the attacker a way back in whenever they want it.

In this cleanup, I logged into the client’s DreamHost file manager and checked /wp-content/. That is where I found three files that had no legitimate reason to be sitting there:

• fa.php
• fazel.php
• trigger.txt

The names were generic enough to be ignored at first glance. That is part of what made them dangerous.

On a hacked site, this is exactly the kind of thing I look for: loose files with vague names, sitting in places where they do not belong, and blending in just enough that the site owner never questions them.

Why These Files Were a Red Flag

wp-content is a normal WordPress directory, but that does not mean every file inside it is normal.

Plugins, themes, uploads, and other site-specific assets live under wp-content. What concerned me here was the combination of location, file type, and naming:

• two unexplained PHP files placed directly in wp-content/
• a text file named trigger.txt sitting beside them
• no legitimate plugin or theme reason for those files to be there

That does not happen in a healthy WordPress install by accident.

If you are trying to figure out whether your own site shows similar warning signs, read my guide on how to detect WordPress malware manually.

What the Backdoor Was Doing

After I found the files, I opened the code to see what the attacker had actually left behind.

This was not a full visual web shell on its own. It was a loader — a small piece of code whose job was to pull in the real payload later.

1. It fetched a second-stage payload

In the sample I analyzed, the code used a function named geturlsinfo to request content from a remote URL. That is the first big clue that you are not dealing with a harmless stray file.

A loader like this does not need to contain the whole attack. It only needs enough logic to reach out, pull down code, and execute it when needed.

2. It used trigger.txt as a simple control file

In this case, the script checked the contents of trigger.txt before running. That made the file more than harmless clutter. It acted like a basic switch for the loader.

The important point is not that every malware sample uses a file with this exact name. The important point is that attackers often leave behind tiny helper files that control when or how the backdoor runs.

3. It executed the fetched code with eval()

The most dangerous behavior in the sample was this line:

eval('?>' . $a);

In plain English, that means: take the code that was just pulled in and run it on the server.

That is what turns a “strange file” into a real compromise.

If an attacker can fetch and execute remote code like that, they do not need to keep uploading every payload manually. They already have a working door back into the site.

Technical Breakdown: Why This Loader Was Dangerous

For developers and technical site owners, here is why this was more than a random stray script.

1. It tried to blend in with normal traffic

The sample included a browser-like user agent string. That is a common trick. It helps outbound requests look more like normal web traffic instead of an obvious automated fetch.

2. It had fallback methods

The script did not rely on only one outbound function. It tried several common PHP methods so it could still pull a payload even if one approach was unavailable on that server.

• curl_exec
• file_get_contents
• fopen

That kind of fallback logic tells you the file was written for reliability, not by accident.

3. It appeared to be pulling an Alfa-style shell

In the sample I reviewed, the fetched payload name suggested an Alfa-style web shell. That matters because once a web shell lands on a server, the attacker can browse files, modify PHP, read configuration data, and plant more malware without going through the normal WordPress login flow.

This is why I treat loader files seriously even when the visible site still looks normal.

For another real example of hidden persistence, see the wp-compat backdoor case and my guide on how hackers hide backdoors in WordPress.

How I Cleaned the Site Properly

Deleting one file is not cleanup. It is only the first visible step.

Here is the process I used on this site:

1. Backed up the infected state: before changing anything, I preserved the current files for reference.
2. Removed the malicious files: I deleted fa.php, fazel.php, and trigger.txt.
3. Reviewed core integrity: I checked for tampered WordPress core files and replaced anything suspicious with clean copies.
4. Searched for other backdoors: I reviewed the rest of the filesystem, database, and high-risk files for persistence.
5. Patched the entry point: I updated WordPress core, plugins, and themes to close the hole that allowed the upload in the first place.
6. Rotated access: I changed credentials and forced active sessions out.

If you only remove the visible file and skip the rest, the same attacker often comes back through the same weakness a day later.

That is exactly why this guide pairs well with why WordPress malware keeps coming back and how to scan and clean your WordPress database for hidden malware.

What I Would Check Next on a Site Like This

When I find a loader like this, I do not stop at the three visible files. I keep going until I understand the full compromise.

On similar jobs, I check:

• wp-config.php for injected includes or altered settings
• .htaccess for redirects or hidden execution paths
• plugins and must-use plugins for hidden backdoors
• cron jobs or scheduled tasks that could reinstall malware
• the database for injected scripts, spam, or rogue options
• other unknown files in wp-content, uploads, or the site root

If your site has already started redirecting visitors, showing strange titles in Google, or generating spam pages, this related cleanup may help: how I removed a malicious redirect from a client WordPress site.

How to Tell if Your Site May Have the Same Problem

You do not always get a big, obvious warning when a backdoor is present. Sometimes the clues are smaller:

• new PHP files you do not recognize
• slow admin or strange outbound requests
• unexpected changes to core files
• spam URLs or odd titles appearing in Google
• scanner results that say “clean” while the site still behaves strangely

If you see unknown pages in Google, also run a quick site:yourdomain.com search and review Search Console security warnings if you have them.

For a broader checklist, see 60 clear signs your WordPress site is hacked.

FAQ

Is every PHP file in wp-content malware?

No. WordPress plugins and themes use PHP. What made this case suspicious was the location, the filenames, and the fact that the client had no legitimate reason for those loose files to exist directly in wp-content/.

Can I just delete fa.php and move on?

Not safely. If one loader file exists, there may be other persistence points in the database, wp-config.php, cron, plugins, or other writable folders.

Why didn’t the WordPress dashboard warn me?

Because file-level backdoors do not need to show up as plugins or visible admin changes. Many infections live quietly in the filesystem until they are used.

What if the files come back after I remove them?

That usually means the real entry point or persistence mechanism is still active. At that point, you are dealing with reinfection, not just leftover files.

Need Help Cleaning a Hidden WordPress Backdoor?

If you found strange files in your hosting panel and you are not sure whether they are harmless or malicious, do not guess.

A file-level backdoor is exactly the kind of infection that gets missed when someone only checks the dashboard or deletes one obvious file.

If you want a proper cleanup, start here:

WordPress Malware Removal Service

Or request a manual review here:

Free WordPress Malware Scan