Первый час: не спешите все удалять
Открываете админку WordPress, а там что-то не так. Посетителей перебрасывает на чужой сайт. Или хостинг прислал письмо о подозрительных файлах. В первый час важно действовать быстро, но быстро - не значит удалять все подряд. Если сайт на WordPress взломали, сначала остановите вред, сохраните копию для расследования и только потом убирайте все пути, по которым злоумышленник может вернуться.
Не уверены, что это взлом? Сначала проверьте признаки взлома WordPress. Если сомнений уже нет - вот порядок действий. Он пригодится и когда нужно восстановление сайта после взлома, и когда предстоит очистка сайта от вирусов.
Шаг 1. Остановите работу зараженного сайта
Не оставляйте скомпрометированную корзину принимать заказы, пока разбираетесь. Плашка «мы уже решаем проблему» не помешает вредоносному скрипту считывать платежные данные или отправлять покупателей куда-то еще. Для магазина это не мелочь: каждый новый заказ может означать нового пострадавшего клиента.
- Если посетителей перекидывает на другой адрес или есть подозрение, что затронута оплата, попросите хостинг временно отключить сайт либо поставить страницу техработ на уровне сервера.
- Если магазин работает на WooCommerce и могла пострадать страница оплаты, приостановите прием платежей. Есть риск утечки платежных данных - свяжитесь с платежным провайдером.
- Сообщите хостингу о возможном взломе. Попросите сохранить журналы доступа и ошибок, пока они не перезаписались или не удалились автоматически.
Обычный плагин «сайт на обслуживании» тут не спасает: вредоносный код может продолжать работать рядом с ним. В серьезном случае используйте инструменты хостинга. И оставьте себе надежный доступ к аккаунту хостинга - расследование еще впереди. Обычно написать в поддержку можно за 10 минут; сколько займет отключение, зависит от хостинга.
Шаг 2. Сохраните копию взломанного сайта
Прежде чем менять пароли, обновлять плагины или удалять файлы, сделайте полную копию текущего состояния: файлы плюс база данных. Да, вместе с заражением. По этой копии потом можно понять, когда появился бэкдор, что изменили в заказе или записи и какую учетную запись завел атакующий. Без нее искать точку входа гораздо труднее.
Подойдет инструмент резервного копирования у хостинга. Другой вариант - отдельно выгрузить файлы и базу, а затем убрать обе копии с пострадавшего сервера. Явно подпишите архив «взломан»: восстанавливать его на рабочем сайте без проверки нельзя. Заодно попросите у хостинга логи за предполагаемый период взлома. Не умеете безопасно выгрузить данные сами? Пусть поддержка сделает это до любой очистки. На экспорт может уйти от нескольких минут до часа, если сайт большой.
Шаг 3. Верните контроль над доступами
Считайте, что пароли и ключи, хранившиеся на сервере, могли попасть к атакующему. Меняйте их с устройства, которому доверяете. И не рассылайте новые пароли коллегам по обычной почте - так можно быстро устроить себе второй инцидент.
- Сбросьте пароли всех администраторов WordPress. Проверьте, кому вообще еще нужен доступ администратора.
- Поменяйте пароль хостинга или cPanel, а также все учетные данные SFTP и SSH. Незнакомые учетные записи удалите.
- Смените пароль пользователя базы данных в панели хостинга и сразу обновите соответствующее значение в
wp-config.php, иначе сайт потеряет связь с базой. - Замените секретные ключи WordPress в
wp-config.php, обновите подключенные API-ключи и отзовите пароли приложений WordPress, которые больше не нужны.
Замена секретных ключей сбросит действующие cookie входа в WordPress - пользователям придется войти заново. Где возможно, завершите активные сеансы через инструменты безопасности или хостинга. Но не путайте смену паролей с очисткой. Если на сервере остался бэкдор, атакующий создаст себе нового администратора хоть завтра. Эта работа дает вам передышку, не больше.
Шаг 4. Найдите все бэкдоры
Начните с проверки файлов и базы данных. Лучше работать с копией или в контролируемом окружении хостинга, особенно если действующий магазин еще обрабатывает заказы. Раздел «Пользователи» в WordPress полезен, но доверять ему целиком нельзя: вредоносный код умеет скрывать учетку на этой странице. Посмотрите напрямую таблицы wp_users и wp_usermeta. Префикс таблиц у вас может отличаться от wp_. Ищите права администратора, незнакомые адреса почты и аккаунты, созданные примерно во время инцидента.
- Проверьте
wp-content/mu-plugins/, обычные плагины и темы: нет ли того, что вы не устанавливали. Must-use плагины не видны в привычном списке плагинов. - Ищите PHP-файлы внутри
wp-content/uploads/. Загруженным картинкам исполняемый PHP ни к чему. - Посмотрите недавние изменения PHP командой
find wp-content -type f -name '*.php' -mtime -7. Подстройте число дней под свою историю. Старый бэкдор такой поиск не покажет. - Сравните
wp-config.phpи.htaccessс заведомо чистыми копиями. Проверьте задания WP-Cron и серверный cron в аккаунте хостинга. - Поищите внедренные скрипты, редиректы и странные настройки администраторов в
wp_optionsи содержимом записей. Если префикс другой, смотрите соответствующие таблицы.
Если есть WP-CLI, запустите wp core verify-checksums и wp plugin verify-checksums --all. Команды помогают найти измененные файлы ядра WordPress и плагинов, доступных через wordpress.org. Но галочка «все чисто» после них не появляется: платные и самописные плагины придется проверять отдельно. Если консоль для вас темный лес, не экспериментируйте на рабочем магазине - попросите специалиста. Сама проверка занимает минуты, разбор находок может затянуться на часы.
Зачем столько возни? В октябре 2026 года Patchstack сообщил о кампании, где вредоносные скрипты прятали в заявках Ninja Forms и заказах WooCommerce с WPC Product Bundles. Скрипт срабатывал, когда администратор открывал такую заявку или заказ. Атака ставила поддельный плагин «WP Smart Thumbnails», создавала видимого и скрытого администраторов, секретную ссылку для входа и файловый менеджер. Часть компонентов лежала в wp-content/mu-plugins/. Обновление уязвимого плагина могло остановить новые атаки, но уже оставленные бэкдоры никуда бы не делись.
Шаг 5. Очистите сайт или соберите его заново из надежных копий
Очень хочется просто вырезать подозрительную строчку из PHP-файла. Я бы заменил файл целиком: кто знает, что спрятано еще на двадцать строк ниже. Поставьте свежие файлы ядра WordPress. Плагины с wordpress.org скачайте и установите заново; платные плагины и темы берите у их разработчиков. wp-config.php и wp-content/ оставляйте только после проверки. Перезаписывать настройки и папку с загрузками вслепую - плохая идея.
Удалите найденные вредоносные учетные записи, файлы, задания по расписанию и вставки в базе. Есть бэкап, сделанный до проникновения? Восстановление может оказаться быстрее ручной чистки. Но если копию создали уже после взлома, в ней сидит тот же бэкдор. Не знаете дату первого заражения - одного отката мало. Для небольшого сайта замена файлов может занять несколько часов; с магазином и заказами в базе проверка обычно дольше.
Шаг 6. Закройте путь, по которому вошли
Выясните, как атакующий получил доступ. Необновленный плагин? Украденный пароль администратора? Старый SFTP-аккаунт подрядчика, о котором все забыли? Если пропустить этот вопрос, злоумышленник вернется через ту же дверь. Вот почему разбор логов и сохраненная копия так нужны.
После сохранения улик обновите WordPress, плагины и темы. Уберите заброшенные расширения, неиспользуемые темы и любое пиратское ПО. Пересмотрите права администраторов, включите двухфакторную аутентификацию там, где это возможно. Для магазина отдельно проверьте корзину, оформление заказа, ответы платежной системы и письма о заказах. Главная страница открывается? Отлично. Но если покупатель не может оплатить товар, сайт еще не восстановлен.
Когда срочные работы закончены, заведите привычный график обновлений и бэкапов. Проверка раз в неделю обычно занимает 20-30 минут, если изменений немного. Нет на это времени - обслуживание WordPress вручную можно передать специалистам.
Шаг 7. Проверьте сайт снаружи и следите, не вернулась ли зараза
Откройте отчет «Проблемы безопасности» в Google Search Console. Если Google пометил сайт как опасный, устраните причину по его рекомендациям и запросите повторную проверку. Заодно узнайте, не попал ли домен в крупные браузерные и защитные черные списки. Повторяйте эти проверки в ближайшие недели - поисковые системы не всегда замечают исправления мгновенно.
Следите за новыми пользователями, изменениями файлов, редиректами наружу, незнакомыми заданиями cron и свежими предупреждениями хостинга. Бэкапы в этот период не отключайте. Тот же странный файл появился снова? Не удаляйте его по кругу - что-то его создает. В статье о том, почему сайт снова заражается после очистки, разбираем, где искать причину.
Когда звать специалиста
Просите помощи, если нашли скрытого администратора, сайт заразился повторно или могли пострадать данные покупателей. То же относится к ситуации, когда у вас нет заведомо чистого бэкапа либо безопасного доступа к базе и логам хостинга. Убрать заметный мусор несложно. А вот пропустить спрятанный файловый менеджер - вполне реально.
Для бизнеса в ЕС возможную утечку персональных данных нужно оценивать без промедления. По статье 33 GDPR при определенных условиях о нарушении надо сообщить надзорному органу в течение 72 часов после того, как вам стало о нем известно. Записывайте, что уже выяснили, и обратитесь за юридической консультацией или советом специалиста по защите данных. Не ждите идеального технического отчета, прежде чем решать вопрос с уведомлением. Если расследование и ремонт хотите поручить нам, посмотрите услугу очистки взломанного сайта WordPress.
Что сделать прямо сейчас
Если сайт еще открыт, а оплату или редиректы могли подменить, напишите хостингу прямо сейчас. Попросите поставить страницу техработ на уровне сервера и сохранить логи. Следом сделайте копию файлов и базы. Не стирайте улику, по которой можно понять, как атакующий попал внутрь.