Исследователи Sucuri разобрали заражение WordPress, где атакующие не просто залили бэкдор, а раскидали его по восьми местам сразу: по файлам, по базе данных и по разделяемой памяти. И каждое из этих мест умеет восстановить все остальные. Удаляете плагин, его переписывает drop-in. Удаляете drop-in, его переписывает тема. Вычищаете все файлы на диске, и следующая же загрузка страницы поднимает весь набор обратно из базы или из сегмента памяти. Получается замкнутая система, у которой нет одной точки, убрав которую, можно всё остановить.

Бэкдор назвали SC по маркерам SC_ в инжектированном коде. Sucuri описывает его как самовосстанавливающуюся сеть под управлением через блокчейн. Для владельца сайта вывод простой и неприятный: привычная чистка «нашёл заражённый файл, удалил» против такого не работает.

Почему обычная чистка бесполезна

Суть угрозы не в отдельном вредоносном файле, а в том, что копии бэкдора лежат в принципиально разных местах, и пока жива хотя бы одна, она отстраивает остальные на следующем же запросе. Главная ловушка — это разделяемая память. На серверах с поддержкой System V shared memory пейлоад пишется в сегмент с фиксированным числовым ключом. Этот сегмент живёт в оперативной памяти, поэтому переживает и удаление файлов, и чистку базы, а на шаред-хостинге может вообще принадлежать другому аккаунту. Вы вычистили диск и базу — а бэкдор молча сидит в RAM и ждёт.

Читаемых имён функций в коде нет, вместо них декодер расшифровывает всё подстановочным шифром, так что глазами по коду заражение не найти. Вот восемь компонентов, из которых собрана эта сеть.

.user.ini ставит auto_prepend_file, чтобы загрузчик запускался перед каждым PHP-запросом во всём дереве каталогов.
wp-content/c1b12371.php — это загрузчик, который подключает скрытый файл с точкой в начале имени, если тот лежит рядом.
wp-content/.c1b12371.php — это тот самый скрытый файл, загрузчик первой стадии: находит фейковый плагин и пересобирает его в mu-plugins из трёх источников (копия в папке плагинов, закодированный кусок в каталоге кэша и ZIP-архив со случайным hex-именем).
wp-content/db.php подгружается при старте WordPress и несёт весь пейлоад в сжатом Base64. Декодирует и разворачивает плагин заново, как только тот пропал или стал слишком маленьким.
wp-content/advanced-cache.php загружается до обычных плагинов, когда включено кэширование, и пересобирает плагин из пяти независимых источников: существующий mu-plugin, копия плагина, сегмент разделяемой памяти с PHP, ZIP-архив и база данных.
wp-content/themes/khorshidi/functions.php — это близнец db.php, вшитый в тему: тот же бэкдор, переписывает плагин каждый раз, когда его нет на месте.
wp-content/mu-plugins/hyper-engine-kit.php — это сам вредонос, установленный и как must-use плагин, и как обычный.
wp-content/plugins/hyper-engine-kit/hyper-engine-kit.php — это дубль того же пейлоада для подстраховки.

Что бэкдор умеет, когда запущен

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

С таким доступом оператор полностью владеет сайтом: может подтягивать произвольный JavaScript и инжектить его посетителям (скиммеры для карт или другой вредонос), выполнять PHP-код, отключать и удалять конкретные плагины. Командный канал спрятан внутри легитимной блокчейн-инфраструктуры, поэтому его не заблокируешь так же легко, как обычный C2-домен.

Отдельно про устойчивость через cron. Бэкдор регистрирует хуки планировщика, в том числе со случайными именами рядом с известным хуком-загрузчиком. Системный cron дёргает файл WordPress-крона, а не трафик посетителей, и по расписанию запускает переустановку. То есть даже сайт без посещений сам себя переинфицирует по таймеру.

Как это вообще попадает на сайт

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

Что с этим делать

Главная мысль: если на сайте хоть что-то похоже на SC, относитесь к нему не как к заражённому файлу, а как к заражённой системе. Чистка по одному файлу гарантированно проиграет циклу переустановки.

Снимите сайт с боя на время чистки. Пока PHP на сервере может выполняться, любой запрос поднимает бэкдор обратно. Чистить работающий сайт бесполезно.
Не забудьте про разделяемую память. Удаления файлов и чистки базы недостаточно. Сегмент System V shared memory с фиксированным ключом надо сбросить, иначе он переживёт всё остальное. На практике это означает перезапуск служб или перезагрузку, которые очистят эти сегменты.
Чистите все восемь мест разом, а не по очереди. Пока жива хоть одна копия (в теме, в db.php, в advanced-cache.php, в базе, в RAM), она восстановит остальные. Удалять надо одновременно, при остановленном выполнении PHP.
Проверьте точки, которые чистильщики пропускают: .user.ini, drop-in файлы (db.php, advanced-cache.php), functions.php темы, mu-plugins, скрытые файлы с точкой в начале имени, задачи cron со случайными именами, скрытые учётки администратора.
Самый надёжный путь — это пересборка из заведомо чистого состояния: свежая установка WordPress, переустановка плагинов и темы из официальных источников, перенос только проверенного контента и выверенной базы, а не попытка вылечить заражённый сайт на месте.
После восстановления смените всё: пароли администраторов, ключи и соли в wp-config.php, учётные данные базы, ключи API. И закройте точку первичного входа, иначе вернётся то же самое.

Заодно: активно эксплуатируют дыру в плагине wpForo

В ту же сводку попала высокосерьёзная SQL-инъекция без аутентификации в плагине wpForo Forum (CVE-2026-1581, 7.5 по CVSS). Она затрагивает все версии плагина вплоть до 2.4.14 включительно. По данным Previdian, с 3 июля 2026 замечено меньше 20 попыток эксплуатации с пяти уникальных IP-адресов из Болгарии, Швейцарии, Франции, США и Йемена. Попыток пока немного, но неаутентифицированная SQL-инъекция в форуме — это ровно тот класс дыры, через который на сайт и заезжают бэкдоры вроде SC. Если у вас стоит wpForo, обновляйтесь.

Вывод

SC — это напоминание, что современное заражение WordPress может быть не файлом, а системой. Один и тот же бэкдор размножен по drop-in файлам, теме, фейковому плагину в двух местах, базе и разделяемой памяти, командный канал спрятан в блокчейне, и с любой уцелевшей копии он переписывает себя на следующем же запросе. Против такого «нашёл и удалил» не работает в принципе. Работает только одновременная чистка всех копий при остановленном PHP и сбросе памяти, а надёжнее всего пересборка с нуля из чистого состояния с последующей сменой всех секретов и закрытием точки входа.

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