Удалили заражённый файл, обновили плагины, проверили сайт — а через несколько секунд бэкдор появился снова. Именно такой случай разобрали специалисты Sucuri.

Исследователи назвали семейство вредоносного кода SC. Его главная особенность в том, что заражение живёт не в одном PHP-файле. Несколько компонентов дублируют друг друга и могут заново восстановить удалённые части.

Поэтому обычная схема «нашёл подозрительный файл — удалил — готово» здесь не работает.

Почему вирус возвращается после удаления

По данным Sucuri, полезная нагрузка была распределена как минимум по восьми точкам. Часть находилась в файлах WordPress, часть — в базе данных, а одна из копий могла храниться в System V shared memory на сервере.

Компоненты были связаны между собой так, чтобы выживший элемент мог восстановить остальные.

Например, если удалить обычный плагин, его могла вернуть копия из db.php. Если убрать один drop-in, восстановление могло произойти через код в теме. Даже после полной очистки файлов заражение могло вернуться из базы или памяти сервера.

Где именно прячется SC malware

В исследованном случае Sucuri обнаружила несколько типов точек закрепления.

• .user.ini с директивой auto_prepend_file;
• скрытые PHP-загрузчики в wp-content;
• wp-content/db.php;
• wp-content/advanced-cache.php;
• вставку в functions.php активной темы;
• копию вредоносного кода в mu-plugins;
• вторую копию в обычной папке plugins;
• копию полезной нагрузки в базе данных и shared memory.

Имена отдельных файлов могут отличаться, поэтому искать только один конкретный filename бессмысленно.

Почему advanced-cache.php особенно опасен

Файл advanced-cache.php загружается WordPress очень рано, когда включён WP_CACHE.

В разобранной Sucuri схеме этот компонент выступал как восстановитель. Он мог искать копию вредоносного плагина в нескольких местах, включая mu-plugin, обычную папку плагина, shared memory, ZIP-бандл и базу данных.

Нашёл живую копию — снова записал плагин на диск и подключил его.

Поэтому удалить только основной вредоносный plugin-файл недостаточно.

База данных тоже становится частью заражения

Одна из самых неприятных особенностей этой схемы — хранение полной полезной нагрузки в таблице options.

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

Это объясняет классическую ситуацию, когда после «полной» очистки подозрительные файлы внезапно появляются снова.

Вредоносный код может пережить очистку файлов и базы

Sucuri также обнаружила копию PHP-кода в System V shared memory.

Это уже память сервера, а не обычный файл WordPress. Если заражённый компонент умеет читать этот сегмент, он может восстановить код даже после удаления файлов и записи из базы.

На shared hosting ситуация дополнительно усложняется тем, что сегмент памяти может принадлежать другому системному пользователю, и владелец конкретного сайта не всегда сможет удалить его самостоятельно.

Зачем используется auto_prepend_file

Через .user.ini злоумышленник может назначить PHP-файл, который выполняется до основного скрипта при каждом запросе.

Это позволяет вредоносному загрузчику запускаться ещё до WordPress.

Есть и неприятный нюанс при очистке: значение auto_prepend_file может кэшироваться PHP. Если сначала удалить целевой файл, а директива ещё активна в кэше, PHP-запросы сайта могут начать падать.

Поэтому Sucuri отдельно подчёркивает важность порядка действий.

Бэкдор маскируется под обычный плагин

Вредоносная нагрузка присутствовала одновременно как must-use plugin и как обычный plugin.

Она могла скрывать себя из списка плагинов WordPress, из счётчиков и из интерфейса обновлений. Внешне папка при этом могла выглядеть как нормальный компонент с настройками.

То есть проверка только страницы «Плагины» в wp-admin не даёт уверенности, что на сайте нет такой закладки.

Команды могут приходить через публичную blockchain-инфраструктуру

В исследованном варианте SC malware использовал несколько публичных Ethereum RPC gateway для получения данных из smart contract.

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

Из-за этого блокировка одного конкретного домена не гарантирует остановку канала: в коде может быть сразу несколько запасных RPC endpoint.

Что умеет сама полезная нагрузка

По данным Sucuri, бэкдор собирал информацию о сайте, версиях WordPress и плагинов, активных темах и других параметрах окружения.

Он также мог:

• получать и устанавливать новый PHP-код;
• добавлять JavaScript на frontend;
• удалять или отключать security-плагины;
• создавать скрытого администратора;
• маскировать этого пользователя в wp-admin;
• восстанавливать удалённые компоненты заражения.

Для интернет-магазина инъекция JavaScript особенно опасна, потому что может затронуть checkout и данные, которые вводит покупатель.

Почему просто восстановить файлы из бэкапа может быть недостаточно

Чистая копия файлов полезна, но сама по себе она не удалит вредоносную запись из базы, shared memory, cron или database trigger.

Если точка закрепления остаётся активной, чистые файлы могут быть заражены снова сразу после первого запроса.

Поэтому при подозрении на подобную схему нужно рассматривать сайт, базу и серверное окружение как одну систему.

Порядок очистки здесь критичен

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

1. Нейтрализовать auto_prepend_file, не ломая PHP-запросы.
2. Удалить вредоносные данные из базы и shared memory.
3. Проверить cron и database triggers.
4. Найти и удалить скрытых администраторов.
5. За один проход убрать загрузчики, drop-ins, поддельные плагины и вставки в тему.
6. Снова просканировать сайт и следить, не появляются ли компоненты повторно.
7. Закрыть исходную точку входа и сменить скомпрометированные доступы.

Что проверить на WordPress-сайте

Главный вывод

Современное заражение WordPress может быть не отдельным файлом, а сетью взаимно восстанавливающих компонентов.

Если вредоносный PHP возвращается после удаления, бессмысленно удалять один и тот же файл снова и снова. Нужно найти источник восстановления и проверить не только wp-content, но и базу, cron, server memory и конфигурацию PHP.

Для профилактики полезно держать WordPress и расширения обновлёнными, ограничивать права, иметь независимые резервные копии и периодически проводить проверку безопасности WordPress.

Если заражение уже произошло и нужно разобраться с сайтом без полной переделки, можно начать с технической диагностики WordPress.

Официальный источник

Sucuri — SC WordPress Malware: A Self-Healing Mesh of Loaders, Drop-Ins, and a Blockchain-Controlled Backdoor