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

По оценке исследователей, под удар попали около 1,98 тыс. WordPress-сайтов. Схема оказалась необычной: атакующий прятал управляющие данные в невидимых символах Unicode, а потом собирал из них адрес вредоносного скрипта.

Какую проблему решаем

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

Для бизнеса вывод простой: защищать нужно не только сам сайт, но и учетные записи, плагины, темы, FTP/SFTP-доступ и журналы исходящих соединений. Если злоумышленник получил хотя бы один из этих ключей, дальше он часто действует быстро и почти без шума.

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

Что подготовить

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

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

Пошаговые действия

один. Проверьте точки входа

Начните с учетных записей администратора, FTP/SFTP и почтовых ящиков, связанных с сайтом. Если кто-то использовал украденный пароль, малварь часто возвращается через тот же канал.

два. Ищите следы постороннего JavaScript

Исследователи указывают на неожиданные внешние скрипты и обращения к подозрительным доменам. В этом случае отдельно настораживают загрузки JS-файлов с именами, похожими на библиотечные, но не совпадающими с ними.

три. Проверьте исходящие соединения

Обратите внимание на обращения WordPress-сервера к внешним ресурсам, включая необычные запросы к Steam Community. Нормальный сайт не должен «разговаривать» с такими сервисами ради работы фронтенда.

четыре. Ищите скрытые символы и странные кеш-записи

В кампании использовали шесть невидимых символов Unicode. Если в базе или шаблонах есть похожие конструкции, это повод для ручной проверки: обычный просмотр в редакторе их не покажет.

пять. Сверьте поведение с журналами

Насторожить должны POST-запросы с нестандартными параметрами, необычные cookie и отключенная проверка SSL в cURL-запросах. Еще один маркер — записи, где система сама отключает логирование или пытается замаскировать вызовы стандартных API WordPress.

Если вы работаете из чужой сети, дополнительный слой защиты трафика может быть полезен как часть цифровой гигиены. Например, частный канал для рабочих сессий имеет смысл рассматривать вместе с менеджером паролей и 2FA, а не вместо них.

Как проверить себя

После очистки сайт должен перестать тянуть внешний JavaScript из неизвестных доменов. Логи не должны показывать обращения к подозрительным профилям, а в коде страниц не должно оставаться скрытых Unicode-вставок и чужих скриптов.

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

Здесь полезно помнить и о смежных рисках. Например, атаки через расширения и плагины часто выглядят как обычная ошибка сайта, хотя на деле запускают цепочку заражения — об этом у нас есть разбор Уязвимость WP Maps Pro позволяет создать админов на WordPress-сайтах.

Что делать, если не получилось

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

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

Практический чек-лист

  • Проверить админов, FTP/SFTP и почту, связанную с сайтом
  • Сравнить файлы сайта с чистой резервной копией
  • Найти внешние JS-загрузки и подозрительные домены в логах
  • Просмотреть базу на скрытые Unicode-символы и странные кеш-записи
  • Проверить исходящие запросы WordPress-сервера к внешним ресурсам
  • Обновить WordPress, темы и плагины после очистки
  • Сменить пароли и включить 2FA для всех админов
  • Восстановить сайт из чистого бэкапа, если ручная чистка не уверена
Поделиться: