We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 33186
    • 17 Posts
    Quote from: chrisandy at Sep 17, 2014, 08:39 AM
    I just got asked to look at a crippled Modx site. I'm seeing the same hack with every .js file on the site affected with the script as mentioned by Yoman.

    It also gets mentioned here along with a possible clean-up script:

    http://blog.lux-medien.com/2014/09/how-to-fix-actermoto-and-its-edited-javascript-files/

    Is this a working solution to clean the site? (it's off course not the leak...)

    My websites are on a server with Modruid2 installed, is it possible this is the causing the problem?
      • 28107
      • 230 Posts
      Quote from: yoman at Sep 18, 2014, 09:50 AM
      Quote from: chrisandy at Sep 17, 2014, 08:39 AM
      I just got asked to look at a crippled Modx site. I'm seeing the same hack with every .js file on the site affected with the script as mentioned by Yoman.

      It also gets mentioned here along with a possible clean-up script:

      http://blog.lux-medien.com/2014/09/how-to-fix-actermoto-and-its-edited-javascript-files/

      Is this a working solution to clean the site? (it's off course not the leak...)

      My websites are on a server with Modruid2 installed, is it possible this is the causing the problem?

      I guess, the problem lies within MODX EVO. Different sites on different systems means it is very unlikely that your system is causing that.
        CONIN Werbeagentur . Köln
        http://www.conin.de
        • 36582
        • 463 Posts
        Again - if it's any help…

        I just found three '.gif' files in cgi-bin, containing trojans.
          Web site design in Nottingham UK by Chris Fickling http://www.chrisficklingdesign.co.uk
        • I have noticed that those files only appear in folders which are "more open" and writeable. Like "\assets" or "\core/cache" or "\core/export".

          By the way: How did you scan your site for trojans?
            • 36582
            • 463 Posts
            Zipped it, downloaded it, scanned it with ClamXav
              Web site design in Nottingham UK by Chris Fickling http://www.chrisficklingdesign.co.uk
              • 28173
              • 409 Posts
              In my case, I only found .php file.
              Yesterday I run a find with "<?php eval(base64_decode($_POST" string and delete all results.
              I will check if new hacked files come again in next days...

              But I didn't find any .js files
              Any tip to find them (maybe I don't have) ?
                • 36582
                • 463 Posts
                Just a bit more information…

                The .js files don't seem to get infected until around 60 days after the initial hack.

                By doing a search for files modified in the last ## days I found some .php files whose permissions were set at 200. That means they won't be easy to spot doing a 'normal' search.

                I didn't find any infected files older than 60 days.
                  Web site design in Nottingham UK by Chris Fickling http://www.chrisficklingdesign.co.uk
                  • 7159
                  • 5 Posts
                  I have the same issue with one of my sites. It was originally hacked a on 26th September 2014 when it was running 1.0.5, following this we wiped the server, deleted the database, installed Modx 1.0.14 and manually recreated the site.

                  Unfortunately it's just been hacked again, every .js file has been infected.

                  I'm chasing the hosts to help highlight where the attackers entered but so they aren't being much use.

                  This suggests there is definitely a vulnerability in 1.0.14 as this was a completely clean install less than 2 weeks ago.

                  • Could be an Evo issue. Could be an 1.0.14 issue. But without looking into the access log it is impossible to locate the attacking vector.

                    Another possible hole could be the shellshock issue discovered two weeks ago.

                    So first locate the time when the files are modified. A bit difficult if the file date is modified by the attacking script. The attached hashalert script could help you with that. Credits go to http://www.sitepoint.com/detect-hacked-files-via-cronphp/ – I just modified the sql file for MySQL, debugged the script and moved the configuration variables to top.

                    For the next days you should execute hashscan.php with a cron job hourly (or shorter if you want to check less lines in the apache access log) and detect when the script files are modified. If this happens, you could look into the apache access log and see what files are called there and look for suspicous lines. I could maybe help you with that.
                      • 7159
                      • 5 Posts
                      Thanks for the reply Jako.

                      I've been looking through the logs today and have put together some of the more interesting entries.

                      Before the cleanup and new install it appears /assets/plugins/qm/css/b247598be7.php was accessed regularly. After the cleanup there were still attempts to access this file even though it didnt exist on the server.

                      Following the new install the first hacked file to be accessed by the hackers appears to be /images/c404a14.php

                      I've attached the entries if you have a couple of minutes to take a look please?

                      Thanks