Признаки взлома сайта на 1С-Битрикс: как понять, что вас уже взломали

Заражённый сайт редко выглядит сломанным: он продолжает работать, а вредоносный код показывают только поисковым роботам или посетителям с телефонов. Разбираем признаки, по которым заражение находят до того, как о нём сообщит Яндекс.

Сайт заражают не для того, чтобы его сломать. Его заражают, чтобы им пользоваться: рассылать письма, продавать ссылки, подменять выдачу поисковикам, держать доступ на будущее. Поэтому первый признак заражения — обычно не «сайт лёг», а что-то незаметное.

Признак 1. Поисковик или браузер ругаются раньше вас

Первым о заражении часто сообщает не администратор, а Яндекс.Вебмастер, Google Search Console или браузер клиента, который показал предупреждение. Это худший сценарий: к этому моменту сайт уже мог месяц раздавать вредоносный код.

Что проверить прямо сейчас:

• уведомления в Вебмастере и Search Console — раздел безопасности;
• как выглядит сниппет сайта в выдаче: не подменились ли заголовки на посторонние;
• открывается ли сайт нормально в режиме инкогнито с мобильного.

Признак 2. В списке администраторов есть кто-то лишний

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

Что делать:

1. Открыть список пользователей с правами администратора и сверить его с реальными людьми.
2. Проверить дату создания каждой учётной записи. Аккаунт, созданный «непонятно когда», — повод для разбора.
3. Включить журналирование событий: вход, ошибка входа, добавление файла, изменение прав.

Признак 3. Всплеск POST-запросов к одному файлу

Если в логах веб-сервера один и тот же адрес получает десятки POST-запросов подряд с разных адресов — это либо уязвимый обработчик, либо уже установленный шелл. В нашем случае именно так выглядел вектор: небезопасный вызов десериализации в ajax-файле решения, куда приходил подготовленный POST.

Проверять стоит:

• топ URL по числу POST-запросов за неделю;
• запросы с пустым или поддельным реферером;
• обращения к файлам, которых нет в дистрибутиве CMS.

Если логов у сайта нет вообще — это отдельная проблема: разбирать инцидент будет не по чему. Включите хранение логов минимум на 30 суток.

Признак 4. Файлы, которых не должно быть

Веб-шелл — это обычный PHP-файл. Он может называться wp-ver.php на сайте без WordPress, adminfuns.php в папке бэкапа или иметь имя из случайных символов. Искать их по названию бессмысленно, а по сигнатурам — ненадёжно.

Рабочий способ: собрать реестр всех PHP-файлов вне дистрибутива CMS и проверить каждый подозрительный запросом. Отвечает на GET или POST чем-то осмысленным — разбираемся.

Отдельно проверьте места, которые переживают чистку:

• папки с бэкапами деплоя внутри вебрута;
• каталоги загрузок, где разрешено исполнение PHP;
• кэш и временные папки;
• архивы .zip, .tar.gz, .sql в корне — их скачивает кто угодно.

Признак 5. Разное содержимое для разных посетителей

Классика: обычный посетитель видит нормальный сайт, поисковый робот — страницу с чужими ссылками, а посетитель с мобильного — редирект на постороннюю страницу. Разделение делается по User-Agent или по реферу.

Как проверить:

• откройте сайт с подменённым User-Agent поискового бота;
• посмотрите сохранённую копию страницы в поиске;
• проверьте исходный код главной на посторонние скрипты и ссылки.

Признак 6. Изменились файлы, которые никто не менял

Сравнение с чистой копией той же версии платформы показывает, что изменилось. Если bitrix/header.php или файлы шаблона отличаются от эталона, а никто из команды их не трогал — это находка.

Здесь важно не полагаться на даты: mtime подделывается. Сравнивать нужно содержимое.

Признак 7. Почта уходит без вашего ведома

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

Что делать, если признаки подтвердились

1. Снимите полную копию сайта и базы «как есть». Она понадобится для разбора, а после чистки восстановить улики уже не получится.
2. Не начинайте с массового удаления файлов. Сначала — поиск точки входа.
3. Соберите реестр PHP вне дистрибутива и проверьте подозрительные файлы запросом.
4. Проверьте список администраторов и включите журналирование.
5. Смените пароли: админка, FTP, SSH, панель хостинга, база.
6. Закройте вектор: обновление платформы и решения, патч уязвимого файла, отключение опасного обработчика.
7. Только после этого чистите последствия и просите переобход в панелях вебмастеров.

Чего делать не стоит

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

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