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

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

Что сделать в первые 30 минут

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

1. 01
   Зафиксируйте время и часовой пояс, адрес проблемной страницы, условия появления симптома, скриншоты и сообщения сканера. Запишите, какие файлы уже удаляли и какие действия предшествовали возвращению проблемы.
2. 02
   Сохраните файлы, базу данных и доступные журналы в защищённом месте вне публичной папки сайта. Пометьте копию как заражённую: она нужна для анализа и не считается чистой резервной копией.
3. 03
   Ограничьте посторонний доступ к панели WordPress, хостингу и средствам управления сервером. При захвате аккаунта восстанавливайте контроль вместе с провайдером через доверенное устройство.
4. 04
   Проверьте, затронуты ли другие сайты, почта и интеграции в том же аккаунте. Для дальнейшего исследования подготовьте изолированную копию с контролируемым выполнением кода и сетевыми подключениями.
5. 05
   Составьте список доступов для отзыва и перевыпуска: WordPress, панель хостинга, SSH/SFTP, база данных, почта, ключи API. Секреты, которые могли быть раскрыты во время очистки, потребуется заменить в доверенной среде.

Как отличить повторное заражение от старых симптомов

Время и условия возвращения проблемы помогают выбрать первую проверку. Сами по себе они не доказывают определённый механизм.

Если сохранилось только неправильное отображение страницы, сравните ответ исходного сервера и кеширующих слоёв с помощью администратора или поддержки. После фиксации симптомов очистите соответствующий кеш и повторите проверку. Возвращение файла на диске или вредоносной записи в БД требует отдельного расследования; кеш браузера такого изменения не объясняет.

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

Почему WordPress заражается снова

Проверка через панель хостинга без SSH

Владелец сайта может собрать сведения через файловый менеджер, phpMyAdmin и раздел запланированных заданий. Начинайте с сохранённой копии. В файловом менеджере включите показ скрытых файлов, иначе .user.ini и .htaccess могут быть не видны.

• Запишите имя, путь и время изменения возвращающегося файла. Сохраните его для проверки, не открывая через URL.
• Просмотрите корневой каталог и wp-config.php, папку wp-content/mu-plugins, специальные файлы в wp-content и пользовательские загрузки. Сначала выясните происхождение неизвестных объектов.
• Проверьте список пользователей и задания в панели хостинга. При подозрении на скрытого администратора передайте специалисту копию БД: список внутри WordPress может быть подменён.
• Найдите старые установки и тестовые поддомены. Уточните, какие из них используют тот же аккаунт и могут записывать файлы основного сайта.
• Сохраните названия и версии тем и плагинов, сведения об обновлениях и использованной резервной копии.

Где искать источник повторного заражения

Проверяют происхождение файла, его содержимое и способ запуска. Специальные файлы WordPress, называемые drop-in, подключают отдельные функции, например кеширование или работу с БД. Они могут принадлежать законному плагину или хостингу.

Пошаговая диагностика для администратора

Команды ниже предназначены для проверки собственного сайта. Примеры shell-команд рассчитаны на Linux и выполняются из корня установки WordPress. Путь и префикс таблиц нужно сверить с конкретной установкой. Команды не выполняют автоматическую очистку.

wp core verify-checksums

wp plugin verify-checksums --all

find wp-content/uploads -type f \
  \( -iname '*.php' -o -iname '*.phtml' \) -print
find wp-content/mu-plugins -maxdepth 2 -type f -print
find wp-content -maxdepth 1 -type f \
  \( -name 'db.php' -o -name 'advanced-cache.php' \
  -o -name 'object-cache.php' \) -print

grep -RIn -E 'auto_prepend_file|auto_append_file' \
  --include='.user.ini' --include='php.ini' \
  --include='.htaccess' .

find wp-content -type f -name '*.php' -mtime -7 -print

SELECT ID, user_login, user_registered
FROM wp_users
ORDER BY ID DESC;

SELECT option_name, LENGTH(option_value) AS size_bytes
FROM wp_options
ORDER BY size_bytes DESC
LIMIT 30;

wp cron event list --fields=hook,next_run_gmt,recurrence

Как удалить заражение и восстановить сайт

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

1. 01
   Определите границы инцидента. Установите, затронуты ли только файлы сайта или также БД, соседние проекты, аккаунт хостинга и сервер.
2. 02
   Остановите обнаруженные способы запуска. Учитывайте ранние подключения PHP, обязательные плагины, тему и фоновые задания. Для магазина заранее согласуйте порядок обслуживания и сохранения текущих заказов.
3. 03
   Удалите связанные компоненты и хранилища вредоносного кода. Одновременно проверьте записи БД, неизвестные аккаунты и задания. При подтверждённых признаках закрепления в общей памяти или системных процессах подключите администратора сервера.
4. 04
   Восстановите компоненты из доверенных источников и закройте выявленные уязвимости. Не переносите неизвестные файлы и настройки в новую установку автоматически. Сохраните необходимые законные доработки после проверки.
5. 05
   Отзовите раскрытые пароли, ключи и токены, завершите старые сессии. Выполняйте замену через доверенные устройства. Если секрет использовался в ещё заражённой среде, считайте возможным его повторное раскрытие.
6. 06
   Проверьте сайт на изолированной копии: вход, формы, оплату, письма, API, фоновые задачи и перенаправления. После очистки обновите нужные кеши и повторите проверку как обычный посетитель.
7. 07
   Верните сайт в работу с контролем файлов, учётных записей и журналов. Сохраните возможность восстановления проверенной конфигурации и список выполненных изменений.

Как выбрать резервную копию после взлома

Используйте проверенную чистую копию с подходящей точкой восстановления. Обычно стремятся выбрать наиболее свежую подтверждённо чистую копию до компрометации, чтобы сократить потерю данных. Дата первого видимого симптома не равна дате проникновения, а самый старый архив не становится безопасным автоматически.

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

Как мы устранили возвращающийся редирект на сайт казино

В одном из проектов VozniNet посетителей сайта перенаправляло на ресурс онлайн-казино. После очистки кода сайт снова выглядел исправным, но затем перенаправление возвращалось. Найти источник проблемы помогла проверка журналов событий.

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

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

Как помог анализ журналов

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

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

Что изменилось после устранения источника

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

Как проверить результат очистки

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

Что проверить в Google после взлома

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

• Проблемы безопасности. Изучите замечания в Google Search Console. Если они есть, запросите проверку после устранения причин и заражённых объектов. Отсутствие предупреждения не заменяет собственную диагностику.
• Меры, принятые вручную. Проверьте этот отчёт отдельно: он отличается от проблем безопасности. Если мера применена, выполните требования соответствующего уведомления.
• Спамные URL. Адреса удалённых страниц, созданных атакующим и не имеющих полезной замены, обычно должны возвращать 404 или 410. Не перенаправляйте их массово на главную. Полезные страницы очищают и восстанавливают с корректным содержимым и ответом 200.
• Условия индексирования. Проверьте robots.txt, noindex, canonical, Sitemap и внутренние переходы. Удалите внесённые злоумышленником ограничения, подмены и спамные адреса. Один запрет обхода в robots.txt не является способом гарантированно убрать URL из поиска.
• Содержимое и перенаправления. Проверьте заголовки, описания, текст и маршруты переходов. Различайте текущий ответ сайта и старые сведения в выдаче, которые ещё не обновились после повторного обхода.
• Результат восстановления. Проверьте важные URL и наблюдайте за индексированием, показами и кликами по страницам и запросам. Зафиксируйте дату очистки, чтобы сопоставлять изменения с дальнейшей динамикой.

Если после очистки остаются проблемы с индексированием и доступностью страниц, их проверяют в рамках технического SEO-аудита. Пример состава такой работы — технический аудит сайта на 162 URL.

Как снизить риск нового взлома

Поддерживайте WordPress, темы, плагины и серверное ПО на поддерживаемых версиях. Удаляйте ненужные расширения и старые установки, которые доступны из интернета. При изменении версии PHP заранее проверяйте совместимость сайта и интеграций.

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

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

Вопросы о повторном заражении WordPress

Когда обращаться за диагностикой WordPress

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

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