WordPress взломали — что делать пошагово: от обнаружения до полного восстановления

Как понять, что сайт взломали: 7 явных признаков

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

• Хостинг заблокировал аккаунт — Beget, Timeweb или Reg.ru присылают письмо «Ваш сайт заблокирован за вредоносную активность». Это самый частый первый сигнал.
• Страницы переадресуют на другие сайты — при открытии сайта браузер уходит на казино, фарму или фишинг. Иногда редирект срабатывает только для поисковых ботов (cloaking), поэтому вы можете не замечать его в браузере.
• В выдаче Яндекса или Google сайт помечен как опасный — в результатах поиска появляется пометка «Сайт может угрожать вашей безопасности». Яндекс Вебмастер присылает уведомление о заражении.
• Появились незнакомые пользователи-администраторы — в списке пользователей WordPress есть аккаунты, которые вы не создавали, с правами Administrator.
• Новые файлы в корне сайта — появились файлы с названиями вроде shell.php, wp-login.php (в неожиданном месте), 404.php, admin.php, файлы с бессмысленными именами типа g76h3j.php.
• Незнакомые плагины и темы — в админке появились установленные плагины или темы, которые вы не ставили.
• Сайт тормозит или падает — вредоносные скрипты грузят процессор, отправляют спам или участвуют в DDoS-атаках. Хостинг сообщает о превышении лимитов CPU.

Этап 1. Изоляция сайта — чтобы не потерять всё

Первое, что нужно сделать — отключить сайт от посетителей. Это остановит распространение заражения и снизит нагрузку на сервер.

1.1 Включите режим обслуживания

Создайте в корне сайта файл .maintenance с содержимым:

<?php $upgrading = time() - 600; ?>

WordPress покажет стандартную страницу «Ведутся технические работы». Если .maintenance уже существует — обновите timestamp.

1.2 Временно закройте доступ через .htaccess

Добавьте в корневой .htaccess:

Order Deny,Allow
Deny from all
# Разрешить себе по IP
# Allow from ВАШ.IP.АДРЕС

Узнать свой IP: curl ifconfig.me. Закомментированная строка Allow — раскомментируйте и подставьте свой адрес. Это отдаёт 403 всем, кроме вас.

1.3 Снимите дамп базы данных

До любых изменений сохраните копию БД. Через WP-CLI:

wp db export backup-$(date +%Y%m%d-%H%M).sql

Если WP-CLI нет — через phpMyAdmin или SQL-команду:

mysqldump -u USER -p DATABASE > backup-$(date +%Y%m%d-%H%M).sql

Это страховка. Если что-то пойдёт не так при чистке, вы сможете откатиться.

1.4 Скачайте копию файлов сайта

Через FTP или SSH скачайте всю папку public_html на локальный компьютер. Это архив для анализа и восстановления:

rsync -avz user@server:/home/e/user/de-bor.ru/public_html/ ~/backup-site/

Этап 2. Смена всех паролей — пока доступ не ушёл дальше

Злоумышленник мог получить пароли к FTP, БД, админке. Меняйте всё в такой последовательности:

2.1 Пароль хостинга (панель управления)

Зайдите в панель хостинга (Beget, Timeweb, ISPmanager) и смените пароль. Если используется SSH-ключ — проверьте, что authorize_keys не изменён.

2.2 Пароль FTP/SFTP

Смените пароль FTP-пользователя в панели хостинга. Если используете SFTP-ключи — перегенерируйте и замените.

2.3 Пароль базы данных MySQL

В панели хостинга создайте новый пароль для БД и обновите его в wp-config.php:

define('DB_PASSWORD', 'новый-сложный-пароль');

2.4 Пароли всех пользователей WordPress

Зайдите в БД через phpMyAdmin или WP-CLI и смените пароль администратора:

wp user update 1 --user_pass="новый-очень-сложный-пароль"

Этап 3. Поиск и удаление вредоносного кода

Это самая трудоёмкая часть. Вредоносный код может быть где угодно: в PHP-файлах, в JS-скриптах, в базе данных, в .htaccess.

3.1 Проверка через онлайн-сканеры

Бесплатно и быстро:

• SiteCheck by Sucuri (sitecheck.sucuri.net) — проверит сайт на известные сигнатуры малвари. Сканирует публичную часть, находит внешние вредоносные скрипты.
• Quterra Scanner — бесплатный сканер для WordPress, проверяет файлы на хостинге.
• WordPress Security Scanner от NinjaScanner — плагин, который можно установить для сканирования файлов.

Важно: онлайн-сканеры видят только то, что отдаётся на публичной странице. Cloaking-атаки (редирект только для ботов) они могут пропустить.

3.2 Поиск вредоносного кода в файлах вручную

Самый надёжный способ — искать подозрительные файлы через SSH или WP-CLI.

Найдите PHP-файлы, изменённые за последние 7 дней:

find . -name "*.php" -mtime -7 -type f | grep -v wp-content/uploads | grep -v wp-content/cache

Найдите файлы с подозрительной кодировкой (base64_decode, eval, gzinflate, str_rot13):

grep -r "base64_decode\|eval\|gzinflate\|str_rot13" --include="*.php" . | grep -v wp-content/cache | grep -v vendor

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

Найдите файлы с правами 777 (опасно):

find . -type f -perm 777

Найдите скрытые файлы (начинаются с точки):

find . -name ".*" -type f

Найдите подозрительные скрипты в корне сайта:

ls -la *.php | grep -v index.php | grep -v wp-config.php

В корне WordPress (там, где лежат wp-config.php и index.php) не должно быть лишних PHP-файлов.

3.3 Проверка .htaccess на вредоносные правила

Злоумышленники часто прячут редиректы в .htaccess. Проверьте корневой .htaccess и все .htaccess в подпапках:

find . -name ".htaccess" -exec echo "=== {} ===" \; -exec cat {} \;

Обратите внимание на строки с RewriteRule, которые ведут на внешние URL, и на ErrorDocument, указывающий на нестандартные файлы.

3.4 Проверка базы данных на вредоносный код

Вредоносный код может быть вставлен в содержимое записей, в виджеты, в опции темы. Экспортируйте БД и проверьте:

wp db export check.sql && grep -i "base64_decode\|eval\|<script" check.sql | head -20

Проверьте опции WordPress:

wp option list --search="widget*"
wp option get theme_mods_НАЗВАНИЕ-ТЕМЫ

Проверьте содержимое записей на iframe и внешние скрипты:

wp post list --post_type=any --format=ids | xargs -I{} wp post get {} --field=post_content | grep -i "iframe\|<script.*src\|eval"

3.5 Использование плагина безопасности для сканирования

Если админка ещё работает, установите один из плагинов:

• Wordfence Security — самый популярный, сканирует файлы на сигнатуры малвари, проверяет целостность ядра WordPress, плагинов и тем.
• NinjaScanner — легковесный, не требует много ресурсов, хорошо находит shell-скрипты.
• Jetpack Scan — облачное сканирование, не грузит сервер.

Wordfence после сканирования покажет список подозрительных файлов. Не удаляйте всё подряд — проверяйте каждый файл, прежде чем удалять.

Этап 4. Восстановление из бэкапа — если чистить некогда или руки чешутся

Если у вас есть свежий бэкап, сделанный до взлома, можно не чистить — просто восстановить сайт из копии. Это быстрее и надёжнее ручной чистки.

4.1 Полное восстановление файлов

# Удалить текущие файлы (кроме wp-config.php, .htaccess, uploads)
rm -rf wp-admin wp-includes wp-content/plugins wp-content/themes

# Загрузить свежие копии WordPress
wp core download --force

# Скачать и развернуть бэкап плагинов и тем
rsync -avz ~/backup/wp-content/plugins/ wp-content/plugins/
rsync -avz ~/backup/wp-content/themes/ wp-content/themes/

4.2 Восстановление базы данных

wp db import backup-ДАТА.sql

4.3 Проверка восстановленного сайта

После восстановления из бэкапа всё равно смените пароли (этап 2) и закройте уязвимости (этап 5). Иначе взлом повторится.

Этап 5. Закрытие уязвимостей — чтобы взлом не повторился

Взлом сам по себе не случается. Всегда есть причина: уязвимость в плагине, слабый пароль, старая версия WordPress.

5.1 Обновите всё до последних версий

wp core update
wp plugin update --all
wp theme update --all

Если обновить невозможно (самописные правки) — хотя бы установите актуальные версии.

5.2 Удалите неиспользуемые плагины и темы

Каждый неиспользуемый плагин — потенциальный вход для атаки. Удалите всё, чем не пользуетесь:

wp plugin list --status=inactive --field=name | xargs wp plugin deactivate --uninstall
wp theme list --status=inactive --field=name | xargs wp theme delete

5.3 Измените префикс таблиц wp_ (если ещё старый)

По умолчанию WordPress использует префикс wp_. Это знает любой атакующий. Если при установке вы не сменили его — можно изменить через WP-CLI (требует доступа к БД).

5.4 Настройте двухфакторную аутентификацию

Двухфакторка (2FA) блокирует 99% атак на пароли. Используйте плагины:

• Wordfence Login Security — встроенная 2FA через Яндекс Ключ или TOTP-приложение
• WP 2FA — простой плагин, настраивается за 5 минут
• MiniOrange 2FA — много вариантов: email, SMS, TOTP

5.5 Смените логин администратора с "admin"

Если ваш логин admin — злоумышленник уже знает половину данных для входа. Создайте нового пользователя с правами администратора и уникальным логином, удалите admin:

wp user create newadmin email@domain.com --role=administrator --user_pass="сложный-пароль"
wp user delete 1 --reassign=НОВЫЙ-ID

5.6 Защитите wp-admin и wp-login.php

Добавьте в .htaccess ограничение по IP для доступа к админке. Если вы работаете с одного IP — это лучшая защита:

<Files wp-login.php>
Order Deny,Allow
Deny from all
Allow from ВАШ.IP.АДРЕС
</Files>

5.7 Отключите XML-RPC

XML-RPC — одна из самых частых целей для брутфорс-атак. Отключите, если не используете мобильное приложение WordPress:

Добавьте в .htaccess:

# Block XML-RPC
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>

Или через плагин:

wp plugin install disable-xml-rpc --activate

5.8 Настройте авто-бэкапы

Единственная гарантия, что следующий взлом не будет катастрофой — регулярные бэкапы. Настройте автоматические копии:

• UpdraftPlus — бесплатно шлёт бэкапы на Яндекс.Диск, Google Drive, Dropbox
• BackWPup — бэкапы БД + файлов, можно в FTP или облако
• WP Time Capsule — инкрементальные бэкапы, экономит место

Проверка результата

После всех шагов убедитесь, что взлом устранён:

• Зайдите на сайт в режиме инкогнито — нет редиректов, нет лишней рекламы
• Проверьте страницу в SiteCheck Sucuri — нет сигнатур малвари
• Проверьте Яндекс Вебмастер — нет предупреждений о заражении
• Отправьте сайт на перепроверку: Яндекс Вебмастер → Безопасность → Проверить сайт
• Проверьте логи хостинга — нет подозрительных запросов к подозрительным файлам

Когда восстановить сайт самостоятельно не получится

Есть ситуации, когда лучше не геройствовать, а передать сайт специалисту:

• Взлом на уровне ядра сервера — если злоумышленник получил доступ к другим сайтам на том же аккаунте, к панели хостинга, к SSH. Нужен аудит всего сервера.
• Скрытый бэкдор в сотнях файлов — малварь закодирована в легитимных файлах ядра, плагинов, тем. Чистка вручную займёт дни, проще восстановить из бэкапа.
• Фишинг-страницы в wp-content/uploads — злоумышленник загрузил фишинг-формы, подделывающие страницы входа Сбербанка, Госуслуг и т.д. Это уголовная статья, нужно удалять срочно.
• Заблокирован хостинг без доступа к файлам — если Beget или Timeweb заблокировали аккаунт за DDoS или спам, сначала поговорите с поддержкой и получите доступ. Без этого вы ничего не сделаете.
• SEO-урон от cloaking — если сайт в чёрном списке Яндекса, после чистки нужно подать заявку на снятие блокировки. Без этого трафик не вернётся.

Частые вопросы

Типовые схемы взлома WordPress: что ищут злоумышленники

Чтобы лучше понимать, где искать закладки, полезно знать самые распространённые схемы атак в 2025-2026 годах:

Схема 1. Брутфорс wp-login.php

Автоматический перебор паролей. Боты перебирают связки admin/123456, admin/password, а потом комбинации из словаря топ-10000. Защита: 2FA, капча, лимит попыток входа через Wordfence или Limit Login Attempts Reloaded.

Схема 2. Уязвимости в Elementor Pro и других плагинах

Elementor Pro (старые версии до 3.25) содержал RCE-уязвимости, позволяющие загрузить PHP-файл через медиабиблиотеку. Если вы используете старый Elementor — вы в группе риска. То же касается WooCommerce (до 9.3), Contact Form 7 (до 5.9), Jetpack (до 13.5).

Схема 3. SQL-инъекции через устаревшие плагины

Плагины без экранирования запросов позволяют злоумышленнику выполнить произвольный SQL-запрос к вашей БД. Через неё: смена пароля админа, вставка iframe во все записи, создание нового пользователя.

Схема 4. Загрузка PHP-шелла через уязвимость загрузки файлов

Если в теме или плагине разрешена загрузка SVG, PHP-файлы могут быть загружены через манипуляцию MIME-типом. Шелл даёт полный контроль над файловой системой.

Схема 5. Фишинг через уведомления о «необходимости обновить пароль»

Злоумышленник присылает письмо от имени WordPress или хостинга со ссылкой на фальшивую страницу входа. Вы вводите логин и пароль — доступ получен. Это социальная инженерия, её не лечат плагины.

Как найти скрытые бэкдоры: продвинутые техники

Обычная проверка через grep находит только примитивные закладки. Профессиональные злоумышленники используют обфускацию. Вот как искать глубже:

Поиск по нестандартной длине строки

Большинство PHP-файлов WordPress имеют предсказуемую структуру и длину. Найдите аномально короткие или длинные строки:

# PHP-файлы с одной длинной строкой (обфусцированный код)
awk 'length > 500 && /php/' wp-content/themes/НАЗВАНИЕ/functions.php

# Все PHP-файлы, где есть строки длиннее 1000 символов
find . -name "*.php" -exec awk 'length($0) > 1000 {print FILENAME":"NR": "$0}' {} \;

Поиск по таймстампам

Если вы знаете, когда произошёл взлом, найдите файлы, созданные или изменённые в этот период:

# Файлы, изменённые в конкретную дату
find . -name "*.php" -newer wp-config.php ! -newer wp-config.php.bak -type f

Сравнение с эталоном

Если у вас есть бэкап из доверенного источника до взлома, сравните:

diff -rq public_html/ backup/ | grep -v "wp-content/uploads" | grep -v "wp-content/cache" | grep -v "wp-content/languages"

Различия покажут изменённые файлы. Если в диффе есть eval, base64_decode или закодированные блоки — это бэкдор.

Проверка cron-задач

Злоумышленники часто добавляют свои задачи в cron WordPress, которые регулярно подгружают новый вредоносный код:

wp cron event list

Проверьте, нет ли подозрительных событий от неизвестных плагинов. Если видите cron с именем check_visitors или update_checker — это почти наверняка бэкдор.

Как работать с поддержкой хостинга при блокировке

Если хостинг (Beget, Timeweb, Reg.ru) заблокировал ваш сайт, не паникуйте и не пытайтесь скрыть проблему. Поддержка видит логи и знает причину блокировки. Действуйте так:

1. Откройте тикет с конкретикой

Не пишите «сайт заблокировали, что делать?». Напишите так:

Тема: Блокировка за малварь — приступаю к чистке
Сайт: example.ru
Проблема: Получено уведомление о заражении. Я обнаружил подозрительные файлы (список).
План работ: 
1. Изолировал сайт (режим обслуживания)
2. Сканирую файлы через Wordfence
3. Чищу или восстанавливаю из бэкапа
4. Меняю все пароли
5. Обновляю плагины и ядро
Запрос к поддержке: Разблокируйте на 24 часа для чистки, обязуюсь закрыть доступ после работ.

2. Попросите временную разблокировку

Beget и Timeweb обычно дают 24-48 часов на чистку, если вы чётко опишете план. После чистки нужно отправить подтверждение: логи clean-сканера или скриншоты Wordfence.

3. После чистки — запрос на проверку

Когда всё почистили, попросите поддержку проверить и разблокировать. Beget подключает бесплатное сканирование от Dr.Web. Если чисто — блокировка снимается в течение часа.

Как снять блокировку в Яндексе и Google после взлома

Даже если сайт почищен, поисковые системы ещё некоторое время показывают предупреждение. Вот как ускорить:

Яндекс Вебмастер

1. Зайдите в Яндекс Вебмастер → Безопасность → Проверка сайта
2. Нажмите «Проверить сайт» — Яндекс просканирует страницы на наличие вредоносного кода
3. Если проверка прошла, предупреждение снимут автоматически (обычно 1-3 дня)
4. Если Яндекс всё ещё находит угрозы — проверьте логи сканирования: там указано, какие URL заражены

Google Search Console

1. Зайдите в Search Console → Безопасность и руководства по действиям (Manual Actions)
2. Просмотрите отчёт о проблемах безопасности — там перечислены заражённые страницы
3. После чистки нажмите «Запросить проверку»
4. Google проверяет сайт автоматически. Обычно 1-5 дней.

Инструменты для автоматической чистки WordPress

Если ручная чистка кажется сложной, вот инструменты, которые автоматизируют поиск и удаление малвари. Но помните: ни один автомат не гарантирует 100% результат.

• Wordfence CLI — консольная версия Wordfence. Сканирует файлы без загрузки WordPress. Устанавливается через SSH. Быстрее веб-версии, не грузит сайт.
• GOTMLS (Got Malware Scanner) — бесплатный сканер, хорош для базовой проверки. Работает как плагин.
• BulletProof Security — плагин, который не только сканирует, но и блокирует типовые атаки. Полезен для профилактики.
• Anti-Malware Security and Brute-Force Firewall (GOTMLS) — находит и удаляет малварь автоматически. Срабатывает в 70% случаев.
• Quttera Web Malware Scanner — облачный сканер, проверяет внешние скрипты и iframe. Бесплатно и быстро.

Какой бы инструмент вы ни выбрали, после автоматической чистки всё равно проверьте вручную: созданного ли пользователя, cron, .htaccess, опции БД.

Чеклист профилактики: 10 действий на месяц

Чтобы взлом не повторился, внедрите эти привычки. На каждую уходит 5-15 минут.

Что делать, если сайт продолжает взламываться после чистки

Бывает, что вы почистили, сменили пароли, обновили всё — а через неделю сайт снова заражён. Причины:

• Бэкдор в легитимном файле — вредоносный код встроен прямо в functions.php темы или в файл плагина. Вы можете не заметить его при беглой проверке. Решение: переустановите тему и плагины из репозитория, не из бэкапа.
• Уязвимость в хостинг-панели — если злоумышленник получил доступ к ISPmanager, он может заражать сайт снова через панель. Смените пароль панели хостинга и проверьте, есть ли подозрительные действия в логах панели.
• Вирус на локальном компьютере — если вы загружаете файлы через FTP, а на вашем компьютере вирус, он может заражать файлы при загрузке. Проверьте компьютер антивирусом и используйте SFTP вместо FTP.
• Соседи по серверу заражены — на shared-хостинге (Beget, Timeweb) соседние сайты могут влиять на ваш. Если на сервере есть другой заражённый сайт, он может атаковать ваш через локальную сеть. Решение: переезд на VPS.

Сопровождение и поддержка сайта

Защита, обновление, мониторинг, чистка вирусов.

от 5.400 ₽/мес

Подробнее

SEO аудит

Проверка сайта после взлома.

1.800

Подробнее