Введение

Этот материал — реальный технический разбор инцидента на сайте под управлением 1C-Битрикс, где вредоносные файлы появлялись снова и снова даже после удаления.

Задача была не просто «почистить сайт», а понять механизм реинфекции и перекрыть точку входа, чтобы заражение не возвращалось.

Симптомы инцидента

Во время расследования регулярно обнаруживались новые вредоносные файлы:

• в ajax/
• в assets/images/
• периодически в маскирующих каталогах с «случайными» именами

Типичные признаки:

• однофайловые backdoor-скрипты (eval(base64_decode(...)))
• webshell / file manager
• обфусцированные дропперы под видом «легитимного» кода
• вредоносные вспомогательные файлы (php.ini, .txt-стейджеры)

Ключевая проблема: после удаления вредонос восстанавливался.

Почему удаление «по файлам» не решает проблему

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

Поэтому расследование строилось в логике:

1. выявить вектор первичного исполнения;
2. связать события записи файлов с конкретным процессом;
3. по времени процесса найти HTTP-запрос и источник;
4. закрыть уязвимый код, а не только симптомы.

Что было сделано для расследования

1) Включен аудит файловых событий (auditd)

Для каталогов с постоянной реинфекцией были включены правила мониторинга записи/изменения:

• .../ajax
• .../assets/images

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

2) Сопоставление с процессами

По audit-событиям подтверждено:

• вредоносные файлы создавались процессом php-cgi;
• процесс запускался в контексте веб-обработки (apache2 как parent);
• это исключило гипотезу про «фоновый демон из /tmp» как основной источник.

3) Корреляция по access-логам

По точным таймстемпам из audit были найдены соответствующие строки в access-логе виртуального хоста. Это дало цепочку запросов, которая приводила к записи webshell-файлов.

Ключевая exploit-цепочка

В ходе анализа выявлена рабочая связка:

1. запрос к ajax/error_log_logic.php с параметром data (в него передавался PHP payload);
2. payload попадал в локальный файл логирования (ajax/js_error.txt);
3. затем вызывался ajax/form.php с form_id=TABLES_SIZE и параметром url, что приводило к include(...) локального файла;
4. через выполнение payload разворачивался основной webshell (ajax/e883b93f1458.php) и дополнительные дропперы.

То есть реинфекция шла не «сама по себе», а через конкретную уязвимую пару endpoint-ов.

Что оказалось уязвимым в коде

ajax/error_log_logic.php

Файл принимал пользовательский data и писал его в файл в web-доступной директории.
Такой механизм удобно использовать как стейджер для дальнейшего исполнения.

ajax/form.php (ветка TABLES_SIZE)

Ветка таблиц размеров делала include файла из пользовательского параметра url без безопасного whitelist-подхода. Это классический LFI-вектор, который в связке со стейджером превращается в RCE.

Что было удалено

Удалены подтвержденные вредоносные файлы (webshell/droppers), включая семейства:

• e883b93f1458.php
• 2c6d8479de*
• 58b2a3298b*
• и сопутствующие зараженные копии в assets/images

Отдельно удален ajax/error_log_logic.php как подтвержденная точка входа.

Что было исправлено

Для ajax/form.php сделан безопасный патч:

• убран произвольный include по пользовательскому пути;
• добавлена строгая валидация:
  • только реальные файлы;
  • только .php;
  • только внутри разрешенного каталога include/table_sizes.

Таким образом функциональность таблиц размеров сохранена, но LFI-вектор закрыт.

Почему это важно для Bitrix-проектов

Для Bitrix-проектов характерна смесь:

• кастомных ajax/*.php обработчиков,
• шаблонного кода от интеграторов/тем,
• устаревших «временных» debug-файлов.

Даже один небезопасный endpoint в публичной зоне может стать постоянной точкой возврата вредоноса.

Практические выводы

1. Удаление файлов без закрытия вектора входа не работает.
2. Нужна корреляция «файл -> процесс -> запрос».
3. Аудит (auditd) и доступ к корректному access-логу критичны.
4. Все кастомные ajax/*.php должны проходить security-ревизию:
   • без произвольных include/require,
   • без записи пользовательских данных в исполняемые директории,
   • с whitelist-подходом к путям и параметрам.

Минимальный чеклист после инцидента

• смена всех критичных паролей (админка, SSH/FTP/SFTP, БД, панель);
• ревизия администраторов и доступов;
• проверка всех ajax/*.php и кастомных endpoint-ов;
• запрет исполнения PHP в каталогах статики (assets, upload где возможно);
• установка мониторинга на появление новых .php в нетипичных директориях;
• план регулярных security-проверок и обновлений ядра/модулей.

Заключение

Главный результат этого кейса — обнаружение и закрытие реальной exploit-цепочки, а не «косметическая чистка» последствий.

Если вредонос «возвращается», почти всегда есть рабочая точка входа.
Ее можно найти, если собрать расследование как техническую цепочку фактов:
время записи -> процесс -> родитель процесса -> HTTP-запрос -> уязвимый код.