Взлом сайта — стрессовая ситуация, требующая чётких и быстрых действий. Главное правило: не паниковать, действовать системно. Большинство сайтов можно полностью восстановить за несколько часов.

Признаки взлома сайта

Редирект на чужой сайт (фарминг, фишинг)
Предупреждение Google «Сайт содержит вредоносное ПО»
Хостинг заблокировал аккаунт за рассылку спама
Появление новых файлов или директорий
Необъяснимый рост трафика или нагрузки на сервер
Жалобы пользователей на антивирус

Шаг 1: Изоляция и сохранение доказательств

cp -r /var/www/site/ /tmp/site-backup-hacked/
find /var/www/site/ -newer /var/www/site/index.php -type f | head -50
ls -lat /var/www/site/ | head -20

Шаг 2: Поиск вредоносного кода

apt install clamav -y && freshclam
clamscan -r --infected /var/www/site/

find /var/www/site/ -name "*.php" -exec grep -l "base64_decode\|eval\|gzinflate\|str_rot13\|preg_replace.*e" {} \;
find /var/www/site/ -name "*.php" -newer /var/log/dpkg.log -type f
grep -r "FilesMan\|c99\|r57\|WSO Shell\|webshell" /var/www/site/

Шаг 3: Очистка или восстановление

grep -r "eval(base64_decode" /var/www/wordpress/ --include="*.php" -l | while read f; do
  echo "Infected: $f"
done

for infected_file in $(grep -rl "eval(base64_decode" /var/www/wordpress/ --include="*.php"); do
  rm "$infected_file"
  echo "Removed: $infected_file"
done

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

Шаг 4: Устранение причины взлома

grep "access.log" /var/log/nginx/access.log | grep "POST /wp-admin\|/xmlrpc.php" | sort | uniq -c | sort -rn | head -20
grep "404\|403" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

Шаг 5: Уведомить Google

После очистки: Google Search Console → Безопасность → Запросить проверку. Снятие предупреждения занимает 1–3 дня.

Чеклист после восстановления

Действие	Статус
Сменить все пароли (БД, FTP, панель)
Обновить CMS, плагины, темы
Установить WAF (Wordfence, ModSecurity)
Настроить мониторинг изменений файлов
Проверить права на файлы
Запросить проверку в Google Search Console
Уведомить хостинг о чистке

Профилактика важнее лечения: Настройте автоматические обновления CMS/плагинов, регулярные бэкапы, мониторинг файловой системы (auditd, inotifywait) и WAF. Это сократит риск взлома на 90%.

Типичные сообщения при взломе

Сообщение	Что оно значит	Что делать
«Deceptive site ahead» в браузере Chrome	Google Safe Browsing нашёл на сайте фишинговый или обманный контент	Очистите сайт, затем запросите пересмотр в Google Search Console → Безопасность
«Your account has been suspended due to abuse complaints» от хостинга	С сайта рассылался спам или шёл вредоносный трафик, хостинг заблокировал аккаунт превентивно	Свяжитесь с поддержкой хостинга, получите список нарушений, устраните причину до разблокировки
Незнакомое RewriteRule-правило в .htaccess	Атакующий добавил редирект части трафика на сторонний спам- или фишинговый домен	Удалите чужие правила, оставив только те, что добавляли вы сами
siteurl в таблице wp_options указывает на чужой домен	Специфичный для WordPress признак: через уязвимость изменили адрес сайта в базе	Верните значение вручную через `wp option update siteurl "https://example.com"`

Сравнение подходов к очистке

Подход	Скорость	Надёжность	Стоимость
Восстановление из чистого бэкапа	Быстро — минуты-часы	Высокая, если бэкап точно снят до заражения	Бесплатно при наличии бэкапа
Ручная очистка файлов	Медленно — часы или дни	Средняя, есть риск пропустить один заражённый файл	Бесплатно, но дорого по времени специалиста
Платная услуга (Sucuri, MalCare и похожие)	Быстро — обычно в течение суток	Высокая, профессиональный аудит и мониторинг после	$100–400 за разовую чистку

Когда восстановление сложнее чеклиста

Заражение затронуло не только файлы сайта, а сам сервер (руткит, изменённые системные бинарники) — нужен полный аудит ОС, а не только веб-директории
Shared-хостинг, где заразился соседний аккаунт и постоянно переинфицирует ваш через общие ресурсы сервера — единственное решение — переезд на изолированный VDS
Вредоносный код попал через доверенное обновление легитимного плагина (supply-chain атака) — обычное сравнение с оригиналом плагина ничего не покажет
Используется ещё не закрытая 0-day уязвимость в ядре CMS — временное решение — WAF-правило, блокирующее эксплойт, до выхода патча

Чтобы такая ситуация не повторилась, стоит пройтись по чеклисту «Безопасность WordPress: полный чеклист 2026», а на будущее — иметь под рукой заранее готовый «План реагирования на инцидент: первые 60 минут».

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

После очистки убедитесь, что не осталось скрытых точек возврата для атакующего:

# Проверить cron-задачи на сервере и в самом WordPress
crontab -l -u www-data
wp cron event list

# Проверить список администраторов — не появился ли новый
wp user list --role=administrator

# Проверить исходящие соединения на подозрительные адреса
netstat -antp | grep ESTABLISHED

# Повторное сканирование другим инструментом для перекрёстной проверки
apt install rkhunter -y && rkhunter --check --sk

Для защиты от повторного подбора паролей на панели и SSH после чистки поставьте Fail2ban: защита SSH и Nginx от подбора паролей.