Как проверить, не взломан ли ваш сайт или сервер: пошаговые проверки для виртуального хостинга, WordPress и VPS и что делать в первую очередь, если вы что-то нашли

Для кого: для частных лиц и небольших компаний с сайтом на виртуальном хостинге, WordPress или VPS, которые сейчас задаются вопросом «меня взломали?». Руководство показывает, как самостоятельно проверить собственный сайт и сервер. Оно основано на официальной документации WordPress.org, WP-CLI, Google Search Central, страницах руководства (man) каждой команды, материалах японских IPA и JPCERT/CC, а также GDPR. Техники атак здесь не рассматриваются.

Признаки, при которых стоит заподозрить вторжение

Если что-то из этого подходит, переходите к проверкам по средам ниже. В «FAQ My site was hacked» на WordPress.org тоже перечислены явные признаки взлома, в том числе попадание в чёрный список поисковых систем, отключение сайта хостингом и несанкционированные действия, например создание новых пользователей.

Проверки по средам

Проверьте строки, которые соответствуют вашей конфигурации. Если у вас WordPress на виртуальном хостинге, подходят обе первые строки.

Виртуальный хостинг

Даже без SSH панель управления обычно позволяет проверить эти три вещи (названия у разных хостингов отличаются).

• Откройте публичную папку в файловом менеджере и отсортируйте по дате изменения. Обращайте внимание на файлы, изменённые в дни, когда вы их не трогали, PHP-файлы с бессмысленными именами и PHP-файлы в папках для изображений, например uploads
• Скачайте журналы доступа и ошибок и проверьте, откуда и когда приходили запросы к админке (на WordPress — /wp-login.php и /wp-admin/), а также запросы к незнакомым URL
• Если видны счётчики или история отправки почты, поищите большие объёмы, которые вы не отправляли

Проверьте и .htaccess. WordPress.org называет .htaccess одним из файлов, которые чаще всего изменяют и используют во вред независимо от типа заражения, и отмечает, что index.php, header.php и footer.php — ценные цели, потому что влияют на каждый запрос страницы.

WordPress

В консоли проверьте два места.

• «Users» (Пользователи) → «All Users» (Все пользователи): есть ли кто-то с ролью «Administrator» (Администратор), кого вы не создавали?
• «Plugins» (Плагины) → «Installed Plugins» (Установленные): есть ли плагин, который вы не устанавливали? Так же проверьте «Appearance» (Внешний вид) → «Themes» (Темы)

Если на сервере доступен WP-CLI (официальный инструмент командной строки для WordPress), файлы можно автоматически сверить с официальным выпуском.

# Check WordPress core files against WordPress.org checksums
wp core verify-checksums
# Also warn about non-WordPress files in the WordPress root directory
wp core verify-checksums --include-root
# Verify plugins distributed on WordPress.org
wp plugin verify-checksums --all
# List administrator accounts with their registration dates
wp user list --role=administrator

При чистом результате выводится Success: WordPress installation verifies against checksums. Для несовпадающего файла выводится Warning: File doesn't verify against checksum: и его имя. Проверка плагинов сравнивает их с контрольными суммами WordPress.org, поэтому премиум-плагины и собственные темы так проверить нельзя. Для них заново скачайте ту же версию у разработчика и сравните.

VPS (Linux)

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

# SSH login records (the unit is ssh on Debian/Ubuntu, sshd on RHEL-family)
sudo journalctl -u ssh --since "2026-10-01"
# Recent logins (on Debian 13, use wtmpdb last instead; install the wtmpdb and libpam-wtmpdb packages)
last -a
# Each user's last login (on Debian 13, use lastlog2 instead; install the lastlog2 and libpam-lastlog2 packages)
lastlog
# SSH public keys: the current user's (other users: /home/*/.ssh/authorized_keys) and root's
cat ~/.ssh/authorized_keys
sudo cat /root/.ssh/authorized_keys
# Scheduled jobs (per user and system-wide)
crontab -l
sudo crontab -l -u root
sudo cat /etc/crontab
sudo ls -la /etc/cron.d
# Users, and the group with admin rights (wheel on RHEL-family)
getent passwd
getent group sudo
# Listening TCP ports and the programs behind them
sudo ss -tlnp
# Files in the web root whose contents changed in the last 7 days
sudo find /var/www -type f -mtime -7
# Have package files changed since they were installed?
sudo debsums -s      # Debian/Ubuntu (needs the debsums package)
sudo rpm -Va         # RHEL-family

Как читать результаты:

• В выводе journalctl проверьте IP-адреса источников успешных входов (Accepted): нет ли среди них чужих. Если ничего не выводится, имя юнита может отличаться; узнайте имя службы SSH командой systemctl list-units --type=service
• В authorized_keys ищите открытые ключи, которые вы не добавляли. Управление ключами, которыми можно войти на сервер, разобрано в статье минимальные привилегии для SSH-ключей
• В cron ищите строки, которые скачивают и запускают что-то с незнакомого URL
• В списке ss ищите программы на прослушивании, которые вы не запускали
• debsums -s сообщает только о проблемных файлах; rpm -Va помечает изменённые файлы кодами, например размер (S), дайджест (5) и время изменения (T)

Google Search Console

Если сайт ещё не добавлен в Search Console, сначала добавьте его и подтвердите права владельца.

• В отчёте «Security issues» (Проблемы безопасности) посмотрите, указаны ли проблемы. Они делятся на три большие категории: «Hacked content» (Взломанный контент), «Malware and unwanted software» (Вредоносное и нежелательное ПО) и «Social engineering» (Социальная инженерия), обычно с примерами URL. Некоторые проблемы приходят без примеров URL; Google поясняет, что это не значит, что затронутых страниц нет
• Выполните в Google поиск site:вашдомен и поищите страницы, которых вы не создавали. Google сообщает, что так выводятся страницы вашего сайта, включая те, что мог добавить взломщик
• Проверьте подозрительные страницы инструментом проверки URL, чтобы увидеть, как их видит Google

О терминах: следы уже произошедшей компрометации, как описанные выше, называют IOC (индикаторы компрометации). См. что такое IOC, а о распознавании атаки по поведению, пока она ещё идёт, — что такое IOA.

Что делать в первую очередь, если вы что-то нашли

Если перепутать порядок, вы либо уничтожите улики, либо восстановите сайт, оставив точку входа злоумышленника открытой. Действуйте сверху вниз.

Если могли утечь персональные данные

Если вы обрабатываете персональные данные как бизнес и могли утечь отправки контактной формы или записи участников, проверьте правила там, где вы работаете.

• ЕС и Великобритания (GDPR, статья 33): уведомите надзорный орган без неоправданной задержки и, если это возможно, в течение 72 часов с момента, когда вы узнали об утечке персональных данных, кроме случаев, когда она вряд ли создаёт риск для прав и свобод людей. Статья 34 описывает, когда нужно также сообщить пострадавшим
• Япония: Комиссия по защите персональной информации (PPC) перечисляет четыре категории, о которых нужно сообщать, — чувствительные данные, риск финансового ущерба, подозрение на неправомерную цель и более 1000 человек. Утечка в результате несанкционированного доступа приводится как пример категории неправомерной цели. Предварительный отчёт подаётся в течение 3–5 дней с момента обнаружения, окончательный — в течение 30 дней (60 дней для категории неправомерной цели), и пострадавших тоже нужно уведомить
• В других странах: уточните у национального органа по защите данных

Куда обратиться за помощью

Источники (официальные)

• WordPress.org: FAQ My site was hacked — wordpress.org
• WordPress.org: Administration Screens — wordpress.org
• WP-CLI: wp core verify-checksums — developer.wordpress.org
• WP-CLI: wp plugin verify-checksums — developer.wordpress.org
• WP-CLI: wp user list — developer.wordpress.org
• Google: отчёт «Security issues» (Справка Search Console) — support.google.com
• Google: How do I know if my site was hacked? (web.dev) — web.dev
• Google: Fix the cloaked keywords and links hack (web.dev) — web.dev
• Блог Google Search Central: Detect and get rid of unwanted sneaky mobile redirects (октябрь 2015 г.) — developers.google.com
• Справка Google Поиска: Report a problem with Google Search (о пометке «This site may be hacked») — support.google.com
• Страницы руководства Debian: journalctl(1), last(1), lastlog(8), sshd(8), crontab(1), cron(8), ss(8), find(1), debsums(1) — manpages.debian.org
• RPM: rpm(8) (как читать вывод --verify) — rpm.org
• Примечания к выпуску Debian 13 (trixie): команды last, lastb и lastlog заменены — debian.org
• GDPR (Регламент (ЕС) 2016/679), статьи 33 и 34 — eur-lex.europa.eu
• Комиссия по защите персональной информации, Япония: обязательные отчёты об утечках и уведомление пострадавших (на японском) — ppc.go.jp
• Комиссия по защите персональной информации, Япония: реагирование на утечки данных (на японском) — ppc.go.jp
• JPCERT/CC: запрос на реагирование на инцидент (на японском) — jpcert.or.jp
• IPA: сообщения о компьютерных вирусах и несанкционированном доступе (на японском) — ipa.go.jp

Читать дальше

• Для личных аккаунтов: Как проверить, не заходил ли кто-то в ваш аккаунт
• Если взломан сам хостинг: Что делать клиентам, когда взломан ваш веб-хостинг (на английском; подготовка к тому, что ваши собственные настройки не предотвратят)
• Где лежат файлы: Не оставили ли вы секретный файл в публичном каталоге? / Как не выставить .env в интернет на виртуальном хостинге
• WordPress: Безопасность WordPress — справочник по укреплению в продакшене / частая точка входа: уязвимости загрузки файлов (на английском)
• Термины: Что такое IOC? / Что такое IOA? / Что такое бэкдор? (на английском) / Что такое вредоносное ПО?
• Восстановление: Основы резервного копирования