When Unknown PHP Files Appear on Your Server

You log in to the server by FTP to transfer a file. As you move through the site folders, something unfamiliar appears. An image directory contains PHP. Several unfamiliar folders sit among normal site assets. Some files show recent modification times that do not match any planned update. A .htaccess file appears where it is not expected. A closer review shows more files created or changed around the same period. At that point, the pattern is clear. The site has been compromised, and the investigation begins. This technical guide walks through an example investigation using cybersecurity best practices, from first suspicion to the steps that usually matter most. Public sources from CISA, NSA, ASD, and OWASP support the incident-response sequence.

Do Not Clean First

That reaction is understandable, but it can weaken the investigation. The filesystem is already holding useful information. Modification times, ownership, permissions, file sizes, repeated names, and nearby configuration changes can help reconstruct the sequence of the compromise.

CISA incident-response guidance separates detection and analysis from containment, eradication, and recovery. That distinction matters here because deleting files before recording them can destroy the evidence needed to understand what happened (Cybersecurity and Infrastructure Security Agency [CISA], 2024).

NSA and ASD web-shell guidance also explains why suspicious files should be compared against the application’s expected state. Their guidance describes web shells as files that are often created or modified inside existing web applications, and recommends validating suspicious files through known-good comparison rather than relying on one indicator alone (National Security Agency [NSA] & Australian Signals Directorate [ASD], 2020).

Deleting first can destroy the timeline. It can also create false confidence. The directory may look clean while the path that created the file remains open.

Preserve the Scene

The better first move is preservation. Copy suspicious files to a non-public evidence directory, record hashes where practical, and keep their metadata. Preserve the nearby .htaccess files and the first changed-file reports before editing or replacing anything.

The goal is to keep enough context to answer three questions later (CISA, 2024).

• When did the suspicious files appear?
• Which account, process, or application path appears to have written them?
• Which request, login, plugin, or permission boundary could explain that write?

Start With the Timeline

A useful investigation starts with what changed. Not with a theory. Not with the assumption that the cause must be FTP, WordPress, a hosting panel, or a plugin. A clean timeline gives the review a factual base.

The first report should list files modified during the suspected window while skipping noisy paths such as logs and trash folders.

SITE_SLUG="example-site"
SITE_ROOT="/var/www/vhosts/example-owner/example-site.tld"
START="2026-05-07 00:00:00"
END="2026-05-08 00:00:00"
OUT_DIR="/var/www/investigation-reports"
mkdir -p "$OUT_DIR"

cd "$SITE_ROOT"

find . \
  \( -path "*/log/*" -o -path "*/logs/*" -o -path "*/Logs/*" \
     -o -path "*/Trash/*" -o -path "*/trash/*" -o -path "*/.Trash/*" \
     ) -prune -o \
  -newermt "$START" ! -newermt "$END" \
  ! -name "*.txt" \
  -printf '%TY-%Tm-%Td %TH:%TM:%TS %M %u %g %s %p\n' \
  | sort \
  > "$OUT_DIR/${SITE_SLUG}-changed-files-clean-2026-05-07.txt"

This report prints modification timestamp, permissions, owner, group, size, and path, then sorts the output into a readable sequence. GNU Findutils documents that the %T time directive in find -printf refers to the file’s last modification time, so this report is a modification timeline rather than a creation-time timeline.

In this example investigation, the timeline did not show one misplaced file. It showed clusters. Several short directory names appeared close together. Each carried a similar structure, including an index file, a matching .htaccess file, and a repeated PHP payload. A second cluster appeared later in another area of the site. A smaller PHP file appeared after that.

That repetition matters. Random mistakes rarely create matching directory structures with matching access-control files. Repetition suggests automation, tooling, or a payload capable of placing additional files after the initial compromise.

Let Location Change the Meaning

A PHP file is more suspicious in some locations than others. In a plugin or theme directory, PHP may be expected. In images, uploads, cache, tmp, or assets, it usually is not. OWASP explains why this location matters. Its unrestricted file-upload guidance warns that upload features can become dangerous when attackers can place files that the server later interprets or executes. That is why PHP under an image or upload path deserves higher priority than an ordinary source file in an application directory (OWASP Foundation, n.d.-a).

find "$SITE_ROOT" \
  -type f -name "*.php" \
  \( -path "*/uploads/*" -o -path "*/images/*" \
     -o -path "*/cache/*" -o -path "*/tmp/*" \
     -o -path "*/assets/*" \) \
  -printf '%TY-%Tm-%Td %TH:%TM:%TS %u %g %m %p\n' \
  | sort \
  > "$OUT_DIR/${SITE_SLUG}-suspicious-php-in-writable-dirs-2026-05-07.txt"

The OWASP File Upload Cheat Sheet also advices towards a defensive direction to use strict extension allowlists, validate file type, generate safe filenames, limit size, and restrict who can upload. Those recommendations support this guide’s later remediation steps.

In our case, one PHP payload appeared inside an image-style asset path. That location points toward a writable application area, not a normal deployment path.

The payload behavior also mattered. The file was short and direct. It checked a gate value, accepted request input, decoded it, executed it, and included an upload-copy capability. Another repeated file was larger and more obfuscated, using encoded strings and dynamic execution patterns. Together, those behaviors fit MITRE ATT&CK’s description of web shells as server-side scripts used for access and persistence on exposed web servers (MITRE ATT&CK, 2025).

Even then, the investigation should not jump to the cause. The file tells you where the payload landed. It does not yet prove how it arrived.

Treat Access Rules as Part of the Evidence

The next clue is often the access-control file beside the payload.

In our case, suspicious .htaccess files appeared in directories where no .htaccess file had existed before. In other locations, existing .htaccess files had been replaced. Their rules broadly denied executable extensions, then allowed a selected list of PHP filenames. The allowlist included expected WordPress files, but it also permitted unfamiliar PHP filenames found in the suspicious directories.

That matters because .htaccess files can change access rules for a directory. Apache supports rules that deny access broadly while allowing specific filenames or patterns through <Files> and <FilesMatch>. In this case, the .htaccess files helped define which scripts remained reachable, making them part of the compromise evidence.

grep -RniE "Deny from all|Order allow,deny|Order deny,allow|Require all denied|FilesMatch|<Files|\.php" \
  "$SITE_ROOT" \
  2>/dev/null \
  > "$OUT_DIR/${SITE_SLUG}-apache-php-access-rules-2026-05-07.txt"

A rule that blocks PHP execution in an upload folder can be defensive. A rule that blocks broadly but still allows a small set of unfamiliar PHP files is different. In this case, the access rules appeared designed to preserve access to selected scripts.

At this stage, the evidence had a clear pattern: repeated files, repeated directory structures, PHP in writable-looking paths, and .htaccess rules that made exceptions for suspicious filenames. That was enough to move from discovery to hypothesis testing.

Do Not Guess the Cause Too Early

A serious investigation tests several explanations against the evidence. The goal is not to prove the first theory, but to remove weaker explanations until the remaining one fits the most facts.

The common candidates are predictable, but each leaves a different trail.

• FTP or SFTP compromise. Look for matching authentication logs, source IPs, and file-transfer activity near the file timestamps.
• Hosting panel compromise. Look for file-manager use, panel sessions, scheduled tasks, or account activity around the same window.
• CMS administrator compromise. Look for unusual logins, plugin installs, theme edits, media uploads, or new administrator users.
• Theme or plugin editor abuse. Look for legitimate CMS editing features used after a stolen account session.
• Vulnerable plugin or theme. Look for web requests that can explain a file write, especially POST, upload, REST, or admin-ajax activity.
• Weak cross-site permissions. Look for one site user writing into another site directory or shared writable paths across virtual hosts.
• Server-level compromise. Look for shell access, privilege escalation, cron changes, new users, or broader system modifications.

This approach matches CISA’s detection-and-analysis model. Responders collect and analyze evidence before choosing containment and eradication actions. For a small hosting incident, the value is not scale. The value is discipline: gather evidence first, then decide what to contain, remove, and rebuild (CISA, 2024).

A filename may resemble WordPress camouflage. A path may suggest upload abuse. A timestamp may line up with a web request. None of these observations is enough by itself. The conclusion becomes stronger only when several independent facts point in the same direction.

Follow the HTTP Trail

The file timeline shows when the filesystem changed. Web access logs can show what reached the site around the same time.

LOG_DIR="$SITE_ROOT/logs"
LOG_DATE="07/May/2026"

sudo zgrep -hEi 'POST|admin-ajax\.php|xmlrpc\.php|wp-json|async-upload\.php|upload|txets\.php|accesson\.php|wp-conffq\.php' \
  "$LOG_DIR"/* 2>/dev/null \
  | grep "$LOG_DATE" \
  > "$OUT_DIR/${SITE_SLUG}-suspicious-web-requests-2026-05-07.txt"

The goal is correlation. Did a POST request land shortly before the first suspicious file timestamp? Did the same IP request the new PHP file after it appeared? Did upload, REST, or admin-ajax traffic cluster around the first directory creation?

NSA and ASD guidance notes that web shells may blend into normal web traffic, which makes single indicators unreliable. Useful clues often come from combinations of source IPs, user agents, request paths, timing, and repeated access patterns (NSA & ASD, 2020).

This is also where WordPress-shaped filenames become relevant. Names such as wp-conffq.php, wp-logln.php, or wp-admnn.php resemble legitimate WordPress naming patterns but do not match expected core files. When files like these appear near WordPress endpoints in the logs, the application layer becomes a stronger suspect.

The web logs may not prove the full chain. Rotated logs, proxies, missing request bodies, and caching layers can remove context. But logs can still show timing, source IPs, requested paths, response codes, user agents, and whether the new file was accessed after modification.

Why the Plugin Path Became the Stronger Theory

A vulnerable WordPress plugin is an easy explanation to overuse. It should not be the default answer just because the site runs WordPress. It becomes stronger only when the evidence points to a web-exposed write path and credential-based explanations fit less well.

In this investigation, several facts pushed the review in that direction.

• The files appeared inside application-controlled web paths, not in a pattern typical of broad shell access.
• The artifacts clustered in time, which fit an automated web-level action better than slow manual browsing.
• New .htaccess files appeared in directories where they were not expected, while existing .htaccess files in other locations had been replaced.
• The suspicious filenames resembled WordPress naming patterns but did not match expected core files.
• FTP, SFTP, and hosting-panel logs did not show matching activity around the relevant timestamps.
• Access logs showed POST requests close enough to the file changes to make the plugin or theme surface the stronger suspect.

Taken together, the evidence made a vulnerable plugin or theme endpoint the strongest explanation. Still, that did not remove the need for verification. It made the next step more focused: identify the exposed component, compare its version against known vulnerability records, review plugin and theme files against clean copies, and check whether any upload, REST, or AJAX endpoint could write into the affected paths.

WordPress hardening guidance supports this response path: keep WordPress and extensions updated, remove unused themes and plugins, and limit high-risk administrative features such as the built-in file editor (WordPress.org, 2023).

Containment should therefore start at the application layer. Disable nonessential plugins, isolate or remove the suspected component, reinstall clean plugin and theme files from trusted sources, and assume the application can still write until the vulnerable path is closed.

Contain Before You Clean

Once the likely write path is identified, the response changes. The priority is no longer to remove strange PHP files as quickly as possible. The priority is to stop new files from being written, preserve enough evidence to understand the incident, and then clean from a known-good state.

A practical containment sequence is straightforward, but the order matters.

• Preserve evidence. Copy suspicious files, .htaccess files, timelines, and matching log extracts into a private archive before eradication begins (CISA, 2024).
• Restrict execution. Block PHP execution in upload, image, cache, tmp, and asset directories where possible. OWASP supports strict upload handling, and NSA/ASD guidance recommends limiting web-application write access to executable web paths where feasible (OWASP Foundation, n.d.-b; NSA & ASD, 2020).
• Contain the application. Disable the suspected plugin or theme, or place the site in maintenance mode if active exploitation is likely.
• Rotate credentials. Reset CMS administrator accounts, hosting-panel users, FTP/SFTP accounts, database passwords, and exposed API keys.
• Reinstall clean code. Replace WordPress core, plugins, and themes from trusted sources rather than editing infected files in place.
• Remove artifacts. Delete confirmed malicious files only after the evidence is preserved and the write path is closed.
• Patch and reduce surface. Remove abandoned plugins, update supported components, disable dashboard file editing, and tighten filesystem permissions. WordPress documents DISALLOW_FILE_EDIT and other hardening controls for reducing risky plugin and theme modification paths (WordPress.org, 2023).
• Monitor for recurrence. Watch changed files, POST activity, and new PHP files in writable directories after restoration. Reappearance can indicate missed persistence or an unclosed entry path, which is why response guidance includes continued monitoring and post-incident activity (CISA, 2024; NSA & ASD, 2020).

The order is important. If the payload is removed while the vulnerable plugin remains active, the attacker may write the files again. If the vulnerable path is patched while old backdoors remain, the attacker may no longer need the original weakness. Containment, eradication, recovery, and monitoring have to work together; otherwise, the site can look clean while the compromise path remains usable.

The Four Reports Worth Keeping

After containment, the investigation still needs a record. The goal is not to save every terminal output. The goal is to keep the reports that explain the case clearly enough to review later.

Four reports are usually worth archiving. Together, they show what changed, where suspicious PHP appeared, which web requests lined up with the changes, and which access rules may have shaped the attacker’s access. The supporting sources are practical. GNU Findutils explains the timestamp output. OWASP explains why upload-like paths matter. Apache explains why .htaccess rules matter. NSA and ASD explain why web-shell evidence should be correlated rather than judged from one signal alone (Free Software Foundation, n.d.; OWASP Foundation, n.d.-a; Apache Software Foundation, n.d.-a; NSA & ASD, 2020).

# 1. Suspicious PHP in writable/static paths
find "$SITE_ROOT" -type f -name "*.php" \
  \( -path "*/uploads/*" -o -path "*/images/*" -o -path "*/cache/*" -o -path "*/tmp/*" -o -path "*/assets/*" \) \
  -printf '%TY-%Tm-%Td %TH:%TM:%TS %u %g %m %p\n' | sort \
  > "$OUT_DIR/${SITE_SLUG}-suspicious-php-in-writable-dirs-2026-05-07.txt"

# 2. Clean changed-file timeline
find . \
  \( -path "*/log/*" -o -path "*/logs/*" -o -path "*/Trash/*" -o -path "*/pool/*" \) -prune -o \
  -newermt "$START" ! -newermt "$END" \
  ! -name "*.txt" \
  -printf '%TY-%Tm-%Td %TH:%TM:%TS %M %u %g %s %p\n' | sort \
  > "$OUT_DIR/${SITE_SLUG}-changed-files-clean-2026-05-07.txt"

# 3. Suspicious web requests
sudo zgrep -hEi 'POST|admin-ajax\.php|xmlrpc\.php|wp-json|async-upload\.php|upload|txets\.php|accesson\.php' \
  "$LOG_DIR"/* 2>/dev/null | grep "$LOG_DATE" \
  > "$OUT_DIR/${SITE_SLUG}-suspicious-web-requests-2026-05-07.txt"

# 4. Apache/PHP access-control rules
grep -RniE "Deny from all|Order allow,deny|Order deny,allow|Require all denied|FilesMatch|<Files|\.php" \
  "$SITE_ROOT" 2>/dev/null \
  > "$OUT_DIR/${SITE_SLUG}-apache-php-access-rules-2026-05-07.txt"

These commands are not a complete forensic platform. They are a disciplined first response. They preserve the timeline, the suspicious locations, the web activity, and the access-control clues that guide the next review. From there, the responder can decide which deeper logs, backups, plugin records, or account histories deserve attention.

What Good Investigation Feels Like

Good cybersecurity work is controlled doubt. You do not trust the first explanation. You test it. You do not treat a filename as evidence by itself. You place it in time, location, ownership, request history, permissions, and nearby configuration changes.

The sources in this guide point to the best practices behind each investigation step. CISA supports the response sequence. NSA and ASD support web-shell validation and traffic correlation. OWASP supports the upload-risk model. Apache supports the interpretation of access rules. GNU Findutils supports the timestamp command behavior. WordPress.org supports the hardening actions relevant to plugins, themes, and dashboard file editing.

In this investigation, the likely story became clearer only after several facts aligned. There were unfamiliar directories, repeated payload names, access-control files that allowed selected scripts, WordPress-shaped filenames, PHP under an asset path, and clustered timestamps.

None of those facts was enough alone. Together, they pointed toward a web-application write path, with a vulnerable WordPress plugin or theme as the strongest explanation after credential-based routes were checked.

The fix confirmed the direction of the investigation. Vulnerable WordPress plugins were identified, matched against publicly reported vulnerability information, and updated or replaced. After the exposed components were patched and the malicious files were removed, the same file pattern did not reappear during follow-up monitoring.

Here is the practical lesson: suspicious files should be treated as evidence of a capability, not just as objects to delete. In this case, the important capability was that the attacker could write executable PHP into directories where PHP did not belong. The backdoors had to be removed, but the vulnerable application component had to be fixed first. Otherwise, the same files could be written again. Final remediation also meant blocking PHP execution in upload-style directories, replacing modified `.htaccess` files, updating vulnerable WordPress plugins, rotating credentials, and monitoring for recurrence.

Field Checklist

• Preserve suspicious files before deleting them. This reflects the CISA sequence of analyzing before eradication and the NSA/ASD emphasis on validating suspicious files against expected application state (CISA, 2024; NSA & ASD, 2020).
• Build a changed-file timeline for the suspected window, while treating timestamps as triage evidence rather than standalone proof. The GNU citation is included because the command uses find -printf time directives based on file modification time (Free Software Foundation, n.d.).
• Search specifically for PHP in writable or static directories. OWASP guidance supports prioritizing executable code in upload-like locations because unrestricted uploads can enable code execution or system compromise (OWASP Foundation, n.d.-a).
• Inspect .htaccess and access-control rules for selective allowlists. Apache documentation explains how configuration sections and .htaccess files can target directories and filenames (Apache Software Foundation, n.d.-a, n.d.-b).
• Correlate file timestamps with POST, upload, REST, and admin-ajax requests. NSA/ASD guidance supports this because web shells often blend into normal traffic and require multiple detection signals (NSA & ASD, 2020).
• Check FTP/SFTP, hosting panel, and CMS login records before settling on a cause.
• Treat plugin vulnerability as a conclusion to earn, not an assumption to start with.
• Patch or disable the suspected component before final cleanup. WordPress hardening guidance supports removing unused components, keeping maintained components updated, and limiting dashboard editing paths (WordPress.org, 2023).
• Reinstall clean core, plugin, and theme files from known-good sources. This supports eradication after the write path is closed (CISA, 2024; WordPress.org, 2023).
• Keep short-term monitoring in place after restoration because recurrence can reveal missed persistence or an unclosed entry path (CISA, 2024; NSA & ASD, 2020).

References

Apache Software Foundation. (n.d.-a). Access control. Apache HTTP Server Version 2.4 Documentation. https://httpd.apache.org/docs/2.4/howto/access.html

Apache Software Foundation. (n.d.-b). Configuration sections. Apache HTTP Server Version 2.4 Documentation. https://httpd.apache.org/docs/2.4/sections.html

Cybersecurity and Infrastructure Security Agency. (2024). Federal government cybersecurity incident and vulnerability response playbooks. https://www.cisa.gov/resources-tools/resources/federal-government-cybersecurity-incident-and-vulnerability-response-playbooks

Free Software Foundation. (n.d.). Time directives. GNU Findutils Manual. https://www.gnu.org/software/findutils/manual/html_node/find_html/Time-Directives.html

MITRE ATT&CK. (2025, October 24). Server software component: Web shell (T1505.003). https://attack.mitre.org/techniques/T1505/003/

National Security Agency, & Australian Signals Directorate. (2020). Detect and prevent web shell malware. https://media.defense.gov/2020/Jun/09/2002313081/-1/-1/0/CSI-DETECT-AND-PREVENT-WEB-SHELL-MALWARE-20200422.PDF

OWASP Foundation. (n.d.-a). Unrestricted file upload. https://owasp.org/www-community/vulnerabilities/Unrestricted_File_Upload

OWASP Foundation. (n.d.-b). File upload cheat sheet. OWASP Cheat Sheet Series. https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html

WordPress.org. (2023). Hardening WordPress. WordPress Developer Resources. https://developer.wordpress.org/advanced-administration/security/hardening/

Download as PDF