Кейс: как мы убрали вредоносный редирект WordPress (LiteSpeed Cache)

Сайт загородного комплекса отдыха на WordPress перенаправлял посетителей на сторонние сайты, в том числе с контентом для взрослых, но только тех, кто заходил со смартфона, через мобильный интернет и впервые, без cookies. Владелец и разработчики видели нормальный сайт, а Google Ads заблокировал рекламный кабинет, и клиент потерял деньги на рекламе. Причиной оказалась старая взломанная (nulled) копия плагина кеширования LiteSpeed Cache с известной уязвимостью. Мы нашли код в двух файлах из 32 000, вычистили сайт и закрыли дыру, а позже клиент переехал на нашу систему управления Atom.

Что видел клиент

Обычный сайт: админка работает, страницы открываются, у самого владельца никаких редиректов. При этом Google Ads заблокировал рекламный кабинет. Реклама остановилась, а бюджет, потраченный на клики, которые вели на вредоносный сайт, не вернуть.

Сложнее всего было воспроизвести проблему. С компьютера, с Wi-Fi, с телефона, на котором сайт уже открывали, редиректа не было. Он срабатывал только при трёх условиях одновременно:

• мобильное устройство;
• мобильный интернет, а не Wi-Fi;
• первый визит без cookies, то есть новый посетитель.

Так вредоносный код прячется намеренно: владелец сайта, администратор и разработчик почти всегда заходят из сохранённых сессий и с офисного Wi-Fi, поэтому ничего не видят. А новый покупатель из рекламы на смартфоне как раз и попадает под редирект.

Как мы нашли вредоносный код

Когда стало понятно, кого именно перенаправляет сайт, мы перешли от проверки в браузере к проверке сервера:

1. Определили дату взлома. Злоумышленники получили доступ примерно 20 апреля 2024 года.
2. Сравнили файлы с бэкапом. На старом сервере сохранилась резервная копия за 15 апреля, то есть ещё до взлома. Мы откатили сайт на неё и сравнили все 32 000 файлов со взломанной версией.
3. Нашли разницу в двух файлах. Вредоносный код был дописан в functions.php темы сайта и в самое начало системного wp-includes/js/jquery/jquery-migrate.min.js. Этот скрипт WordPress подключает почти на каждой странице, поэтому код выполнялся везде.
4. Проверили пользователей. В админке появился второй администратор wp-configuser, которого никто не создавал.

Подсказкой стала проверка недавно изменённых файлов. Но она сработала только тогда, когда мы уже понимали, что ищем: на сайте с десятками тысяч файлов «что-то изменилось» находит сотни совпадений.

Откуда взялся взлом

На сайте стоял LiteSpeed Cache, популярный плагин кеширования с более чем 5 миллионами установок. Это не подозрительный плагин, а нормальный продукт. Проблема в том, что на сайте стояла взломанная копия (nulled), скачанная со стороннего сайта, поэтому она никогда не обновлялась.

В версиях LiteSpeed Cache до 5.7.0.1 была уязвимость CVE-2023-40000. Она позволяла без авторизации вставить JavaScript в страницы админки. Разработчики исправили её в октябре 2023 года, а весной 2024-го началась массовая атака на сайты, которые не обновились: скрипт создавал нового администратора (как раз wp-configuser или wpsupp-user) и дописывал вредоносный код в файлы сайта. Об этой кампании в мае 2024 года писали исследователи WPScan.

То есть сайт взломали не из-за WordPress как такового и не из-за LiteSpeed Cache, а потому что копия плагина была пиратской и застряла на старой версии. Официальная версия плагина получила исправление ещё за полгода до атаки.

Почему Google Ads блокирует за такое

Google проверяет не только объявления, но и сайт, на который они ведут. Страница, которая перенаправляет посетителей на сторонние сайты через взломанный код, подпадает под правила Google Ads о злоупотреблении рекламной сетью. Для владельца сайта это выглядит несправедливо, ведь он сам пострадал. Но для Google это сайт, который вредит пользователям, и пока код на месте, реклама работать не будет.

То же касается поиска: скрытый редирект, который показывает людям не то, что видит Google, — это нарушение правил Google в отношении спама, а взломанные сайты Google отмечает в отчёте «Проблемы безопасности» в Search Console.

Что мы сделали

• Восстановили сайт из чистого бэкапа и перенесли его на новый сервер.
• Удалили вредоносный код и постороннего администратора.
• Убрали nulled-плагины. Во время проверки мы нашли ещё 18 мест в плагинах, которые могли служить бэкдорами (скрытым входом для повторного взлома).
• Добавили защиту от повторного взлома и передали клиенту отчёт о выполненных работах.

Почему клиент переехал с WordPress

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

В течение месяца клиент решил переехать на нашу систему управления Atom: одна оплата за разработку, без сторонних плагинов и без лицензий, которые нужно продлевать. Мы разработали новый сайт под ключ, результат есть в портфолио.

По состоянию на ноябрь 2026 года клиент на постоянном обслуживании. Сейчас мы разрабатываем для него CRM-систему под ключ и готовим сайт к старту SEO-продвижения.

Как проверить, не взломан ли ваш сайт

• Откройте сайт так, как новый покупатель: со смартфона, через мобильный интернет, в режиме инкогнито. Проверка с рабочего компьютера ничего не покажет.
• Просмотрите список администраторов в админке. Незнакомый аккаунт — точный признак взлома.
• Проверьте отчёт «Проблемы безопасности» в Google Search Console и статус сайта в Google Safe Browsing.
• Не ставьте nulled-темы и плагины. Их нельзя обновить, а часть уже содержит бэкдоры из коробки.
• Храните бэкапы вне основного сервера. В этом кейсе именно копия на старом сервере позволила точно найти изменённые файлы.

Если реклама вдруг отклонена из-за «взломанного сайта» или клиенты жалуются на странные переходы, напишите нам. Расследование и чистку мы делаем в рамках обслуживания сайтов.