Коротко
Если сайт на WordPress взломали, действуйте по порядку: изолируйте сайт, снимите копию текущего состояния для анализа, найдите и удалите вредоносный код и лишних администраторов, обновите ядро, темы и плагины, смените все пароли и секретные ключи (соль), а затем закройте уязвимость, через которую попали. Восстановление из чистой резервной копии ускоряет процесс.
Мало вычистить вирус — нужно закрыть дыру, иначе сайт заразят повторно за считанные дни. Поэтому восстановление после взлома всегда состоит из двух частей: очистка и защита.
| Этап | Цель | Типичная ошибка |
|---|---|---|
| Изоляция | Не заражать посетителей, остановить ущерб | Оставить сайт открытым «пока разбираемся» |
| Копия «как есть» | Сохранить следы для анализа | Сразу удалить всё подозрительное |
| Очистка | Удалить вредоносный код, чужих администраторов | Почистить только видимые симптомы |
| Смена доступов | Отрезать злоумышленника | Сменить только пароль админки |
| Закрытие уязвимости | Не допустить повторного взлома | Не выяснить, как проникли |
| Снятие пометок | Вернуть доверие поисковиков и браузеров | Забыть про Вебмастер и Search Console |
Основная мысль
Взлом WordPress — это не только вредоносный код, который нужно удалить, а открытая дверь, которую нужно найти и закрыть: сайт считается восстановленным, когда он чист, все доступы сменены, уязвимость устранена и настроена защита от повторения.
Типичная история: владелец находит заражённый файл, удаляет его, сайт снова работает. Через несколько дней всё повторяется. Причина в том, что злоумышленник оставил скрытый вход — бэкдор в другом файле, лишнего администратора или запись в базе, — а уязвимый плагин так и не обновили.
Поэтому действовать нужно системно: сначала остановить ущерб и зафиксировать состояние, потом чистить, затем закрывать уязвимость и укреплять защиту. Разберём каждый шаг.
Как понять, что сайт взломан
Явные признаки
- Чужая реклама и редиректы на посторонние сайты.
- Неизвестные страницы в выдаче, часто на других языках или со спамом.
- Предупреждение браузера или антивируса при открытии сайта.
- Жалобы хостинга на рассылку спама или повышенную нагрузку.
- Незнакомые администраторы в панели.
Скрытые признаки
Не каждый взлом заметен сразу. Часть вредоносного кода показывает рекламу или редиректы только посетителям из поиска или только с мобильных устройств, а администратору сайт выглядит нормально. Насторожить должны:
- резкое падение трафика из поиска;
- новые файлы в папке загрузок, особенно с расширением PHP;
- изменённые даты у файлов ядра;
- рост исходящей почты с сервера;
- неизвестные задачи cron.
Что взломщики обычно делают с сайтом
| Цель | Как проявляется |
|---|---|
| Спам-страницы для поиска | Тысячи чужих страниц в индексе |
| Перенаправление трафика | Редиректы на сторонние сайты для части посетителей |
| Рассылка спама | Жалобы хостинга, блокировка почты домена |
| Кража данных | Скрытые формы, перехват данных заказов |
| Использование ресурсов | Высокая нагрузка на сервер, майнинг |
Виды вредоносного кода в WordPress
Бэкдоры
Бэкдор — скрытый вход, который позволяет злоумышленнику вернуться на сайт даже после смены паролей. Обычно это небольшой PHP-файл с безобидным именем в папке загрузок, темы или плагина, либо фрагмент кода, дописанный в существующий файл. Пока бэкдор не найден, очистка остальных файлов не имеет смысла: сайт заразят снова.
Внедрённые скрипты и редиректы
Вредоносный JavaScript дописывают в файлы темы, в записи базы данных или в настройки виджетов. Он показывает рекламу, перенаправляет посетителей на сторонние сайты или подгружает код с внешнего сервера. Часто такой код срабатывает выборочно: только для посетителей из поиска, только с телефонов или только один раз для каждого посетителя.
Спам-страницы и дорвеи
Взломщики создают на сайте тысячи страниц со спамом, чтобы использовать репутацию домена в поиске. Страницы могут храниться в базе как записи или генерироваться скриптом на лету. Признак — резкий рост числа страниц в индексе и незнакомые запросы в отчётах вебмастеров.
Скрипты рассылки и вредоносные задачи
Скрипт рассылки превращает сервер в источник спама, из-за чего хостинг блокирует аккаунт, а почта домена попадает в чёрные списки. Вредоносные задачи cron периодически восстанавливают удалённые файлы, поэтому при очистке проверяют и системный cron хостинга, и задачи внутри WordPress.
Что сделать в первый час после взлома
Срочные действия
- Закройте сайт для посетителей (режим обслуживания), чтобы не заражать их и не терять репутацию.
- Смените пароли хостинга, FTP/SSH и админа — злоумышленник может ещё иметь доступ.
- Снимите полную копию «как есть» для анализа причины.
- Сообщите хостингу — они помогут с логами и остановят рассылку спама.
- Не удаляйте всё в панике: сначала фиксируем следы, потом чистим.
Почему нельзя сразу всё удалять
Удалив заражённые файлы без анализа, можно уничтожить следы, по которым определяется точка входа. Без понимания, как злоумышленник попал на сайт, уязвимость останется открытой. Копия «как есть» позволяет спокойно разобраться: какие файлы изменены, когда, через какой плагин или доступ.
Что попросить у хостинга
Журналы доступа к сайту и к FTP/SSH за последние недели, информацию о подозрительной активности, при необходимости — копию сайта с их стороны на дату до взлома. Многие хостинги хранят такие копии несколько дней или недель.
Пошаговый план восстановления
Последовательность действий
- Изолируйте сайт: включите режим обслуживания или закройте доступ, чтобы не пострадали посетители.
- Снимите полную копию файлов и базы «как есть» — для анализа и на случай ошибок при чистке.
- Просканируйте сайт на вредоносный код и найдите изменённые и чужие файлы.
- Замените ядро WordPress на чистые файлы официальной версии.
- Удалите неизвестные плагины, темы и подозрительные PHP-файлы в uploads.
- Проверьте список пользователей и удалите лишних администраторов.
- Смените все пароли (админ, БД, FTP/SSH, хостинг) и обновите соль-ключи в wp-config.
- Обновите ядро, темы и плагины до актуальных версий.
- Найдите и закройте уязвимость, через которую проник злоумышленник.
- Проверьте сайт в Яндекс.Вебмастере и Google на пометки о вредоносности.
Сканирование и поиск вредоносного кода
Сканирование проводят несколькими способами: сканером на сервере, сравнением файлов ядра с официальной версией, поиском характерных конструкций, которыми маскируют вредоносный код. Ни один инструмент не находит всё, поэтому автоматическую проверку дополняют ручным просмотром подозрительных файлов.
Особое внимание — папке загрузок. Там должны лежать только изображения и документы. Любой PHP-файл в uploads почти наверняка вредоносный.
Замена ядра, тем и плагинов
Файлы ядра WordPress не должны меняться, поэтому их проще заменить целиком на чистые из официального дистрибутива той же версии. Темы и плагины также переустанавливают из официальных источников. Если тема дорабатывалась вручную, её изменённые файлы сравнивают с исходной версией построчно.
Плагины, которые давно не обновлялись разработчиком или скачаны не из официальных источников, лучше удалить и заменить аналогами. Взломанные и «бесплатные» версии платных плагинов — один из частых источников заражения.
Проверка базы данных
Вредоносный код прячется не только в файлах. В базе данных проверяют:
- список пользователей и их роли;
- содержимое записей и страниц на чужие скрипты и ссылки;
- настройки сайта: адрес, активные плагины, виджеты;
- задачи, запланированные внутри WordPress.
Смена паролей и секретных ключей
Смените все пароли: администраторов, базы данных, FTP/SSH, панели хостинга. Обновите секретные ключи (соль) в wp-config — после этого все текущие сессии завершатся, и злоумышленник, если он ещё авторизован, потеряет доступ.
Восстановление из резервной копии
Когда это лучший путь
Если есть заведомо чистая копия до взлома — это быстрый путь. Сайт возвращают в состояние до заражения, а затем обязательно обновляют ядро, темы и плагины и закрывают уязвимость. Иначе сайт заразят снова тем же способом.
Как понять, что копия чистая
Главная сложность — определить дату заражения. Вредоносный код мог появиться задолго до того, как проявился. Поэтому копию проверяют тем же сканированием, что и рабочий сайт, и сравнивают файлы. Если копия тоже заражена, берут более раннюю или чистят вручную.
Что делать с данными после даты копии
Всё, что появилось на сайте после даты копии — новые записи, заказы, комментарии, — придётся перенести вручную или выборочно из заражённой базы, предварительно проверив. Для магазинов на WooCommerce это особенно важно: заказы нельзя просто потерять. Если резервной копии нет или все копии заражены, поможет восстановление сайта с ручной чисткой.
Сравнение подходов
| Подход | Когда подходит | Сроки |
|---|---|---|
| Восстановление из чистой копии | Есть копия до заражения | Простые случаи — несколько часов |
| Ручная чистка | Нет чистой копии, заражение ограниченное | От нескольких часов |
| Чистка с поиском уязвимости | Глубокое заражение, повторные взломы | До 1–2 дней |
Поиск и закрытие уязвимости
Частые точки входа
- Устаревшие плагины и темы с известными уязвимостями.
- Слабые или утёкшие пароли администраторов, FTP, хостинга.
- Взломанные версии платных плагинов с встроенным бэкдором.
- Заражение соседних сайтов на том же аккаунте хостинга.
- Незащищённые формы загрузки файлов.
Как найти, через что проникли
Точку входа ищут по журналам доступа и по датам изменения файлов. Первый изменённый файл и запросы к сайту в это время обычно указывают на уязвимый плагин или форму. Если в журналах видны входы в админку с незнакомых адресов, проблема в пароле.
Соседние сайты на хостинге
Если на одном аккаунте хостинга размещено несколько сайтов, заражение одного часто распространяется на все. Проверять и чистить нужно каждый, иначе вирус вернётся с соседнего сайта. Заброшенные тестовые копии и старые версии сайта лучше удалить совсем.
Как защититься от повторного взлома
Базовые меры
- Своевременно обновляйте ядро и плагины — устаревшие плагины причина большинства взломов.
- Двухфакторная аутентификация и ограничение попыток входа.
- Минимум плагинов, только из проверенных источников.
- Регулярные автоматические бэкапы с хранением вне сервера.
- Файрвол или WAF и запрет выполнения PHP в папке загрузок.
Дополнительные меры
- Отключение редактирования файлов тем и плагинов из админки.
- Отдельные учётные записи с минимальными правами для редакторов.
- Защищённый доступ по SSH вместо FTP.
- Мониторинг изменений файлов и доступности сайта.
- Регулярная проверка сайта сканером.
Настройки сервера и хостинга
Часть защиты настраивается на уровне сервера. Актуальная версия PHP, правильные права на файлы и папки, отдельный пользователь для каждого сайта на хостинге, закрытый доступ к служебным файлам вроде wp-config — всё это снижает ущерб даже при появлении уязвимости в плагине. Если хостинг не позволяет выполнить эти настройки, стоит подумать о переезде.
Как часто делать резервные копии
Для сайта, который редко меняется, достаточно еженедельных копий. Для магазина и сайта с ежедневными публикациями — ежедневных. Хранить стоит несколько копий за разные даты: заражение часто обнаруживают не сразу, и последняя копия может оказаться уже заражённой.
Поддержка как часть защиты
Большинство взломов случается на сайтах, которые годами не обновлялись. Регулярная поддержка — обновления, резервные копии, проверки — обходится дешевле восстановления. Стоимость поддержки — от 2 000 ₽ в час. Если сайт устарел и нужны серьёзные изменения, помогает доработка сайта на WordPress.
Регламент обслуживания после восстановления
Что и как часто делать
Защита работает, только если её поддерживают. После восстановления полезно закрепить простой регламент:
| Действие | Периодичность | Зачем |
|---|---|---|
| Обновление плагинов и тем | По мере выхода, не реже раза в месяц | Закрывает известные уязвимости |
| Обновление ядра WordPress | По мере выхода | Исправления безопасности |
| Резервная копия вне сервера | Ежедневно или еженедельно | Быстрое восстановление без потерь |
| Проверка сканером | Еженедельно | Раннее обнаружение заражения |
| Аудит пользователей и плагинов | Раз в квартал | Удаление лишних доступов и неиспользуемых плагинов |
| Проверка отчётов вебмастеров | Еженедельно | Пометки о безопасности, спам-страницы |
Обновления без риска
Обновления иногда ломают сайт, и из-за этого их откладывают. Решение — обновлять сначала на тестовой копии или хотя бы делать резервную копию перед каждым обновлением. Так сайт остаётся защищённым, а риск поломки контролируется.
Кто отвечает за безопасность
На сайте должен быть один ответственный за обновления и резервные копии: сотрудник, разработчик на поддержке или хостинг с управляемым обслуживанием. Когда ответственного нет, обновления не выполняются годами, и сайт становится лёгкой целью.
Поиск и репутация после взлома
Снятие пометок о вредоносности
Проверьте сайт в Яндекс.Вебмастере и Google Search Console. Если сайт помечен как опасный, после очистки отправьте запрос на перепроверку. Пока пометка висит, браузеры и поисковики предупреждают посетителей, и трафик резко падает.
Удаление спам-страниц из индекса
Если взломщики создавали спам-страницы, они могут оставаться в индексе. После очистки такие адреса должны отдавать ошибку 404 или 410. Поисковики постепенно исключат их при следующих обходах.
Почта домена
Если с сервера рассылался спам, почта домена может попасть в чёрные списки. Письма клиентам начинают уходить в спам или не доходить. После очистки проверяют репутацию домена и при необходимости подают запросы на исключение из списков.
Сценарии из практики
Сценарий 1: редирект на сторонний сайт с мобильных
Владелец не видит проблемы: с компьютера сайт работает. Жалобы приходят от клиентов, которые открывают сайт с телефона из поиска. Причина — скрипт в базе данных, который срабатывает только для мобильных посетителей из поиска. Решение: поиск по базе, очистка записей и настроек, обновление плагина, через который скрипт был внедрён, смена паролей.
Сценарий 2: тысячи спам-страниц в индексе
В Вебмастере резко выросло число страниц, в выдаче по названию компании появились чужие заголовки. Взломщики через устаревший плагин загрузили скрипт, генерирующий страницы. После удаления скрипта и бэкдоров спам-адреса начинают отдавать 404, а поисковики постепенно их исключают. Параллельно закрывают уязвимость и настраивают мониторинг файлов.
Сценарий 3: повторное заражение после чистки
Сайт чистили уже дважды, но через неделю вирус возвращается. Обычно причина одна из трёх: не найден бэкдор, не обновлён уязвимый плагин или заражён соседний сайт на хостинге. В таком случае проверяют весь аккаунт хостинга, заменяют ядро, темы и плагины целиком, меняют все доступы и ищут точку входа по журналам.
Сценарий 4: заражённый магазин на WooCommerce
Для магазина ставки выше: в базе хранятся заказы и данные клиентов, а простой означает потерю продаж. Сайт закрывают на обслуживание, сохраняют копию, проверяют страницы оформления заказа на скрытые формы перехвата данных и платёжные модули на подмену. Заказы, оформленные после даты чистой копии, переносят выборочно.
Типичные ошибки при восстановлении
Чего не стоит делать
- Удалять заражённые файлы без копии и анализа.
- Ограничиваться сменой пароля админки, не меняя пароли базы, FTP и хостинга.
- Восстанавливать копию, не проверив, что она чистая.
- Оставлять устаревшие плагины после очистки.
- Не проверять соседние сайты на том же хостинге.
- Забывать про пометки в Вебмастере и Search Console.
Чек-лист после восстановления
- Сайт просканирован, вредоносный код не найден.
- Ядро, темы и плагины обновлены до актуальных версий.
- Лишние администраторы удалены, все пароли и соль-ключи сменены.
- Уязвимость найдена и закрыта.
- Настроены резервные копии вне сервера.
- Пометки о вредоносности сняты или запрошена перепроверка.
Частые вопросы
Как понять, что сайт взломан?
Признаки: чужая реклама и редиректы, неизвестные страницы в выдаче, предупреждение браузера или антивируса, жалобы хостинга на рассылку спама, незнакомые администраторы в панели.
Можно ли просто восстановиться из бэкапа?
Если есть заведомо чистая копия до взлома — это быстрый путь. Но обязательно нужно закрыть уязвимость и обновить всё, иначе сайт заразят снова.
Сколько занимает восстановление?
Простые случаи — несколько часов. Если заражение глубокое или нет чистого бэкапа — до 1–2 дней с учётом поиска и закрытия уязвимости.
Нужно ли сообщать хостингу?
Да. Хостинг может дать логи доступа, помочь найти точку входа и остановить рассылку спама с вашего аккаунта, пока сайт чистят.
Вернутся ли позиции в поиске после чистки?
Если действовать быстро и снять пометку о вредоносности в Вебмастере и Search Console, позиции обычно восстанавливаются. Чем дольше сайт заражён и помечен, тем сильнее и дольше просадка.
Достаточно ли установить плагин безопасности?
Нет. Плагин безопасности помогает обнаружить часть угроз и ограничить попытки входа, но не заменяет обновления, надёжные пароли и резервные копии. Если сайт уже заражён, плагин может не найти весь вредоносный код.
Почему сайт заражают повторно?
Чаще всего потому, что после чистки не закрыли уязвимость: не обновили плагин, не сменили все пароли или не нашли скрытый бэкдор. Второй частый случай — заражённый соседний сайт на том же хостинге.
Могли ли украсть данные клиентов?
Такой риск есть, особенно у магазинов и сайтов с формами. Поэтому при анализе проверяют, не было ли доступа к базе и скрытых форм перехвата данных. Если данные могли пострадать, стоит сменить пароли клиентских аккаунтов.
Нужно ли менять хостинг после взлома?
Не обязательно: в большинстве случаев причина в самом сайте, а не в хостинге. Но если хостинг не даёт журналов, не обновляет PHP и не помогает при инцидентах, переезд на более надёжный стоит рассмотреть.
Можно ли вылечить сайт самостоятельно?
Простое заражение с чистой резервной копией — можно, если вы уверенно работаете с файлами, базой и хостингом. При глубоком заражении, повторных взломах и магазинах с данными клиентов надёжнее обратиться к специалисту.
Что делать, если резервных копий нет совсем?
Сайт чистят вручную: заменяют ядро, переустанавливают темы и плагины из официальных источников, проверяют базу и загрузки. Это дольше, чем восстановление из копии, но результат тот же. Сразу после очистки настраивают автоматические копии вне сервера.
Итог
Восстановление взломанного сайта на WordPress — это последовательность: изоляция, копия «как есть», очистка файлов и базы, смена всех доступов и соль-ключей, обновление, поиск и закрытие уязвимости, снятие пометок в поисковиках. Пропуск любого шага повышает риск повторного взлома.
Главное — не ограничиваться удалением видимого вредоносного кода. Сайт считается восстановленным, когда уязвимость закрыта, а защита настроена: обновления, двухфакторная аутентификация, резервные копии вне сервера, запрет выполнения PHP в загрузках.
Если сайт на WordPress взломали, я как частный разработчик вычищу вредоносный код, найду и закрою уязвимость, настрою защиту и помогу снять пометки в поисковиках. Работаю напрямую, без посредников — подробнее об услуге лечение сайта от вирусов.
