Issue Plesk adding hex data to index.php after change of httpdocs folder

[Liberator]

Server operating system version

Debian 12.10

Plesk version and microupdate number

Plesk Obsidian 18.0.68 Update #2

I have a website on my server where I had to upload a new httpdocs folder. I renamed the old folder and then uploaded the new folder. All went well until I loaded the (new) website in a browser only to find that my old index.php was shown. On inspection I discovered that the file permissions for this file were set to 0444 and a big section of hex code was added at the start of the file (presumably the old index.php page). It also changed the permissions on my .htaccess file to 0444. I cannot change the permissions on these files and if I delete them and upload replacements the same thing happens.

Anyone have a clue as what is happening and how to solve the problem?

 

[scsa20]

The first question is are you uploading using a FTP application or you using the file manager within plesk?

 

[Liberator]

The first question is are you uploading using a FTP application or you using the file manager within plesk?

I was uploading using ftp. Then I used SFTP - both the same result. I just tried uploading using plesk file manager and the same thing happens, including setting permissions to 0444. The original file is 26k. When uploaded it changes to 44k and has the huge section of hex characters at the start. The file now starts with:

<?php
$hex='3c3f7068........

The hex section ends with:
......0d0a3f3e';
$bin=hex2bin($hex);
eval('?>'.$bin);?>

After that is the normal html / php content OF THE OLD VERSION of index.php.

I have tried deleting index.php from the server - both by FTP and Plesk file manager. It makes no difference.

I tried uploading the same file as index2.php and that works 100%.

Something is protecting the index file (and the .htaccess file) and preventing me from changing it...

 

[Raul A.]

That looks like a malicious injection. Check if you have a running process spawned by your website system user. First, identify the system user:

Next, via SSH, check if there are any running processes:

# ps -u example.com_y52t56kk2ld -f
UID          PID    PPID  C STIME TTY          TIME CMD
example+ 2158175       1  0 06:11 pts/0    00:00:00 sleep 1000

In the above, I started the sleep command to exemplify the ps output.

Also check if you have any new cron tasks that are executed every minute (Scheduled Tasks in the above screenshot).

It might also be the case where the malicious code is already injected in your web application and every website access will trigger the code to reinject the index.php file.

I recommend installing the Imunify extension (the free version will scan for you, but you will have to clean the files manually).