Мобильных посетителей уносит на казино
С телефона сайт открывает чужой домен, с вашего десктопа — работает нормально. Вредонос читает User-Agent и Referer, поэтому владелец проблему не видит, а клиенты и Яндекс видят.
Убираю редиректы на казино, веб-шеллы и спам-рассылку, нахожу точку входа по логам, закрываю уязвимость и снимаю флаг «опасный сайт» в Яндексе и Google. Без абонентки и почасовки — фиксированная цена за результат.
Восемь признаков, с которыми ко мне приходят чаще всего. Достаточно одного совпадения, чтобы проверить сайт: заражение почти никогда не выглядит как «сайт не открывается».
С телефона сайт открывает чужой домен, с вашего десктопа — работает нормально. Вредонос читает User-Agent и Referer, поэтому владелец проблему не видит, а клиенты и Яндекс видят.
Яндекс подставил предупреждение в выдачу, Chrome показывает красный экран «Обманчивый сайт». Органический трафик падает почти до нуля за сутки, а не за неделю.
Письмо от поддержки про рассылку спама, фишинговые страницы или превышение лимита процессов. Сайт выключен и не включится, пока файлы не будут вычищены.
Рядом с bitrix/ появились radio.php, .style.php, wp-conf.php. Отдельный красный флаг — любой PHP внутри /upload/: штатный Битрикс туда исполняемый код не кладёт.
Load average вырос, счётчики Метрики стоят на месте. Так выглядит майнер или почтовый рассыльщик, запущенный из-под пользователя веб-сервера.
Пароль перестал подходить или в списке пользователей появился администратор, которого вы не заводили. Иногда — новый ключ в ~/.ssh/authorized_keys.
В шаблоне или в свойствах инфоблоков появился eval с base64_decode либо скрытый блок ссылок на посторонние сайты. Это SEO-паразитирование: сайт продолжает работать и продвигает чужой ресурс.
IP сервера попал в чёрные списки вроде Spamhaus, уведомления о заказах не доходят до менеджеров и клиентов. Почти всегда это следствие рассылки с заражённого сайта.
Цена фиксированная и не зависит от того, сколько шеллов найдётся внутри. Ниже — полный состав работ и, отдельно, то, что в эту сумму не входит.
Порядок шагов не декоративный. Пункты 02 и 03 — слепок и поиск точки входа — идут до чистки, потому что после удаления файлов искать источник заражения уже нечем.
Смотрю выдачу Яндекса и Google, HTML страниц, корень сайта и /upload/, прогоняю штатную «Проверку целостности файлов» в Мониторе качества. На выходе — подтверждённое «да/нет» и список того, что видно сразу. Если заражения нет, вы ничего не платите.
Снимаю полную копию файлов и базы ДО вмешательства: это и точка отката, и единственный материал для поиска точки входа. Сайт закрываю заглушкой или HTTP-авторизацией, чтобы вредонос не отрабатывал на посетителях и поисковых роботах, пока идёт чистка.
Сортирую файлы по mtime и ctime, беру самый ранний подозрительный и ищу его в access-логах: там видно URL, IP и User-Agent запроса, которым загрузили шелл. Без этого шага чистка бессмысленна — зайдут через ту же дверь на следующей неделе.
Сверяю ядро и коммерческое решение с эталонным дистрибутивом и удаляю всё, чего в нём нет. Отдельно прохожу шаблоны, .htaccess, задания cron, автозагрузку /bitrix/php_interface/init.php и вставки скриптов в базе.
Обновляю уязвимый модуль или решение, выставляю права 644 на файлы и 755 на каталоги, запрещаю выполнение PHP в /upload/, включаю двухфакторную аутентификацию администраторам и меняю все пароли и ключи доступа.
Отправляю сайт на перепроверку в Яндекс.Вебмастере и Google Search Console и передаю письменный отчёт. Флаг снимают не мгновенно: Google обычно убирает предупреждение за 1–3 суток после запроса, Яндекс — в течение недели.
Битрикс — самая распространённая коммерческая CMS в России, поэтому и самая массовая цель. Но взламывают почти всегда не через хитрые уязвимости, а через четыре банальные причины.
Самая частая причина. В начале 2025 года ко мне за месяц пришли три сайта на Битриксе с одинаковой картиной: CPU в полке, свежие PHP-файлы в корне и не обновлённый Aspro с уязвимостью в unserialize. Разбор этого случая — в блоге.
Взлом сайтов на Aspro: уязвимость unserialize →Второй по частоте сценарий — вход в /bitrix/admin/ по подобранному или утёкшему паролю. Отдельная беда — самописные доработки, которые сохраняют пароль пользователя в читаемом виде.
Сохранение пароля пользователя: антипаттерн →Форма обратной связи или загрузка файлов в каталог даёт злоумышленнику положить .php в /upload/. Если сервер его исполняет — шелл готов. Закрывается одним правилом в .htaccess или в конфиге nginx.
Настройка .htaccess для 1С-Битрикс →Заражение живёт на сайте в среднем не часы, а недели: его замечают, когда падает трафик или блокирует хостинг. Регулярный разбор access-логов ловит перебор паролей и обращения к несуществующим PHP-файлам заранее.
Анализ логов Apache и Nginx →Можно, и у 1С-Битрикс для этого есть штатные инструменты: «Проверка целостности файлов» в Мониторе качества находит подменённые файлы ядра, модуль проактивной защиты ловит часть попыток исполнения, а сравнение с эталонным дистрибутивом даёт список всего лишнего. Если заражение свежее и ограничено парой файлов в корне, вы справитесь за вечер.
Сложность не в удалении, а в двух других вопросах: через что зашли и что ещё успели изменить. Веб-шелл — это не вирус в привычном смысле, а обычный PHP-файл, который выполняет команды. Пока открыта дверь, через которую его положили, удаление тела ничего не меняет: за одну-две недели файл появляется снова, иногда под другим именем и в другом каталоге.
Четыре действия до того, как вы обратитесь ко мне или к кому-то ещё. Они бесплатные и заметно ускоряют лечение.
Подозрительный PHP-файл — единственный след, по которому находится точка входа. Удалите его, и лечение превратится в угадывание: шелл вернётся, а откуда — уже не восстановить.
Отдельно от рабочих бэкапов и до любых правок. Заражённая копия полезнее, чем её отсутствие: из неё восстанавливают контент, если чистка пойдёт не так.
Хостинг-панель, SSH, FTP, база, /bitrix/admin/. Если пароли уводили стилером с вашей машины, новая пара логин-пароль утечёт следом за старой.
Именно оттуда отправляется запрос на перепроверку после лечения. Удалённый и заново добавленный сайт проходит проверку дольше, а флаг всё это время висит в выдаче.
Лечение одного сайта на 1С-Битрикс стоит фиксированные 10 000 ₽ независимо от количества найденных шеллов и объёма файлов. В цену входит поиск и удаление вредоносного кода в файлах и базе, определение точки входа по логам, закрытие найденной уязвимости, заявка на снятие флага в Яндексе и Google, письменный отчёт и 14 дней гарантии. Второй и последующие сайты на том же хостинг-аккаунте — по 5 000 ₽. Диагностика до оплаты бесплатна: если заражения нет, вы не платите ничего.
Экспресс-диагностика занимает 2 часа, типовое лечение сайта на Битриксе — 24 часа с момента получения доступов. Сложные случаи (несколько сайтов на одном аккаунте, подменённые файлы ядра, заражение старше полугода) занимают до 3 суток. Снятие предупреждения в поиске идёт дольше самой чистки: Google обычно убирает флаг за 1–3 суток после запроса на перепроверку, Яндекс — в течение недели.
Порядок всегда один: сначала вычистить вредоносный код и закрыть уязвимость, потом отправить сайт на перепроверку в Яндекс.Вебмастере (раздел «Безопасность и нарушения») и в Google Search Console (раздел «Проблемы безопасности»). Запрос на перепроверку до чистки бесполезен: робот находит тот же код, а повторные заявки после отказа рассматриваются дольше. Заявку я отправляю сам в рамках услуги за 10 000 ₽ и контролирую снятие флага.
Да, у Битрикса есть штатные инструменты: «Проверка целостности файлов» в Мониторе качества, модуль проактивной защиты и сравнение с эталонным дистрибутивом — они найдут подменённые файлы ядра. Сложность не в удалении, а в двух других вещах: понять, через какую дыру зашли, и убедиться, что закладок не осталось в базе, в cron и в authorized_keys. Если пропустить любую из них, сайт заражается повторно в течение одной-двух недель.
Даю 14 дней гарантии на повторное заражение через ту же уязвимость: вернулось — чищу бесплатно. Абсолютной гарантии не даёт никто, и это честный ответ: сайт можно заразить заново через новую уязвимость в необновлённом модуле, через утёкший пароль сотрудника или через соседний сайт на том же аккаунте. Стопроцентную чистоту после серьёзной компрометации даёт только развёртывание с нуля: новый сервер, ядро из дистрибутива, ваш код из git и проверенная база.
Попросите у поддержки отчёт антивирусного сканера со списком заражённых файлов и доступ по SSH или FTP хотя бы на чтение — с этим списком лечение идёт быстрее. Не соглашайтесь на автоматическое «лечение» хостера как на единственную меру: сканер удаляет тела вирусов, но не закрывает точку входа, поэтому через несколько дней аккаунт блокируют снова. Разблокировка обычно происходит после того, как вы отпишетесь в тикет о завершении чистки и повторный скан пройдёт чисто.
Пришлите адрес сайта — за 2 часа отвечу, есть ли заражение и что именно нашлось. Дальше решаете вы: лечу за 10 000 ₽ или отдаю чек-лист, чтобы почистили сами.