Устранение последствий атак на сайты под управлением 1С-Битрикс, работающих на Аспро

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

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

Убедитесь, что скрипт выполняется с достаточными правами доступа.
Использование неправильных параметров может повлиять на файловую систему 1С-Битрикс.
Перед запуском рекомендуется создать резервную копию данных.
Разработчики рекомендуют с осторожностью использовать скрипт, так как внесенные изменения могут повлиять на работу системы.

А это значит, что не получится избавиться от проблем нажатием одной кнопки.

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

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

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

Архив со всеми вспомогательными скриптами расположен в конце статьи.

1. Файлы .htaccess

Вирус создает множество файлов .htaccess, которые приводят к неработоспособности сайта — он не работает ни в публичной части, ни в административной панели. Патчер от Аспро не удаляет вредоносные .htaccess-файлы. Поэтому первым делом нужно избавиться от этой напасти.

Можно чистить все вручную, можно использовать модуль bitrix.xscan с маркетплейса для старых версий БУС, хотя он сейчас не доступен, а функционал перенесен в проактивную защиту в новых редакциях продукта. А вредоносные .htaccess не позволяют использовать даже админпанель. Поэтому мы подготовили bash-скрипт clean_htaccess_self_delete.sh для запуска по SSH, который устанавливает минимальный набор .htaccess для сайтов на 1С-Битрикс. Архив со всеми скриптами расположен в конце статьи. Просто загрузите этот скрипт  в директорию сайта и запустите через SSH:

bash /full/path/to/clean_htaccess_self_delete.sh

где /full/path/to/ — это полный путь к корневой директории сайта.

Что делает скрипт:

• Удаляет все .htaccess-файлы в указанной директории и вложенных.

• Создаёт (подобно модулю проактивной защиты):

  • корректный .htaccess в корне,

  • защитный .htaccess в upload/,

  • Deny from All в критичных папках (bitrix/modules, php_interface, updates, upload/1c_exchange).

• Удаляет сам себя после выполнения.

2. Устранить уязвимости в модулях Аспро

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

Или можно сделать это вручную, используя для диагностики подготовленный нами скрипт scan_unserialize.sh. Его, подобно предыдущему, нужно загрузить в корневую директорию и запустить из SSH командной строки:

bash /full/path/to/scan_unserialize.sh

где /full/path/to/ — это полный путь к корневой директории сайта.

Данный скрипт выполняет только поиск уязвимых файлов и никак их не модифицирует. Устранять уязвимости здесь придётся вручную. Скрипт сохраняет в корневой директории файл лога типа unserialize_scan_<currentdate>_<current_time>.log, в котором содержатся все уязвимые файлы, строки, в которых найдена уязвимость, и рекомендации по их исправлению для каждой конкретной строки.

пример файла лога unserialize_scan_<currentdate>_<current_time>.log

Поиск уязвимых вызовов unserialize() без allowed_classes...
Проверяются директории: ajax include form
---------------------------------------------------------
 Файл: /full/path/to/site/include/mainpage/comp_catalog_ajax.php:17
    Найдено: 	$arComponentParams = unserialize(urldecode($arIncludeParams));
    Рекомендуется: 	$arComponentParams = unserialize(urldecode($arIncludeParams, ['allowed_classes' => false]));

---------------------------------------------------------
 Обнаружены потенциально уязвимые вызовы.
 Внедрите защиту: добавляйте ['allowed_classes' => false] при использовании unserialize().

В данном примере видно что в файле comp_catalog_ajax.php на 17 строке есть уязвимость и рекомендация как заменить код данной строки, чтобы ее устранить.

Какой способ выбрать на этом шаге — решать вам самим.

3. Удалить или поместить в карантин вредоносный код, который был создан на сайте через уязвимость

Эта задача тоже достаточно творческая, и уровень творчества зависит от уровня творчества злоумышленников. Как уже говорилось выше в статье, можно использовать встроенные инструменты для поиска вирусов:

• в модуле проактивная защита — для обновлённых платформ;

• или модуль bitrix.xscan — для старых версий Битрикс.

Они автоматически найдут вредоносные файлы и будет возможность нажатием кнопки в строке найденного файла поместить его в карантин (переименование расширения файла из .php в .ph_).

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

Также не стоит сразу бездумно нажимать на каждую кнопку "В карантин", так как антивирус может принять за вирус очень даже нужный файл. Или вирус может быть просто внедрён в обычный рабочий файл.

Конкретно этот вирус внедряет кусок вредоносного кода в index.php и проставляет для него права 0444 (только для чтения).

Файл index.php с инкапсулированным кодом достаточно просто исправить, удалив из его начала вредоносный код до:

<?
require($_SERVER["DOCUMENT_ROOT"]."/bitrix/header.php");

Но не делайте этого сразу! Сначала запишите себе куда-либо дату изменения файла index.php — она поможет найти всё вредоносное, что создал вирус.

Сложности с исправлением index.php

Ранее мы говорили, что права на инфицированный index.php выставляются как "только для чтения", но это не предел творческих усилий злоумышленников.

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

• меняете файлу права,

• удаляете вредоносную часть кода,

• сохраняете файл — а он снова с правами 0444 и с инкапсулированным вирусом в начале.

Пробуете переименовать файл или удалить — а он создаётся снова в первозданном виде.

Тогда вам нужно найти фоновый процесс, установленный вирусом. Часто достаточно просто выполнить в SSH консоли:

ps aux | grep php

И если вы увидите в ответе строки типа:

<username> 65836  ... php -f /tmp/httpd.conf
<username>  73246 ... php -f /tmp/httpd.conf 

— то вы на верном пути.

httpd.conf в /tmp/ — это не конфигурация Apache, а маскирующийся PHP-скрипт, который возможно:

• следит за index.php;

• восстанавливает его;

• может выполнять бэкдор-команды (например, eval base64 и т.п.).

При этом файла /tmp/httpd.conf может даже не существовать физически.

Что нужно сделать? Убить подозрительные процесс(ы):

kill -9 65836 73246

(используйте свои ID процессов из вывода ps aux!)

процесс может быть один или их может быть несколько, убивать надо все подозрительные.

Теперь index.php и другие файлы, за которыми следил скрипт, можно успешно менять, удалять и делать с ними всё, что нужно.

Поиск вредоносных файлов

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

Для этого запускаем скрипт поиска scan_files.sh с указанием даты начала заражения (мы зафиксировали ее ранее) в формате ГГГГ-ММ-ДД:

 bash /full/path/to/scan_files.sh 2025-06-19

Скрипт ищет все файлы, изменённые с даты (начала инфицирования) по текущий момент, и сохраняет их в два файла лога:

• scan_main_<дата начала>_to_<дата окончания>.log — лог, содержащий все файлы за исключением кэша;

• scan_cache_<дата начала>_to_<дата окончания>.log — лог, содержащий только файлы папок кэша.

Пример файла лога

2025-06-19 11:00:13.000000000 +0300 77 /full/path/to/site/bitrix/public_html/robots.txt
2025-06-23 03:35:36.440425357 +0300 4921 /full/path/to/site/bitrix/public_html/bitrix/components/bitrix/news.line/lang/en/en/cache.php
2025-06-23 03:35:36.440425357 +0300 5629 /full/path/to/site/bitrix/public_html/bitrix/components/bitrix/news.line/lang/en/en/index.php

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

Архив со скриптами

Что в итоге?

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

Но вы также всегда можете обратиться к тем, кто максимально эффективно поможет устранить проблемы.

Нужна наша помощь? Просто свяжитесь с нами!