Webshell Backdoors: How They Enter, What Attackers Can Do, and How to Fix Website Weak Points

A website can look normal while an attacker secretly accesses its files. One way this happens is through a webshell backdoor.

A webshell is malicious server-side code, often stored in a PHP file. An attacker sends requests to that file to browse folders, read files, upload more malware, or run commands.

Its access depends on the permissions of the user running PHP.

How Does a Webshell Backdoor Get Installed?

An attacker first needs a way to place or modify executable code on the server.

These are possible causes. Finding an old plugin does not prove that attackers used it.

In the incident examined here, webshells were reported inside WordPress websites. The exact weakness used to plant them remains unknown.

When Does the Backdoor Become Accessible?

A backdoor becomes accessible when the malicious file is installed in a location the server can execute and the attacker can reach it.

For example, a malicious PHP file inside a publicly served plugin folder may receive requests through a URL such as:

https://example.com/wp-content/plugins/suspicious.php

This is an illustrative URL. Do not open suspected webshell URLs to test them; inspect files and logs instead.

The incident report describes webshell activity between 7 August and 26 September 2026. That is the reported activity window, not proof of the exact installation date.

A later screenshot also reports a remaining backdoor at:

/opt/lampp/htdocs/holidaylandmark/blog/wp-content/plugins/Down.php

Its current presence must be checked on the server.

Why Do Attackers Hide Webshells?

Webshells provide remote access without requiring a normal SSH login.

Attackers may give them ordinary-looking names, place them among legitimate PHP files, or obscure their contents. In this incident, reported filenames included:

Ge.php
blue.php
Server.php
chengse.php
v.php

A filename alone is not proof of malware. The file’s contents and surrounding evidence must be reviewed.

What Can an Attacker Do Through a Webshell?

A webshell does not automatically provide root access. However, ordinary web-user permissions can still expose significant data.

How One Website Can Affect Other Files and Applications

In the reported incident, the webshell ran as the daemon user.

That user could access other application folders and read .env files containing secrets.

The reported exposure route was:

WordPress webshell → daemon permissions → other application folders → readable application secrets.

The report did not directly prove SMTP password theft. It established that the credentials were readable by the compromised user.

Weak Points Identified in the Report

All paths below use /opt/lampp/htdocs as their base.

Having many plugins is not automatically a vulnerability. Vulnerable, unnecessary, or untrusted plugins increase the problem.

Commands to Investigate the Backdoor

These checks are read-only unless explicitly marked otherwise. Preserve logs and do not execute suspicious PHP files.

1. Check Whether the Reported Backdoor Exists

sudo stat /opt/lampp/htdocs/holidaylandmark/blog/wp-content/plugins/Down.php

Purpose: Show file existence, owner, permissions, and timestamps. Timestamps alone do not establish when an attacker installed it.

Record its hash:

sudo sha256sum /opt/lampp/htdocs/holidaylandmark/blog/wp-content/plugins/Down.php

Purpose: Create an identifier for the file’s current contents.

2. Find Requests to Known Webshell Names

sudo find /opt/lampp/logs -type f -print0 |
sudo xargs -0 -r zgrep -haiE '(blue\.php|Ge\.php|PHPMailer/Server\.php|chengse\.php|youtube/v\.php|/Down\.php)'

Purpose: Display matching requests

top 20 rows tak limit karega to Known Webshell Names

sudo find /opt/lampp/logs -type f -print0 |
sudo xargs -0 -r zgrep -haE \
'(blue\.php|Ge\.php|PHPMailer/Server\.php|chengse\.php|youtube/v\.php|/Down\.php)' |
awk '$6 ~ /^"(GET|POST|HEAD)$/ {
    print $9, $7
}' |
sort | uniq -c | sort -rn | head -20

output

25 200 /blog/wp-content/plugins/blue.php
10 404 /youtube/v.php
 3 403 /blog/Down.php

Identify which website’s logs contain the suspicious requests

sudo find /opt/lampp/logs -type f -print0 |
sudo xargs -0 -r zgrep -lE \
'/wp-admin/css/colors/blue/blue\.php|/wp-includes/sodium_compat/src/Core/Curve25519/Ge/Ge\.php|/blog/wp-content/plugins/Down\.php'

output

purpose: This lists the log files containing these URLs. Website-specific log filenames may help identify the affected website. Your previous output combined requests from multiple log files. If websites share one log, additional information is needed to identify the website.
Pehle path set karein:

Suspicious files abhi server par kahan hain?

sudo find /opt/lampp/htdocs -type f \
\( -name 'blue.php' -o -name 'Ge.php' -o -name 'Down.php' \) \
-exec stat -c 'File: %n | Owner: %U:%G | Mode: %a | Modified: %y | Changed: %z' {} +

output

Purpose: Actual file location, owner, permission aur timestamps milenge. Timestamp alone upload time ka proof nahi; file nahi milne se historical compromise disprove nahi hota. Abhi files delete ya execute na karein.

1. Affected WordPress code daemon modify kar sakta hai? Example mein sreschool use kiya hai; step 1–2 ke result ke according path set karein:

WP_SITE='/opt/lampp/htdocs/sreschool'

cd /tmp

sudo -u daemon find \
"$WP_SITE/wp-admin" \
"$WP_SITE/wp-includes" \
"$WP_SITE/wp-content/plugins" \
"$WP_SITE/wp-content/themes" \
-writable -print |
head -30

Purpose: Output mein aaye code files/folders daemon modify kar sakta hai. Writable folder mein attacker additional backdoor bana sakta hai. head -30 sirf pehle 30 results dikhata hai.

WP_SITE='/opt/lampp/htdocs/holidaylandmark/blog'

1. Plugin/theme versions check karein Plugins:

sudo grep -RnE --include='*.php' \
'^[[:space:]]*\*?[[:space:]]*(Plugin Name|Version):' \
"$WP_SITE/wp-content/plugins"

Themes:

sudo grep -RnE --include='style.css' \
'^[[:space:]]*\*?[[:space:]]*(Theme Name|Version):' \
"$WP_SITE/wp-content/themes"

Purpose: Names aur versions dhundhna. Exact version ko security advisory se match karna hoga; version alone vulnerability confirm nahi karti.

1. Stolen WordPress admin account ke clues

sudo find /opt/lampp/logs -type f -print0 |
sudo xargs -0 -r zgrep -haiE \
'wp-login\.php|wp-admin/(plugin-install|update|plugin-editor|theme-editor|users|user-new)\.php'

Purpose: Login, plugin editing/install aur user-management requests dekhna. Successful login confirm karne ke liye audit/session evidence bhi chahiye; 200 alone enough nahi.

1. Unsafe upload feature ke clues Uploads mein executable-looking files:

sudo find "$WP_SITE/wp-content/uploads" -type f \
\( -iname '*.php' \
-o -iname '*.php[0-9]' \
-o -iname '*.phtml' \
-o -iname '*.phar' \
-o -iname '*.php.*' \) \
-print

Upload-related requests:

sudo find /opt/lampp/logs -type f -print0 |
sudo xargs -0 -r zgrep -haiE \
'async-upload\.php|admin-ajax\.php|wp-json/|upload'

Upload code locations:

sudo grep -RnE --include='*.php' \
'move_uploaded_file|wp_handle_upload|wp_handle_sideload|upload_mimes|ALLOW_UNFILTERED_UPLOADS' \
"$WP_SITE/wp-content"

Purpose: Review ke liye files/endpoints identify karna. Matching functions normal bhi ho sakte hain; authentication aur file-validation logic inspect karna hoga.

1. Stolen SSH/hosting/deployment credentials ke clues SSH journal:

sudo journalctl -u ssh -u sshd \
--since '2026-08-01' --no-pager |
grep -E 'Accepted password|Accepted publickey|session opened'

Rotated authentication logs:

sudo find /var/log -maxdepth 1 -type f -name 'auth.log*' -print0 |
sudo xargs -0 -r zgrep -hE \
'Accepted password|Accepted publickey'

Login history:
last -ai | head -50

Authorized SSH key-file metadata:

sudo find /root /home -type f -name authorized_keys \
-exec stat -c '%y %U:%G %n' {} +

Purpose: Unknown successful logins aur key-file changes identify karna. Hosting panel aur CI/deployment systems ke separate audit logs bhi check karne honge.
5.Writable website code identify karein

sudo -u daemon find \
"$WP_SITE/wp-admin" \
"$WP_SITE/wp-includes" \
"$WP_SITE/wp-content/plugins" \
"$WP_SITE/wp-content/themes" \
-writable -print

Purpose: Code files/directories jahan daemon write kar sakta hai. Output aana permission weakness ka clue hai, attack ka proof nahi.
Laravel .env readability bhi check karein:

sudo -u daemon test -r /opt/lampp/htdocs/holiday-new/booking/.env
result=$?
printf 'Readability check exit=%s\n' "$result"

output

Solution to read env using daemon

First, run these read-only checks:

sudo stat -c 'Owner: %U:%G | Permissions: %a | File: %n' \
/opt/lampp/htdocs/holiday-new/booking/.env

ps -eo user,group,comm,args |
grep -E '[h]ttpd|[a]pache2|[p]hp-fpm'

For HTTP protection, the intended Apache configuration is:

<FilesMatch "^\.env(?:\..*)?$">
    Require all denied
</FilesMatch>

How to hardened the wordpress