Типичный сценарий обращения: сайт открывается с редиректом на непонятный ресурс, либо в Google Search Console пришло уведомление о «проблемах безопасности», либо браузер посетителей показывает красный экран «Сайт может нанести вред вашему устройству». Во всех трёх случаях сайт заражён, и задача разбивается на три этапа: найти и удалить вредоносный код, закрыть точку входа, снять санкции поисковых систем.
В подавляющем большинстве случаев причина не «хакер целенаправленно взломал именно вас», а автоматизированный скан уязвимостей известных плагинов и тем, которые давно не обновлялись. Массовые сканеры ищут открытые формы загрузки файлов без проверки типа, устаревшие версии плагинов с публично известными CVE, и слабые пароли администратора через брутфорс wp-login.php. На 1С-Битрикс вектор чаще — незакрытые уязвимости в устаревших компонентах или скопированный с чужого сайта модуль без проверки кода.
Не всегда заражение выглядит очевидно. Частые признаки: рост исходящего трафика или нагрузки на сервер без роста посетителей (сайт используется для рассылки спама или как узел в ботнете), появление в индексе Google страниц, которых вы не создавали (спам-дорвеи на темы фармацевтики или реплик, размещённые в отдельной директории), редирект на другой домен только для посетителей из поиска, но не при прямом заходе (маскировка от администратора). Последнее особенно коварно — сайт «выглядит нормально», когда его проверяет владелец.
Первый и самый надёжный способ — сравнение файлов с эталонными. Для WordPress это делается через WP-CLI: wp core verify-checksums и wp plugin verify-checksums --all — команды сверяют хэши файлов ядра и плагинов с официальным репозиторием и показывают изменённые или добавленные файлы, которых там быть не должно.
Дальше — поиск характерных сигнатур по всей файловой системе сайта:
grep -rl --include=*.php -E "eval(|base64_decode(|gzinflate(|assert(\$_" .
Сама по себе функция base64_decode не вредоносна, но в сочетании с eval() — классическая сигнатура шелла, обфусцирующего свой код от поверхностной проверки. Отдельно смотрю файлы с недавней датой изменения, не совпадающей с датой последнего легитимного обновления: find . -type f -name "*.php" -newer wp-config.php. Подозрительны файлы в директориях загрузок (wp-content/uploads), где в норме не должно быть исполняемого PHP-кода вообще — это первый признак, что фильтр загрузки файлов на сайте был обойдён.
Шелл в файловой системе — только половина проблемы. Классический вектор закрепления в WordPress — инжект вредоносного JavaScript или редиректа прямо в опции wp_options (поля widget_text, иногда — подмена значения siteurl/home), либо создание скрытой учётной записи администратора в wp_users с непубличным логином. Проверяю оба места вручную через phpMyAdmin или SQL-запросом на подозрительные <script> и eval в текстовых полях, а также список пользователей с ролью administrator, которых не заводил владелец сайта.
Удаление шелла без закрытия уязвимости, через которую он попал, бессмысленно — файл появится снова в течение суток. Порядок действий: обновить ядро, все плагины и тему до актуальных версий (если тема кастомная и не обновлялась — отдельно проверить её код на уязвимые формы загрузки), сменить все пароли — администратора WordPress, доступа к хостингу/FTP, базе данных, — и обязательно перегенерировать ключи безопасности AUTH_KEY/SECURE_AUTH_KEY и остальные SALT-константы в wp-config.php, которые обнуляют все существующие сессии авторизации. Дополнительно ограничиваю доступ к wp-login.php и wp-admin по списку IP на уровне веб-сервера там, где это возможно.
После полной очистки санкции не снимаются автоматически — нужно явно запросить повторную проверку. В Google Search Console: раздел «Проблемы безопасности», после устранения — кнопка «Запросить проверку» с описанием, что именно было исправлено. Проверка обычно занимает от нескольких часов до нескольких дней. В Яндекс.Вебмастере аналогичный процесс — раздел «Безопасность и нарушения», где после очистки нужно подтвердить, что сайт больше не представляет угрозы. Важно не отправлять запрос до полной уверенности в чистоте сайта: повторное обнаружение вредоносного кода после заявленного «исправлено» увеличивает срок последующей проверки и снижает доверие к домену.
Удаление только явно видимого вредоносного файла без проверки остальной файловой системы — самая распространённая ошибка. Современные шеллы почти всегда оставляют несколько точек восстановления: основной файл, который находят и удаляют первым, и один или два скрытых дублирующих файла с безобидными именами (например, замаскированных под wp-cache.php или файл внутри легитимного плагина), которые через сутки восстанавливают удалённый шелл заново.
Вторая ошибка — переустановка ядра WordPress без смены паролей и ключей. Чистая переустановка wp-admin и wp-includes удаляет заражённые файлы ядра, но если пароль администратора и SALT-ключи остались прежними, а точка входа (например, уязвимый плагин) не обновлена, повторное заражение происходит в течение того же дня — атака была автоматической, а не разовой.
Третья — отсутствие проверки резервных копий перед восстановлением из них. Восстановление сайта из бэкапа, сделанного уже после заражения, возвращает вредоносный код вместе с остальными данными — нужно точно определить дату заражения (по логам доступа или дате изменения подозрительных файлов) и брать бэкап заведомо раньше этой даты, что не всегда возможно при редком расписании бэкапов.
Четвёртая — публичное раскрытие деталей инцидента до завершения очистки. Обсуждение взлома в открытых тикетах поддержки хостинга или публичных форумах с указанием точного адреса сайта иногда привлекает внимание других автоматических сканеров, которые специально ищут ещё не долеченные после инцидента сайты как более лёгкую цель.
