Атаки PaperCut із підтримкою ШІ виявляють другу RCE й глобальну мережу жертв

Резюме

Російськомовний зловмисник здійснив цілеспрямовану кампанію проти української інфраструктури, з особливим акцентом на екосистему обміну даними та сервери логування Graylog. Атакуючий використовував инжекційний ланцюжок JNDI на основі Log4Shell для досягнення віддаленого виконання коду та розгортання реверсних шелів. Хоча було здійснено декілька експлойтів проти систем MikroTik та Fortinet, основний успішний доступ залежав від повторного використання ланцюжка десеріалізації CommonsBeanutils2.

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

Розслідування почалося після того, як дослідники виявили директорію оператора, що перебувала у загальному доступі на публічній IP-адресі протягом приблизно 17 годин. Аналітики відновили робочі файли нападника, включаючи скрипти експлойтів, збірники завантажень, історію шелу та результати розвідки. Це викриття дозволило відтворити увесь ланцюжок атаки, від початкового сканування masscan до успішного виконання коду на інстанціях Graylog.

Заходи з пом’якшення

Організації мають пріоритезувати виправлення розгортань Graylog та забезпечити вимкнення або жорстко обмежити запити JNDI через відповідні засоби безпеки Java. Необхідно забезпечити суворе фільтрування вихідного трафіку для блокування несанкціонованих з’єднань LDAP та RMI з серверів додатків. Команди з безпеки також мають спостерігати за незвичайними дочірніми процесами, запущеними Java-сервісами, та застосовувати захист від CSRF на чутливих кінцевих точках API.

Реагування

При виявленні підозрілої активності JNDI або неочікуваних дочірніх процесів, що походять від веб-сервісів, ізолюйте уражений хост негайно. Перегляньте журнали додатків на предмет зразків успішної експлуатації, особливо увагу приділіть кінцевій точці /api/system/sessions . Проведіть судово-експертний аналіз хоста на наявність несанкціонованих SSH ключів, реверсних шелів або персистентних тунелів, які могли використовуватися для півотингу.

Імітація виконання

• Розповідь про атаку та команди: Противник намагається експлуатувати вразливість у веб-додатку для держобміну. Щоб вписатися в адміністративний трафік, вони використовують певний заголовок X-Requested-By: cli. Вони націлюють кінцеву точку управління сесіями /api/system/sessions і намагаються запустити виконання шкідливого шел-скрипта під назвою fire3.sh. Наявність рядка UXP Verifier у відповіді відомо як характеристика специфічного інструментарію, що використовується цим зловмисником. Мета – отримати віддалене виконання коду через веб-сервер.

• Сценарій регресійного тестування:

  #!/bin/bash
  # Сценарій імітації для того, щоб викликати правило виявлення
  # Це імітує запит, що відповідає всім чотирьом критеріям виявлення
  
  TARGET_URL="http://localhost/api/system/sessions"
  
  echo "[+] Імітація цільового запиту атаки..."
  
  # Використовуємо curl, щоб імітувати точні заголовки та шлях запиту.
  # Примітка: Оскільки ми не можемо легко контролювати 'ResponseBody' справжнього сервера 
  # без хостингу макетного сервера, ця імітація передбачає, що журнали 
  # генеруються перехоплюючим проксі або макетним веб-сервісом, що 
  # повертає 'UXP Verifier'.
  
  curl -X POST "$TARGET_URL" 
       -H "X-Requested-By: cli" 
       -H "Content-Type: application/json" 
       -d '{"filename": "fire3.sh", "payload": "echo "UXP Verifier""}' 
       --verbose
  
  echo "[+] Команда імітації надіслана."

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

  # Ніяких постійних змін системи не зроблено, але якщо макетний сервер було запущено:
  # pkill -f "python3 -m http.server"
  echo "[+] Очищення завершено."