PowerShell Malware Hid in the Registry and Pulled Its Miner Out of DNS Records a PNG and Four WAV Files

Your Windows PC mined Monero on 40 percent of your threads. A scan of the disk found nothing to delete. The code sat in the registry. The rest arrived in DNS records, a PNG image and four WAV files.

The machine would not stop complaining about PowerShell. Clean it up, and the next day the alerts were back. The startup folder was empty. There was no download to point at and the fans kept running anyway.

And that is why a cleanup did not help. What made the noise was a chain of five stages, and each stage handed the next one its code without ever saving it as a file. K7 Security Labs pulled it apart.

It starts with one command line:

1

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))

PowerShell normally reads a small startup file of your own when it opens, and -NoProfile skips it, so nothing you set up runs, including anything you told it to log. The other switch overrules the rule that says scripts from outside are not allowed to run.

Then the line turns off the record. Set-PSReadLineOption -HistorySaveStyle SaveNothing tells PowerShell to keep no history of what gets typed, and that happens before a single byte is downloaded.

And the last part of the line does the work: it reads a registry value and runs whatever comes out of it. K7 does not describe what sits inside that .ps1 file, so I am not going to invent that for you. The rest of the line is right there in the open.

Windows keeps a long list of settings for itself and for your programs. Where something is installed, which program opens which file, licence keys, window positions. That list is the registry, and it is built for text and numbers.

The second stage was parked in there, in HKLM:\Software\uf42a9660377\vstdfehzr. The loader read that value, turned it back into code inside memory, and ran it. Nothing was written to disk.

Antivirus that scans files had nothing to open.

Then the code asked DNS for directions. A domain name can carry a line of loose text, whatever the owner wants to put in it. Your mail provider uses it to say which servers may send mail in your name, and a certificate company asks you to put one there to prove the domain is yours. It is called a TXT record. Those lookups happen all day on a normal network.

The script asked sslvalidcert[.]com for its TXT record, later txtcdn[.]net. What came back was a row of numbers with commas between them. Turn each number into a byte, put the bytes next to each other, and you have a web address.

That address was frames-1zm[.]pages.dev/frames.png. The file downloads and opens like any other picture, because it is one.

A pixel is three numbers: how much red, how much green, how much blue. Nudge the red numbers a little and your eye sees the same picture, while those numbers now spell out something else. The script read the red values back and built the next stage out of them.

Next came a ZIP file into Public\Music, and the script emptied that folder first, deleting whatever you had in there. Inside the archive were Atsg.wav and Tmav.wav. Two more came separately from publicwavlib[.]pages.dev: mav.wav, and a file called hdaudio.wav that was written to disk under the name Realtek HD Audio.wav, which is the name of a common Windows sound driver. In a music folder that reads as normal.

A WAV file starts with 44 bytes that tell your player what the sample rate is and how many channels there are. The loader skipped those 44 bytes and went to work on the rest. It took the bottom half of each byte, the nibble, and glued the nibbles of neighbouring bytes back together.

Out came a program, loaded straight into memory with [Reflection.Assembly]::Load(). It never became a file, and quarantine needs a file.

With that running, the script started clearing the road. It added broad Defender exclusions, which is how you tell the scanner to skip entire folders. It set the execution policy to Bypass. It wiped the PowerShell history, the file that keeps what you typed, so the commands were gone.

Then it made sure it would come back. Hidden scheduled tasks fire at logon and again on a timer.

The second way back is quieter. Windows has a service that watches itself and reports what happens: a program starting, a key changing, a disk filling up. It is called WMI, and you can ask it to keep an eye on something and run a command when that thing happens. That request lives inside WMI’s own database, not in a folder and not in a startup key, so a cleanup that only looks at files walks straight past it. This one was watching a registry condition.

Delete the registry value and WMI puts the chain back.

For its orders the payload used DNS over HTTPS, through Google’s resolver, asking for the TXT records of httptls[.]org. A normal DNS question travels in the open and whoever sits on the network can read which name you asked for. DNS over HTTPS packs that question inside an ordinary web request, so the monitor shows a connection to Google and nothing else.

It then reported in to the address it got back. In the header of that request sits X-HWID, and what goes in there is a 20-character identifier the payload made when it first ran and stored in the registry. That is how the operators tell one infected machine from another. The messages are called Info and pingo. Commands come back as ps1 and run in PowerShell. The server in the writeup is 104[.]21[.]2[.]193 on port 8443.

At the end of the chain sits XMRig, the open source Monero miner:

1

-a rx/0 --keepalive -p x --tls --cpu-max-threads-hint=40

rx/0 is RandomX. Monero uses it on purpose, because it runs well on the processor you already have and badly on the special hardware the big mining farms buy. The --tls flag encrypts the line to the pool, a Nanopool address on port 10343, and the rest of the settings come from config-rg7[.]pages.dev/config.txt and softtestcopapool[.]pages.dev/rxconfig.txt.

The number to look at is 40, and it is a percentage. XMRig’s own manual calls --cpu-max-threads-hint the maximum CPU thread count in percentage. On a machine with sixteen threads that is about six of them, running day and night. The rest stays free, the machine keeps working the way you expect, and you go looking for some other reason why it feels slow.

Then there is the driver.

Inside your processor sits a set of switches that decide how it handles memory and caching. Windows does not let a normal program near them. You need code running in the kernel, the innermost part of the system, and that means a driver. RandomX mines faster when those switches are set a certain way, so XMRig brings its own: WinRing0.sys, signed years ago and shipped with ordinary hardware monitoring tools like HWiNFO and MSI Afterburner.

When a driver loads it opens a door that programs can talk to, and that door comes with a list of who may use it. This one has an empty list. Not admins only. Empty. A user with no admin rights can walk through and use the driver to read and write memory anywhere on the machine, kernel memory included.

That is CVE-2020-14979, public since 2020. Defender knows it as VulnerableDriver:WinNT/Winring0 and it sits on Microsoft’s blocklist of drivers that should not load.

And that is what those exclusions are for. In March 2025 Defender started flagging WinRing0 and broke Fan Control, OpenRGB and Libre Hardware Monitor for the people who use them to watch their fan speeds. That is the alarm this chain switches off before it drops the same driver on your machine.

The files in this chain come off Cloudflare Pages, five .pages.dev subdomains and six URLs in all. Free, HTTPS by default, on hostnames that resolve to the same edge network as a large slice of the web.

And so does the command and control. That address in the writeup, 104[.]21[.]2[.]193, falls inside 104.16.0.0/13, one of their own ranges, and 8443 is one of the six ports they proxy HTTPS on, next to 443, 2053, 2083, 2087 and 2096.

So the address you would hand to a firewall sits at the edge of that network. Where the operator’s own machine stands is not in the writeup.

Neither half of this is new.

Code that hides in the registry with nothing on disk is Poweliks, written up by G Data in July 2014, and Kovter, which did the same from May 2015.

XMRig inside WAV files is October 2019, when Cylance researchers found audio files carrying miners and reverse shells on the same network. Some of those files played music, some played static, and their loaders read the hidden data out of the audio samples themselves.

This chain does not bother with that. It skips the header and reads nibbles, which means the file never has to sound like anything at all.

Two old tricks, one from 2014 and one from 2019, welded together with DNS records, a picture and a signed kernel driver.

One more thing, and it is the part that matters if this ever lands on your machine. The C2 channel from the earlier stages keeps running on its own, separate from the mining. K7 says it plainly: even after the miner has been found, the host can stay under the operator’s control through that channel. Find the miner, kill the miner, and the way back in is still open.

What you can look at on your own Windows machine:

• → The registry key: reg query "HKLM\Software\uf42a9660377" (an error saying it cannot be found is the answer you want)
• → Your antivirus exclusions: Get-MpPreference | Select-Object -ExpandProperty ExclusionPath
• → Scheduled tasks you did not make: Get-ScheduledTask | Where-Object {$_.State -ne "Disabled"}
• → Permanent WMI subscriptions: Get-CimInstance -Namespace root\Subscription -ClassName __EventFilter
• → Audio files in a folder you never put audio in: Get-ChildItem C:\Users\Public\Music
• → Turn on the Microsoft vulnerable driver blocklist: Windows Security, Device security, Core isolation

The files in the writeup, by MD5:

• → Realtek HD Audio.wav | ED276B2312F641B00F87FA18E85C48EB
• → mav.wav | BE860A15B7E5D44B0B3D67F598238FAD
• → tmav.wav | C024189E1E7FA0AE6D24353367E8B98D
• → atsg.wav | 94B50ACE73CC03790678C73B867BE129
• → fp.dll | F94DE28BD66AFC4679F546500DB184D4
• → upgrade.exe | F1D2FDB7F3B699DA69A050C5352A33C2

The domains: sslvalidcert[.]com, txtcdn[.]net, httptls[.]org, frames-1zm[.]pages.dev, publicwavlib[.]pages.dev, wavmain[.]pages.dev, config-rg7[.]pages.dev, softtestcopapool[.]pages.dev

And here is what the research does not say, because I am not filling that in for you.

How the machine got infected in the first place is not in there. The analysis starts at a system that kept alerting on PowerShell. The number of infected machines is missing, and so are the amount mined, the country and the date this was seen. The scheduled tasks are not named and the exclusion commands are not printed, so I am not inventing either of them. K7 published the analysis on 18 September 2026.

One thing to be exact about, because it is the first question that comes up with this kind of malware: the loader script in System32 and the WAV files in Public\Music are files, and they are on your disk. What never lands there as a program is the miner. That part only ever exists in memory.

On your own machine you can hide a file inside an image, pull it back out, and see the DNS queries go past.

My Ethical Hacking Complete Course Zero to Expert takes you there step by step: reconnaissance, scanning, exploitation and traffic analysis, hands-on, from your first day with no Linux or hacking background.

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources:

K7 Security Labs | XMRig | Microsoft