R
R
RomkaChev2014-11-14 15:48:24
PHP
RomkaChev, 2014-11-14 15:48:24

How to remove PHP:Decode-CY [Trj] virus?

Files with clearly malicious code began to appear on the server.
Avast says it's PHP:Decode-CY [Trj] in one case and PHP:SHell-HZ[Trj] in the other.
At the same time, spam began to be sent from the server on an industrial scale.
Manual removal of malicious files did not help.

Answer the question

In order to leave comments, you need to log in

2 answer(s)
A
Appp Zooo, 2014-11-14
@RomkaChev

revision.com/ai should help.

N
Nikita Gennadich, 2014-12-01
@Psychosynthesis

I have a similar problem.
Avast gives the following names:
PHP.Agent-MN
PHP.Decode-DJ
PHP.shell-HZ
I couldn't find exactly the loophole through which the server gets infected. Unfortunately, I don't have enough knowledge of PHP to understand how this malware works. I restored the files from an old backup and updated Joomla to the latest version - it didn’t help, literally after three hours the site’s performance was broken again, it pissed me off and I tried to dig deeper.
I found out that the malware creates (apparently) random files in the Joomla system folders, in which the contents of the main code of the virus are encoded. The encoding is not particularly abstruse, it can be either base64 or encoding with unix characters, however, since it turns out to be torn, the logic of work escapes me, and I’m too lazy to put everything together - Avast does not look for all the code for this rubbish, since obviously it’s not in all files contain malicious code. In addition, this brute knows how to mix parts of his code into joomla system files, which makes it difficult to find extra code. Among other things, it modifies the main index file of the site. As far as I understand it, it makes something like a launcher out of it, which launches something that collects the rest of the code together from the parts scattered throughout the directory. Also, even if the site does not use htaccess, the malware adds it to the site root.
Based on everything I've been able to find out, I think that at least some of the operations are done manually.
I haven't found a proper cure for this problem yet. However, I changed the rights to the folder in which the root directory of the site and the files in the root of the site are located - everywhere 0444.
I suspect that the jamb here is in the hoster's configuration, since there were attempts to change index.html even on a static site. However, apparently realizing that this would not give a result (the site is static), the changes were canceled.
However, one of the files contains unix commands, which suggests a vulnerability in the server configuration. Do you, by any chance, have a non-NIC-RU hosting?
It would be cool if someone could help deal with this infection. I saved some files for analysis.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question