Some of my MODx Evo 1.0.15 are hacked

Hi,

I participated to this topic : http://forums.modx.com/thread/93126/some-of-my-modx-1-0-14-are-hacked?page=8#dis-post-516184

The uptade to 1.0.15 was solved the problem, but it just reappered.

Here the files which change last 20 days on one of the hacked website :

# find . -mtime -20 -ls
537096 4 drwxr-x--- 4 vu2104 vu2104 4096 févr. 13 01:16 .
537486 4 drwxr-xr-x 2 vu2104 vu2104 4096 févr. 7 17:44 ./assets/snippets/ditto/lang
537484 4 drwxr-xr-x 2 vu2104 vu2104 4096 févr. 7 17:54 ./assets/snippets/ditto/extenders
537112 4 drwxr-xr-x 3 vu2104 vu2104 4096 févr. 12 03:19 ./assets/templates/modxhost
539607 8 -rw-r----- 1 vu2104 vu2104 5057 févr. 12 03:19 ./assets/templates/modxhost/main.css
537283 4 drwxr-xr-x 4 vu2104 vu2104 4096 févr. 7 17:44 ./assets/plugins/tinymce/jscripts/tiny_mce/plugins/paste
537226 4 drwxr-xr-x 2 vu2104 vu2104 4096 févr. 7 15:49 ./assets/plugins/tinymce/tiny_mce/plugins/xhtmlxtras/langs

But attention : there are other files added which very older dates.
For example, the main php malware is set in a /template.php file, and was "created" the 11 november 2014 and I'm very suspicious that these dates are real.

If need, I will keep theses files for case studie. Just ask.

For now, I go to delete manually those bullshit because my server is loading hard...

In my case, I'm searching all files on my server which contain one of these chain :

• ="stop_"
• eval(base64_decode($_POST[
• =strtoupper(

And I delete after I'm sure is a malware (there can be false positive but not too much) [ed. note: Spheerys last edited this post 9 years, 2 months ago.]

File dates could be changed by PHP with http://php.net/manual/en/function.touch.php if PHP has write access to that file. Most of the hacks don't change the file dates, so they are easier to detect. Some do. You can't be sure with the file date.

One thing that the attackers cannot change is the Apache access log (if they can, you and your provider have lost long before BTW). So the best way to track down what happened during/after a successful attack is to look what URI is called before a suspicious file is created/updated (at that time it is better to have a file with the real date). If the file date of that file is 'touched', you have to check with Apache access log when it was created (you can't use updated files for that check). Apache access log shows a 404 for files that don't exist and 200 for existing files (maybe any status you could set by PHP could be returned – so don't be sure with that – since the attacker wants to know if the attack is successful it has to be different from 404).

If you have located a time range of a not existing/existing file, you have to look what URI are called in that time range and you could locate one attacking vector to your installation. It is maybe not the only one.