Взломы сайтов на 1С-Битрикс: лечение и профилактика

В начале 2025 года произошла масштабная и третья по счету волна взломов сайтов на 1С-Битрикс, затронувшая в первую очередь ресурсы с решениями АСПРО.

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

Февраль 2025. В отдел веб-мастеринга Kokoc.tech поступают первые сигналы: сайты начинают падать, ломаются отдельные компоненты сайтов, появляются ссылки на фармацевтические, азартные и другие запрещенные ресурсы, в поиске — предупреждения «Сайт может навредить вашему устройству». К середине марта поток запросов становится лавиной.

Это была третья по счёту массовая волна взломов сайтов на 1С-Битрикс — и одна из самых масштабных за последние годы.

Ещё в 2023–2024 годах мы наблюдали две волны атак на Bitrix:

Но февраль–июнь 2025 стали переломными. Хакеры атаковали сайты с необновлёнными решениями от АСПРО, стандартными модулями Битрикс и кастомными компонентами, оставшимися без патчей.

Анализ зараженных компонентов показал: волна взломов в первую очередь нацелена на сайты, использующие популярные решения от компании АСПРО — такие как Max, Next, LiteShop и другие. Основной причиной компрометации стали устаревшие версии этих шаблонов и модулей, содержащие критическую уязвимость. Чаще всего атаки реализовывались через уязвимость в функции unserialize, используемой при обработке пользовательских данных в настройках компонентов. Это позволяло злоумышленникам выполнять инъекцию сериализованных объектов, что приводило к произвольному выполнению кода (RCE).

Анализ показал: все инфицированные проекты использовали устаревшие версии решений АСПРО (до 24.1100) и не проводили обновление ядра 1С-Битрикс свыше 12 месяцев. Это создало идеальные условия для проникновения уязвимостей.

Клиенты жаловались на:

Все эти симптомы — не просто «глюки». Это признаки активного вредоносного кода.

Как понять, что сайт заражен? Вот ключевые симптомы:

Важно: даже если ресурс «работает», но в коде сайта есть eval(base64_decode(...)) — это 100% вирус. Не игнорируйте!

Перед лечением — диагноз. Проводим комплексную проверку:

Этап 1: Автоматическая проверка сайта

Диагностика заражения включает комплексное сканирование сайта с использованием специализированных инструментов. В первую очередь мы применяем сканер AI-BOLIT — инструмент для поиска следов взлома и вредоносного кода на сайтах.

AI-BOLIT помогает выявить:

Сканер можно запускать как на хостинге (рекомендуемый способ — через SSH в командной строке), так и локально под Windows, macOS или *nix-системами. Он использует собственную антивирусную базу и эвристические правила, позволяющие обнаруживать даже новые, ещё неизвестные угрозы.

При нахождении подозрительных фрагментов AI-BOLIT формирует подробный отчет в HTML или текстовом формате — с перечнем зараженных файлов и описанием типа угрозы.

Дополнительно проводим проверку через онлайн-сканеры, такие как Dr.Web Site Detector, чтобы подтвердить результаты и выявить активность, заметную извне — например, редиректы или вредоносные iframe.

Этап 2. Проверка сайта вручную

Вначале производим анализ файлов через SSH или через файловый менеджер:

Особое внимание — папкам:

Далее проверяем базу данных. Иногда вирусы прячутся в настройках или контенте:

SELECT * FROM b_file WHERE CONTENT LIKE '%eval%';
SELECT * FROM b_event WHERE MESSAGE LIKE '%base64%';

Также проверяем настройки шаблонов — в них могут быть вставлены JS-скрипты.

Теперь — лечение. Действуем по порядку.

Шаг 1: Бэкап

Шаг 2: Изоляция

Шаг 3: Удаление вредоносного кода

Шаг 4: Очистка базы данных

Чистка — это только начало. Нужно закрыть дыры, через которые проник вирус.

Основная защита от вирусов — это полное обновление системы и модулей, но если в настоящий момент это сделать нет возможности, можно установить «заплатки».

1. Блокировка через .htaccess — первый щит

2. Фильтрация запросов в init.php — остановка до выполнения

Можно добавить защиту на уровне PHP, в файле /bitrix/php_interface/init.php. Это позволяет перехватить опасные запросы до того, как они достигнут уязвимого компонента.

Пример: блокировка unserialize в GET/POST или блокировка по сигнатурам (например, base64 + eval).

Важно: такие проверки не заменяют обновлений, но останавливают большинство автоматизированных атак.

3. Ограничение в php.ini или user.ini

На уровне PHP можно отключить опасные функции (если это не ломает сайт) или ограничить unserialize

Внимание: eval и assert часто используются в шаблонах АСПРО — отключайте с осторожностью.

4. WAF на уровне сервера (ModSecurity)

Если есть доступ к серверу — настройте ModSecurity с правилами OWASP Core Rule Set. Он автоматически блокирует:

Важно понимать:

Лучшая защита — обновление. Но если оно невозможно — правильные .htaccess и фильтры в init.php могут спасти сайт от взлома.

После всех действий — финальный тест:

Обновления — не роскошь, а базовая необходимость.

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

Злоумышленники не взламывают системы. Они просто входят в открытые двери.

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

✅ В нашем Telegram-канале мы публикуем много новых кейсов и статей, рассказываем про наш опыт. А еще мы любим шутки и развлекательный контент. Заглядывайте к нам!