Kworker зловред в centos Битрикс

На сайте смотрим тут --- >>> Рабочий стол Настройки Проактивная защита Поиск троянов Операционная система

Видим такое

> whoami

bitrix

> ps ux -u whoami

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND bitrix 1087 0.0 0.4 746636 9168 ? S May21 0:00 /usr/sbin/httpd -f /etc/httpd/conf/httpd-scale.conf -DFOREGROUND bitrix 1088 0.0 0.4 746636 9168 ? S May21 0:00 /usr/sbin/httpd -f /etc/httpd/conf/httpd-scale.conf -DFOREGROUND bitrix 1089 0.0 0.4 746636 9168 ? S May21 0:00 /usr/sbin/httpd -f /etc/httpd/conf/httpd-scale.conf -DFOREGROUND bitrix 1090 0.0 0.4 746636 9168 ? S May21 0:00 /usr/sbin/httpd -f /etc/httpd/conf/httpd-scale.conf -DFOREGROUND bitrix 9999 194 13.0 285796 267816 ? Ssl Jun03 59733:36 [kworker/u3:11] bitrix 13837 0.0 0.6 333976 13684 ? S May24 3:12 nginx: worker process bitrix 13838 0.0 0.8 338364 17788 ? S May24 23:41 nginx: worker process bitrix 13839 0.0 0.6 334232 14020 ? S May24 2:16 nginx: worker process bitrix 13840 0.0 0.6 333720 13324 ? S May24 4:20 nginx: worker process bitrix 13841 0.0 0.6 333464 13380 ? S May24 6:33 nginx: worker process bitrix 13842 0.0 0.6 333968 13868 ? S May24 3:11 nginx: worker process bitrix 13843 0.0 0.7 335000 15004 ? S May24 10:01 nginx: worker process bitrix 13844 0.0 0.6 333720 13236 ? S May24 2:24 nginx: worker process bitrix 15317 0.1 7.3 757004 150756 ? S Jun22 6:36 /usr/sbin/httpd -DFOREGROUND bitrix 15318 0.1 7.5 759000 153576 ? S Jun22 6:38 /usr/sbin/httpd -DFOREGROUND bitrix 15319 0.1 7.4 758920 152476 ? S Jun22 6:46 /usr/sbin/httpd -DFOREGROUND bitrix 15320 0.1 7.7 759004 159556 ? S Jun22 6:46 /usr/sbin/httpd -DFOREGROUND bitrix 15321 0.1 8.6 759036 176284 ? S Jun22 6:52 /usr/sbin/httpd -DFOREGROUND bitrix 15322 0.1 7.4 758936 152356 ? S Jun22 6:37 /usr/sbin/httpd -DFOREGROUND bitrix 15323 0.1 7.6 754964 157268 ? S Jun22 6:42 /usr/sbin/httpd -DFOREGROUND bitrix 15324 0.1 7.4 752884 153428 ? S Jun22 6:35 /usr/sbin/httpd -DFOREGROUND bitrix 15325 0.1 7.4 756424 153272 ? S Jun22 6:36 /usr/sbin/httpd -DFOREGROUND bitrix 15326 0.1 7.8 760452 160352 ? S Jun22 6:50 /usr/sbin/httpd -DFOREGROUND bitrix 17241 0.0 0.0 51728 1716 ? R 13:46 0:00 ps ux -u bitrix

> crontab -l

no corntab

> last -i whoami

bitrix pts/0 0.0.0.0 Sat Mar 15 16:24 - 16:24 (00:00)

wtmp begins Mon Jun 26 15:01:03 2023

Краткий вердикт: У вас на сервере с вероятностью 99.9% работает замаскированный майнер или другой троян.

Теперь разберем подробно, почему я пришел к такому выводу и что делать дальше.

Анализ ваших данных

1. Проверка процессов (ps ux)

Вывод команды ps содержит огромный красный флаг, который практически однозначно указывает на взлом.

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
...
bitrix    9999  194 13.0 285796 267816 ?       Ssl  Jun03 59733:36 [kworker/u3:11]
...

Давайте разберем эту строку:

• USER: bitrix: Процесс запущен от имени пользователя bitrix.

• COMMAND: [kworker/u3:11]: Процесс маскируется под kworker. Это и есть главная улика.

• Настоящие kworker — это системные процессы ядра (kernel workers). Они всегда запускаются от пользователя root.

• Процесс ядра, запущенный от обычного пользователя (bitrix), — это классический признак вредоносного ПО, которое пытается спрятаться от администратора.

• Квадратные скобки [] также используются, чтобы имитировать вид системного процесса.

• %CPU: 194: Это аномально высокое потребление процессорного времени. %CPU в ps показывает среднее потребление с момента запуска процесса. Такая цифра (больше 100%) говорит о том, что процесс постоянно и очень активно использует как минимум два ядра CPU. Это типичное поведение для криптомайнеров.

• TIME: 59733:36: Процесс наработал огромное количество процессорного времени — более 59 тысяч минут (это ~41 день непрерывной работы). Это подтверждает, что он работает давно и постоянно “жрет” ресурсы.

• START: Jun03: Процесс был запущен 3 июня, что совпадает с огромным накопленным временем работы.

Остальные процессы:

• httpd (Apache) и nginx — это стандартные и ожидаемые процессы для веб-сервера под управлением BitrixVM / BitrixEnv. С ними, на первый взгляд, все в порядке.

Вывод по процессам: Процесс kworker с PID 9999, запущенный от bitrix, — это вредонос.

2. Проверка Crontab (crontab -l)

no corntab

Это означает, что для текущего пользователя (bitrix) нет запланированных заданий. Это хорошо, но недостаточно. Злоумышленник мог добавить задание для пользователя root или в системные директории crontab.

3. Проверка SSH-ключей

Вы не предоставили вывод этой проверки. Обязательно выполните ее.

4. Проверка логов входа (last)

bitrix   pts/0        0.0.0.0          Sat Mar 15 16:24 - 16:24  (00:00)

Запись очень старая, она не имеет отношения к текущему инциденту. Однако стоит помнить, что злоумышленник мог почистить логи (/var/log/wtmp, откуда last берет данные), поэтому доверять этому выводу на 100% нельзя.

---

План действий: Что делать ПРЯМО СЕЙЧАС

Шаг 0: Получите права root Дальнейшие действия требуют повышенных привилегий. Выполните sudo -i или su -.

Шаг 1: Уничтожить вредоносный процесс

Немедленно остановите процесс-майнер, чтобы он перестал потреблять ресурсы и отправлять данные злоумышленнику.

bash Скопировать

Закрыть блок

kill -9 9999

(-9 — это сигнал принудительного завершения, который нельзя проигнорировать).

Шаг 2: Найти исполняемый файл трояна

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

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

bash Скопировать

Закрыть блок

# Эта команда покажет путь к исполняемому файлу процесса с PID 9999
readlink -f /proc/9999/exe

Если вы уже убили процесс, ищите файл по имени. Часто они прячутся в /tmp, /var/tmp или используют имена, похожие на системные.

bash Скопировать

Закрыть блок

# Искать файлы, измененные примерно в дату взлома (например, 3 июня)
find / -mtime -30 -user bitrix -type f -ls 2>/dev/null | grep 'kworker'

# Искать файлы с подозрительными именами в нестандартных местах
find /tmp /var/tmp /dev/shm -name "*" -user bitrix

Шаг 3: Найти и удалить механизм автозапуска

Троян должен как-то запускаться после перезагрузки. Проверьте:

• Системный crontab и cron-директории:bash Скопировать

Закрыть блок

crontab -l -u root
ls -la /etc/cron.*
cat /etc/crontab

• Systemd сервисы: Злоумышленники любят создавать свои сервисы.bash Скопировать

Закрыть блок

systemctl list-unit-files --type=service | grep enabled
# Ищите сервисы с подозрительными именами

Часто они маскируются под что-то вроде systemd-network.service (а настоящий называется systemd-networkd.service).

• Скрипты автозапуска:bash Скопировать

Закрыть блок

cat /etc/rc.local

Шаг 4: Проверить посторонние SSH-ключи (теперь под root)

bash Скопировать

Закрыть блок

cat /home/bitrix/.ssh/authorized_keys
cat /root/.ssh/authorized_keys

Удалите все ключи, которые вы не добавляли.

Шаг 5: Проанализировать, как произошел взлом

Это самый сложный этап. Взлом сервера с Битриксом чаще всего происходит через:

• Уязвимость в модуле сайта: Проверьте, все ли модули обновлены.

• Уязвимость в ядре Битрикса: Убедитесь, что платформа обновлена до последней версии.

• Слабый пароль: Пароль от FTP, SSH или админки сайта.

• Загрузка “шелла” через один из компонентов сайта.

Проанализируйте логи веб-сервера (/var/log/httpd/ или /var/log/nginx/) за дату Jun03. Ищите подозрительные POST-запросы, обращения к странным PHP-файлам, попытки сканирования.

Рекомендация: Самый надежный способ — сделать бэкап сайта и базы данных, полностью переустановить сервер с нуля и развернуть бэкап после тщательной проверки его файлов на наличие посторонних скриптов. Лечить скомпрометированную систему очень сложно, и нет гарантии, что вы найдете все “закладки”.

Мы продолжаем расследование, и новые данные помогают сузить круг поиска.

Анализ новой информации

• Systemd Services (продолжение):

• Список по-прежнему не содержит ничего явно вредоносного. zabbix-agent.service — это легитимный сервис мониторинга (если вы его используете). xinetd.service — супер-сервер, который может запускать другие сервисы, но сам по себе не вредоносный.

• /etc/rc.local:

• touch /var/lock/subsys/local — стандартная команда.

• /opt/webdir/bin/update_network.sh eth0 — стандартный скрипт окружения Битрикса для обновления сетевой конфигурации.

• Вывод: В rc.local нет ничего подозрительного.

• SSH-ключи:

• /home/bitrix/.ssh/authorized_keys: Файл отсутствует. Это хорошо. Значит, под пользователем bitrix нельзя зайти по ключу.

• /root/.ssh/authorized_keys: Содержит один ключ с комментарием ANSIBLE_KEY_vds-fialkaexpsar.timeweb.ru. Это ключ, который, скорее всего, был добавлен вашим хостинг-провайдером (Timeweb) для автоматизации управления сервером с помощью Ansible. Если вы заказывали сервер у Timeweb, этот ключ является легитимным. Если нет — это повод для беспокойства. Предполагаем, что ключ легитимный.

Промежуточные итоги и дальнейший план

Мы проверили все “классические” и самые очевидные места автозапуска (cron, systemd, rc.local) и не нашли прямых улик. Троян с высокой вероятностью использует один из двух оставшихся методов:

• Модификация легитимного скрипта/конфигурации.

• Запуск через веб-шелл, загруженный на сайт.

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

---

План действий: Фокусируемся на файлах и процессах

Шаг 1: Найти исполняемый файл вредоноса (ПРИОРИТЕТ №1)

Мы знаем, что процесс-майнер существует (или существовал). Нам нужно найти его файл на диске. Это самая важная задача сейчас.

Попробуем найти его через файловую систему /proc. Если вы еще не убили процесс kworker с PID 9999 (или он перезапустился под новым PID), выполните:

bash Скопировать

Закрыть блок

# Сначала найдем PID вредоноса. Он будет запущен от bitrix и потреблять много CPU
ps aux | grep 'kworker' | grep 'bitrix'

# Допустим, новый PID - 12345. Выполняем:
ls -l /proc/12345/exe
# Эта команда покажет символическую ссылку на реальный файл, который был запущен.
# Например: /proc/12345/exe -> /tmp/kworker

ls -l /proc/12345/cwd
# Покажет рабочую директорию, из которой был запущен процесс.

cat /proc/12345/cmdline | xargs -0 echo
# Покажет полную команду запуска.

Если вы уже убили процесс и он не перезапустился, этот метод не сработает. Тогда переходим к поиску по диску.

Шаг 2: Глубокий поиск подозрительных файлов на диске

Давайте проведем более агрессивный поиск. Майнеры часто прячутся в “мусорных” директориях и имеют атрибут “исполняемый”.

bash Скопировать

Закрыть блок

# Ищем исполняемые файлы в /tmp и /dev/shm (очень популярные места)
find /tmp /var/tmp /dev/shm -type f -perm /a=x -ls 2>/dev/null

# Ищем любые файлы, принадлежащие пользователю bitrix, вне его домашней директории
# Это может найти файлы, которые троян создал в системных папках
find / -path "/home/bitrix" -prune -o -user bitrix -ls 2>/dev/null

Внимательно изучите вывод. Любой исполняемый файл (-rwxr-xr-x) в /tmp или /dev/shm — это почти 100% вирус.

Шаг 3: Поиск веб-шеллов на сайте

Взлом почти наверняка начался с загрузки PHP-шелла. Его нужно найти и удалить.

bash Скопировать

Закрыть блок

# Ищем файлы, содержащие потенциально вредоносные PHP-функции.
# Эта команда может дать ложные срабатывания, но часто находит шеллы.
# Она ищет функции, которые часто используются во вредоносах.
grep -rPl --include=\*.php "eval\(|base64_decode|gzuncompress|str_rot13|shell_exec|passthru|proc_open" /home/bitrix/www/

Просмотрите список файлов, который выдаст эта команда. Откройте каждый из них и посмотрите на код. Легитимный код Битрикса может использовать eval или base64_decode, но если вы видите длинную, запутанную, нечитаемую строку в eval(base64_decode(...)), — это точно веб-шелл.

Шаг 4: Проверка целостности Битрикса

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

• Зайдите в административную панель сайта.

• Перейдите в Настройки -> Инструменты -> Проверка системы -> Сканер безопасности.

• На вкладке “Контроль целостности” запустите проверку.

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

Резюме для вас:

• Главная цель: Найти файл майнера (kworker). Используйте ps и /proc (Шаг 1).

• Вторая цель: Найти веб-шелл на сайте. Используйте grep по PHP-файлам и сканер безопасности Битрикса (Шаги 3 и 4).

• Как только найдете вредоносный файл, удалите его.

• Как только найдете веб-шелл, удалите его и проанализируйте логи веб-сервера (/var/log/httpd/access_log или /var/log/nginx/access.log) за дату изменения этого файла, чтобы понять, как его загрузили.

---

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