Модификация "eval( base64_decode ())" - Безопасность сайтов на Joomla

Недавно принял проект на Joomla! 3.4.1 Stable.
Сегодня обнаружил, что сайт не работает из-за проблем с файлом www\libraries\ClassLoader.php
Сравнив с файлом из git обнаружил, что добавилась php строчка в самом начале файла.
При первом осмотре стало очевидно, что это взлом, но из кода ничего не было понятно. Когда упростил/преобразовал код, то оказалось, что это вариация "eval( base64_decode ())" с передачей основного кода через POST.

Сверху почти первоначальный вид (было в одну строчку, я придал структурности). Снизу тот же код, но после преобразования.

Для тех, кто ищет поиском: основные участники кода: rwk28, 4edcs_toab6p, cdpm1, strtolower, sdf82, strtoupper, eval, n60302a.

Весь код сайта сейчас сравню с версией из git. Обновлюсь до последней версии. Пароли поменяю.

Но есть два вопроса:
1) Подскажете, пожалуйста, как проверить базу данных? Ещё не успел настроить резервное копирование, поэтому есть только одно сохранение БД месячной давности.
2) Ради чего делают эти атаки? Кража данных, распространение своего кода или ещё что-то? Просто чтобы знать: искать какой-нибудь код в БД или просто смириться, что у меня спёрли саму БД?

2) Ради чего делают эти атаки? Кража данных, распространение своего кода или ещё что-то?

Что угодно. Будет выполняться любая команда-значение параметра n60302a, которое передается через $_POST.

1)В первую очиредь имеет смысл проверить БД на подключение сторонних JS скриптов, так как на сегодняшний день есть бегдоры, которые при авторизованном админе могут делать реализацию, до запеси "БЕГДОРЫ" авторизованым админом, во вторую очиредь наличие PHP кода и его анализ...
2) такие атаки могут быть как целевыми, так и не целевыми, в инете куча инфы по этому поводу, гуглите, всего не распишешь...

robert, winstrool, спасибо, проверю.

Хотя опосля подумал...
На любой странице сайт выдавал ошибку "Fatal error: Namespace declaration statement has to be the very first statement in the script in  \www\libraries\ClassLoader.php on line 9".
Исходя из этого прихожу к выводу, что взлом был сделан автоматическим ботом. Иначе человек увидел бы, что код не работает. Ошибкой было место вставки кода: девятая строчка "namespace Composer\Autoload;" возмутилась, что она не первая команда, поэтому сайт вообще отказался работать. Соответственно, если взлом был с помощью бота, то значит отправленный на следующем этапе POST-запрос просто не сработал.

Всё-равно полностью проверюсь. Но очень надеюсь на такую криворукость или недальновидность взломщика.

Техподдержка хостинга сообщила, что была рассылка спама с адресов:
/www/media/editors/test.php
/www/modules/mod_k2_user/ajax.php
/www/modules/mod_cmscore/mod_cmscore.php
/www/modules/mod_speedup/mod_speedup.php
/www/plugins/system/test.php
/www/plugins/vmpayment/klarna/klarna/api/transport/xmlrpc-3.0.0.beta/lib/xmlrpc.inc
/www/libraries/joomla/image/plugin.php
/www/libraries/joomla/base/ajax.php

Цель взлома ясна. Цели добились.

Техподдержка хостинга сообщила, что была рассылка спама с адресов:
/www/modules/mod_speedup/mod_speedup.php

И в соседней теме про этот модуль http://joomlaforum.ru/index.php/topic,198048.msg1599916.html#msg1599916

Всё-равно полностью проверюсь. Но очень надеюсь на такую криворукость или недальновидность взломщика.

Чисто из практической точки зрения готов помочь, пишите в ПМ!

Итог взлома:
19 ноября
изменено 60 файлов (в начале файла добавлена строка с вариацией "eval( base64_decode ())")
создано 15 файлов (внутри опять же вариация "eval( base64_decode ())")

20 ноября
созданы 5 файлов (внутри большой код с уходом в глобальные переменные. Подробно разбираться не стал)
созданы файлы модуля "xcalendar" (не стал код изучать)

Количество файлов пишу примерно, так как не считал. Файлы раскиданы по всей ширине и высоте структуры папок. Похоже, рандом работал.
Искал:
- сравнением по размеру папок с исходным кодом в Git;
- поиском по фразе "eval" (примерно 100 раз употребляется законно);
- ну, и под конец проверил куда в логах запросы долбятся.
Всё это вычистил. Теперь в логах вижу, что с разных IP всё-таки пытаются пробиться к большим файлам, созданным 20 ноября. Но в ответ получают HTTP-код 404.

В базе данных никаких изменений или чего-то вредоносного не нашёл.

Сайт обновили? А то в 3.4.1 есть уязвимости.

Сайт обновили? А то в 3.4.1 есть уязвимости.

Да. Всё последней версии.

Кстати, сегодня ночью прекратились запросы (к уже отсутствующим файлам) от взломщика. Значит всё в порядке, работаю в спокойном режиме.

Да. Всё последней версии.

Кстати, сегодня ночью прекратились запросы (к уже отсутствующим файлам) от взломщика. Значит всё в порядке, работаю в спокойном режиме.

Поставте снифер запросов к сайту и недельку по наблюдайте, вдруг уязвимый момент остался, через снифер и вычислите его, взломщик будет пытаться восстановить доступ...