We had an opportunity to analyse a system with frequent detection-alerts over powershell execution. Our analysis revealed a multi-stage infection that relied heavily on obfuscation, Registry-based payload storage, covert data delivery, persistence mechanisms, security-control tampering, and in-memory execution. Rather than deploying the final payload directly to disk, the threat actor used layered concealment and reconstructed payloads from Registry data, DNS TXT records, image files, and WAV files to operate Cryptomining 

Phase 1: Registry-Based PowerShell Execution and PNG Payload Delivery

The relevant portion of the PowerShell code is shown below:

The following is the script that triggered the alert:

Powershell.exe -NoProfile -executionPolicy Bypass -File C:\Windows\System32\vstdfehze.ps1 Set-PSReadLineOption -HistorySaveStyle SaveNothing & ([scriptblock]::Create((Get-ItemProperty -Path HKLM:\Software\uf42a9660377\vstdfehzr -Name vstdfehzr).vstdfehzr))

The PowerShell code contained a Registry path referencing HKLM:\Software\uf42a9660377\vstdfehzr, indicating that the Registry was being used to store the next stage of the payload.

The Registry value contained an encoded PowerShell payload in binary data format. The script dynamically retrieved and decoded this value at runtime, allowing the threat actor to execute the payload without storing it as a traditional .ps1 file. 

The script periodically queried DNS TXT records associated with `sslvalidcert.com`, which was later changed to `http[:]//txtcdn[.]net` after a few days, to retrieve encoded data. The TXT response was extracted and converted from decimal values into an ASCII string, which was then used as part of the payload retrieval process. The main part of the code is shown in Figure 3.

Here, `Resolve-DnsName` performs the TXT record query, while the returned comma-separated decimal values are converted into bytes and then reconstructed into an ASCII string. The ASCII string turned out to be a URL from which a PNG image was downloaded :  frames-1zm[.]pages.dev/frames.png .

The image was a covert data container. The script extracted information from the red channel of pixels in the image to reconstruct the embedded payload. Figure 4 contains a raw view of the ‘frames.png’  and Figure 5 shows an enhanced view of the hidden script.

The embedded data was extracted and reconstructed before being executed on the compromised system. Upon execution, the payload initiated a C2 connection to receive another powershell script and secondary instructions.

Phase 2: WAV Files as Payload Containers

The PowerShell script received from the C2 server first removes user’s existing files from the “Public\Music” directory. It then downloaded a ZIP archive and extracted its contents into the same location.

The archive contained files with the “.wav” extension, making them appear to be legitimate audio files:

• “Atsg.wav”
• “Tmav.wav”

However, the files were not used as conventional audio content. Two of the extracted WAV files were subsequently read and processed by the PowerShell scripts for payload extraction.

ATSG.wav: Security Evasion and Persistence

The “Atsg.wav” stage contained another encoded PowerShell payload. During analysis, we observed that the script modified the PowerShell execution policy to “Bypass” and tamper with several security and telemetry mechanisms.

The script modified PowerShell configuration, disabled or weakened selected security-related features, added broad Microsoft Defender exclusions, and removed PowerShell history to reduce visibility into the activity.

Multiple persistence mechanisms were then established. Hidden Scheduled Tasks were created to execute the encrypted payload at logon and at regular intervals. In addition, a WMI permanent event subscription was configured to monitor a Registry-related event and trigger the payload when the specified Registry condition changed. Log can be seen in Figure 9.

Binary-to-ASCII Encoded PowerShell

The script also contained a block of decimal encoded data. After decoding, a powershell script was revealed with the functionality responsible for extracting a .NET assembly from a WAV file.

DNS-Based C2 Communication

The payload also implemented a persistent command-and-control mechanism using PowerShell.

At startup, it generated a unique 20-character host identifier. This identifier was stored in the Registry and subsequently used to identify the compromised system.

For C2 discovery, the payload used DNS-over-HTTPS to query TXT records associated with “httptls.org” through Google DNS. The response contained information used to determine the C2 server address.

After discovering the C2 server, the payload communicated using HTTP/HTTPS POST requests and identified the compromised host through an “X-HWID” header.

The payload periodically transmitted “Info” and “pingo” messages to maintain communication with the server. When the server returned a “ps1” command, the payload extracted the PowerShell code and executed it asynchronously using a PowerShell execution context.

The execution result was subsequently reported to the C2 server using “OK” or “ERR” responses.

The communication mechanism also incorporated randomized delays and exponential backoff when communication failed. This allowed the payload to repeatedly attempt reconnection while reducing the frequency of network requests.

WAV-Based .NET Assembly Extraction

When reversing the decoded PowerShell payload, we found that it download “Realtek HD Audio.wav” from https[:]//publicwavlib.pages[.]dev/hdaudio.wav and extracts an embedded payload from the audio data.

The script skipped the standard 44-byte WAV header and reconstructed the embedded data by combining the lower four bits, or nibbles, of consecutive bytes. The resulting data represented a .NET assembly.

Instead of writing the reconstructed assembly to disk, the script loaded it directly into the PowerShell process using:

“[Reflection.Assembly]::Load()”

This allowed the .NET assembly to execute directly from memory.

.NET DLL: PowerShell Execution and Defense Evasion

After extracting the .NET DLL, we analyzed its functionality and found that it further modified the PowerShell environment.

The DLL modified the PowerShell profile and configured the execution policy to “Bypass”. It also created a separate PowerShell execution context and used it to disable or weaken selected security and telemetry features, add broad Microsoft Defender exclusions, disable selected Defender-related services and scheduled tasks, and remove PowerShell history files.

These capabilities indicate that the DLL primarily served as a defense-evasion component, reducing security visibility and removing artifacts associated with PowerShell execution before the infection progressed further.

TMAV.wav: In-Memory .NET Execution

The Tmav.wav stage contained another PowerShell payload. After decoding, the script checked whether mav.wav was already present in the Public\Music directory, where it had been extracted from the previously downloaded ZIP archive.

If mav.wav was not found locally, the script downloaded a copy from https[:]//publicwavlib[.]pages.dev/mav.wav. This fallback mechanism ensured that the payload could still be retrieved if the previously extracted file was unavailable.

Further analysis revealed that this third WAV file too acted as a carrier for a hidden .NET executable. Similar to the previous extraction stage, the script skipped the 44-byte WAV header and reconstructed the embedded data by combining the lower nibbles of consecutive bytes.

The resulting .NET executable was then loaded directly into memory using:

“[Reflection.Assembly]::Load()”

Its entry point was subsequently invoked, allowing the final payload to execute without requiring the reconstructed executable to be written to disk.

Phase 3: .NET Executable – Cryptocurrency Mining

Analysis of the reconstructed .NET executable revealed that it was the final payload and functioned as a cryptocurrency miner associated with the XMRig mining ecosystem.

While debugging the executable, we observed an embedded command-line configuration similar to:

-a rx/0 -o xmr-asiannanopoolorg:10343 --keepalive -u <Alphanumeric value> -p x --tls --cpu-max-threads-hint=40

The configuration indicated the use of the “rx/0” RandomX algorithm, a remote mining pool, a wallet/worker identifier, persistent pool communication, TLS, and a CPU-thread configuration hint.

The executable also contacted a remote “config.txt” resource, which returned additional mining parameters:

These parameters provided the miner with its algorithm, pool, wallet, communication settings, and custom CPU-utilization controls.

During analysis, we also observed that the .NET executable dropped “WinRing0.sys”, a signed kernel-mode driver used by XMRig on Windows to provide access to CPU Model-Specific Registers (MSRs) for RandomX optimization. Its presence is therefore consistent with the miner’s low-level CPU optimization requirements.

This investigation uncovered a multi-layered infection chain in which each stage concealed the next payload using a different technique.

The initial PowerShell script was stored in the Registry and dynamically executed. DNS TXT records were then used to retrieve information that led to a PNG-based payload container. Subsequent stages used ZIP archives and WAV files to disguise additional PowerShell scripts and .NET assemblies. The assemblies were reconstructed and loaded directly into memory, reducing the need to write executable payloads to disk.

At the same time, the malware established persistence through Scheduled Tasks and WMI permanent event subscriptions, while modifying PowerShell and Microsoft Defender settings to reduce detection and telemetry.

The final stage deployed a cryptocurrency miner based on the XMRig ecosystem, with both embedded and remotely retrieved configurations controlling its mining behavior.

An important aspect of the infection is that the C2 communication established during the earlier stages remained available independently of the final mining activity. This means that even after identifying the cryptocurrency miner, the compromised host could potentially remain under the threat actor’s control through the existing C2 channel. The channel could subsequently be used to deliver additional payloads, execute further commands, or conduct other malicious activity.

Indicators of Compromise (IOCs)

URL

https[:]//wavmain[.]pages.dev/main.wav

https[:]//publicwavlib[.]pages.dev/mav.wav

https[:]//frames-1zm[.]pages.dev/frames.png

https[:]//config-rg7[.]pages.dev/config.txt

https[:]//softtestcopapool[.]pages.dev/rxconfig.txt

https[:]//publicwavlib[.]pages.dev/hdaudio.wav

Files

Hash	File Name	Detection Name
ED276B2312F641B00F87FA18E85C48EB	Realtek HD Audio.wav	Trojan ( 0001140e1 )
BE860A15B7E5D44B0B3D67F598238FAD	mav.wav	Trojan ( 0001140e1 )
C024189E1E7FA0AE6D24353367E8B98D	tmav.wav	Trojan ( 0001140e1 )
94B50ACE73CC03790678C73B867BE129	atsg.wav	Trojan ( 0001140e1 )
F94DE28BD66AFC4679F546500DB184D4	fp.dll	Trojan ( 0001140e1 )
F1D2FDB7F3B699DA69A050C5352A33C2	upgrade.exe	Trojan ( 0001140e1 )

C2 Connection

104[.]21[.]2[.]193:8443