Finding malicious or unexplained code inside one PHP file should never be treated as an isolated incident until the rest of the website has been checked.

For example, suppose a website suddenly stops opening and investigation reveals unfamiliar PHP code inserted at the beginning of index.php. After removing that code, the website immediately starts working again.

Although the immediate problem appears solved, an important question remains:

Was only index.php modified, or does the hosting account contain additional malware?

Attackers commonly maintain persistence by placing malicious code in multiple locations. They may create hidden PHP files, ZIP archives, web shells, randomly named directories, scheduled tasks, .user.ini directives, modified .htaccess files, or secondary backdoors.

Therefore, discovering one injected PHP file should trigger a broader security investigation.

Example of Suspicious Obfuscated PHP

Consider code similar to this:

<?php
$data = array(122, 105, 112, 58, 47, 47, 120, 121, 122, 35, 97);
$loader = '';

for ($i = 0; $i < count($data); $i++) {
    $loader .= chr($data[$i]);
}

require $loader;
?>

At first glance, this may appear meaningless.

The important elements are:

chr()

and:

require $loader;

Instead of writing the filename or resource directly, the code converts numbers into characters and constructs it dynamically.

In a real-world case, this technique can be used to construct a PHP stream such as:

zip://something#file

The resulting string is then supplied to:

require

This can cause PHP to load code from an archive.

The presence of obfuscation does not automatically prove malicious intent, but unexplained obfuscated code inserted into an existing website—especially immediately before legitimate application code—is a major warning sign.

What Is PHP Code Injection?

PHP code injection occurs when unauthorized code is inserted into legitimate PHP files or when new malicious PHP files are uploaded to the server.

Attackers may modify:

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

They may also create entirely new files.

The malicious code may perform activities such as:

• loading additional malware;
• redirecting visitors;
• creating spam pages;
• injecting SEO spam;
• downloading additional payloads;
• providing remote access;
• recreating deleted malware;
• stealing application information;
• executing commands;
• creating hidden administrator access;
• modifying other PHP files.

Removing the visible malicious code may restore the website without removing the original security compromise.

Why Would Malware Use zip://?

PHP supports several stream wrappers.

One of them is:

zip://

PHP applications can legitimately use ZIP functionality. However, attackers may abuse archive handling to make malicious components less obvious.

Instead of maintaining an easily recognizable file such as:

malware.php

an attacker may attempt to reference content stored inside an archive.

Conceptually:

ZIP archive
    |
    +--- hidden PHP payload
              |
              +--- loaded by compromised PHP file

This is why discovering suspicious code involving:

zip://

should lead to an investigation of both PHP files and archives.

Step 1: Do Not Assume Only One File Is Infected

If malware has been confirmed in:

/public_html/index.php

do not simply clean index.php and declare the server safe.

The attacker may have installed another file responsible for reinfecting it.

For example:

public_html/
|
|-- index.php                 <- Modified
|-- .htaccess
|-- .user.ini
|
|-- includes/
|     |-- header.php
|     +-- unknown.php         <- Suspicious
|
|-- assets/
|     +-- 482751/
|           +-- index.php     <- Suspicious
|
|-- images/
|     +-- cache.php           <- Highly unusual
|
+-- backup/
      +-- data.zip            <- Requires investigation

The secondary file may remain dormant until needed.

Step 2: Create a Backup Before Cleanup

Before deleting suspicious files, create a backup of:

• website files;
• database;
• configuration files;
• .htaccess;
• .user.ini;
• important logs, if available.

However, clearly mark the backup as:

Potentially infected — do not restore directly into production.

The backup may be valuable for forensic investigation and for recovering legitimate content accidentally affected during cleanup.

Step 3: Search the Website for Suspicious PHP Functions

Search the complete website for commonly abused functions and patterns.

Useful search terms include:

base64_decode(
eval(
gzinflate(
gzuncompress(
str_rot13(
chr(
assert(
shell_exec(
system(
passthru(
exec(
proc_open(
popen(
zip://
phar://
data://
file_put_contents(

These functions are not automatically malicious.

For example, a legitimate application may use:

base64_decode()

or:

file_put_contents()

The purpose of searching is to locate code requiring inspection.

Step 4: Search Specifically for chr() Obfuscation

Because the discovered infection used numerical values converted with chr(), search the entire hosting account for:

chr(

A single legitimate occurrence may not be concerning.

This pattern deserves more attention:

$values = array(120, 121, 122, ...);

foreach ($values as $value) {
    $string .= chr($value);
}

require $string;

The combination of:

• arrays of character codes;
• chr();
• dynamically generated strings;
• require;
• include;

is substantially more suspicious than chr() alone.

Step 5: Search for Dynamically Constructed Includes

Search for patterns such as:

require $variable;
include $variable;
require_once $variable;
include_once $variable;

Normal applications sometimes use dynamic includes, so context matters.

A suspicious example might resemble:

$a = [...];
$b = '';

foreach ($a as $c) {
    $b .= chr($c);
}

require $b;

The developer should determine what $b becomes before allowing it to execute.

Step 6: Search Specifically for PHP Stream Wrappers

Search for:

zip://
phar://
data://

For example, using SSH:

grep -Rni "zip://" public_html

You can also search multiple patterns:

grep -RniE "zip://|phar://|data://" public_html

Any unexpected occurrence should be reviewed.

Step 7: Search for ZIP and Other Archive Files

Do not limit the investigation to .php files.

Search for:

*.zip
*.gz
*.tar
*.rar

With SSH:

find public_html -type f \( -iname "*.zip" -o -iname "*.gz" -o -iname "*.tar" -o -iname "*.rar" \)

Review every unexpected archive.

However, do not automatically delete every archive. Website owners often maintain legitimate backup ZIP files.

Determine:

• who created it;
• when it was created;
• whether its filename is expected;
• what files it contains;
• whether application code references it.

Archives Without .zip Extensions

An important limitation of extension-based searches is that an archive does not necessarily need to be named:

something.zip

A suspicious file could be called:

cache
data
tmp
abc
update
backup1

Therefore, investigation should consider file content/type in addition to filename.

Step 8: Sort Files by Modification Date

This is one of the most useful techniques during a compromise investigation.

Suppose the compromised index.php was modified on:

06-Aug-2026 03:18 AM

Look for other files modified around that time.

You might discover:

03:17  .user.ini
03:18  index.php
03:18  includes/cache.php
03:19  assets/582194/index.php
03:20  temp/archive.dat

That sequence can reveal the scope of the compromise.

Finding Recently Modified PHP Files with SSH

Files modified during the last seven days:

find public_html -type f -name "*.php" -mtime -7 -print

Files modified during the last 30 days:

find public_html -type f -name "*.php" -mtime -30 -print

Review the output rather than deleting it automatically.

Step 9: Inspect Unusual PHP Files in Static Directories

PHP files in certain directories deserve special attention.

For example:

/images/update.php
/css/config.php
/js/cache.php
/fonts/index.php
/uploads/shell.php

An images directory normally contains files such as:

.jpg
.jpeg
.png
.webp
.gif
.svg

Therefore:

/images/security.php

should immediately be investigated unless the application architecture explains it.

Similarly:

/css/update.php

or:

/fonts/cache.php

may be abnormal.

Step 10: Investigate Randomly Numbered Directories

Attackers sometimes create directory structures such as:

/assets/582194/
/uploads/374821/
/includes/693147/

and place:

index.php

inside them.

For example:

assets/
   582194/
      274193/
         index.php

This does not automatically prove malware, because legitimate applications can generate numeric directories. However, if the site's normal architecture does not use them, they deserve immediate inspection.

Step 11: Examine .htaccess

The .htaccess file can control how requests are processed by Apache-compatible web servers.

Review it carefully for unexpected directives.

Pay particular attention to:

RewriteRule
RewriteCond
AddHandler
SetHandler
php_value
auto_prepend_file
auto_append_file

A normal website may legitimately contain rewrite rules such as:

RewriteEngine On

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule . /index.php [L]

Therefore, the presence of RewriteRule is not itself evidence of malware.

You are looking for unexpected rules pointing to unfamiliar files, external destinations, or strange handlers.

Step 12: Inspect .user.ini

.user.ini deserves particular attention during PHP malware investigations.

A malicious configuration could attempt to load another PHP file automatically using a directive such as:

auto_prepend_file=/path/to/unknown.php

Conceptually:

Visitor requests index.php
        |
        v
PHP reads .user.ini
        |
        v
auto_prepend_file executes
        |
        v
Malicious PHP executes
        |
        v
Normal index.php executes

This means a legitimate PHP page can look perfectly clean while malicious code is being executed before it.

Check the entire hosting structure for unexpected .user.ini files.

Step 13: Check PHP Configuration Files

Depending on the hosting environment, review:

php.ini
.user.ini
.htaccess

Look for unfamiliar references to:

auto_prepend_file
auto_append_file

If an unknown PHP script is configured here, simply cleaning index.php may not solve the compromise.

Step 14: Check Cron Jobs

Another persistence mechanism is a scheduled task.

For example, a malicious cron job could theoretically run periodically and recreate a deleted file.

Check your hosting control panel's:

Cron Jobs / Scheduled Tasks

Review every configured job.

A legitimate job might run:

backup.php
scheduled-report.php
maintenance.php

An unfamiliar command executing a randomly named PHP file deserves investigation.

If no cron jobs exist, that eliminates one potential persistence mechanism but does not prove that the account is clean.

Step 15: Check WordPress Scheduled Activity Separately

If WordPress exists anywhere in the same hosting environment, remember that WordPress has its own scheduled task mechanism.

Also inspect:

• plugins;
• themes;
• wp-content/uploads;
• administrator accounts;
• wp-config.php;
• unknown files in wp-admin;
• unknown files in wp-includes.

Core WordPress directories should be compared against clean versions of the same WordPress release when possible.

Step 16: Search the Entire Hosting Account, Not Just One Domain

This is especially important on shared hosting accounts containing several websites.

For example:

/home/account/
|
|-- site-one.com/
|-- site-two.com/
|-- site-three.com/
+-- public_html/

If one website is compromised, investigate the others as well.

The exact amount of cross-site access depends on the hosting architecture and permissions, but limiting the scan to only the visibly affected domain can miss related files.

Step 17: Search for Obfuscated Code

Common suspicious structures include very long unreadable strings:

$abc = "aGVsbG8gd29ybGQ...";

followed by something like:

base64_decode($abc);

More suspicious combinations include:

eval(base64_decode($data));

or layered transformations involving compression and encoding.

Again, functions such as base64_decode() can have legitimate uses. The context determines whether the code is dangerous.

Step 18: Look for Extremely Long Single-Line PHP Files

Malware authors frequently remove formatting to make inspection difficult.

For example:

<?php $a='...';$b='...';$c=base64_decode($a); ... ?>

A PHP file consisting of one enormous line containing hundreds or thousands of apparently random characters deserves investigation.

Legitimate minified or generated code exists, so this is an indicator rather than definitive proof.

Step 19: Check for Recently Created Files

A compromise may create new files instead of modifying existing ones.

Look for unexpected filenames such as:

update.php
class.api.php
cache.php
wp-old.php
temp.php
test1.php
shell.php
old-index.php

Random filenames are also common:

xq12.php
ab783.php
298471.php

Do not rely exclusively on suspicious-looking names. Malware can also use convincing names.

Step 20: Compare Website Files Against a Known-Good Backup

If you have a clean backup from before the incident, compare it against the current site.

For example:

CLEAN BACKUP               CURRENT WEBSITE

index.php                  index.php        MODIFIED
header.php                 header.php       SAME
footer.php                 footer.php       SAME
                           cachex.php        NEW

This is often much more reliable than attempting to identify malware purely by appearance.

Step 21: Verify Application Core Files

For popular applications such as WordPress, reinstalling or verifying core files against official distributions can help detect modifications.

Do not overwrite:

• custom application code;
• configuration files;
• uploaded content;

without understanding what will be affected.

Take backups first.

Step 22: Review Hosting Logs

If available, inspect:

• access logs;
• error logs;
• FTP logs;
• authentication history;
• control-panel login history.

Look for unusual activity around the modification time of the infected file.

For example:

02:58 suspicious POST request
03:01 new PHP file created
03:03 index.php modified
03:05 unusual external request

Logs may help identify how the compromise occurred.

Step 23: Check File Permissions

Excessively permissive permissions can increase risk.

Avoid casually assigning:

777

to files and directories.

Typical configurations frequently use permissions similar to:

Directories: 755
Files:       644

but the correct values depend on the hosting platform and application.

Follow your hosting provider's recommended permissions rather than changing everything blindly.

Step 24: Change Hosting Credentials

After investigating a confirmed compromise, review and rotate relevant credentials.

This may include:

• hosting control-panel password;
• FTP password;
• SFTP password;
• SSH credentials;
• CMS administrator passwords;
• database passwords where appropriate;
• API credentials;
• application passwords.

Enable two-factor authentication wherever supported.

Do not reuse the old password.

Step 25: Check FTP Accounts

An old FTP account can provide continued access.

Review:

FTP Accounts
SFTP Accounts
SSH Users

Remove accounts that are:

• unknown;
• unused;
• created for former developers;
• associated with old projects.

Reset credentials for accounts that must remain active.

Step 26: Check CMS Administrator Accounts

For WordPress and similar CMS platforms, review every administrator.

Look for:

• unknown administrators;
• unfamiliar email addresses;
• recently created privileged accounts;
• old developer accounts;
• accounts no longer required.

Do not assume that changing the main administrator password removes other privileged access.

Step 27: Update CMS, Plugins and Themes

Outdated components are a common source of web compromises.

Update:

• CMS core;
• plugins;
• themes;
• PHP applications;
• third-party libraries.

Remove abandoned components rather than merely disabling them when they are no longer needed.

Step 28: Remove Unused Websites

An old website under the same hosting account can become the entry point for a compromise.

For example:

main-site.com       Updated
old-demo.com        WordPress from years ago
test-site.com       Forgotten
development/        Old PHP application

The forgotten website may contain the vulnerability.

If a test or old website is no longer required, back it up if necessary and remove it from production hosting.

Step 29: Remove Unused Plugins and Themes

Disabled does not necessarily mean harmless.

If vulnerable code remains on the server and is directly accessible, it may still increase attack surface.

Keep only what the website actually requires.

Step 30: Run Hosting Malware Scans

If your hosting provider provides a malware scanner, run a complete scan after manual investigation.

Do not rely on only one scanner.

A stronger process is:

Hosting malware scanner
          +
Manual source-code inspection
          +
File modification review
          +
Known-good comparison
          +
Log investigation

Useful SSH Commands

Search for suspicious PHP functions

grep -RniE "base64_decode|gzinflate|gzuncompress|str_rot13|eval[[:space:]]*\(|shell_exec|passthru|proc_open|popen|zip://|phar://|data://" public_html

Search for chr()

grep -Rni "chr(" public_html

Search for ZIP wrapper usage

grep -Rni "zip://" public_html

Search for dynamically generated include/require patterns

grep -RniE "require[[:space:]]+\$|include[[:space:]]+\$" public_html

Find ZIP files

find public_html -type f -iname "*.zip"

Find common archives

find public_html -type f \( -iname "*.zip" -o -iname "*.gz" -o -iname "*.tar" -o -iname "*.rar" \)

Find PHP files modified during the last seven days

find public_html -type f -name "*.php" -mtime -7 -print

Find PHP files modified during the last 30 days

find public_html -type f -name "*.php" -mtime -30 -print

Be Careful With Automated grep Results

Suppose this command:

grep -Rni "base64_decode" public_html

returns 40 files.

That does not mean you have 40 infected files.

Libraries may legitimately use encoding and decoding functions.

Likewise:

exec()

can exist in legitimate administrative applications.

Therefore, use automated searching for discovery, not automatic deletion.

A Better Malware Classification Method

During manual investigation, classify files into four groups.

1. Known Clean

Files matching a trusted backup or official application distribution.

2. Probably Clean

Files whose code and purpose are understood but have not yet been independently verified.

3. Suspicious

Files containing unexplained:

• obfuscation;
• dynamic includes;
• encoded strings;
• unusual external communication;
• unexpected archive loading;
• random filenames;
• PHP inside static-content directories.

4. Confirmed Malicious

Files conclusively identified as unauthorized or malicious.

Only delete or replace files when you understand their role or have a trusted clean copy.

How Malware Can Return After You Delete It

One of the most frustrating scenarios is:

Delete malware
      |
      v
Website becomes clean
      |
      v
Several hours later
      |
      v
Malware returns

This can happen when the original persistence mechanism remains active.

Possible causes include:

Hidden PHP backdoor
      |
      +----> Rewrites index.php

Cron job
      |
      +----> Downloads/recreates malware

.user.ini
      |
      +----> Automatically executes hidden PHP

Compromised CMS admin
      |
      +----> Attacker uploads malware again

Stolen FTP credentials
      |
      +----> Attacker reconnects

Vulnerable plugin
      |
      +----> Website gets exploited again

Therefore, reinfection is evidence that the root cause has not been removed.

What to Do If the Website Works After Removing Injected Code

If removing suspicious code makes the website work again, that is useful evidence that the code was involved in the failure.

However:

Website working ≠ website clean

After restoring functionality:

1. Back up the current state.
2. Scan all PHP files.
3. Search for ZIP/archive loaders.
4. Inspect .htaccess.
5. Inspect .user.ini.
6. Check recent file modifications.
7. Search static directories for PHP.
8. Review random directories.
9. Check cron jobs.
10. Review administrator accounts.
11. Review FTP/SFTP/SSH access.
12. Update software.
13. Change relevant credentials.
14. Run another malware scan.
15. Monitor the website for reinfection.

Recommended Incident Response Workflow

A practical workflow is:

Website problem detected
        |
        v
Identify suspicious file
        |
        v
Preserve backup/evidence
        |
        v
Remove or replace confirmed malicious code
        |
        v
Restore website functionality
        |
        v
Search entire account
        |
        v
Check recent modifications
        |
        v
Inspect .htaccess / .user.ini
        |
        v
Check archives and hidden loaders
        |
        v
Check cron / CMS / FTP access
        |
        v
Patch vulnerable software
        |
        v
Change credentials
        |
        v
Run complete security scan
        |
        v
Monitor for reinfection

How to Reduce the Risk of Future PHP Infections

Keep Software Updated

Apply security updates promptly to CMS platforms, plugins, themes and third-party PHP libraries.

Remove Unused Applications

Old demo installations and abandoned applications increase attack surface.

Use Strong Passwords and 2FA

Protect hosting, CMS and administrative accounts.

Limit FTP Accounts

Remove unused developer and temporary accounts.

Maintain Off-Site Backups

A backup stored only inside the same compromised hosting account may also be altered or deleted.

Maintain separate backups with appropriate retention.

Monitor File Changes

Unexpected modifications to:

index.php
.htaccess
.user.ini
config.php
header.php
footer.php

should trigger investigation.

Use Web Application Protection

A properly configured Web Application Firewall can help reduce exposure to certain web attacks, although it does not replace application patching and server security.

Frequently Asked Questions (FAQ)

1. If only one PHP file is infected, is the rest of the website safe?

Not necessarily. One confirmed infection should trigger investigation of the entire website and, where appropriate, the hosting account.

2. Can deleting malicious code from index.php completely fix the problem?

It may restore the website, but a hidden backdoor or persistence mechanism could remain.

3. What does chr() do in PHP?

chr() converts an integer into its corresponding single-byte character. It is legitimate PHP functionality but can be abused to hide strings.

4. Is every use of chr() malware?

No. Context is important. Large arrays of numbers converted into a hidden string and then passed to require or include are much more suspicious.

5. What is zip:// in PHP?

It is a PHP stream mechanism that can be used to access content associated with ZIP archives. Legitimate applications can use archive functionality, but unexplained usage in injected code requires investigation.

6. Can malware execute code stored in an archive?

PHP's supported stream/archive mechanisms can allow applications to access content inside archives. Unexpected archive-based loading in compromised code should be treated as suspicious.

7. Should I delete every ZIP file from my hosting account?

No. Some may be legitimate backups or application packages. Inspect them first.

8. Can malware create ZIP files without a .zip extension?

A file's content does not have to match its extension, so checking only filenames is insufficient.

9. Why should I check .user.ini?

It can alter per-directory PHP configuration and may contain directives such as auto_prepend_file.

10. What does auto_prepend_file do?

It instructs PHP to process another file before the requested PHP script, making it important during malware investigations.

11. Should I inspect .htaccess?

Yes. Look for unfamiliar redirects, handlers and rules pointing to unknown files.

12. Are random numbered directories always malware?

No, but unexplained numeric directories containing PHP files deserve investigation.

13. Why would malware place PHP files in an images directory?

Static directories can make malicious scripts less obvious to someone manually browsing the site.

14. Is base64_decode() proof of malware?

No. It has legitimate uses. Investigate how and why it is being used.

15. Is eval() dangerous?

eval() executes PHP code represented as a string and therefore deserves careful review, particularly when combined with encoded or externally supplied data.

16. Should I search all websites under the same hosting account?

Yes, particularly when multiple sites share the same account and filesystem permissions.

17. Can an old WordPress installation cause problems?

Yes. Forgotten and outdated applications can remain vulnerable even if they are no longer actively promoted.

18. Can disabled plugins still create security concerns?

Potentially. Removing unnecessary vulnerable code is safer than keeping abandoned components indefinitely.

19. Should I change my hosting password after an infection?

Credential rotation is a sensible part of incident response, especially if unauthorized access cannot be ruled out.

20. Should FTP passwords also be changed?

Yes, when FTP credentials may have been exposed or the method of compromise is unknown.

21. Should database passwords be changed?

Consider rotating them if there is reason to believe configuration files or database credentials were exposed. Update the application's configuration carefully afterward.

22. Can cron jobs recreate malware?

Yes. Scheduled scripts are one possible persistence mechanism and should be checked.

23. Why does malware sometimes return after deletion?

The original vulnerability, backdoor, scheduled task, compromised credential, or another persistence mechanism may still exist.

24. Is a hosting malware scanner sufficient?

It is useful but should be combined with manual inspection, file comparisons, updates and access review.

25. Should I restore an old backup?

Only if you have confidence that the backup predates the compromise. After restoration, patch the vulnerability that caused the compromise.

26. Can I search PHP files using SSH?

Yes. Commands such as grep and find are very useful for identifying suspicious patterns and recently modified files.

27. Can I automatically delete every file found by grep?

No. Search results require manual validation because legitimate applications may use the same PHP functions.

28. What should I check first after discovering injected PHP?

Preserve a backup, identify the suspicious code, review recent modifications, and investigate the wider hosting environment.

29. Should hidden files be inspected?

Yes. Files beginning with a dot, including .htaccess and .user.ini, are especially important.

30. Does a working homepage mean the malware is gone?

No. It only confirms that the page can currently execute successfully.

Conclusion

Discovering injected code inside a PHP website should be treated as a security incident rather than simply a broken-page problem.

Removing the malicious lines may immediately restore the website, but the more important task is determining:

How did the code get there, what else was modified, and can the attacker regain access?

The investigation should include PHP files, archives, hidden configuration files, modification timestamps, static directories, cron jobs, CMS accounts, FTP/SFTP/SSH access, outdated applications, and all other websites sharing the hosting environment.

The safest principle is:

Find one infection → investigate the entire account → remove persistence → patch the entry point → rotate relevant credentials → monitor for reinfection.

 

#PHPSecurity #PHPMalware #WebsiteSecurity #CyberSecurity #MalwareRemoval #WebsiteMalware #PHPWebsite #WebSecurity #CodeInjection #PHPInjection #HackedWebsite #WebsiteHacked #MalwareDetection #SecurityAudit #WebsiteAudit #PHPBackdoor #WebShell #BackdoorDetection #MalwareScanner #HostingSecurity #SharedHosting #PublicHTML #IndexPHP #HTAccess #UserINI #PHPDeveloper #WebDeveloper #WebHosting #ServerSecurity #LinuxSecurity #SSH #CyberAttack #IncidentResponse #WebsiteProtection #MalwareCleanup #PHPProgramming #SecureCoding #CyberSafety #FileIntegrity #SecurityMonitoring #WordPressSecurity #WordPressMalware #WebsiteBackup #DataSecurity #HostingMalware #CyberDefense #WebApplicationSecurity #PHPBackdoorRemoval #WebsiteRecovery #CyberSecurityTips