Сайт на Битрикс взломали: признаки, лечение и защита

Обычно всё начинается со звонка менеджера: «Клиент говорит, что с нашего сайта его кинуло на казино». Открываете сайт с ноутбука, всё на месте. Проверяете с телефона через поиск Яндекса, и вас уносит на чужой домен.

Такой редирект часто оказывается видимой частью заражения. Под ним бывают шелл в /upload/, агент в базе, который возвращает удалённые файлы, и лишний администратор с логином вроде bitrix_support. Если снести только редирект, через три дня он вернётся.

Ниже разбираем порядок действий. Первые разделы написаны для владельца сайта: как заметить взлом и что сделать в первый час. Дальше идёт технический блок с командами для разработчика или админа.

1. Как понять, что сайт взломан

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

Что видно без доступа к серверу:

• Редирект только для части посетителей. Код проверяет User-Agent и Referer. Админ, зашедший по прямой ссылке, видит нормальный сайт. Посетитель со смартфона, пришедший из поиска, попадает на казино или «выигрыш iPhone».
• Чужие страницы в поиске. Наберите в Яндексе site:вашдомен.ru и пролистайте выдачу. Страницы с дорвеями, аптекой или кредитами, которых вы не создавали, означают, что сайт уже работает на кого-то другого.
• Предупреждения в Вебмастере. Раздел «Диагностика → Безопасность и нарушения» в Яндекс Вебмастере. Если там стоит пометка о вредоносном коде, в выдаче сайт уже показывают с предупреждением.
• Письма от хостинга. «С вашего аккаунта идёт спам-рассылка» или «Процессы PHP грузят CPU на 100%». Сервер могут использовать для рассылки или майнинга.
• Новые администраторы. В админке откройте «Пользователи» и отсортируйте по дате регистрации. Незнакомая учётка в группе «Администраторы» говорит о взломе сама по себе.
• Исчезнувший контент или чужая главная. Самый заметный вариант. В мае 2023 года так выглядели тысячи сайтов в зоне .РФ.

2. Почему ломают именно Битрикс

Ядро Битрикса разработчики латают быстро. Патчи на громкие уязвимости выходили в день публикации. Ломают сайты, на которых эти патчи не стоят. Таких много: Битрикс часто разрабатывают один раз, сдают и годами не обновляют, потому что «работает же».

Коротко по главным эпизодам:

• Март 2022, модуль vote. CVE-2022-27228, оценка 9.8 по CVSS. Через файл /bitrix/tools/vote/uf.php без авторизации можно было записать на сервер произвольный файл. Уязвимы все версии модуля до 21.0.100.
• Май 2023, массовый дефейс .РФ. Использовали ту же дыру в vote и скрипт html_editor_action.php модуля fileman. Злоумышленники подменяли index.php, удаляли /bitrix/.settings.php, чистили таблицы инфоблоков и оставляли агентов в базе. Многие бэкдоры поставили ещё в 2022 году, а сработали они через год.
• Сентябрь 2023, модуль landing. BDU:2023-05857, CVSS 10 из 10: выполнение системных команд на сервере. Исправлено в версии 23.850.0. По данным на октябрь 2025 года, из миллиона активных установок Битрикса без патча оставались около 150 тысяч.
• 2025, сторонние решения. Уязвимости нашли не в ядре, а в шаблонах Аспро (файлы reload_basket_fly.php, show_basket_fly.php, show_basket_popup.php) и модулях импорта-экспорта eSolutions и «Маяк». Причина везде одна: unserialize() от пользовательских данных.

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

3. Первый час: что делать сразу

Главная ошибка в первый час: сразу откатиться на вчерашний бэкап и выдохнуть. Бэкдор мог появиться месяц назад. Откат вернёт сайт вместе с ним, а заодно сотрёт следы, по которым можно понять, как вас взломали.

Порядок такой:

1. Сделайте копию текущего состояния. Файлы и дамп базы как есть, вместе с вирусом. Положите отдельно от рабочих бэкапов и подпишите. Это материал для расследования.
2. Ограничьте доступ к сайту. Закройте сайт заглушкой или пустите только свои IP. Если сайт приносит деньги каждый час, оставьте его открытым, но уберите хотя бы редирект: посетители не должны попадать на мошенников.
3. Смените пароли с другого, чистого устройства. Панель хостинга, SSH, FTP, база данных, все администраторы Битрикса. Если на сервере лежал пароль от почты или 1С-обмена, его тоже.
4. Сохраните логи веб-сервера. На многих хостингах они ротируются за 7–14 дней. Скопируйте access.log за весь доступный период, иначе источник заражения уже не найти.

Дальше начинается работа для технического специалиста.

4. Диагностика: где искать вредонос

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

Логи: как вошли

Ищем успешные POST-запросы к скриптам, через которые ломали в последние годы. zgrep читает и обычные, и сжатые логи:

zgrep -E 'POST /bitrix/tools/(vote/uf\.php|html_editor_action\.php|landing/ajax\.php|upload\.php)' \
  /var/log/nginx/access.log* | grep '" 200 '

Визуальный редактор в админке тоже шлёт POST в html_editor_action.php, поэтому сверяйте IP со своими. Нашли чужие запросы? IP и дата первого из них дают точку отсчёта. От неё выбирается чистый бэкап.

Файлы: что появилось и что изменилось

PHP-файлы, изменённые за последние 30 дней, без кеша:

find . -name "*.php" -mtime -30 \
  -not -path "./bitrix/cache/*" \
  -not -path "./bitrix/managed_cache/*" \
  -not -path "./bitrix/stack_cache/*" | sort

Злоумышленник может подменить дату файла через touch, поэтому одного mtime мало. Второй проход ищет сигнатуры, по которым 1С-Битрикс сам рекомендует искать заражение:

grep -rlE 'eval\(base64_decode|str_rot13|gzinflate\(base64|parse_str\(hex2bin|md5\(\$_COOKIE|BX_TOKEN|bitrixxx' \
  --include="*.php" . | grep -v '/bitrix/cache/'

str_rot13 встречается и в легитимном коде. Каждое совпадение смотрите глазами, не удаляйте списком.

Отдельно проверяем места, где PHP-файлов быть не должно, и известные имена шеллов:

find ./upload -type f -name "*.php*"
find . -name "xmlrpcs.php" -o -name "inputs.php" -o -name "l.php"
find ./bitrix/admin -regextype posix-extended -regex '.*/[0-9a-f]{12}\.php'
find . -name ".htaccess" -mtime -30

Последняя команда ловит .htaccess с редиректами. При дефейсе 2023 года их раскладывали в каждую папку сайта.

Частые места внедрения в ядро: /bitrix/modules/main/include/prolog_after.php, /bitrix/modules/main/bx_root.php, /bitrix/php_interface/init.php, header.php шаблона. Сравните их с эталонным дистрибутивом той же версии.

База: агенты и пользователи

Агенты Битрикса выполняют PHP-код из поля NAME по расписанию. Это удобное место для закрепления: удалили файлы, а агент через час записал их заново.

SELECT ID, MODULE_ID, NAME, ACTIVE, NEXT_EXEC
FROM b_agent
WHERE NAME REGEXP 'eval|base64|assert|file_put_contents|gzinflate|curl_exec|\\$_(POST|GET|REQUEST|COOKIE)';

Администраторы, отсортированные по дате регистрации:

SELECT u.ID, u.LOGIN, u.EMAIL, u.DATE_REGISTER, u.LAST_LOGIN
FROM b_user u
JOIN b_user_group g ON g.USER_ID = u.ID
WHERE g.GROUP_ID = 1
ORDER BY u.DATE_REGISTER DESC;

Проверьте ещё и содержимое инфоблоков и SEO-полей. Скрытые ссылки и <script> часто вставляют прямо в DETAIL_TEXT элементов.

Сервер: cron и процессы

crontab -l -u bitrix   # в BitrixVM сайт работает от пользователя bitrix
ls -la /etc/cron.d/ /var/spool/cron/
ps aux --sort=-%cpu | head -15

Незнакомая задача в cron или процесс с именем вроде kworkerds на 90% CPU означают, что заражён уже сервер, а не только сайт.

Встроенные инструменты

У Битрикса есть официальный модуль «1С-Битрикс: Поиск троянов» (bitrix.xscan). Ставится из Маркетплейса, запускается в «Настройки → bitrix.xscan → Поиск». Он находит большую часть типовых шеллов, но не заменяет ручную проверку: обфускацию под конкретный сайт он пропускает.

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

5. Лечение: порядок, который не даёт заразиться снова

Когда картина ясна, лечим в таком порядке:

1. Выберите точку восстановления. Нужен бэкап, сделанный раньше первого подозрительного запроса из логов. Если такого нет, чистите текущую копию вручную.
2. Замените ядро целиком. Папку /bitrix/modules/ надёжнее перезалить из дистрибутива вашей версии, чем выискивать в ней изменённые строки. Ваш код должен лежать в /local/, ядро вы не правите.
3. Удалите найденное. Шеллы, лишние .htaccess, вредоносных агентов, чужих администраторов, задачи в cron.
4. Обновите всё. Ядро, модули, решения из Маркетплейса, PHP. Модули, которые больше не поддерживаются, удалите или замените.
5. Смените секреты ещё раз. Пароль БД в /bitrix/.settings.php, ключи API платёжек и служб доставки, токены интеграций. Всё, что лежало на заражённом сервере, считается скомпрометированным.
6. Проверьте сайт повторно через 24–48 часов. Прогоните поиск по сигнатурам и агентам ещё раз. Если что-то вернулось, значит, остался источник.

Если обновить модуль прямо сейчас нельзя (например, старая лицензия или кастомизация в ядре), закройте уязвимый скрипт на уровне nginx как временную меру. Пример для vote/uf.php, если опросы на сайте не используются:

# http {}
map "$request_method:$uri" $bx_block_vote {
    default 0;
    "~^POST:/bitrix/tools/vote/uf\.php$" 1;
}

# server {}
if ($bx_block_vote) { return 403; }

Это заплатка, а не решение. Обновление всё равно нужно поставить.

6. Как защитить сайт на Битрикс от повторного взлома

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

Обновления по графику. Раз в месяц: ядро, модули, решения Маркетплейса. Сначала на тестовой копии, потом на проде. Продлённая лицензия нужна именно для этого: без неё обновления не приходят.

Проактивный фильтр (WAF). Модуль «Проактивная защита» блокирует типовые SQL-инъекции и XSS. Включается в «Настройки → Проактивная защита → Проактивный фильтр».

Двухфакторная авторизация для админов. В том же модуле раздел «Одноразовые пароли». Украденный пароль без второго фактора бесполезен.

Админка только со своих IP. «Проактивная защита → Защита административного раздела». Если у команды нет статических IP, закройте /bitrix/admin/ через VPN.

Запрет PHP в загрузках. В /upload/ не должно исполняться ничего:

location ~* ^/upload/.*\.(php\d?|phtml|phar)$ {
    deny all;
}

Правило должно стоять выше основного location ~ \.php$, иначе nginx до него не дойдёт.

Аудит сторонних модулей. Раз в квартал проверяйте, что поставлено, кто автор и когда модуль последний раз обновлялся. Всё, что не обновлялось два года и не используется, удаляйте.

Бэкапы, которые проверяли. Правило 3-2-1 и регулярное тестовое восстановление. Подробно разобрали в статье «Бэкапы сайта и базы: как пережить аварию без потери данных». Без бэкапа старше даты заражения лечение превращается в ручную археологию.

Мониторинг. Контроль целостности файлов, уведомления Яндекс Вебмастера на почту, алерт на новые учётки в группе администраторов. Взлом, замеченный за сутки, лечится за 3–4 часа. Взлом, который жил полгода, лечится днями.

7. Когда звать специалиста

Справиться своими силами реально, если заражение свежее, бэкап есть, а в команде есть человек с SSH-доступом и опытом Битрикса. Звать специалиста стоит в трёх случаях:

• вредонос возвращается после удаления;
• пропали данные в базе: заказы, товары, пользователи;
• заражён сервер целиком: чужие процессы, cron, пользователи в системе.

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