DEV#POPPER RAT, доставлений через зламані випуски npm від Joyfill

Резюме

Два скомпрометовані бета-релізи @joyfill пакету npm були знайдені з імпортним JavaScript-вбудованням, яке використовує транзакції блокчейну через Tron, Aptos та BNB Smart Chain для завантаження та розгортання трояна віддаленого доступу (RAT) DEV#POPPER. Кампанія націлена на робочі станції розробників та CI/CD конвеєри шляхом виконання шкідливого коду відразу після імпорту ураженого модуля.

Розслідування

Команда досліджень Socket виявила злом, аналізуючи бета-версії @joyfill/layouts and @joyfill/components. Дослідники ідентифікували багатоступеневий ланцюг доставки навантаження, що поєднує обфусцирований JavaScript з механізмами доставки, підтримуваними блокчейном. Розслідування зв’язало початковий завантажувач з родиною PolinRider та підтвердило, що кінцеве навантаження належало до родини шкідливого ПЗ DEV#POPPER.

Пом’якшення наслідків

Розробники повинні негайно видалити уражені @joyfill бета-версії з lockfiles, кешів пакетів, середовищ збірки та артефактів розгортання. Рекомендується прикріпити залежності до перевірених випусків, таких як @joyfill/layouts@0.1.1 or @joyfill/components@4.0.0-rc24 . Команди безпеки також повинні блокувати скомпрометовані версії через проксі-реєстри та інструменти управління залежностями.

Реакція

Будь-яка система, що імпортувала уражені пакети, повинна бути ізольована, а всі облікові дані, доступні компрометованому процесу Node.js, повинні бути змінені. Дослідники повинні перевірити додатки розробників, включаючи VS Code, GitHub Desktop і Discord, на предмет несподіваних змін ядра модулів. Телеметрія кінцевих точок та CI/CD також повинна бути переглянута для виявлення відокремлених процесів Node.js, відомих C2-адрес і підозрілої RPC-трафіка блокчейну.

Виконання симуляції

Попередня умова: Телеметрія та попередня перевірка базової лінії повинні бути пройдені.

Обґрунтування: Цей розділ детально описує точне виконання техніки супротивника (TTP), призначеної для запуску правила виявлення. Команди та наративи ПОВИННІ безпосередньо відображати ідентифіковані TTP та прагнуть генерувати точну телеметрію, очікувану логікою виявлення. Абстрактні або не пов’язані приклади призведуть до неправильної діагностики.

• Сценарій атаки та команди: Супротивнику вдалося впровадити шкідливий код у широко використовувану npm-залежність (компрометація ланцюга постачання). Коли розробник виконує команду npm install або починає проект, шкідливий скрипт запускається. Сценарій спочатку намагається приховати свої наміри, призначаючи функцію require глобальній змінній (global.r = require), що дозволяє йому завантажувати модулі в будь-якому місці програми без виклику напряму require (обфускація). Нарешті, він використовує child_process.spawn для запуску відокремленого командного процесу, який під’єднується назад до сервера керування та управління (C2), намагаючись уникнути виявлення, відокремлюючи шкідливий процес від процесу Node.js.

• Скрипт тестування регресії:

  #!/bin/bash
  # Симуляційний скрипт для запуску правила виявлення ін'єкцій Node.js.
  # Цей скрипт створює тимчасовий шкідливий JS-файл і виконує його через Node.js.
  MALICIOUS_FILE="malicious_pkg.js"
  echo "[+] Створення шкідливого скрипта Node.js..."
  cat << 'EOF' > $MALICIOUS_FILE
  // Імітація глобальної ін'єкції модуля (T1027)
  global.r = require;
  // Імітація виконання відокремленого процесу через child_process.spawn (T1059.006)
  const cp = require('child_process');
  cp.spawn('bash', ['-c', 'sleep 30 &'], { detached: true, stdio: 'ignore' });
  console.log("[!] Виконано шкідливе навантаження.");
  EOF
  echo "[+] Виконання шкідливого скрипта через Node.js..."
  node $MALICIOUS_FILE
  echo "[+] Симуляція завершена. Перевірте SIEM для оповіщення: Виявлення ін'єкцій модуля Node.js та виконання відокремлених процесів."

• Команди очищення:

  # Видалити змодельований шкідливий файл
  rm -f malicious_pkg.js
  # Вбити будь-які осиротілі процеси sleep, запущені під час симуляції
  pkill -f "sleep 30"