Если сайт на WordPress начал редиректить на чужие страницы, в коде появились незнакомые вставки, а в админке — новые пользователи или странные плагины, сначала нужно не «лечить наугад», а быстро найти, где именно сидит проблема. Взломы и заражения редко ограничиваются одним файлом: обычно меняются ядро WordPress, темы, плагины и иногда база данных.
Ниже — практический порядок проверки, который помогает локализовать вредоносный код и скрытые изменения файлов до начала очистки. Он подходит для большинства сайтов на обычном хостинге, без специальных инструментов уровня SIEM или серверного антивируса.
С чего начать, если есть подозрение на взлом
Перед проверкой сделайте копию сайта: файлов и базы данных. Это не защита от заражения, а страховка на случай, если при удалении подозрительных вставок вы случайно сломаете рабочий сайт. Если у хостинга есть снимок состояния или резервная копия, используйте её. Если нет — скачайте архив сайта и экспортируйте базу через phpMyAdmin или другой доступный инструмент.
Дальше зафиксируйте симптомы. Это поможет понять, где искать:
- неожиданные редиректы на мобильных или только для поисковых роботов;
- новые файлы в корне сайта или в папках темы и плагинов;
- изменения в файлах, которые вы давно не трогали;
- неизвестные администраторы в WordPress;
- спам-ссылки, скрытые блоки или iframe в контенте;
- ошибки 500, белый экран, странные предупреждения PHP;
- подозрительная активность в логах веб-сервера.
Если сайт уже ведёт себя нестабильно, не обновляйте всё подряд до проверки. Обновление может затереть следы заражения и усложнить поиск источника.
Проверка файлов WordPress: где обычно прячется вредоносный код
Самые частые места заражения — wp-content, корень сайта и файлы активной темы. Ядро WordPress тоже проверяют, но его обычно проще восстановить из чистой копии, чем вручную вычищать.
Сравните ядро WordPress с оригиналом
Если у вас есть доступ по SSH, самый надёжный способ — сравнить файлы ядра с официальной версией той же ветки WordPress. Для этого удобно использовать WP-CLI, если он установлен на хостинге. Команда ниже проверяет целостность ядра и покажет, какие файлы изменены, удалены или добавлены:
wp core verify-checksumsЕсли команда сообщает об изменениях в ядре, это не всегда вредоносный код, но это повод проверить конкретные файлы. Особенно подозрительны изменения в wp-admin, wp-includes и корневых PHP-файлах, которые обычно не редактируют вручную.
Если WP-CLI недоступен, сравните содержимое папок WordPress с чистой копией той же версии. Вручную это дольше, но принцип тот же: в ядре не должно быть лишних PHP-файлов, а существующие файлы не должны содержать посторонние вставки вроде длинных закодированных строк, обфускации через base64_decode, gzinflate, str_rot13 или подозрительных вызовов eval.
Проверьте корень сайта и папку uploads
В корне сайта часто оставляют загрузчики, бэкдоры и файлы с безобидными названиями вроде cache.php, old.php, wp-info.php. В папке wp-content/uploads PHP-файлы вообще не должны появляться в обычной установке WordPress. Если там лежит .php, .phtml или похожий исполняемый файл, это почти всегда повод для ручной проверки.
Отдельно смотрите на:
- файлы с недавней датой изменения, если вы ничего не обновляли;
- файлы с необычными именами, похожими на системные;
- скрытые файлы вроде
.user.ini,.htaccess,web.config; - архивы, временные файлы и дубликаты с расширениями
.bak,.old,.tmp.
Если есть SSH, полезно быстро вывести недавно изменённые файлы. Команда ниже покажет PHP-файлы, изменённые за последние 7 дней, в текущем каталоге и ниже:
find . -type f -name '*.php' -mtime -7Это не доказывает заражение, но помогает сузить круг поиска. На живом сайте дата изменения часто указывает на момент внедрения вредоносного кода.
Ищите типовые признаки обфускации
Вредоносный код редко пишут «чисто». Чаще его прячут в длинные строки, кодируют и разбивают на куски. Насторожить должны:
- многоуровневые вызовы
base64_decodeиeval; - длинные строки без пробелов, похожие на закодированный текст;
- неожиданные обращения к удалённым доменам;
- код, который выполняется только при определённых условиях: по IP, по User-Agent, для неавторизованных посетителей или только для поисковых роботов;
- вставки в конце файла после закрывающего PHP-тега, если он вообще используется.
Если вы открываете файл и не понимаете, зачем он нужен, не удаляйте его сразу. Сначала сравните с чистой версией из репозитория темы или плагина, если она доступна. Для коммерческих тем и плагинов безопаснее переустановить оригинальный пакет, чем править файл вручную.
Как проверить плагины и тему, не сломав сайт
Заражение часто сидит не в ядре, а в активной теме или одном из плагинов. Особенно это касается старых расширений, которые давно не обновлялись, или скачанных из сомнительных источников.
Сначала составьте список активных плагинов и проверьте, есть ли среди них:
- неизвестные вам расширения;
- плагины без понятного автора или с подозрительным названием;
- устаревшие плагины, которые не обновлялись годами;
- дублирующие функции, которые вы не устанавливали осознанно.
Если есть доступ к файловой системе, откройте папки плагинов и сравните их с оригинальными версиями. У плагинов и тем особенно подозрительны файлы с именами functions.php, init.php, class-*.php, а также случайные PHP-файлы в корне папки. В нормальном плагине структура обычно предсказуемая, и лишние исполняемые файлы сразу бросаются в глаза.
Для темы проверьте:
functions.php;- файлы шаблонов, которые вы не редактировали;
- подключения внешних скриптов и стилей;
- вставки в футере и хедере, особенно если они появились без вашего участия.
Если тема или плагин взяты из официального источника, самый надёжный способ проверки — заменить их чистой копией той же версии. Это быстрее и безопаснее, чем выискивать вредоносную вставку вручную в большом количестве файлов.
Проверка базы данных: когда вредоносный код живёт не в файлах
Если на сайте есть скрытые ссылки, спам-тексты, редиректы или странные блоки, проблема может быть в базе данных. В WordPress это чаще всего записи в wp_posts, настройки в wp_options и иногда пользовательские поля.
Что проверять в первую очередь:
- главную страницу и последние записи на наличие скрытых ссылок, iframe и неочевидных вставок;
- таблицу
wp_options— особенно значения с длинным кодом, внешними URL и непонятными сериализованными данными; - виджеты и настройки темы, если сайт использует их для вывода HTML;
- пользовательские поля и SEO-поля, если они активно используются на сайте.
В phpMyAdmin удобно искать по базе по характерным признакам: iframe, base64, eval, подозрительным доменам, словам из спам-вставок. Но искать нужно аккуратно: такие строки могут встречаться и в легитимных настройках, поэтому ориентируйтесь не только на ключевое слово, но и на контекст записи.
Если в базе найдено что-то подозрительное, не удаляйте запись целиком без понимания, к чему она относится. В WordPress одна неверно удалённая строка в wp_options может сломать тему, меню или настройки плагина. Сначала сохраните содержимое, затем сравните с чистой установкой или с резервной копией до заражения.
Как понять, что сайт действительно заражён, а не просто изменён вручную
Не каждое отличие от «чистой» версии означает взлом. Иногда разработчик сам добавлял кастомный код, а иногда хостинг менял служебные файлы. Поэтому смотрите на совокупность признаков:
- изменения появились без ваших действий;
- файл изменён в нерабочее время или серией массовых правок;
- код содержит обфускацию, внешние обращения или скрытое выполнение;
- в папках WordPress есть исполняемые файлы, которым там не место;
- в админке появились неизвестные пользователи или роли;
- в базе есть скрытые ссылки, редиректы или спам.
Если совпадает несколько пунктов, вероятность заражения высокая. Если найден только один подозрительный файл, сначала проверьте, не относится ли он к вашей кастомной доработке или к плагину, который вы сами устанавливали.
Что делать сразу после обнаружения подозрительных файлов
Когда проблема локализована, не спешите массово удалять всё подряд. Сначала ограничьте ущерб: временно смените пароли администраторов, FTP/SFTP, базы данных и панели хостинга. Если есть возможность, переведите сайт в режим обслуживания или закройте публичный доступ к админке на время проверки.
Дальше действуйте по порядку:
- сохраните копию подозрительных файлов и дамп базы;
- удалите только явно вредоносные файлы, которые не относятся к ядру, теме или плагинам;
- замените ядро WordPress чистой версией той же ветки;
- переустановите тему и плагины из официального источника;
- проверьте пользователей с правами администратора;
- после очистки ещё раз просканируйте сайт на наличие тех же признаков.
Если заражение затронуло много файлов или вы не можете уверенно отделить вредоносный код от легитимного, безопаснее восстановить сайт из чистой резервной копии и затем обновить все пароли. На практике это часто быстрее и надёжнее, чем ручная вычитка десятков файлов.
Как проверить результат после очистки
После удаления подозрительных вставок проверьте сайт не только в браузере, но и на уровне файлов и базы. Откройте несколько страниц в обычном режиме и в приватном окне, проверьте мобильную версию, форму входа и главную страницу. Затем повторно сравните файлы ядра и папки wp-content с чистыми версиями.
Полезно ещё раз посмотреть:
- нет ли новых PHP-файлов в
uploads; - не появились ли изменения в
.htaccessили.user.ini; - не вернулись ли подозрительные записи в базе;
- не создались ли новые администраторы;
- не идут ли редиректы только для поисковых роботов или только с определённых IP.
Если после очистки симптомы исчезли, это ещё не гарантия, что проблема закрыта. Вредоносный код мог оставить бэкдор. Поэтому финальная проверка должна быть повторной, уже после смены всех паролей и обновления компонентов сайта.
Для владельца сайта практический ориентир простой: сначала ищите изменения в ядре, теме, плагинах и базе данных, потом отделяйте легитимные правки от подозрительных, и только после этого переходите к очистке. Такой порядок экономит время и снижает риск удалить нужный код вместе с вредоносным.