Site hacked with script injection. how to fix?

I've had several sites hacked with this new script injection before they were upgraded to 2.6.5 now even though they have been upgraded & the gallery plugin updated as well... the hack still comes back.

index.php files in the root, manager and connectors folders all have a similar encoded bit at the top:



(what is that encoded with anyway?)

In only one of the sites (there are about 6) did I find a suspicious plugin or snippet, and only one of them had extra files in the assets.images directory.

is there a list of checksums for the modx distribution files that I can use to find other altered files?

how can these sites be 'cleaned'?

On decoding above path, it gives "/var/www/vhosts/[replaced]/httpdocs/assets/fonts/.d34d02e3.ico" Remove this file but dont think that malware is cleaned its just a honeypot to make us believe that its cleaned. Best idea is to follow this tutorial https://docs.modx.com/revolution/2.x/administering-your-site/security/hardening-modx-revolution, it basically suggests to rename core folders like core, connectors, manager. password protecting them.

We moved our core folder outside of puclic_html directory.

Quote from: amitpatil at Aug 30, 2018, 08:47 AM

On decoding above path, it gives "/var/www/vhosts/[replaced]/httpdocs/assets/fonts/.d34d02e3.ico" Remove this file but dont think that malware is cleaned its just a honeypot to make us believe that its cleaned. Best idea is to follow this tutorial https://docs.modx.com/revolution/2.x/administering-your-site/security/hardening-modx-revolution, it basically suggests to rename core folders like core, connectors, manager. password protecting them.

We moved our core folder outside of puclic_html directory.

most of the sites were hardened anyway - following that after the fact will not fix the problem nor would it have prevented it in the first place. (it was a vulnerability in gallery/phpthumb)

seems like whatever file(s) got compromised they are still there after an update and updating/reinstalling any plugins

so what is that line encoded with?

Quote from: sean69 at Aug 30, 2018, 02:47 PM

Quote from: amitpatil at Aug 30, 2018, 08:47 AM

On decoding above path, it gives "/var/www/vhosts/[replaced]/httpdocs/assets/fonts/.d34d02e3.ico" Remove this file but dont think that malware is cleaned its just a honeypot to make us believe that its cleaned. Best idea is to follow this tutorial https://docs.modx.com/revolution/2.x/administering-your-site/security/hardening-modx-revolution, it basically suggests to rename core folders like core, connectors, manager. password protecting them.

We moved our core folder outside of puclic_html directory.

most of the sites were hardened anyway - following that after the fact will not fix the problem nor would it have prevented it in the first place. (it was a vulnerability in gallery/phpthumb)

seems like whatever file(s) got compromised they are still there after an update and updating/reinstalling any plugins

so what is that line encoded with?

Did you revert the back-ups?

Quote from: stefany at Aug 30, 2018, 06:46 PM

Did you revert the back-ups?

Some of them were pretty static & I was able to delete everything and restore, because this script/exploit writes extra files 'restoring over' an existing site will not do the trick - you have to delete everything and restore fresh. these remaining sites change enough that a wipe & restore are not an option.

I a daily incremental backup with a 90 day history - so there was that, but it doesn't have any sort of file diffing tools that I could use to isolate the new and modified files.

What I can say so far is that it looks like 2 different exploits - only one of the sites had any snippets or chunks added &/or modified (which was fairly easy to find - just look in the database table & look for the last id

I think I am going to have to download a clean copy of modx, the extras & create checksums from there then test the live files If I can eliminate distribution files then at least there is a step.

One thing I am also seeing is an index file being written to pretty much every directory in the site(s) with an include as well. replacing that with an index.php set to 0000 permissions (or root:root ownership) seems to be working (so far) but it certainly hasn't removed the exploit.

What is that include encoded with?? how can I decode it?

Quote from: sean69 at Aug 30, 2018, 07:01 PM

Quote from: stefany at Aug 30, 2018, 06:46 PM

Did you revert the back-ups?

Some of them were pretty static & I was able to delete everything and restore, because this script/exploit writes extra files 'restoring over' an existing site will not do the trick - you have to delete everything and restore fresh. these remaining sites change enough that a wipe & restore are not an option.

I a daily incremental backup with a 90 day history - so there was that, but it doesn't have any sort of file diffing tools that I could use to isolate the new and modified files.

What I can say so far is that it looks like 2 different exploits - only one of the sites had any snippets or chunks added &/or modified (which was fairly easy to find - just look in the database table & look for the last id

I think I am going to have to download a clean copy of modx, the extras & create checksums from there then test the live files If I can eliminate distribution files then at least there is a step.

One thing I am also seeing is an index file being written to pretty much every directory in the site(s) with an include as well. replacing that with an index.php set to 0000 permissions (or root:root ownership) seems to be working (so far) but it certainly hasn't removed the exploit.

What is that include encoded with?? how can I decode it?

^^ As Amit suggested, try hardening your fresh installation and move it to another server if you can. If that doesn't stop it, maybe you have snippets that are being exploited. Review them.

My sites have been hacked.

Strange index(dot)php files are inserted in many directories and they reappear again and again.
I found strange lines of code in the .htaccess files and deleted these lines. However the php files still reappear.

This line is injected in the upper part of all my index.php files:
/*0d3db*/@include "\057var\057www\(a lot more...)/*0d3db*/

In the filemanager at the Webhost there are some files which I would like to ask if anyone here can see are
supposed to be there:

The filenames are:
.bash_logout
.bash_profile
.bashrc


[ed. note: evalykke last edited this post 5 years, 2 months ago.]

My site and subsites have been hacked and now I can't log into the main manager.
Error log says:
2019-02-02 00:03:16] (ERROR in modMenu::getSubMenus @ /var/www/my.domain/public_html/core/model/modx/modmenu.class.php : 145) modAction support is deprecated since version 2.3.0. Support for modAction has been replaced with routing based on a namespace and action name. Please update the extra with the namespace core to the routing based system.

I've updated the packages core and core.transport via ftp - however the problem remains. Can anyone explain (step by step please - I'm not a pro) how to solve this?

@Sean Kimball:

I run a daily incremental backup with a 90 day history - so there was that, but it doesn't have any sort of file diffing tools that I could use to isolate the new and modified files.

It's still labor intensive, but you might find this interesting as a large-scale diffing tool: https://bobsguides.com/blog.html/2018/09/20/comparing-things-in-phpstorm-iii/. It compares whole directories showing files that are in one and not the other. When two files exist, but are not the same, you can click to see the differences.

@evalykke: That error message is "normal" in MODX 2.7.0 and probably doesn't have anything to do with your problems.

Do you have a backup of the site from before the hack?

Quote from: BobRay at Feb 26, 2019, 06:37 PM

@Sean Kimball:

I run a daily incremental backup with a 90 day history - so there was that, but it doesn't have any sort of file diffing tools that I could use to isolate the new and modified files.

It's still labor intensive, but you might find this interesting as a large-scale diffing tool: https://bobsguides.com/blog.html/2018/09/20/comparing-things-in-phpstorm-iii/. It compares whole directories showing files that are in one and not the other. When two files exist, but are not the same, you can click to see the differences.

@evalykke: That error message is "normal" in MODX 2.7.0 and probably doesn't have anything to do with your problems.

Do you have a backup of the site from before the hack?

interesting , but still requires a clean copy to diff.... what we need is some kind of tool that can diff from ~ say ~ the modx repo on github ... but that still leaves us with a myriad of extras and diffing does nothing to address database records.

I am using ImmunifyAV on my server & it has done a pretty good job of detecting these infected files, a few false positives, but does nothing for the database. Finding the files is no problem, finding the script or code that is writing them is the issue. So far I have seen nothing posted about that other than it may be Gallery or thumbof or phpthumb or something like that....


A useful extra would be something that sends an alert if a new snippet, chunk, template or TV are written to the database. (and lock it down until it is reviewed)