Deepwatch 
TL;DR
Deepwatch analyzed an emerging Windows Remote Access Trojan delivered through a ClickFix campaign and executed through an unusual DLL sideloading chain. The malware abuses a legitimate IBM-signed executable from the SPSS distribution, with no prior public reporting of this specific abuse. The RAT includes a previously unseen AMSI bypass, an interpreter architecture, a custom domain-specific language for operator playbooks, broad anti-analysis coverage, and DNS-over-HTTPS-based C2 resolution. The malware appears operational but unfinished, with several features still under development. This is a family worth watching.
Deepwatch recently analyzed a newly observed Windows Remote Access Trojan delivered through a ClickFix social engineering campaign and executed through a multi-stage DLL sideloading chain.
The loader chain is the most interesting part of the sample. It uses a legitimate IBM-signed executable from the SPSS distribution, a modified dependency, and a forced import to pull attacker-controlled code into a trusted process. From there, the malware decrypts shellcode hidden at the end of a playable .wav file, interprets an encrypted operator playbook, and eventually hands execution to the RAT.
The RAT itself is capable, but it does not look complete. Its current feature set focuses on reconnaissance, persistence, command-and-control communication, and payload execution. Several execution paths return “not implemented yet,” which suggests the malware is already operational but still under active development.
That combination makes this sample notable: the loading and evasion tradecraft is advanced, while some of the post-exploitation functionality still looks unfinished.
Initial Access: ClickFix as the Launch Point
The attack began with a ClickFix lure: a fake CAPTCHA that instructed the user to paste a command into the Windows Run dialog. In this case, the command downloaded a payload from westbrookexchange[.]com and executed it with mshta.exe.
The recovered artifact appeared to be a PDF, but its file header showed that it was actually a ZIP archive renamed with a .pdf extension. Inside was a deployment kit built around sslconf.exe, a legitimate IBM SPSS executable, along with its signed dependencies and several files that do not belong to the SPSS distribution.
That mismatch is what made the archive worth pulling apart.
The Sideload Chain: Turning Trust into Execution
The execution chain begins with the IBM-signed executable sslconf.exe.
When Windows launches it, dependencies resolve in sequence:
sslconf.exe imports
tempdir.dll
tempdir.dll imports
platdep.dll
platdep.dll imports
icuin61.dll
The final dependency is the pivot. The attacker supplied a modified version of icuin61.dll, a legitimate ICU internationalization library. This modified copy adds one attacker-controlled import: fltU-1.dll!CompressFromFile.
That function is never called by icuin61.dll. It does not need to be. Because Windows resolves declared imports when a DLL is loaded, the added import is enough to force the loader to bring fltU-1.dll into the same trusted process.
In other words, the attacker does not need an obvious LoadLibrary call or a direct execution handoff from the modified ICU library. The Windows loader does the work because the import table tells it to.
Execution then moves into fltU-1.dll, an unsigned loader DLL that reads encrypted content, decrypts shellcode, stages it into memory, and transfers execution.
Unpacking and Loading
Once fltU-1.dll is pulled into the IBM-signed process, it loads helper DLLs and reads a playable .wav file from disk. The file contains valid audio, but an encrypted shellcode blob has been appended to the end.
fltU-1.dll reads and decrypts that appended content, then uses a helper DLL to allocate memory, copy the decrypted shellcode into it, mark the memory executable, and run the shellcode inside the trusted process.
That shellcode becomes the intermediate loader. It locates sentiment.bak, decrypts it, and runs a custom built-in interpreter that processes decrypted records through a command dispatcher.
Inside sentiment.bak is a custom domain-specific language program. That program acts like an operator playbook: it contains persistence instructions and the handoff logic for the final payload, the RAT.
The design is modular. The DLL chain stages shellcode. The shellcode interprets sentiment.bak. Operators can change instructions or embedded payloads without rebuilding the full execution chain.
RAT Capabilities and Development Signals
The stage-two RAT identifies itself internally as client and reports version 1.5.1.
It can collect host information, enumerate antivirus products, inspect Microsoft Defender status, gather hardware and operating system details, list installed software, collect network and socket data, and identify browser processes from a hardcoded list of 17 browsers.
Persistence appears in two layers. The DSL applies the persistence observed in this campaign using the masquerade name SSL Config Manager. The RAT also contains broader persistence options, including Run keys, Scheduled Tasks, Startup shortcuts, and Windows Service installation.
Payload execution support includes EXEs, MSIs, batch files, PowerShell scripts, and DLL execution through rundll32.exe or regsvr32.exe. With sufficient privileges, the RAT can also attempt elevated or SYSTEM execution through scheduled task mechanisms.
Two execution variants return “not implemented yet.” That is a small detail, but an important one. It points to an operational framework that is still being built out.
Anti-Analysis and AMSI Evasion
The RAT includes broad anti-VM coverage across VMware, VirtualBox, Hyper-V, QEMU/KVM, Parallels, and Xen. It checks drivers, services, registry paths, hardware identifiers, and GPU names. The GPU-name check is especially useful for the malware because some virtualized environments mask obvious CPU, driver, or registry artifacts while still exposing a virtual GPU name.
The most notable evasion technique is the RAT’s AMSI bypass.
Many AMSI bypasses patch functions such as AmsiScanBuffer, creating detectable memory protection changes or byte mismatches between the loaded DLL in memory and the copy on disk. This sample takes a different route.
Instead of patching amsi.dll, the RAT loads it, registers a vectored exception handler, and unmaps amsi.dll from the process using NtUnmapViewOfSection.
Later AMSI calls jump into unmapped memory and trigger an access violation. The handler catches the fault and terminates the scanning thread. Because the caller’s result buffer was zero initialized, the caller effectively receives a clean result even though the content was never scanned.
That makes this technique notable from a defender’s perspective. Detections focused only on memory protection changes to amsi.dll may miss it. The more useful signals are the unmapping of a legitimately loaded system module, vectored exception handler registration near script or .NET activity, and managed or scripted execution in a process where amsi.dll is no longer mapped.
Why This Matters
This sample is worth watching because the strongest parts of the malware are not necessarily the RAT commands themselves. The more interesting signals are in the architecture: signed process abuse, import-table force loading, modular interpreter logic, a custom DSL, broad anti-analysis coverage, and a patchless AMSI bypass.
At the same time, the RAT is not fully mature. Some execution features are stubbed out, and the payload execution model still creates detection opportunities because dropped payloads must touch disk before they run.
That is what makes the family interesting. It is not a fully polished offensive framework, but it already shows enough custom engineering to suggest active development. Future versions may fill in the missing execution paths, expand C2 handling, or add more advanced in-memory execution and evasion features.
Deepwatch will continue tracking this family as it evolves.
↑
Share