Site hacked, though everything was uptodate

I’m posting this because I don’t have a clue why below happened, because everything was uptodate. Maybe more people are experiencing this?

A client’s site was hacked, while everything was uptodate (including PHP versions, etc.).
Visitors get redirected to a “You Are Today’s Lucky Visitor” spam site when approaching the site through the Google Business page in the Google search results. When approaching the site via the domain name nothing was wrong (or seemed wrong).

A scan gave these results:

‘/var/www/vhosts/website.nl/httpdocs/assets/bestanden/documenten/wcynluzp.php’

Known exploit = [Fingerprint Match] [PHP Shell [P1654]]

‘/var/www/vhosts/website.nl/httpdocs/assets/components/gallery/connector.php’

Known exploit = [Fingerprint Match] [PHP Injection Exploit [P0997]]

‘/var/www/vhosts/website.nl/httpdocs/assets/components/gallery/packages/hdevuurb.php’

Known exploit = [Fingerprint Match] [PHP Shell [P1654]]

‘/var/www/vhosts/website.nl/httpdocs/assets/components/redactor/qxtnpmwp.php’

Known exploit = [Fingerprint Match] [PHP Shell [P1654]]

‘/var/www/vhosts/website.nl/httpdocs/assets/components/sitedashclient/.d1caf546.ico’

Known exploit = [Fingerprint Match] [PHP Exploit [P1496]]

‘/var/www/vhosts/website.nl/httpdocs/assets/gallery/1/tabufoiv.php’

Known exploit = [Fingerprint Match] [PHP Shell [P1654]]

‘/var/www/vhosts/website.nl/httpdocs/core/components/captcha/lexicon/redyajmh.php’

Known exploit = [Fingerprint Match] [PHP Shell [P1654]]

‘/var/www/vhosts/website.nl/httpdocs/core/components/formit/test/ljrpamsk.php’

Known exploit = [Fingerprint Match] [PHP Shell [P1654]]

‘/var/www/vhosts/website.nl/httpdocs/core/components/gallery/index.class.php’

Known exploit = [Fingerprint Match] [PHP Injection Exploit [P0997]]

‘/var/www/vhosts/website.nl/httpdocs/core/components/versionx/pflperjq.php’

Known exploit = [Fingerprint Match] [PHP Shell [P1654]]

‘/var/www/vhosts/website.nl/httpdocs/core/components/wayfinder/configs/cssplay-dropdown.config.php’

Known exploit = [Fingerprint Match] [PHP Injection Exploit [P0997]]

‘/var/www/vhosts/website.nl/httpdocs/core/components/wayfinder/configs/cssplay-flyout.config.php’

Known exploit = [Fingerprint Match] [PHP Injection Exploit [P0997]]

‘/var/www/vhosts/website.nl/httpdocs/core/docs/etlftfha.php’

Known exploit = [Fingerprint Match] [PHP Shell [P1654]]

etc.

2 Likes

This is something that I would like to follow closely as well.

What is the modx version that you are running?
What are the extras that you are using and respective version?
What is the php version that you are using?
Are your .htaccess files blocking directory listing?
Are you allowing php shell extension on your environment?

This will help the devs, so they can also help you afterwards.

Cheers

MODX 2.7.2. PHP 7.3

Bootstrap 1.0.29-pl
Captcha 3.3.4-pl
FormIt 4.2.5-pl
Gallery 1.7.1-pl
getFeed 1.0.0-pl
getResources 1.6.1-pl
pdoTools 2.12.3-pl
ReCaptchaV2 3.2.1-beta1
Redactor 2.4.0-pl
SiteDashClient 1.3.1-pl
TinyMCE Rich Text Editor 1.3.3-pl
VersionX 2.2.2-pl
Wayfinder 2.3.3-pl

This is the htaccess:

# MODX supports Friendly URLs via this .htaccess file. You must serve web
# pages via Apache with mod_rewrite to use this functionality, and you must
# change the file name from ht.access to .htaccess.
#
# Make sure RewriteBase points to the directory where you installed MODX.
# E.g., "/modx" if your installation is in a "modx" subdirectory.
#
# You may choose to make your URLs non-case-sensitive by adding a NC directive
# to your rule: RewriteRule ^(.*)$ index.php?q=$1 [L,QSA,NC]

RewriteEngine On
RewriteBase /



# Rewrite www.domain.com -> domain.com -- used with SEO Strict URLs plugin
RewriteCond %{HTTP_HOST} .
RewriteCond %{HTTP_HOST} !^dezandbloem\.nl [NC]
RewriteRule (.*) https://website.nl/$1 [R=301,L]
#
# or for the opposite domain.com -> www.domain.com use the following
# DO NOT USE BOTH
#
#RewriteCond %{HTTP_HOST} .
#RewriteCond %{HTTP_HOST} !^www\.example-domain-please-change\.com [NC]
#RewriteRule (.*) http://www.example-domain-please-change.com/$1 [R=301,L]



# Rewrite secure requests properly to prevent SSL cert warnings, e.g. prevent 
# https://www.domain.com when your cert only allows https://secure.domain.com
RewriteCond %{SERVER_PORT} !^443
RewriteRule (.*) https://website.nl/$1 [R=301,L]



# The Friendly URLs part
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]



# Make sure .htc files are served with the proper MIME type, which is critical
# for XP SP2. Un-comment if your host allows htaccess MIME type overrides.

#AddType text/x-component .htc



# If your server is not already configured as such, the following directive
# should be uncommented in order to set PHP's register_globals option to OFF.
# This closes a major security hole that is abused by most XSS (cross-site
# scripting) attacks. For more information: http://php.net/register_globals
#
# To verify that this option has been set to OFF, open the Manager and choose
# Reports -> System Info and then click the phpinfo() link. Do a Find on Page
# for "register_globals". The Local Value should be OFF. If the Master Value
# is OFF then you do not need this directive here.
#
# IF REGISTER_GLOBALS DIRECTIVE CAUSES 500 INTERNAL SERVER ERRORS :
#
# Your server does not allow PHP directives to be set via .htaccess. In that
# case you must make this change in your php.ini file instead. If you are
# using a commercial web host, contact the administrators for assistance in
# doing this. Not all servers allow local php.ini files, and they should
# include all PHP configurations (not just this one), or you will effectively
# reset everything to PHP defaults. Consult www.php.net for more detailed
# information about setting PHP directives.

#php_flag register_globals Off



# For servers that support output compression, you should pick up a bit of
# speed by un-commenting the following lines.

#php_flag zlib.output_compression On
#php_value zlib.output_compression_level 5



# The following directives stop screen flicker in IE on CSS rollovers. If
# needed, un-comment the following rules. When they're in place, you may have
# to do a force-refresh in order to see changes in your designs.


ExpiresActive On
ExpiresByType image/gif A2592000
ExpiresByType image/jpeg A2592000
ExpiresByType image/png A2592000
ExpiresByType text/css A2592000
ExpiresByType application/javascript A2592000
ExpiresByType application/x-javascript A2592000
ExpiresByType text/javascript A2592000
BrowserMatch "MSIE" brokenvary=1
BrowserMatch "Mozilla/4.[0-9]{2}" brokenvary=1
BrowserMatch "Opera" !brokenvary
SetEnvIf brokenvary 1 force-no-vary


AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript

Don’t know about php shell.

You can use three back ticks on new lines before and after your code to make code blocks. Otherwise it’s impossible to tell what you really have in your code as the forum strips and replaces characters that aren’t within the code block.
You should be able to edit your existing posts and just add the back ticks on new lines.

There’s nothing stripped, except for hashtags. A hashtag in this forum renders a bigger font.

BWT: SiteDash is monitoring this site, and I did not get any warnings or preventative measures.

Since some hashtags have been stripped and others haven’t, the way your htaccess file is displayed now it’s tough to tell which rules are commented out and which aren’t…

The lines with hashtag are commented out. The big font is comments.

Please just put three backticks --> ` before and after your .htaccess code so we can read things properly. If you want help, you might as well accept it :slight_smile:

1 Like

I’ve not heard of any vulnerabilities in the core nor the extras you list. Gallery would be my top candidate as that was the cause for the most recent flurry of hacks, but that was patched with v1.7.1 so you should be in the clear. If this hack is the result of an as of yet unknown issue in MODX or an extra, congratulations on being the first to report it :wink:

Looking at the list of files that you list, it seems the attacker managed to infect a whole bunch of files, making that list of files useless in terms of figuring out the source.

The access logs and timestamps on files are now your next step to try to find out when and how this hack occurred. Sometimes timestamps on edited or created files can help pinpoint the exact time, but with sufficient access to the site those can also be masked, so don’t rely solely on that.

Try correlating the assumed time against the access logs and start scouring through them for any non-standard requests. POSTs to files that would not typically be accessed, long query strings, etc.

I’d be interested in seeing what you find there to help make sense of it, but it’s best not to post that raw on the forum. Hackers are also looking, so if you find anything that might look like an as-of-yet unknown vulnerability, please responsibly disclose that to security@modx.com.

It’s most likely that your site had been previously hacked before upgrading to the latest version, and a backdoor was left behind and laid dormant until recently. We’ve seen that dozens if not 100s of times.

We’ve found phpMalwareScanner to be really useful. Let it scan every file, not just .php files. Payloads are often found in hidden files starting with a dot, or .ico files (and I see you have one of those in your list above … delete it). I bet you have a few more malicious files laying around.

There’s a couple of legit PHP files there that have been modified, and a lot of nonsense-named PHP files that are purely backdoors/shells. Fix the legit files and nuke the backdoors.

If you’re stuck getting it cleaned up, drop a line to help@modx.com and we can offer some options.

2 Likes

Also, delete all old package versions for any extras, which is a lot easier thanks to 2.7.2, and needless to say upgrade to the latest version of all Extras if they’re not already.

I skipped through old fysical backups and found out that this hack must have found place somewhere in 2018. All this time it was unnoticed. Back then I wasn’t using SiteDash, Patchman, etc. But even now those monitoring tools did not find the hack.

My new question is: would the database be intact/not hacked? It would be much simpler if I could only replace the files.

1 Like

It’s always a gamble. If you are going that method, check your plugins to make sure nothings been altered and reset all the user passwords/site passwords. It might make sense to just rebuild this site in a fresh install and point the domain to the new site. That is usually how we handle these. Only move over resources and necessary elements, then reinstall any of the previously installed extras.

Only move over resources and necessary elements

That’s my biggest challenge. Not sure how to do that.

To be honest, if you just create a clean install of the MODX instance using the same version, you should be able to just overwrite the database it creates with a copy of your existing database. A lot of times if I do that, I will also bulk disable all the plugins in the modx_site_plugins table on the new database to prevent any issues.

After that, go into your package installer on the new site, delete all the Extras it shows listed, and re-download them.

Yes, that’s what’s probably best. But the question remains if the database is clean/not hacked.

How do you bulk disable the plugins through PHPmyAdmin?

Ok, I tried a fresh install (on a different domain name, same MODX version), imported the database and copied the /assets folder through FTP.

Both website and manager are blanc. What did I do wrong?

Do you have any errors in the browser JS console?

Nothing at all.

Is there any instruction on how to do this? It’s getting quite frustrating after several attempts.