Почему откат из бэкапа не лечит взломанный сайт (и как вытащить проект из петли)

В 2021 году ко мне пришел владелец интернет-магазина автозапчастей. У него была выработана простая реакция на стресс: сайт взломали, он заходит в панель хостинга, нажимает «Откатить на вчера», сайт снова открывается без мобильных редиректов. Через три дня — та же история. За две недели он нажал эту кнопку шесть раз, пока хостер намертво не заблокировал сервер за рассылку спама с 40 000 ящиков-однодневок.

Откат из бэкапа — это первое, за что хватается бизнес. Это логично, быстро и дает иллюзию контроля. Проблема в том, что в 9 из 10 случаев откат не просто бесполезен. Он вреден.

Ловушка «чистой копии»

Бэкап возвращает файлы и базу данных к состоянию, скажем, недельной давности. Но он не закрывает дыру, через которую к вам залезли. Если у вас стоял брошенный три года назад плагин для слайдера или на сервере остался тестовый PHP-скрипт с паролем от базы, автоматический бот найдет его снова ровно через двадцать минут после восстановления.

Вторая проблема еще неприятнее: инкубационный период. По моей статистике, средний бэкдор тихо лежит в структуре каталогов от 14 до 90 дней, прежде чем злоумышленники запустят полезную нагрузку — дорвеи, криптомайнеры или тихий парсинг платежных данных. Когда сайт наконец «заболел» на глазах у пользователей, все ваши последние тридцать бэкапов уже заражены. Вы просто откатываетесь из одного инфицированного состояния в другое, теряя свежие заказы и комментарии клиентов.

Анатомия взлома: почему плагины безопасности бессильны

Когда владельцы понимают, что откат не сработал, они ставят Wordfence или Sucuri и нажимают кнопку сканирования. Плагин радостно рапортует, что удалил три подозрительных файла. На утро сайт снова лежит.

Любой толковый взлом состоит из трех звеньев:

  1. Точка входа (уязвимость): SQL-инъекция, RCE через загрузку картинок, банальный брутфорс админки со слабым паролем.
  2. Закрепление (бэкдор): скрытый способ вернуться на сервер в обход стандартной авторизации WordPress.
  3. Монетизация (малварь): то, что приносит хакерам деньги (спам, скрытые ссылки, перенаправление мобильного трафика на фишинг).

Сканеры безопасности обычно видят только третье звено — саму малварь, потому что у нее есть явные сигнатуры. Но они слепы к бэкдорам, написанным в две строчки. Настоящий поиск бэкдора на сайте — это ручная работа. Я находил шеллы, замаскированные под шрифты в каталоге темы, спрятанные внутри base64-строк в таблице wp_options, и миниатюрные инъекции прямо в ядро, в файл wp-settings.php, где вызов вредоносной функции ловко терялся среди сотен стандартных констант движка.

Как строится реальное восстановление взломанного WordPress

Если вы хотите прервать этот день сурка, забудьте про полумеры. Полноценная чистка малвари wordpress строится по жесткому протоколу, где нет места догадкам.

1. Изоляция и заморозка
Первым делом сайт переводится в режим обслуживания, меняются пароли к FTP/SSH, базе данных и хостингу. Критически важно отключить выполнение PHP в каталоге /wp-content/uploads/ через директивы веб-сервера. Девять из десяти вредоносных скриптов пытаются исполняться именно оттуда, маскируясь под аватарки или PDF-документы.

2. Полная замена окружения
Я никогда не трачу время на «лечение» файлов ядра или плагинов. Мы просто сносим директории /wp-admin/, /wp-includes/ и все файлы движка в корне, кроме wp-config.php, и накатываем оригинальные версии напрямую из официального репозитория wordpress.org. То же самое делается с плагинами: папки удаляются и загружаются заново из чистых архивов авторов. Единственное место в файловой системе, требующее скрупулезного построчного ручного аудита — это активная кастомная тема и папка загрузок.

3. Стерилизация базы данных
Многие забывают про базу, а зря. Вредоносный код обожает прятаться в хуках wp_cron, записях wp_posts (в виде невидимых <script> тегов) и таблице wp_users. Обязательно проверяются скрытые пользователи с правами администратора, которых злоумышленники часто создают напрямую через сырые SQL-запросы, минуя интерфейс админки.

4. Работа по логам и закрытие уязвимостей после взлома
Удалить вирус — половина дела. Нужно понять, как он туда попал. Для этого мы берем временную метку (timestamp) создания первого найденного бэкдора и поднимаем сырые логи доступа к серверу (access.log) за эту дату. Логи не врут. В них четко видно: пришел POST-запрос на уязвимый AJAX-обработчик старой темы, за ним последовал статус 200, и через секунду в uploads лег файл license.php. После этого проводится точечное закрытие уязвимостей после взлома: выпиливание дырявого кода, запрет опасных функций вроде eval и exec на уровне PHP, включение двухфакторной аутентификации для всех пользователей с правами выше редактора.

Спокойствие стоит системы

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

Если у вас нет времени сутками разбирать сырые дампы логов и вручную деобфусцировать вредоносные скрипты, изучите, как у нас устроена методика восстановления взломанного WordPress-сайта в GuardLabs — мы берем проект, полностью вычищаем заразу, гарантированно закрываем точки входа и возвращаем стабильный, чистый ресурс без риска повторного падения через неделю.