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

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

Сайт начал вести себя странно. Кто-то жалуется, что вместо вашей страницы открывается аптека. В Метрике с утра скачок переходов из Японии. Хостер прислал письмо со словом «abuse» в теме. Все три истории я слышал на этой неделе, и все три закончились одним и тем же: сайт был заражён, точку входа никто не закрывал месяцами. Ниже разберём семь признаков, по которым вы поймёте, что это именно взлом, а не глюк темы или каприз кеша. И что делать, если вы уже узнали хотя бы один.

Семь признаков, по которым видно, что сайт скомпрометирован

Я выделяю семь, потому что именно эти семь сценариев у меня попадаются чаще всего за последние пять лет работы с малым бизнесом на WordPress, Битрикс и OpenCart. Иногда срабатывает один, иногда сразу четыре. Если у вас совпадает хотя бы один из них и совпадение не объясняется обычной технической причиной, считайте это инцидентом.

1. Браузер пишет «Опасный сайт»

Chrome, Edge, Яндекс Браузер и Firefox опираются на одну общую базу Google Safe Browsing плюс свою локальную (у Яндекса своя). Когда хотя бы один из этих сервисов считает, что на сайте есть фишинг, малварь или нежелательный софт, в браузере появляется красная страница. Это значит, что робот Google или Яндекса уже видел вредоносный код или поведение, и отметка теперь работает на стороне браузера, а не на вашей.

Проверьте сами:

• https://transparencyreport.google.com/safe-browsing/search?url=ваш-домен.ru покажет статус Safe Browsing.
• В Search Console раздел «Безопасность и меры, принятые вручную» покажет конкретные URL и тип угрозы.
• В Яндекс Вебмастере в «Диагностике сайта» будет красное уведомление с категорией нарушения.

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

2. В поисковой выдаче появились страницы на чужом языке

Открываете в Яндексе или Google запрос site:ваш-домен.ru и видите тысячи страниц на японском, китайском, индонезийском или арабском. Чаще всего это так называемый японский SEO-спам, технология известна с 2015 года и до сих пор активно используется. Злоумышленник поднимает на вашем сайте генератор страниц с фармой, репликами, казино и линк-фермой, чтобы перенаправить ссылочный вес на свои проекты.

Признак коварен тем, что владелец сайта про эти страницы обычно не знает: они отдаются только поисковому боту, обычный посетитель видит ваш нормальный контент. Поэтому проверять надо именно site: и логи запросов от Yandex/Googlebot.

3. Сайт редиректит на казино, фарму или порно

Заходите с телефона по запросу из Яндекса, и вместо вашего сайта открывается ставочная контора. Заходите с десктопа, прямой URL, всё нормально. Это типовой шаблон cloaking-редиректа. В код вшита проверка User-Agent, источника перехода (Referer) и иногда геолокации, и редирект включается только при определённых условиях.

Места, где обычно лежит инжект:

• .htaccess в корне или внутри wp-content/.
• header.php или functions.php темы.
• Таблица wp_options в WordPress, ключ siteurl, home или новый кастомный.
• JS-файлы темы или плагинов с base64-обфускацией.
• Битрикс: /bitrix/php_interface/init.php, /bitrix/templates/.default/header.php.

Подробный разбор у меня есть в отдельной статье, как выкорчёвывать редирект из WordPress, Битрикс и OpenCart.

4. Письмо от хостера про abuse, спам или майнер

Тема письма обычно начинается со слов «abuse report», «превышение нагрузки», «исходящий спам» или «обнаружен майнер». Внутри ссылка на лог, дата, иногда сразу скриншот процесса CPU 1200 процентов и предупреждение, что аккаунт будет заблокирован через 24 часа, если ничего не сделать.

Игнорировать такие письма категорически нельзя. Хостер не шлёт их просто так: его автоматика реально засекла аномалию. Если в течение суток не отреагировать, у большинства российских хостингов аккаунт уходит в принудительный suspend, и сайт становится недоступен. Я видел случаи, когда из-за этого магазин лежал три дня в декабре, потому что письмо ушло в спам-папку владельца.

5. В админке появились чужие пользователи

Заходите в админку CMS, открываете список пользователей и видите аккаунт, которого там не должно быть. Чаще всего:

• английский ник вроде admin1, support, wordpress на сайте, где все ваши коллеги пишут кириллицей;
• email на бесплатных сервисах (@yopmail, @10minutemail), которые никто из своих не использует;
• права администратора, выданные сегодня или вчера;
• последний вход с IP из страны, где у вас никого нет.

В WordPress смотрите Пользователи -> Все пользователи, фильтр «Администратор». В Битрикс админка Настройки -> Пользователи -> Список пользователей, сортировка по дате создания. В OpenCart Система -> Пользователи -> Пользователи.

6. Странные файлы в файловой системе

Если есть FTP или SSH-доступ, пройдитесь по типичным местам, где взломщики прячут шеллы и бэкдоры. Чек-лист подозрительных файлов:

• В корне: wp-temp.php, wp-cache.php, .wp-config.php~, файлы с двойным расширением (logo.php.jpg).
• В wp-content/uploads/: любые .php, .phtml, .phar файлы. В uploads PHP не должно быть никогда.
• В темах: новые файлы, которые не входят в стандартный комплект темы (сравните по checksum или по составу из официального ZIP).
• В плагинах: class-wp-update.php, wp-vcd.php, radio.php без объяснимого происхождения.
• В bitrix/cache/, bitrix/managed_cache/: PHP с обфусцированным кодом, хотя кеш должен быть обычным.

Командная строка через SSH помогает быстрее любого FTP-клиента:

# Все PHP-файлы, изменённые за последние 7 дней
find . -name "*.php" -mtime -7 -type f

# PHP-файлы в uploads, где их быть не должно
find ./wp-content/uploads -name "*.php" -type f

# Файлы с подозрительными сигнатурами
grep -RIl "eval(base64_decode|str_rot13|gzinflate(base64" --include="*.php" .

7. В логах аномальный трафик

Загляните в access.log хостинга или в раздел «Логи» cPanel/ISPmanager. Признаки, по которым видно атаку:

• Тысячи POST-запросов на /wp-login.php, /bitrix/admin/, /admin/index.php с одного или нескольких IP за короткое время. Это брутфорс.
• Сотни GET-запросов на /xmlrpc.php или на странные URL вроде /?author=1, /?author=2. Это разведка пользователей.
• POST на uploads-папку. Это уже эксплуатация уязвимости.
• Кратный рост 5xx-ответов. Сервер не справляется или падает на каком-то конкретном файле.

# Топ-10 IP по запросам за день
awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -10

# Все POST на wp-login за сегодня
grep "POST /wp-login.php" access.log | grep "$(date +%d/%b/%Y)" | wc -l

Что НЕ является признаком взлома

Половина паники в моей практике идёт не от инцидентов, а от обычных технических неисправностей, которые принимают за взлом. Сводная таблица, чтобы не путать:

Симптом	Скорее всего	Почему не взлом
Сайт стал медленнее за неделю	Хостинг, тяжёлый плагин, кеш	Взломщики обычно не нагружают сайт, им нужно тихо
Форма перестала отправлять письма	SMTP, спам-фильтр, антибот	Ломают форму ради блока почты редко
Поплыла вёрстка после обновления	Плагин или тема не совместимы	Взлом редко делает сайт визуально странным
Пропали картинки в каталоге	CDN, кеш, право доступа	Удалять картинки взломщику бессмысленно
Письмо «ваш домен скоро истечёт»	Фишинг от регистратора-двойника	Это атака на вас, а не уже взломанный сайт

Эти симптомы тоже надо чинить, но это не инцидент безопасности. Не разворачивайте процедуру восстановления из-за SMTP-проблемы.

Что сделать в первые 15 минут после обнаружения

Если хотя бы один из семи признаков подтвердился, делаете строго по шагам и без отклонений. Самая частая ошибка владельца в этот момент: попытаться «посмотреть и удалить», из-за чего теряются артефакты, по которым потом надо находить точку входа.

Шаг 1, минута 0-2: закройте сайт от посетителей

Если сайт раздаёт малварь, каждый его посетитель сейчас попадает в группу риска. Включите maintenance-режим или выложите простой index.html с надписью «Технические работы». В WordPress это плагин WP Maintenance Mode (если он у вас уже стоит) или ручной редирект через .htaccess:

RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^123.45.67.89$
RewriteCond %{REQUEST_URI} !^/maintenance.html$
RewriteRule ^(.*)$ /maintenance.html [R=302,L]

Замените 123.45.67.89 на свой IP, чтобы вы видели сайт, а посетители видели заглушку. Не редиректьте на белую 503 без текста, чтобы Яндекс и Google не выпали из индекса с ошибкой.

Шаг 2, минута 2-5: снимите грязный бэкап

Звучит парадоксально, но именно «грязный» бэкап важен. Чистого у вас, скорее всего, нет, а понять, как именно вас поломали и что трогали, можно только по слепку текущего состояния. Через cPanel или ISPmanager делаете полный архив сайта плюс дамп БД. Кладёте его не в ту же папку (иначе попадёт под чистку), а скачиваете на свою машину.

# На сервере, если есть SSH
tar czf /tmp/dirty-backup-$(date +%F).tar.gz public_html/
mysqldump -u user -p dbname > /tmp/dirty-db-$(date +%F).sql
# Скачать локально через scp или sftp

Шаг 3, минута 5-10: смените пароли везде, где есть

Список паролей, которые меняются обязательно, в этом порядке:

1. Хостинг-панель (cPanel/ISPmanager/админка хостера).
2. FTP/SFTP/SSH-аккаунты.
3. База данных (через панель хостера, не забыв обновить wp-config.php).
4. Админка CMS, все аккаунты администраторов.
5. Почта на этом домене.
6. Регистратор домена.
7. Яндекс Вебмастер, Search Console (если был общий пароль).

Пароли длиной от 20 символов, генерируйте через Bitwarden или 1Password, не придумывайте сами. Включите двухфакторную аутентификацию, где её ещё нет.

Шаг 4, минута 10-15: напишите хостеру

Открываете тикет с описанием: «Подозреваю компрометацию аккаунта. Прошу проверить логи входа в панель и FTP за последние 30 дней, прислать список IP-адресов входов.» Хостер обычно отвечает в течение часа и присылает данные, по которым видно, через какой канал зашли.

Если у хостера есть антивирусное сканирование (ImunifyAV, AI-Bolit), просите запустить полное сканирование и прислать отчёт. Это бесплатно у большинства российских хостингов.

Где смотреть логи и какие команды подскажут точку входа

Логов на сайте всегда четыре сорта, и все четыре вам нужны.

Access-логи веб-сервера. Лежат обычно в ~/logs/, /var/log/apache2/, ~/access-logs/ в зависимости от хостинга. Показывают каждый HTTP-запрос с IP, временем, URL и User-Agent. По ним ищется первоначальный POST, который доставил шелл.

Error-логи веб-сервера. Там же рядом. Показывают ошибки PHP и веб-сервера. Часто видно момент, когда взломанный плагин начал крашиться.

Логи входов в панель хостинга. Доступны в самой панели, обычно в разделе «Журнал» или «Безопасность». Показывают, с какого IP и когда заходили в cPanel/ISPmanager.

Логи входов в админку CMS. В WordPress по умолчанию их нет, ставится плагин WP Activity Log или Simple History. В Битрикс встроенный журнал событий.

Полезные команды для быстрого осмотра:

# Когда последний раз менялся wp-config.php
stat wp-config.php

# Все файлы, изменённые позже определённой даты
find . -newermt "2026-03-01" -type f -name "*.php"

# Поиск популярной сигнатуры шеллов
grep -RIl "FilesMan|c99shell|r57shell|WSO" .

# Все cron-задачи пользователя (туда любят прятать backdoor)
crontab -l

Если в логах видите POST на /wp-content/plugins/some-plugin/upload.php за сутки до момента, когда сайт начал редиректить, у вас есть точка входа: эта уязвимость в плагине. Дальше задача обновить плагин или удалить его, иначе через два дня ситуация повторится.

Когда стоит звать подрядчика и как описать инцидент

Самостоятельно вы можете дойти до этапа «сайт закрыт, бэкап снят, пароли сменены». Дальше начинается работа, где цена ошибки высока: можно почистить симптомы, оставить точку входа, и через неделю сайт снова уйдёт в редирект на казино, а Safe Browsing уже не снимет пометку с первого раза.

Звать подрядчика разумно, если:

• В логах не получается понять, через какую дыру зашли.
• После чистки симптомы вернулись в течение суток.
• Сайт уже в Safe Browsing или в чёрном списке Яндекса, и подача на пересмотр была отклонена.
• Сайт коммерческий, простой стоит больше, чем работа специалиста.
• Вы не уверены, что сможете отличить чистый файл темы от заражённого.

При обращении к подрядчику соберите пакет данных, чтобы не тратить первые часы на пинг-понг «пришлите ещё»:

• Доступ к хостинг-панели (или временный пользователь с правами).
• Доступ к админке CMS.
• Точная дата и время, когда вы заметили проблему.
• Скриншоты ошибки в браузере, письма от хостера, странного аккаунта в админке.
• Грязный бэкап, который вы сделали на шаге 2.
• Кратко: что вы уже сделали (закрыли сайт, сменили пароли). Это сэкономит подрядчику час.

С таким пакетом профессионал реагирует в течение часа, а не дня.

Финал и что делать прямо сейчас

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

Если вы дочитали и узнали свой случай, напишите мне в форму. Я подключаюсь в течение часа в рабочее время, нахожу точку входа, чищу заражение и закрываю уязвимость, а не просто удаляю редирект. Стоимость экстренного аудита и чистки фиксированная, без сюрпризов, тарифы и состав работ есть на странице цен. Если интересно почитать ещё про безопасность сайтов, в рубрике «security» есть статьи про чёрные списки, SSL, чистку WordPress и редиректы на казино.

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

Как понять, что сайт взломали

Проверьте четыре места: список пользователей в админке, даты изменения файлов, логи доступа и выдачу по запросу site:вашдомен.ru. Чужой администратор, свежие файлы в папке загрузок, всплеск запросов к одному адресу или посторонние страницы в индексе — каждый пункт по отдельности уже повод для проверки.

Что делать в первые пятнадцать минут

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

Может ли предупреждение браузера оказаться ложной тревогой

Может. Истёкший сертификат даёт похожее окно, но это не взлом. Отличить помогает точная формулировка: если браузер пишет про опасный сайт, а не про проблему с сертификатом, дело в содержимом страницы. Разбор частых ситуаций с сертификатами есть в FAQ Let’s Encrypt.

Как проверить, что сайт вычистили до конца

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