Вирус на сайте 1С-Битрикс: как найти и обезвредить в первые часы

Первый признак заражения сайта на 1С-Битрикс редко выглядит как что-то драматичное: сайт вдруг начинает редиректить часть посетителей на сторонние ресурсы, хостинг присылает уведомление о рассылке спама с сервера, или Яндекс помечает сайт как заражённый в поисковой выдаче. К этому моменту вредоносный код уже какое-то время живёт в проекте, и первая реакция — найти и удалить заразу как можно быстрее. Это правильный первый шаг, но важно сразу понимать его границы: удаление файлов останавливает симптомы, а не лечит причину.

Как быстро найти заражённые файлы

Первым делом стоит просмотреть файловую структуру сайта на предмет файлов с нечитаемыми или подозрительными именами — вирусы часто маскируются под наборы случайных символов вроде akd82k3n.php, чтобы не привлекать внимание при беглом просмотре списка файлов. Такие файлы почти всегда можно удалить сразу, особенно если они появились недавно и не связаны с обновлениями модулей.

Отдельно стоит проверить содержимое двух ключевых файлов, которые чаще всего становятся точкой внедрения вредоносного кода:

• index.php в корне сайта — вирус нередко дописывает свой код прямо в начало или конец этого файла, поскольку он гарантированно выполняется при каждом заходе на сайт;
• .htaccess в корне и в других папках — через него вредоносный код часто прописывает редиректы или подключает сторонние файлы без изменения самого PHP-кода.

Если в проекте накопилось много файлов .htaccess в разных папках и просматривать их вручную неудобно, в админке Битрикса есть штатный сканер именно для этой задачи: /bitrix/admin/xscan_htaccess.php?lang=ru. Он показывает все правила из всех .htaccess-файлов проекта в одном месте, что заметно ускоряет поиск лишних записей.

Поиск файлов, изменённых недавно

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

1. Открыть терминал и перейти в корневую папку проекта.
2. Выполнить команду:

   find . -type f -name "*.php" -newermt "$(date +%Y-%m-%d)" ! -path "./bitrix/managed_cache/*" ! -path "./bitrix/cache/*" 2>/dev/null

   команда найдёт все PHP-файлы, изменённые за сегодняшний день — дату в кавычках можно заменить на нужную. Папки с кэшем Битрикса исключены из поиска отдельно, чтобы не засорять список файлами, которые система пересобирает сама.
3. Просмотреть каждый найденный файл вручную. В первую очередь искать признаки внедрённого кода: eval, base64_decode, обфусцированные (нечитаемые, «зашифрованные») блоки кода, неожиданные redirect-конструкции.
4. После очистки запустить команду повторно — если список файлов снова не пуст, часть вредоносного кода осталась либо заражение продолжается через ещё не найденную точку входа.

Если чистка не помогает: логирование запросов

Если после чистки файлов заражение возникает снова, значит осталась точка входа, через которую вирус продолжает попадать на сайт, и её нужно поймать «на живую».

Этот способ актуален только в одном случае — когда сайт размещён на обычном хостинге и нет доступа к журналам логов nginx или Apache, то есть штатными средствами посмотреть, кто и какие запросы шлёт на сервер, невозможно. Если доступ к логам веб-сервера есть — например, на своём VPS, — нужно смотреть именно их: они полнее самодельного лога и не зависят от того, успевает ли вообще выполниться PHP-код заражённого проекта.

Когда логов веб-сервера нет, временный лог можно организовать средствами самого Битрикса:

1. Открыть файл /bitrix/php_interface/init.php.
2. Вставить в начало файла следующий код:

   if($_SERVER['REQUEST_METHOD'] === 'POST') {
       $url = $APPLICATION->GetCurPage();
       file_put_contents(
           $_SERVER['DOCUMENT_ROOT'] . '/request.log',
           $_SERVER["REMOTE_ADDR"]." POST [".date('d.m.Y H:i:s')."] $url?".http_build_query($_GET)." || " .
           print_r($_POST,1) . "\r\n\r\n", FILE_APPEND
       );
   }

3. Подождать 1–2 дня, затем проверить файл request.log в корне сайта — искать в нём запросы с подозрительными адресами или неожиданным содержимым POST-данных.
4. Убрать этот код сразу после того, как источник заражения найден — это временный диагностический инструмент, а не постоянный механизм логирования проекта.

Штатный сканер файлов и проверка агентов

Кроме ручной проверки, в самой платформе есть встроенный сканер файлов на признаки заражения по сигнатурам: /bitrix/admin/xscan_worker.php?lang=ru. Его стоит запустить в рамках первичной чистки — он находит часть заражённых файлов автоматически, без ручного перебора.

Отдельно, но уже не сканером, а вручную стоит просмотреть список агентов — это штатный механизм Битрикса для периодически выполняемого PHP-кода (аналог cron-задач, но настраиваемый внутри самой системы, в разделе Настройки → Агенты). Легитимные агенты платформа и модули создают сами — например, для рассылок или переиндексации. Но именно поэтому агент — удобное место, чтобы спрятать вредоносный код: он лежит не в файле на диске, а в базе данных, выполняется по расписанию сам по себе и продолжает работать даже после того, как все подозрительные php-файлы в проекте уже удалены.

Если в списке агентов встретился пункт с незнакомым названием, странным путём к обработчику или кодом, который не похож на типовую логику модуля — это почти всегда сигнал, что заражение глубже, чем пара файлов в корне сайта.

Почему чистка файлов — это не лечение

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

Полное лечение обязательно включает три вещи, и ни одну из них нельзя пропустить:

1. Найти причину заражения. Через какую уязвимость, устаревший компонент, скомпрометированный пароль или чужой доступ вирус попал в систему. Без ответа на этот вопрос всё остальное — временная мера.
2. Откатить проект бэкапом на состояние до заражения, а не точечно исправлять вручную найденные файлы. Ручная чистка почти никогда не даёт гарантии, что не осталась скрытая часть вредоносного кода — бэкдор, изменённый агент или файл с отложенной активацией, которые просто не попали в поле зрения при разборе.
3. Залатать найденную дыру до возврата сайта в продакшн. Иначе восстановленный из бэкапа сайт заразится повторно тем же путём, каким проник исходный вирус — и весь цикл придётся проходить заново.

VPS: почему отката файлов может быть недостаточно

Если сайт размещён на выделенном сервере или VPS, а не на обычном shared-хостинге, откат одних только файлов проекта не гарантирует чистоту системы — потому что заражённым может быть не только сайт, но и сам сервер.

Мы сталкивались с ситуацией, когда другая команда разработки неверно настроила права на веб-сервере. Из-за этой ошибки вирус смог не просто внедрить код в файлы сайта, а создать нового непривилегированного пользователя SSH — и уже из-под него, независимо от состояния файлов самого проекта, атаковать основной сайт на этом же сервере. Откат файлов в такой ситуации ничего не даёт: скомпрометирован не проект, а сервер целиком, и новый пользователь спокойно переживает любую чистку файловой системы.

Поэтому для VPS или выделенного сервера при подтверждённом заражении полноценное лечение — это откат всего сервера на снапшот, сделанный до момента заражения, а не только файлов сайта. После восстановления снапшота стоит отдельно проверить список пользователей системы, ssh-ключи, задания cron или systemd-таймеры и открытые порты — заражение сервера обычно оставляет следы именно там, а не в файлах веб-проекта.