Бэкдор SC восстанавливает себя в WordPress из файлов, БД и памяти

Исследователи Sucuri обнаружили бэкдор SC в скомпрометированных сайтах WordPress. Вредоносный код размещается как минимум в восьми точках: в файлах, базе данных и сегменте разделяемой памяти System V. Каждая сохранившаяся копия способна заново развернуть остальные, поэтому удаления одного плагина или очистки файлов недостаточно.
Как устроено самовосстановление
Название SC связано с маркерами «SC_» во внедрённом содержимом. Sucuri называет схему «самовосстанавливающейся сеткой»: у неё нет единственной точки, удаление которой прекращает работу бэкдора.
Цепочку запускает файл .user.ini, задающий PHP-параметр auto_prepend_file для выполнения загрузчика перед каждым PHP-запросом в соответствующем дереве каталогов. Загрузчик wp-content/c1b12371.php подключает скрытый файл с точкой в начале имени.
Скрытый загрузчик ищет поддельный плагин и восстанавливает его в каталоге must-use plugins из существующей копии, закодированной заготовки в кэше либо ZIP-архива со случайным шестнадцатеричным именем. В wp-content/db.php находится полный полезный код в сжатом формате Base64: он декодируется и повторно размещает плагин, если тот отсутствует или слишком мал.
Резервные копии в компонентах WordPress
Файл advanced-cache.php, который WordPress загружает до обычных плагинов при включённом кэшировании, собирает вредоносный плагин из пяти независимых источников. Среди них уже установленный must-use plugin, обычная копия плагина, ZIP-архив, база данных и сегмент System V shared memory. Затем код подключает его через обработчик plugins_loaded.
Ещё одна копия присутствует в functions.php темы khorshidi. Сам бэкдор дублируется как must-use plugin hyper-engine-kit.php и как обычный плагин hyper-engine-kit/hyper-engine-kit.php. Понятнее оценить риск помогает переход от комментария к выполнению кода на сервере WordPress, где описан переход от уязвимого комментария к выполнению кода на сервере WordPress.
На серверах с поддержкой System V вредонос записывает PHP-код в сегмент памяти с фиксированным числовым ключом. Такой сегмент существует в оперативной памяти и, как отмечает Sucuri, сохраняется после удаления файлов и очистки базы. В среде shared hosting он также может принадлежать другой учётной записи.
Что способен делать оператор
SC скрывает себя в списке плагинов административной панели и при проверке обновлений. Для связи с управляющим сервером он использует Ethereum, собирает характеристики заражённого сайта и загружает дополнительные полезные нагрузки. В числе заявленных возможностей — создание скрытой учётной записи администратора, выполнение PHP-кода, отключение или удаление выбранных плагинов и загрузка произвольного JavaScript для атак на посетителей, включая скиммеры.
Вредонос также регистрирует задания cron с известным и случайными именами. Системный cron запускает файл WordPress cron и по расписанию инициирует повторное развёртывание. Способ первоначального проникновения в этом случае не установлен. Sucuri перечисляет типичные векторы: известные уязвимости WordPress, плагинов и тем, слабые пароли, компрометацию цепочки поставки и небезопасную загрузку медиафайлов или форм.
Практический вывод
При расследовании такого инцидента бизнесу недостаточно удалить подозрительный плагин. Нужно проверить загрузочные файлы и drop-in-компоненты, активную тему, базу данных, каталоги обычных и must-use плагинов, задания cron и разделяемую память сервера. После очистки необходимо установить причину первоначального доступа и сменить затронутые учётные данные, иначе восстановленная или новая копия бэкдора может вернуться.

