◯Ghost in the Bit

Cloned VM Image, Three Cryptojacking Panels, One Delivery Chain

threat hunting research Threat hunting 22 min read
One note before we start. I am not a malware reverse engineer by trade. What I am decent at is the part that comes before the deep reversing: noticing something that does not add up, pulling the thread methodically, and refusing to overclaim. I would rather be the person who says I am not sure, let me verify, than the one who confidently ships something wrong.

I was hunting something else entirely when I stumbled into a cryptojacking operation. Three IP addresses running PureMiner mining panels, all exposing their open directories. Two of them are byte identical clones of the same Windows VM image, proven by identical RDP certificates, SMB server GUIDs, and machine names. The third is connected via a shared PowerShell dropper. When I checked the three nodes against the feeds, the coverage was a patchwork: one node was flagged in some places and invisible in others, and one was missing from everything I checked. I mapped all of them, decoded the actual injected payloads, and found the operation is not just cryptojacking, it runs an AsyncRAT build configured to profile victims for cryptocurrency wallets and flag high value theft targets.

The short version

How I got here

I was hunting something unrelated on Censys, pivoted on a different lead entirely, and by accident landed on a PureMiner panel sitting in an open directory on a host that was also running AsyncRAT. That host turned up in the feeds. But when I pulled its details, I noticed something odd: the RDP certificate and SMB server fingerprints looked like they had been copied byte for byte to another host on a different provider. Then a third node turned up in the dropper configuration. By the time I was done, I had three nodes, all connected by infrastructure forensics rather than by anything the feeds handed me.

The point is that feed coverage is not complete, and machines leave fingerprints when you look at the right data. An RDP certificate is not a mystery, it is a copy paste operation. An SMB server GUID is a cloned drive. A machine name is a template image. These are the tells that real operators do not think about.

The nodes

172.94.18[.]103 (M247 Europe, Frankfurt DE)

Status: Known in both feeds. ThreatFox entry since October 2025 (AsyncRAT), and 50 pulses on OTX. VT 15/91 detections. This is the operation's known anchor node.

This host is running PureMiner on port 80 with an open directory. It also listens for AsyncRAT C2 on ports 73, 75, 76, 79, and 80. The exposed directory contains server.pfx (the RDP host private key) and usersettings.json (the mining configuration, 107 KB, showing pool addresses, profitability algorithm weights, and the payout wallet). The DDNS fronts proxey[.]publicvm[.]com and panel[.]freeddns[.]org both resolve to this IP.

46.105.149[.]77 (OVH SAS, Gravelines FR)

Status: The feed gap case. ThreatFox returned no result, but OTX already had it in 33 pulses. VT 2/91 (noise). So this node was invisible to one feed while well documented in another, which is exactly the single feed blind spot worth paying attention to.

This host is a byte identical clone of 172.94.18[.]103. Proof:

The operator cloned the entire VM image to a second provider. This is not coincidence or shared tooling, this is infrastructure replication. The machine names, certificates, and GUIDs are interior state that does not get reused unless the entire disk was copied.

128.1.79[.]99 (UCLOUD Information Technology, Bangkok TH)

Status: The genuinely new node. Absent from both ThreatFox (no result) and OTX (no prior pulses until mine). VT 1/91 (noise). This is the one node in the cluster that neither feed had seen.

This host is tied to the cluster via the PowerShell dropper enyhxk.ps1 (SHA 256 3b19ba5c3212bde4570940d81aa5b34ff1d9138961556aedf498dda616dbced5), which is a trojan.boxter loader. The VirusTotal report for this dropper lists its contacted_ips as 128.1.79[.]99, 172.94.18[.]103, and 8.8.8[.]8. The Bangkok node also stages the injection machinery: folders /pp/ and /ss/ contain AutoHotkey process injection scripts and encoded PE payloads.

165.154.184[.]75 (UCLOUD Information Technology, Bangkok TH)

Status: Flagged but feed thin. ThreatFox no result. VT 8/91 (malicious consensus).

This host is the plugin and payload distribution server. The miner configurations on 46.105.149[.]77 and 128.1.79[.]99 reference hxxp://165.154.184[.]75/New2026/plugin{1,2,3}.bin. VirusTotal already flagged this host as malicious, but ThreatFox had not indexed it. Known bad to one source, missing from another, which is the same coverage gap pattern the rest of the cluster shows.

The delivery machinery and process injection

The Bangkok node stages a sophisticated delivery chain using process injection and in memory PE loading. Two folders, /pp/ and /ss/, each contain three components:

The .ahk scripts implement a process hollowing technique: they read the encoded PNG file (comma separated decimal numbers), decode it by multiplying each value by a factor (2 or 4), and inject the resulting PE executable into a suspended AppLaunch.exe process using a sequence of Windows API calls (CreateProcess, ReadProcessMemory, WriteProcessMemory, SetThreadContext, ResumeThread). The decoded payloads are injected into memory without touching the filesystem, leaving no direct traces.

The decoded payloads

Both decoded PE files are 66,560 bytes, PE32 .NET assemblies compiled in Visual Basic .NET. I decoded them by reversing the PNG encoding (multiplying CSV decimal values by 2 or 4) and then decompiled them to determine actual functionality.

a2026_decoded.exe (decoded from a2026.png, multiply by 2)

This is a recognized AsyncRAT variant. AsyncRAT is a known remote access trojan sold on underground markets. The presence of a known RAT alongside the crypto stealer (below) suggests a two stage delivery: first profile the victim, then deploy the RAT for manual control once high value targets are identified.

s_decoded.exe (decoded from s.png, multiply by 4), AsyncRAT Build Configured as a Wallet Stealer & Target Profiler

This payload was not sitting in a feed waiting to be found. I pulled the encoded staging file s.png from the open directory on 128.1.79[.]99, applied the cipher transform the AutoHotkey script uses (the CSV float values, multiplied by 4) to reconstruct the original PE, and generated the hash above from the decoded binary. It was absent from VirusTotal at that point, and I submitted both the sample and the indicators afterward. The decode is what surfaced it.

I first thought this was a wholly new standalone stealer. Detonating it in a sandbox corrected that. The backbone is AsyncRAT, a known family, the sample creates the signature AsyncRAT mutex AsyncMutex_6SI8OkBSS, which is a known default and confirms the family but does not tie it uniquely to this operator. What is distinctive here is the configuration: this build is set up to hunt cryptocurrency wallets, and it calls a fresh C2 I had not seen before.

Once you account for the AsyncRAT base, the wallet targeting behavior (confirmed by both decompilation and detonation) is the interesting part. Upon execution it performs the following reconnaissance:

System Profiling: Collects HWID (hardware fingerprint), username, Windows version, admin status, and installed antivirus/security products. This creates a unique victim identifier.

Crypto Wallet Detection: Scans for installed cryptocurrency wallet browser extensions across Chrome, Edge, Firefox, and Brave. Specifically checks for MetaMask, TrustWallet, TronLink, Bitcoin Core, Ledger Live, Trezor Suite, Exodus, Atomic Wallet, and Binance. This identifies which victims hold cryptocurrency.

2FA Detection: Checks whether Bitcoin Core has 2FA authentication enabled. This is the critical targeting filter, victims with 2FA are low value targets (harder to steal from), while victims without 2FA are flagged as high priority.

Live C2: Sandbox detonation surfaced a fresh callback at 34.171.51[.]66:190 (Google Cloud). That is a new IOC for this specific build, separate from the cluster panels.

All this data is packaged and sent back to the C2. The operator uses this intelligence to decide which victims to pursue further. Victims with multiple unprotected wallets and no 2FA are the targets for the next stage: a cryptocurrency clipper or transaction hijacker that will steal outbound crypto transfers.

So the honest framing is an AsyncRAT build wearing a wallet stealer configuration, not a brand new malware family. The base is borrowed and credited; the targeting config and the fresh C2 are the parts worth reporting.

What I am not claiming

On the machine cloning: I proved they are clones by the certificates, GUIDs, and machine names. I did not pull the disks or prove they were cloned at a specific time. But the evidence is airtight: an RDP cert and SMB GUID do not duplicate unless the entire disk was copied.

On the operator: I do not have a persona, a wallet address (though it is probably in the usersettings.json payout field, which I chose not to pull), an email, or any person level identification. This is pure infrastructure attribution. The operator will likely redeploy this image to new providers once they know it got reported, so the tracking signature is the machine identity KSKGNROPECBQUBT, which will catch the next clone.

On the next stages: The wallet stealer profiles victims, but I did not capture the actual crypto theft tools (the clipper or drainer that would follow). Those are likely deployed separately to high value targets once the operator reviews the profiling data. I also did not pull the operator's cryptocurrency payout wallet, which would identify their funding flow. Both are deliberate choices to avoid operator loot fetches.

The tracking signature

The operator is cloning this Windows VM image across hosting providers. Future instances will carry the same interior identifiers: 

Computer name:                    KSKGNROPECBQUBT
RDP certificate CN:               KSKGNROPECBQUBT
RDP certificate SHA-256:          0254cdb43059463dc3c6c752a629ce7afe79b83e6a3f24bfa799d5540585a633
SMB server GUID:                  …48bdf0df8a67e040aab8fdd21d197710

In Censys, use either of these queries to catch future clones:

host.services.cert.parsed.subject_dn="CN=KSKGNROPECBQUBT"

host.services.cert.fingerprint_sha256="0254cdb43059463dc3c6c752a629ce7afe79b83e6a3f24bfa799d5540585a633"

As of June 12, 2026, Censys reports exactly two clones on these signatures. Both are the ones I already identified. When the operator replicates to a new provider, this query will catch it immediately.

Indicators

C2 Nodes

172.94.18[.]103       M247 DE         PureMiner + AsyncRAT C2     KNOWN (ThreatFox + OTX)
46.105.149[.]77       OVH FR          PureMiner (clone)             OTX-known, ThreatFox-absent
128.1.79[.]99         UCLOUD Bangkok  PureMiner + injection staging  NEW (absent from both feeds)

Payload Distribution, DDNS & Sample C2

165.154.184[.]75                  UCLOUD Bangkok  plugin/payload host        (VT 8/91)
34.171.51[.]66:190                Google Cloud    s_decoded.exe live C2      (from detonation)
proxey[.]publicvm[.]com → 172.94.18[.]103      operator DDNS front
panel[.]freeddns[.]org  → 172.94.18[.]103      operator DDNS (host reported)

Malware Samples

3b19ba5c3212bde4570940d81aa5b34ff1d9138961556aedf498dda616dbced5
  enyhxk.ps1 — PowerShell boxter loader

eee4f6c96ed1a8390ea884e5abdc5be2746bf9407466d4dff0a48f862c074dfc
  FileDeployer.exe — crysan dropper

d0774f8d94ca78dc6b159b23d0a2471a0f9a6fb2bb21463fe9b9f6050e95f4c1
  intell.exe — VB.NET loader

effdea83c6b7a1dc2ce9e9d40e91dfd59bed9fcbd580903423648b7ca97d9696
  s.exe / real.exe — AutoHotkey interpreter (carrier)

4dd0748c0296953a216bbf962c2ebdf228463536ad6974dc38cb37425db6e422
  a2026_decoded.exe — AsyncRAT/MSIL (58/76 VT)

8be38944888bfccf63a61956707a9fc53654e2b70e5adfec860235a9afaaad24
  s_decoded.exe — AsyncRAT build, wallet stealer config
  Live C2: 34.171.51[.]66:190 (Google Cloud) · Mutex: AsyncMutex_6SI8OkBSS

What to actually do about it

If you are defending a network: Block the three C2 IPs and the payload host. They are the immediate threats. Hunt for the behavior: process injection via PowerShell dropper into hidden folders, AutoHotkey process hollowing, and encoded PE staging. This campaign will rotate hosts, but the machine identity KSKGNROPECBQUBT will catch the next clone. Report it to ThreatFox and ShadowServer. The infrastructure is wide open; the control side is dark for now.

If you are a regular person: Cryptojacking does not usually come with a lure page like ClickFix. It usually hits you through a watering hole, a vulnerable service, or a compromised third party. The risk is mostly background CPU theft and electricity costs. If you think you are infected, disconnect from the network, get the machine checked by someone who knows how, and change your passwords from a different device.

The honest wrap up

This started as an accident (I was looking for something else entirely) and turned into a complete infrastructure map. The three node cluster is real, the cloning is real, the delivery chain is real, and the decoded payloads are in my hands. The feed coverage told its own story: one node known in both ThreatFox and OTX, one missing from ThreatFox but already in 33 OTX pulses, and one absent from both. One payload is documented (AsyncRAT), one was new to the feeds. The patchwork is the point. The same node can be known in one feed and invisible in another, and the gaps run in both directions, which is exactly the kind of thing that slips through when you trust a single source of top level IOCs instead of reading the fingerprints of the machines underneath.

The infrastructure is real, the machines are real, and the machines will behave the same way when the operator spins up the next clone. That is what the tracking signature is for.

Sources and methodology. Infrastructure clustering and certificate analysis via Censys Platform. Malware sample analysis via VirusTotal and local decompilation. Process injection technique cross referenced against known patterns. The AutoHotkey process hollowing pattern is a documented technique, repurposed here in a cryptojacking context.

Powered by Buttondown.