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).

 

[Bitpalast]

This is for sure a hacked server or hacked website. If other scripts reside in the same webspace subscription, they are probably infected with malware that scans the directory tree and writes itself (or some other malicious code) into the files that it finds that are suitable for infection but have not yet been infected. It is less likely that this is happening on the operating system level.

 

[Liberator]

That looks like a malicious injection. Check if you have a running process spawned by your website system user. First, identify the system user:
View attachment 28128
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).

Thanks @Raul A. and @Bitpalast for your input.

I installed and ran Imunify. First run it found 9 infected files in various folders. Some of the folders did not exist previously. All except 1 of the infected files were 'index.php' - the other was named 'blank.php'. I deleted the whole httpdocs folder content and copied clean files to it. Imunify now reports that it is clean. Despite this the root index.php file was immediately replaced with an old version (with the hex characters at the top) and set to 0444. My htaccess was also set to 0444. I then ran a clanscan on my whole system with no reported infections. Imunify still reports that the folder is clean.

I am tempted to create a new folder with a different name and point the domain to that folder as the document root. What do you think?

 

[scsa20]

You'd be better off rebuilding the server not gonna lie.

 

[Bitpalast]

Maybe. But if the infected files are all in the same webspace subscription, it is more likely that a process in that subscription is causing the problem. We've only ever seen it this way here. Unless a user would have disabled chrooting. So maybe removing and recreating the subscription will fix it (if and only if no files outside the subscription show signes of infection).