Recovering from a Hacked Site: Part 3

Part 3 of a 3-part series on recovering a MODX website after it has been compromised and keeping it safe in the future.

By Jay Gilmore  |  Updated: December 21, 2018  |  4 min read
Recovering from a Hacked Site: Part 3

This article is part 3 of a 3-part series on recovering a MODX website after it has been compromised and keeping it safe in the future.

Helpful Tips and Tactics from the MODX Community

The MODX Community has rallied to help provide advice and feedback about how to get their websites back to normal and keep them safe. The following is a collection of some of the useful tips shared in the MODX Community Slack and the MODX Community Forums.

A special thanks to @donshakespeare from the MODX Community Slack for compiling this list of resources and their recommenders.

Sucuri's website scanner, serverside scanner, and WAF

@opengeek, @forpur (swears by it), @zackw (uses it extensively on dozens of sites), and @andytough all laud Sucuri. We also use this at MODX in combination with the malware scanner below.

PHP Malware Scanner by scr34m

Recommended by @ifusiontt, @rthrash, and @jaygilmore, this is an actively maintained and updated project. We find it useful for finding and locating malicious files very quickly.

For servers with ssh access to the command line we do the following in your web root:

git clone https://github.com/scr34m/php-malware-scanner

Then from your web root run the following:

php php-malware-scanner/scan.php -kpt -e ico -e json -e js -e php -d /www/

The scanner outputs a report of suspected malicious files. You'll find that in a clean site there are false positives for MODX files in the Smarty directory (which is a templating language used in the Manager). Moreover, there may be other false positives for some Extras. If you’ve replaced the MODX core as part of the site recovery, this won't be an issue. If not, you can always compare the files on your site with those in the GitHub repository or a clean download of Revo of the same version.

Scanner AI-Bolit

@alroniks has used this to identify and remediate hacks on a variety of websites. We've not tried it, but it may be worth your consideration. @alroniks is a smart guy.

PHP Malware Finder

@Gareth finds PHP Malware Finder very useful in repairing sites. He’s also created a whitelist file to go with it that eliminates false positives for MODX 2.6.5 and frequently-used Extras.

Web Server Rules

@bezumkin has this as his standard modhost.pro hosting practice and has suffered no hack for years including the latest hack.

His key recommendation is to add a directory "PASSWORD [for] all three major folders: CORE, CONNECTORS, MANAGER, done!" See the example below:

@bezumkin's Nginx Web Config (from https://en.modhost.pro/help/nginx)

location ~* ^/(manager|core|connectors)/ {
    auth_basic "Restricted Access";
    auth_basic_user_file /home/yourlogin/.htpasswd;
    try_files               $uri $uri/ @rewrite;
    location ~ \.php$ {
        include         fastcgi_params;
        fastcgi_param   SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass    backend-yourlogin;
    }
}

For Apache Servers (with a simple .htaccess)

  • https://www.thesitewizard.com/apache/password-protect-directory.shtml
  • https://www.htaccesstools.com/articles/password-protection/
  • https://serverfault.com/questions/476443/apache-authentication-for-multiple-directories
  • https://davidwalsh.name/password-protect-directory-using-htaccess
  • https://www.virtualmin.com/documentation/tutorial/how-to-password-protect-directory
  • https://documentation.cpanel.net/display/1144Docs/Password+Protect+Directories (edited)

Protection and Vigilance

Protecting your website or that of your clients and customers requires vigilance and some good protective practices. You can use the Advanced distribution and rename the core and Manager directories (in MODX Cloud we block access to the core directory at the platform level). Developers can rely on the MODX API and xPDO to connect to databases and prevent SQL injections.

However, there is no 100% secure software and the surest protection from compromise is to upgrade as soon as upgrades are available.

Furthermore, if something ever does go wrong, daily site backups with retention a week or preferably longer can be indispensable for quick site repairs.

For upgrades, you’ll need to ask, "Can we do the upgrades, or is someone willing to pay to make sure they are?" For backups, you'll need to ask yourself. "Can my web host do this or help make it possible and is someone willing to pay for it?"

Web Application Firewalls (WAFs)

You can place a WAF in front of your site to prevent DDoS and Brute Force Attacks. WAFs also typically protect against volumetric DDoS attacks, too. While WAFs sometimes won’t be able to block zero-day attacks, they can prevent commonly known attacks from being successful. Sucuri, StackPath, Cloudflare, and Incapsula all offer DNS-based firewalls that are well-worth considering deploying in front of sites.

More in this Series

For more in the Recovering from a Hacked Site Series, you can read Part 1 on vigilance and how to identify a compromised MODX site, and Part 2 for practical details on how to recover from a compromise.