Что увидел владелец
- на сайте появлялись записи и страницы с заголовками «Hacked by …»;
- в списке пользователей — администраторы, которых никто не создавал;
- часть таких записей была опубликована от имени настоящего администратора.
Как бот попал на сайт
На сайте стояло дополнение к Elementor Pro с конструктором форм. В его версии была известная уязвимость: обработчик формы принимал запросы от неавторизованных посетителей и позволял загрузить файл на сервер. Боты массово ищут сайты с этим плагином и загружают через него веб-шелл в папку uploads, а дальше создают администраторов.
Самое неприятное: плагин ничего не делал для сайта. Мы проверили все страницы и шаблоны — ни один элемент из него не использовался. Его поставили когда-то вместе с другими дополнениями и забыли.
plugins может остаться доступным напрямую, даже если плагин выключен в админке.Первая чистка и почему её не хватило
Первая чистка удалила веб-шеллы из uploads и чужих администраторов. Но через месяц их было уже около сотни, а страницы «Hacked by» создавались от имени главного администратора. Это значило, что на сайте остался код, работающий независимо от плагина.
Сверка ядра WordPress с официальными контрольными суммами показала:
- в глубине
wp-includes, в папке библиотеки шифрования, лежал посторонний файл с правдоподобным именем; - он был только для чтения, с подделанной датой изменения 2020 года и зашифрованным содержимым;
- шесть настоящих файлов ядра подключали его одной добавленной строкой.
Такая же схема встретилась нам на сайте аудиторской компании — подробно о ней в кейсе «Сайт взламывали пять раз подряд». Похоже, это один и тот же инструмент массового взлома.
Что сделали
- Удалили уязвимый плагин целиком, а заодно ещё несколько неактивных плагинов.
- Заменили всё ядро WordPress чистой копией той же версии с русским языковым пакетом и проверили контрольные суммы.
- Удалили чужих администраторов и записи, созданные от их имени.
- Сменили пароль базы данных и секретные ключи — все сессии завершились.
- Поставили защитный must-use плагин: запрещает создавать администраторов кому-либо, кроме администраторов; закрывает XML-RPC, список пользователей через REST и комментарии; ограничивает подбор пароля; присылает письмо при подозрительных действиях.
- Закрыли регистрацию и комментарии — на сайте федерации они были не нужны.
wp core verify-checksums без параметра --locale=ru_RU считает изменённым файл version.php. Это ложная тревога: он отличается в русской сборке. Сверяйте с той локалью, которая установлена.Как проверить свой сайт на такие плагины
- Откройте список плагинов и для каждого ответьте: где на сайте он работает? Если ответа нет — удаляйте.
- Особое внимание — дополнениям к Elementor, конструкторам форм, файловым менеджерам и плагинам импорта. У них чаще всего бывают уязвимости с загрузкой файлов.
- Проверьте
wp-content/uploadsна файлы.php— их там быть не должно. - Запретите выполнение PHP в
uploadsчерез.htaccess. - Если плагин платный и без обновлений — ищите замену. Устаревшая платная версия опаснее бесплатной актуальной.
Полный список мер — в чек-листе защиты WordPress.
Частые вопросы
Если плагин отключён, он безопасен?
Не всегда. Файлы плагина остаются на сервере, и некоторые из них можно вызвать напрямую по адресу. Надёжно только удаление.
Как узнать, что у плагина есть уязвимость?
Проверяйте базы уязвимостей WordPress (WPScan, Patchstack, Wordfence Intelligence) по названию плагина и версии. Наш сервис делает это автоматически для каждого сайта на подписке.
Почему после удаления плагина взлом продолжился?
Пока плагин был открыт, бот успел оставить на сайте собственный загрузчик в ядре WordPress. Закрыть дверь мало — нужно найти всё, что уже занесли внутрь.