Skip to content
GeneralAdvanced

How to Scan Downloaded PHP Website Files for Malware, Backdoors, Webshells and Malicious Code

A PHP website can sometimes be compromised without showing any obvious symptoms. The homepage may continue working normally while malicious PHP code operates...

BI
Bison Technical Team Enterprise IT specialists
Updated 07 Aug 2026 20 min read 0 total views

A PHP website can sometimes be compromised without showing any obvious symptoms. The homepage may continue working normally while malicious PHP code operates silently somewhere inside the website.

Attackers may inject malicious code into legitimate PHP files or create completely new files inside directories such as:

Advertisement
/uploads/
/images/
/assets/
/cache/
/includes/
/wp-admin/
/wp-content/
/tmp/

Malware may also be hidden several directories deep using random or numeric folder names.

If you have access to your website files through FTP, SFTP, a hosting control panel, or a hosting backup system, one useful security technique is to download the complete website to your local computer and scan it offline.

This article explains how to scan downloaded PHP websites on a Windows computer using antivirus software, PowerShell, YARA-based detection, PHP-specific malware scanners and manual investigation techniques.


Why Scan a PHP Website Locally?

Many shared-hosting environments restrict access to server-side security tools. You may not have SSH access, root access, Maldet, ClamAV or advanced malware-scanning utilities.

Downloading the website gives you more control.

You can:

  • Scan every downloaded file with antivirus software
  • Search thousands of PHP files quickly
  • Identify suspicious PHP functions
  • Find recently modified files
  • Locate unexpected PHP files
  • Detect PHP files inside upload and image directories
  • Search for encoded or obfuscated code
  • Compare clean and infected versions
  • Calculate file hashes
  • Run YARA rules
  • Quarantine suspicious files without immediately modifying the production website

However, local scanning should be considered one part of a complete incident investigation, not proof that the live hosting account is clean.


Common Signs of a Compromised PHP Website

Website infections can appear in many different forms.

Common symptoms include:

  • Unknown PHP files suddenly appearing
  • Random numeric directories
  • Unexpected ZIP files
  • Search-engine spam pages
  • Website redirects
  • Browser security warnings
  • Antivirus warnings
  • Hosting malware alerts
  • Modified .htaccess
  • Modified index.php
  • Unknown administrator accounts
  • Unexpected cron jobs
  • Strange JavaScript injections
  • Encoded PHP code
  • Website files repeatedly becoming infected after cleaning
  • PHP files appearing inside image or upload folders
  • Suspicious outbound network activity
  • High CPU or resource consumption
  • Spam emails originating from the hosting account

Sometimes there may be no visible symptom at all.


What Is PHP Malware?

PHP malware is malicious code written in or injected into PHP files.

Attackers may use it to:

  • Maintain unauthorized access
  • Upload additional malware
  • Execute commands
  • Modify website files
  • Redirect visitors
  • Inject advertisements
  • Create spam pages
  • Steal database credentials
  • Send spam
  • Create administrator accounts
  • Download additional payloads
  • Manipulate SEO results
  • Control the website remotely

A particularly dangerous category is the PHP webshell.


What Is a PHP Webshell?

A webshell is a malicious server-side script that can provide an attacker with remote access or command-execution capabilities through a web interface or specially crafted HTTP requests.

A webshell may allow an attacker to:

  • Browse files
  • Upload files
  • Download files
  • Delete files
  • Modify PHP code
  • Execute commands
  • Read configuration files
  • Access database credentials
  • Create additional backdoors

Some webshells are hundreds of kilobytes in size.

Others can be extremely small and intentionally obfuscated.


Step 1: Download the Complete Website

Do not download only index.php or the visibly affected directory.

Download the entire website whenever possible.

This may include:

public_html/
www/
htdocs/
wp-admin/
wp-content/
wp-includes/
vendor/
includes/
assets/
images/
uploads/
cache/
config/

Also include important hidden configuration files where your download method permits it, such as:

.htaccess
.user.ini

If WordPress is being used, download the complete WordPress installation.

For a custom PHP website, download all PHP, JavaScript, CSS, configuration and supporting files.


Step 2: Preserve an Original Copy

Before scanning, editing or deleting anything, preserve an untouched copy.

A useful structure is:

D:\WebSecurity\
    ORIGINAL\
    WORKING-COPY\
    QUARANTINE\
    CLEAN\

Put the untouched downloaded website under ORIGINAL.

Perform investigation on WORKING-COPY.

Move confirmed or strongly suspicious files to QUARANTINE rather than immediately destroying them.

This makes later comparison and forensic investigation easier.


Step 3: Scan the Website with Microsoft Defender

Windows includes Microsoft Defender Antivirus.

First update Defender's security intelligence, then scan the complete website directory.

For example:

D:\WebsiteScan\example.com\

You can right-click the directory in File Explorer and use the Microsoft Defender scanning option available on your Windows installation.

Alternatively, PowerShell can initiate a custom scan:

Start-MpScan -ScanType CustomScan -ScanPath "D:\WebsiteScan\example.com"

Microsoft Defender may detect known:

  • Trojan scripts
  • Backdoors
  • Webshells
  • Downloaders
  • Malicious JavaScript
  • Encoded payloads
  • Suspicious archives

However, traditional antivirus software alone should not be your only PHP malware detection method.


Why Antivirus Alone Is Not Enough

Website malware is different from conventional Windows malware.

A PHP backdoor does not necessarily contain a Windows executable.

It may simply be PHP source code such as:

<?php
// malicious logic
?>

Attackers also modify their code frequently.

A newly generated PHP webshell may therefore avoid signature-based detection.

This is why PHP-specific source-code inspection is valuable.


Step 4: Search PHP Files for Suspicious Functions

PowerShell provides a convenient way to inspect thousands of PHP files.

For example:

Get-ChildItem "D:\WebsiteScan\example.com" -Recurse -File -Include *.php |
Select-String -Pattern "eval\(|base64_decode\(|gzinflate\(|gzuncompress\(|str_rot13\(|assert\(|shell_exec\(|passthru\(|proc_open\(|popen\(|system\(|exec\(" |
Select-Object Path, LineNumber, Line

This searches PHP files for several functions frequently encountered during malware investigations.

Potentially interesting functions include:

eval()
base64_decode()
gzinflate()
gzuncompress()
str_rot13()
assert()
shell_exec()
passthru()
proc_open()
popen()
system()
exec()

Important Warning About False Positives

These functions are not automatically malicious.

For example:

base64_decode()

has legitimate programming uses.

Similarly:

exec()

may be intentionally used by certain applications.

The important question is:

Why is the function being used, where is it being used, and what data is being passed to it?

A scanner should therefore flag suspicious code for investigation rather than automatically deleting every matching file.


Step 5: Look for Multiple Layers of Obfuscation

Malware authors frequently attempt to make PHP code difficult to understand.

One suspicious pattern might resemble:

eval(base64_decode("encoded-data"));

Another may involve several transformations:

eval(gzinflate(base64_decode("encoded-data")));

Attackers may also split suspicious function names:

$f = "ba"."se64_"."decode";

This is intended to bypass simplistic scanners searching only for:

base64_decode

Other malware may use:

  • Character concatenation
  • Hexadecimal strings
  • Escape sequences
  • Compressed payloads
  • Dynamically generated function names
  • Variable functions
  • Extremely long encoded strings
  • Multiple decoding stages

This is one reason why YARA rules and PHP-specific malware scanners can outperform simple keyword searches.


Step 6: Find PHP Files in Suspicious Directories

One of the most useful checks is finding executable PHP code in directories that primarily contain non-executable content.

Run:

Get-ChildItem "D:\WebsiteScan\example.com" -Recurse -File -Filter *.php |
Where-Object {
    $_.FullName -match "\\uploads\\|\\images\\|\\cache\\|\\tmp\\|\\assets\\"
} |
Select-Object FullName

You might discover something like:

/uploads/2026/08/index.php
/images/384829/shell.php
/assets/839472/293847/index.php
/cache/system.php
/tmp/update.php

These files deserve investigation.

Again, directory location alone does not prove malware. Some frameworks legitimately place PHP files in unexpected locations.


Step 7: Look for Random and Numeric Directories

Attackers often try to hide files inside structures resembling:

/assets/768102/82550/74076/index.php
/includes/360862/index.php
/uploads/938472/23894/index.php

Random folder structures make manual discovery difficult.

When investigating an infection, pay special attention to:

  • Numeric-only directories
  • Random character directories
  • Recently created directories
  • Directories containing only index.php
  • PHP files buried several levels deep
  • Directories whose naming style differs from the rest of the website

For example, if your website normally contains:

/assets/css/
/assets/js/
/assets/images/

and suddenly contains:

/assets/748291/930284/12938/index.php

it warrants immediate investigation.


Step 8: Find Very Small PHP Files

Some malicious loaders and backdoors are surprisingly small.

Use:

Get-ChildItem "D:\WebsiteScan\example.com" -Recurse -Filter *.php |
Where-Object {$_.Length -lt 3000} |
Sort-Object Length |
Select-Object Length, FullName

This displays PHP files smaller than approximately 3 KB.

Do not automatically delete them.

Legitimate websites can contain very small PHP files.

The purpose is to generate an investigation list.


Step 9: Find Recently Modified PHP Files

Modification dates are extremely useful when investigating a recent compromise.

Run:

Get-ChildItem "D:\WebsiteScan\example.com" -Recurse -Filter *.php |
Sort-Object LastWriteTime -Descending |
Select-Object LastWriteTime, Length, FullName

Suppose your website has been running for several years, but suddenly dozens of unrelated PHP files show the same recent modification date.

That may indicate automated injection.

Inspect those files first.


Step 10: Check Important Entry Files

Attackers commonly modify files that are automatically loaded by the application.

Depending on the website, inspect files such as:

index.php
header.php
footer.php
functions.php
config.php
wp-config.php
.htaccess
.user.ini

For WordPress installations, also examine theme and plugin files that have recently changed.

A small malicious loader placed inside a commonly executed file may activate another payload hidden elsewhere.


Step 11: Inspect the Beginning and End of Legitimate PHP Files

Injected malware is sometimes appended to an otherwise legitimate file.

For example, a normal file may contain hundreds of lines of legitimate code followed by unexpected code at the bottom.

Other attackers prepend malicious code at the beginning.

Therefore, don't only inspect newly created files.

Also inspect recently modified legitimate files, particularly:

index.php
functions.php
header.php
footer.php
configuration files
plugin files
theme files

Step 12: Use YARA for Advanced Malware Detection

YARA is a pattern-matching technology widely used in malware research and incident response.

YARA rules can identify combinations of:

  • Strings
  • Code structures
  • Regular expressions
  • Encoded patterns
  • Known malware characteristics
  • Suspicious programming techniques

YARA is particularly useful when scanning large collections of PHP files because a rule can examine characteristics more sophisticated than a simple keyword search.

A YARA-based workflow can help detect:

  • Webshells
  • Obfuscated PHP
  • Backdoors
  • Loaders
  • Known malware families
  • Suspicious encoded payloads

Always review the quality and origin of YARA rules before relying on them.


Step 13: Use PHP Malware Finder

PHP Malware Finder is an open-source project designed to identify potentially malicious PHP code.

It uses YARA rules and is particularly useful for identifying suspicious PHP patterns and obfuscation.

It can complement:

Microsoft Defender
+
PowerShell investigation
+
YARA
+
Manual code review

No single scanner should be treated as perfect.


Step 14: Linux Malware Detect (Maldet/LMD)

Linux Malware Detect, commonly called LMD or Maldet, is another useful security scanner, especially in Linux hosting environments.

It is designed with web-hosting threats in mind.

Maldet is most naturally used on Linux servers or Linux-based analysis environments.

For Windows administrators, a Linux virtual machine or WSL-based lab may provide another way to perform additional scanning where compatible.

If you have server-level access to Linux hosting, Maldet can be particularly valuable.

On shared hosting, however, you may not have permission to install it.


Step 15: Use ClamAV as a Second Opinion

ClamAV is an open-source antivirus engine.

It can provide another detection layer.

A useful approach is:

Microsoft Defender
        ↓
PHP-specific scanner
        ↓
YARA
        ↓
ClamAV
        ↓
Manual investigation

Different engines may identify different threats.


Step 16: Check Selected Suspicious Files with VirusTotal

VirusTotal can analyze files using multiple security engines and other analysis signals.

This can be helpful when you discover an unknown file such as:

/wp-admin/includes/x.php
/assets/748392/index.php
/uploads/system.php

However, be careful.

Do Not Upload Sensitive Files

Avoid uploading files containing:

  • Database passwords
  • API keys
  • Private encryption keys
  • Customer information
  • Proprietary source code
  • Authentication tokens
  • Confidential business information

Files submitted to external scanning services should not automatically be assumed private.

Use such services selectively.


Step 17: Search for Suspicious ZIP Files

Website compromises sometimes leave archive files behind.

Look for:

.zip
.tar
.gz
.rar
.7z

An unexpected file such as:

backup123.zip
wp-update.zip
wp-waypoint.zip
files.zip
admin.zip

deserves investigation.

An archive may contain:

  • Webshells
  • Stolen data
  • Malware packages
  • Backup copies
  • Tools uploaded by an attacker

Do not execute unknown files extracted from suspicious archives.


Step 18: Compare Against a Known-Good Backup

A known-good backup can be one of the strongest investigation tools.

Suppose you have:

Website Backup – January
Website Backup – February
Website Backup – Current

Compare them.

Look for:

  • New PHP files
  • Deleted files
  • Changed files
  • New directories
  • Modified configuration
  • Modified JavaScript
  • Changed .htaccess
  • Changed themes/plugins

File hashes can make this comparison more reliable.


Step 19: Calculate SHA-256 Hashes

PowerShell can calculate file hashes:

Get-FileHash "D:\WebsiteScan\example.com\index.php" -Algorithm SHA256

For all PHP files:

Get-ChildItem "D:\WebsiteScan\example.com" -Recurse -Filter *.php |
Get-FileHash -Algorithm SHA256

Hashes are useful for determining whether files have changed between backups.

For example:

Clean Backup
index.php → SHA256 ABC123...

Current Website
index.php → SHA256 XYZ789...

Different hashes tell you the contents differ, although they do not tell you whether the change is malicious.


Step 20: Compare WordPress Core Files

For WordPress websites, legitimate WordPress core files should ideally be compared against the corresponding official WordPress release.

This can help identify:

  • Modified core files
  • Unexpected files
  • Injected code
  • Backdoors masquerading as WordPress files

Plugins and themes should likewise be compared with trusted original packages where practical.

Do not assume that a file is safe merely because its filename looks like a standard WordPress file.


Why File Names Cannot Be Trusted

Malware does not need a suspicious filename.

An attacker can name a malicious file:

wp-config-old.php
class-wp.php
functions.php
index.php
admin.php
update.php

or use names similar to legitimate system files.

Therefore:

Filename + location + content + timestamps + hashes + expected application structure

should be considered together.


Step 21: Check .htaccess

.htaccess can be abused to:

  • Redirect visitors
  • Redirect search-engine crawlers
  • Execute unusual handlers
  • Hide malicious URLs
  • Change PHP behavior
  • Route requests to malicious scripts

Compare .htaccess against your expected configuration.

Unexpected rewrite rules deserve investigation.


Step 22: Check .user.ini

PHP environments may use .user.ini to define per-directory configuration.

Attackers sometimes abuse PHP configuration mechanisms to automatically load malicious code.

Inspect unexpected settings carefully, particularly directives that cause another PHP file to be loaded automatically.


Step 23: Check JavaScript Too

Not every website compromise is PHP malware.

Attackers may inject malicious JavaScript into:

.js
.php
.html
.htm

This may cause:

  • Browser redirects
  • Fake login forms
  • Malicious advertisements
  • Skimming
  • Spam
  • External script loading

Therefore, PHP-only scanning is useful but not complete.


Step 24: Scan Configuration Files for Unauthorized Changes

Inspect configuration files carefully.

Look for:

  • Unknown remote domains
  • Unexpected include or require
  • Strange IP addresses
  • Unknown API endpoints
  • Dynamically constructed URLs
  • Unexpected PHP execution

Do not publish configuration files or credentials while seeking outside assistance.


Step 25: Check the Database

A completely clean PHP filesystem does not prove that the website is clean.

Malicious content may exist inside the database.

For WordPress, attackers may abuse database content such as:

  • Posts
  • Widgets
  • Options
  • Administrator accounts
  • Plugin settings

Look for:

  • Unknown administrator users
  • Injected JavaScript
  • Spam URLs
  • Changed site URLs
  • Unknown scheduled actions

Database analysis should therefore be included when an infection keeps returning.


Step 26: Check Hosting Cron Jobs

A malicious cron job can recreate deleted malware.

This explains a common situation:

  1. Administrator deletes suspicious PHP file.
  2. Website appears clean.
  3. Several hours later the same file returns.

The actual persistence mechanism may be:

Cron job
        ↓
Malicious loader
        ↓
Downloads/recreates malware

Check the hosting control panel for all scheduled jobs.

If SSH access is available, inspect the relevant user-level scheduled tasks using the hosting provider's supported method.


Step 27: Check FTP and SFTP Accounts

An attacker with stolen FTP credentials can simply upload the malware again.

Review:

  • FTP users
  • SFTP users
  • SSH accounts
  • Hosting users
  • Recently created accounts
  • Unknown credentials

Remove unused accounts and reset compromised credentials.


Step 28: Change Credentials After a Confirmed Compromise

Depending on the scope of the incident, credentials requiring rotation may include:

  • Hosting password
  • FTP password
  • SFTP password
  • SSH credentials
  • WordPress administrator passwords
  • Database passwords
  • Control-panel passwords
  • API keys
  • Application passwords

Do not reuse the previous compromised passwords.

Where supported, enable multi-factor authentication.


Step 29: Update WordPress, Plugins and Themes

Cleaning malware without closing the vulnerability that allowed it in can result in reinfection.

Update:

  • WordPress core
  • Plugins
  • Themes

Remove:

  • Abandoned plugins
  • Unused plugins
  • Unused themes
  • Pirated/nulled plugins
  • Pirated/nulled themes
  • Old test installations

A forgotten WordPress installation in a directory such as:

/demo/
/old/
/backup/
/test/
/dev/

can compromise the entire hosting account if it remains vulnerable.


Step 30: Check File Permissions

Incorrect permissions can increase risk.

Avoid unnecessarily permissive settings.

For example, using permissions equivalent to world-writable access across a website is generally a poor security practice.

Use the permissions recommended by your hosting provider and application.


Why Malware Sometimes Returns After Cleaning

Repeated infection usually means the root cause was not removed.

Possible causes include:

  • Hidden backdoor
  • Second webshell
  • Malicious cron job
  • Compromised FTP account
  • Compromised hosting account
  • Vulnerable WordPress plugin
  • Vulnerable theme
  • Old WordPress installation
  • Database persistence
  • Stolen credentials
  • Malicious .htaccess
  • Malicious .user.ini
  • Another infected website under the same hosting account

This last point is particularly important.

If multiple websites share one hosting account, cleaning only one website may not solve the problem.


Scan Every Website Under the Hosting Account

Suppose your hosting account contains:

site-a.com
site-b.com
site-c.com
old-site/
demo/

If site-a.com was compromised, investigate all of them.

The infection may have originated in old-site/ but spread into the other websites.


Recommended Local PHP Malware Investigation Workflow

A practical workflow is:

Download complete website
          ↓
Preserve untouched original
          ↓
Create working copy
          ↓
Update and run Microsoft Defender
          ↓
Run PHP-specific malware scanner
          ↓
Run YARA rules
          ↓
Search suspicious PHP functions
          ↓
Find PHP in unusual directories
          ↓
Find recent modifications
          ↓
Find unusual small files
          ↓
Check random/numeric directories
          ↓
Inspect .htaccess and .user.ini
          ↓
Check archives
          ↓
Compare with known-good backup
          ↓
Compare hashes
          ↓
Manually inspect high-risk files
          ↓
Check database
          ↓
Check cron jobs
          ↓
Check hosting/FTP/SFTP accounts
          ↓
Patch vulnerability
          ↓
Rotate compromised credentials
          ↓
Upload verified clean website
          ↓
Continue monitoring

Suggested Risk Scoring for Suspicious PHP Files

If you are building your own PHP website scanner, a risk-scoring system can help prioritize thousands of files.

For example:

Finding Example Risk
PHP file inside uploads +20
Recently created PHP file +10
Random numeric directory +15
eval() detected +15
base64_decode() detected +10
gzinflate() detected +15
shell_exec() detected +20
system() detected +20
Extremely long encoded string +15
Multiple obfuscation techniques +25
Known YARA malware match +40
Known antivirus detection +50

A scanner could then classify files:

0–19    Low
20–39   Review
40–59   Suspicious
60–79   High Risk
80–100  Critical

These values are illustrative. They should not be treated as a universal malware standard.


Features for a Windows PHP Website Malware Scanner

Organizations maintaining many PHP websites may benefit from building or using a dedicated local scanner.

Useful features could include:

Folder Selection

Allow the administrator to select:

D:\Websites\ClientWebsite\

Recursive Scanning

Analyze every subdirectory automatically.

PHP Content Analysis

Search for:

eval
base64_decode
gzinflate
shell_exec
system
exec
passthru
proc_open
popen
assert

Obfuscation Detection

Identify:

  • Very long strings
  • Encoded payloads
  • String concatenation
  • Suspicious variable functions
  • Repeated decoding operations

Location Analysis

Flag PHP files appearing in:

uploads
images
cache
tmp
assets

Timestamp Analysis

Highlight recently modified files.

Hash Generation

Generate SHA-256 hashes.

YARA Integration

Apply reputable PHP/webshell detection rules.

Risk Score

Give each file a security score.

Quarantine

Move selected suspicious files to a separate quarantine directory while preserving the directory structure.

Reports

Export results to:

HTML
CSV
JSON
PDF

Baseline Comparison

Save a known-good website snapshot and report:

NEW
MODIFIED
DELETED
UNCHANGED

This can be extremely effective for future monitoring.


Example Dashboard

A scanner could display:

WEBSITE SECURITY SCAN

Files Scanned:             18,492
PHP Files:                  3,841
Recently Modified:             27
Suspicious PHP:                14
PHP in Upload Folders:          3
Obfuscated Files:               6
YARA Matches:                   2
Critical Findings:              1

Overall Risk: HIGH

The administrator could then investigate the highest-risk files first.


Important: Never Automatically Delete Every Detection

Automated deletion is dangerous.

A legitimate PHP application may intentionally use functions that security scanners consider suspicious.

Incorrect deletion could:

  • Break the website
  • Break plugins
  • Break themes
  • Cause HTTP 500 errors
  • Damage application functionality

A safer approach is:

Detect
   ↓
Score
   ↓
Review
   ↓
Quarantine
   ↓
Test
   ↓
Delete/replace only after verification

Malware Cleaning vs Root-Cause Analysis

These are two different activities.

Malware Cleaning

Answers:

What malicious files currently exist?

Root-Cause Analysis

Answers:

How did the attacker get access?

A website is not truly secured until both questions have been addressed.

For example:

Vulnerable plugin
      ↓
Attacker gains access
      ↓
Uploads webshell
      ↓
Webshell creates backdoor
      ↓
Backdoor modifies index.php

Deleting index.php malware addresses only the final symptom.

The vulnerable plugin and webshell still need to be addressed.


Tools Worth Considering

Useful technologies for PHP malware investigations include:

Microsoft Defender — general local antivirus scanning.

YARA — advanced rule-based malware identification.

PHP Malware Finder — PHP-oriented malicious-code detection.

Linux Malware Detect (Maldet/LMD) — particularly useful for Linux/web-hosting malware scanning.

ClamAV — additional open-source antivirus layer.

VirusTotal — useful for carefully selected non-sensitive suspicious files.

PowerShell — extremely useful for local file searches, hashes, timestamps and source-code pattern analysis.

No single product should be considered 100% reliable.


Final Security Checklist

After discovering a PHP website infection, check:

  • Complete website downloaded

  • Untouched forensic copy preserved

  • Microsoft Defender scan completed

  • PHP source-code scan completed

  • YARA scan completed

  • Recently modified PHP files reviewed

  • PHP files in upload/image/cache directories reviewed

  • Random directories investigated

  • Suspicious archives checked

  • .htaccess reviewed

  • .user.ini reviewed

  • JavaScript reviewed where relevant

  • WordPress core verified where applicable

  • Plugins reviewed and updated

  • Themes reviewed and updated

  • Old installations removed

  • Database checked

  • Cron jobs checked

  • FTP/SFTP/SSH accounts reviewed

  • Hosting account reviewed

  • Passwords rotated where necessary

  • MFA enabled where supported

  • File permissions checked

  • Other websites under the same hosting account scanned

  • Clean backup established

  • Ongoing monitoring enabled


Frequently Asked Questions (FAQ)

1. Can I scan a PHP website after downloading it to my Windows PC?

Yes. Downloading the complete website allows you to scan files using Microsoft Defender, YARA, PHP-specific malware scanners, PowerShell and other tools.

2. Can Microsoft Defender detect PHP malware?

It can detect some known malicious scripts, webshells and other threats, but it should not be your only detection method.

3. Is base64_decode() always malware?

No. It is a legitimate PHP function. Its presence should be investigated in context.

4. Is eval() always malicious?

No, but unexpected or heavily obfuscated use of eval() deserves careful investigation.

5. What is a PHP webshell?

A PHP webshell is malicious server-side code that can provide an attacker with unauthorized remote capabilities on a compromised server.

6. Why do attackers create numeric directories?

Random or numeric names can make malicious files harder for administrators to notice and may also be automatically generated by malware.

7. Should PHP files exist inside an uploads directory?

Usually an upload directory is intended for uploaded content, but application designs differ. Unexpected PHP files there deserve investigation.

8. Can I delete every file detected by a PHP malware scanner?

No. False positives are possible. Review or quarantine files before permanent deletion.

9. Can VirusTotal scan PHP files?

Yes, but do not upload confidential source code, passwords, API keys, private keys or sensitive configuration files.

10. What is YARA?

YARA is a rule-based pattern-matching system widely used for identifying malware and suspicious files.

11. What is PHP Malware Finder?

It is an open-source project designed to identify suspicious PHP code using YARA-based rules.

12. What is Maldet?

Maldet, or Linux Malware Detect, is a malware scanner commonly used in Linux and web-hosting environments.

13. Can ClamAV scan website files?

Yes. ClamAV can provide an additional antivirus scanning layer.

14. Why does malware return after I delete it?

A persistence mechanism may remain, such as another backdoor, cron job, vulnerable plugin, compromised credentials or another infected website.

15. Should I scan all websites under the same hosting account?

Yes, particularly after a confirmed compromise. One vulnerable website may affect others depending on hosting isolation and permissions.

16. Should I check .htaccess?

Yes. Attackers can modify it for malicious redirects and other unwanted behavior.

17. Should I check .user.ini?

Yes. Unexpected PHP configuration can sometimes be used as a persistence mechanism.

18. Can malware exist in a website database?

Yes. Malicious scripts, spam content, administrator accounts and configuration changes may exist in the database.

19. Can malware hide inside legitimate PHP files?

Yes. Attackers may prepend or append malicious code to legitimate files.

20. Is downloading and scanning the website enough?

No. It checks downloaded files but does not fully investigate the live hosting environment, accounts, database, cron jobs or the original vulnerability.

21. Should I change passwords after an infection?

After a confirmed compromise, credentials potentially exposed to the attacker should be rotated.

22. Can old WordPress installations cause security problems?

Yes. Forgotten installations containing outdated plugins, themes or WordPress versions can become entry points.

23. Should unused WordPress plugins be removed?

Yes. If a plugin is not required, removing it reduces the attack surface.

24. Are file modification dates useful?

Yes. They can help prioritize files changed around the suspected compromise period.

25. Why calculate SHA-256 hashes?

Hashes help identify whether files have changed compared with a known-good version.

26. Can a clean antivirus result guarantee the website is safe?

No. No malware scanner provides an absolute guarantee.

27. What is the best way to detect modified legitimate files?

Compare the current website against a known-good backup or trusted original application package and use file hashes.

28. Can JavaScript also be infected?

Yes. Attackers frequently inject malicious or unwanted JavaScript into websites.

29. Should suspicious ZIP files be investigated?

Yes. Unexpected archives may contain malicious scripts, stolen data or attacker tools.

30. What should I do before deleting suspicious files?

Back up the website, preserve an original copy, review the detection and preferably quarantine the file first.


Conclusion

Downloading a complete PHP website and scanning it locally is an effective component of website malware investigation, especially when working with shared hosting where server-level security tools may be unavailable.

A strong investigation combines several techniques:

Antivirus
+ PHP source-code analysis
+ YARA
+ File location analysis
+ Timestamp analysis
+ Hash comparison
+ Known-good backup comparison
+ Manual review
+ Database inspection
+ Hosting account investigation

The most important principle is:

Do not only remove the malicious file. Find and eliminate the reason it was created.

If the original vulnerability, stolen credential, malicious cron job, hidden backdoor or compromised secondary website remains active, the malware may simply return.

Disclaimer

This article is provided for educational and informational purposes only. Malware detection results can include false positives, and deleting or modifying legitimate website files can cause application failure or data loss. Always maintain verified backups before making changes. For production, business-critical or compromised systems, consider consulting your hosting provider, website developer or qualified cybersecurity professional. Security tools, commands and detection methods may change over time, so verify current documentation before proceeding.

 

#PHPMalware #PHPWebsite #MalwareScanner #WebsiteSecurity #PHPsecurity #WebSecurity #MalwareDetection #PHPScanner #Webshell #WebshellDetection #PHPBackdoor #BackdoorDetection #CyberSecurity #WebsiteMalware #MalwareRemoval #WebsiteProtection #WordPressSecurity #WordPressMalware #HackedWebsite #WebsiteRecovery #YARA #PHPMalwareFinder #Maldet #LinuxMalwareDetect #ClamAV #MicrosoftDefender #VirusTotal #PowerShell #SecurityAudit #WebsiteAudit #MalwareAnalysis #ThreatDetection #IncidentResponse #FileIntegrity #SHA256 #PHPDevelopment #WebDevelopment #WebHosting #HostingSecurity #SharedHosting #WordPress #PHP #CyberThreats #WebsiteHacking #SecurityTools #MalwareInvestigation #WebApplicationSecurity #PHPWebshell #WebsiteMonitoring #InformationSecurity

YOUR FEEDBACK

Was this guide useful?

Your answer helps us keep BISONKB accurate and practical.

BISON AI

Ask about “How to Scan Downloaded PHP Website Files for Malware, Backdoors, Webshells and Malicious Code”

This interface is ready to connect to your preferred AI provider. No article or user data is sent until that service is configured.

THE BISON BRIEF

Practical IT knowledge, once a week.

New troubleshooting guides, scripts and infrastructure notes. No noise.

By subscribing, you agree to our privacy policy.