SolarisLoader - A New Malware Loader

Executive Summary

• SolarisLoader - a new malware loader | Spamhaus' Cyber Threat Intelligence Unit (CTI FU) identified this new malware loader, named as SolarisLoader, used by an unknown threat actor that is using this previously undocumented and undetected loader to actively deploy additional loaders/stealers.

• Naming rationale | We are tracking this new malware family as Solaris, based on the internal project name recovered from a Program Database (PDB) path found within its watchdog component.

• Defense evasion | Solaris is not obfuscated but instead relies on Safetica Windows Driver to disable Windows Services as well as to kill Endpoint Detection and Response (EDR) processes to avoid detection and increase infection rates.

• Advanced stealth tactic | The loader patches Window's internal Antimalware Scan Interface (AMSI) and Event Tracing for Windows (ETW) via direct opcode modification, blinding Windows telemetry before persistence is established.

• A resilient three-layer persistence mechanism | Solaris combines scheduled task registration, registry-based self-backup, and a watchdog process that automatically re-initiates the implant to ensure it keeps running after a victim restarts their computer.

• Active development cycle | This malware stealer has matured significantly with 10 distinct versions, confirming active operational evolution by the threat actor.

Introduction

In May 2026, the CTI FU identified a new malware family in the wild that we track as SolarisLoader distributed by various crack tools. Solaris has been observed delivering a variety of other infamous stealers and loaders, including StealC, XTinyloader and Amadey.

While Solaris is mainly used as a loader, early versions had clipping capabilities, targeting cryptocurrency coins.

During our analysis (as of June 2026), we have encountered two types of fake installers containing SolarisLoader:

• Installers containing the malicious Solaris executable in an unencrypted form, dropping it to disk and executing it immediately.

• Installers that have the malicious executables in its Resource section, encrypted with the same single XOR byte constant or with a hardcoded RC4 key, decrypting them, dropping to disk and then executing them.

Distribution Chain

Fake Installer Campaigns

Unencrypted Solaris Executable

The analyzed fake installers contain multiple malware families embedded within the executable. These payloads are extracted to disk under randomly generated filenames and subsequently executed via CreateProcess or ShellExecute.

The installer's final stage consists of writing and executing the legitimate cracked software that is being impersonated. This is likely to reduce the user's suspicion after the malware deployment has completed.

It is worth noting that this behavior was not present in all observed samples. Earlier variants deployed only the malicious payloads and did not drop the advertised software. The addition of the impersonated application in later samples suggests an effort by the malware operators to improve the perceived legitimacy of the installer and reduce the likelihood of users noticing the compromise.

Encrypted Solaris Executable

With this version the payloads are stored within the Portable Executable (PE) resource section and are extracted using one of the two following methods:

1. Resources with IDs such as 1, 2, and subsequent entries are encrypted using a single-byte XOR key. After decryption, the files are written to disk and executed via ShellExecuteW.

2. Resources with IDs such as 100, 101, and subsequent entries are encrypted using RC4. The RC4 key is hardcoded within the binary. Following decryption, the payloads are written to disk and executed via ShellExecuteW.

Distribution Through Other Loaders

In addition to the fake installer campaigns described above, Solaris has also been observed being distributed by other known malware loaders, including XTinyLoader and Amadey.

Infection chain

Solaris is not directly embedded within the analyzed fake installers. Instead, it is delivered through an intermediate loader that executes prior to the Solaris payload. This loader appears to be based on an open-source project ^[1], as evidenced both by the embedded PDB path ^[2] and by the functionality exposed by the loader itself.

Loaders

SH-Loader-1 | Anatomy

The loader bridges the gap between the fake installer and the malicious payload delivery. Before spawning any payloads, it performs two key preparatory steps:

Firstly, it spoofs its own process image path to explorer.exe by directly manipulating the ProcessParameters fields in the Process Environment Block (PEB) via NtQueryInformationProcess, while also walking the PEB loader module list to patch the corresponding entry there. This enables the process to appear as a legitimate explorer.exe file to tools that obtain process information from user mode rather than from kernel sources

Secondly, it bypasses User Account Control (UAC) silently, without triggering a prompt by abusing the COM Elevation Moniker interface Elevation:Administrator!new:{3E5FC7F9-9A51-4367-9063-A120244FBEC7} (ICMLuaUtil), allowing child processes to be spawned with elevated privileges transparently and without issue.

Early variants launched two elevated components: SvcHostAnalyzer.exe, an EDR-disabling utility discussed in the following section, and WinUpdateHelper.exe, the Solaris implant. Later variants abandoned the additional EDR-disabling stage altogether, simplifying the execution chain and proceeding directly to Solaris execution after privilege elevation. The filenames used throughout the chain are intended to blend in with legitimate Windows components.

Defense Evasion

The defense evasion component, dropped by the loader as SvcHostAnalyzer.exe, bears a strong resemblance to the publicly available WinDefenderKiller project by S12cybersecurity, as evidenced by the embedded PDB path C:\Users\vboxuser\Desktop\BypassUAC-master\WinDefenderKiller-main\CombinedWindowsDefKiller\x64\Release\CombinedWindowsDefKiller.pdb.

The name CombinedWindowsDefKiller is telling, and the codebase is visibly assembled from multiple public scripts stitched together, with the same operations applied redundantly across different functions.

A recurring typo - CurrentControlSet\\Servies'\ instead of Services\\ - appears consistently across multiple registry-manipulation functions. Since the actual driver service registration uses the correct path (otherwise the driver would never load), this typo causes several Defender service-disabling functions to silently fail at runtime - RegOpenKeyExW returns an error and execution continues unimpeded. The kernel-level process termination via the driver IOCTL is doing the real heavy lifting for evasion; the intended registry manipulation are largely rendered ineffective by the actor's coding errors.

Driver Loading (CVE-2026-0828)

Before any malicious payload is dropped, the installer deploys a defense evasion component that abuses CVE-2026-0828, a vulnerability in the Safetica endpoint protection driver (STProcessMonitorDriver).

The vulnerable driver is embedded directly in the dropper binary and extracted to %TEMP%\EmbeddedDriverService.sys at runtime, after which it is registered as a kernel service and loaded via NtLoadDriver following privilege escalation to SeLoadDriverPrivilege. The dropper attempts to unload and clean up any previously installed instance before re-registering the driver, suggesting it was designed to handle repeated execution cleanly.

Windows Defender Dismantling

With kernel-level access established, the dropper proceeds to systematically dismantle Windows Defender through a combination of service key deletion, policy-based registry disabling, and process termination. The service registry trees for all major Defender components are either deleted outright or have their Start value set to 4 (disabled):

• WinDefend

• Sense (Microsoft Defender for Endpoint)

• WdNisSvc

• WdFilter

• WdBoot

• WdNisDrv

• SecurityHealthService

• MdCoreSvc

Tamper Protection is disabled via SOFTWARE\Microsoft\Windows Defender\Features\TamperProtection = 0, and an extensive set of Group Policy registry values under SOFTWARE\Policies\Microsoft\Windows Defender disables real-time monitoring, behavior monitoring, on-access protection, IOAV protection, and cloud-based sample submission. Windows Security Center (wscsvc) is also disabled, eliminating any visible security alerts from the system tray. Running Defender processes are then forcibly terminated via the vulnerable driver's IOCTL 0xB822200C, with the kill loop running for approximately three minutes and targeting:

• MsMpEng.exe

• NisSrv.exe

• MsSense.exe

• SenseIR.exe

• MpCmdRun.exe

• MpSigStub.exe

• SecurityHealthService.exe

• SecurityHealthSystray.exe

Third-Party AV Termination

Beyond Windows Defender, the dropper explicitly targets two additional security products: 360 Total Security and Rising Antivirus (RAV) - both dominant in Chinese-speaking markets and ReasonLabs RAV Endpoint Protection. For 360 Total Security, seven processes are targeted for termination:

• 360sd.exe

• 360rp.exe

• 360tray.exe

• 360safebox.exe

• zhudongfangyu.exe

• 360entclient.exe

• QHActiveCheck.exe

Rising AV is targeted through process termination, and the processes targeted for termination are:

• Ravbg64.exe*

• ravmond.exe

• ravcp.exe

• ravwinsrv.exe

*Ravbg64.exe appears to have been incorrectly grouped with the other Rising AV processes, as it is unlikely to be related and may have been included in error by the author.

ReasonLabs RAV services are disabled via registry manipulation:

• RAVAVService

• RAVNetFilter

• RAVFileFilter

• RSANAV

• RSWINSVC

RAV's Realtime monitoring and updates are additionally disabled via: SOFTWARE\Policies\RAVEndpointProtection.

Avast and AVG processes are also included in the termination list:

• AvastSvc.exe

• AvastUI.exe

• afwServ.exe

• avgsvc.exe

• avgui.exe

• aswIdsAgent.exe

The explicit targeting of 360 Total Security and Rising AV is a strong indicator that the campaign actively targets Chinese-speaking users.

Network Isolation

As a final layer of defense evasion, the dropper appends a hardcoded blocklist of over 55 domains to %WINDIR%\System32\drivers\etc\hosts, redirecting them all to 0.0.0.0.

The blocked domains cover Microsoft Defender for Endpoint telemetry and gateway endpoints (winatp-gw-*), Windows Update infrastructure, certificate revocation endpoints (crl.microsoft.com, pkiops.microsoft.com), and Azure AD authentication. The list also includes a significant number of US Government cloud endpoints (*.usgovcloudapi.net, *.wd.microsoft.us, login.microsoftonline.us) - which in the context of the broader campaign profile, likely reflects the list being sourced from a publicly available EDR bypass resource rather than deliberate government sector targeting.

A deduplication check is performed before writing - if winatp-gw-usmt.microsoft.com is already present in the hosts file, the write is skipped. Additionally, %TEMP%, %APPDATA%, and %LOCALAPPDATA% are added to Windows Defender's exclusion list via SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths, directly covering the directories used by Solaris for its own persistence and execution.

Technical Analysis

Here is the CTI FU's technical overview of Solaris with version 1.8.2

String Obfuscation & WinAPI Resolution

Across the Solaris samples we have encountered, strings are encrypted and decrypted at runtime with XOR using a single byte constant, varying per sample.

Before resolving the Windows API, it performs a straightforward ntdll unhooking technique by loading a clean copy of ntdll.dll directly from disk, mapping it into memory, and overwriting the in-memory .text section of the already-loaded (potentially hooked) ntdll with the pristine bytes from disk.

Solaris then employs the same XOR pattern to resolve Windows API at runtime, decrypting the targeted Windows API strings and finding the address from the relevant loaded Windows DLL.

Anti-Analysis

As mentioned above, Solaris is using a vulnerable Windows Driver to disable Windows Defender and various EDR applications. Beyond this, during its execution, it locates AmsiScanBuffer and EtwEventWrite via direct opcode modification, writing `B857000780C3`^[3] and `C3` respectively.

Persistence

Registry Copy

During execution, Solaris stores a registry-backed copy of itself under HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Advanced. It reads its own executable from disk, verifies the MZ PE header, and XOR-encodes the entire file with a single byte XOR constant before writing it into the ICtrlData registry value as binary data. The original executable path is also stored in the ICtrlPath value.

Scheduled Task

The malware copies itself to %APPDATA%\\Microsoft\\Windows\\Services\\winhost.exe, a path chosen to resemble legitimate Windows components. Before installation, it removes any existing copy, or renames the old file to winhost.exe.old if deletion fails. After copying itself, it deletes the Zone.Identifier alternate data stream. Finally, it timestamps the new file using timestamps from cmd.exe and sets the file attributes to hidden and system, helping it blend in with legitimate Windows files.

Solaris' next step is to check whether the current process is running with elevated administrator privileges under UAC by checking the process token. If the token is elevated, then it creates a scheduled task with the name Windows Security Checks, otherwise it uses the name Windows Update Assistant.

Via the Task Scheduler COM API, Solaris creates a Windows Scheduled Task, deleting any existing task with the same name, creating a new task definition, and configuring it to run under the interactive user token with a normal/non-elevated run level. The task is set to start when available, ignore battery-related restrictions, run without an execution time limit, and use a below-normal priority.

Persistence Monitoring

Solaris also spawns a dedicated persistence monitor thread that periodically verifies the integrity of its registry foothold. Every fixed interval, it checks whether the ICtrlData value under HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced is still present - and if not, re-establishes the registry-backed copy of itself. To avoid interfering with self-update operations, the thread checks a global flag before each iteration; if a self-update is detected, it gracefully exits.

Logon Script Fallback

If scheduled task creation fails regardless of elevation level, Solaris falls back to setting the UserInitMprLogonScript value under HKCU\Environment, pointing it to a command that invokes cmd.exe /c start /b "" "<path>" - launching the malware silently in the background on every user logon, requiring no elevated privileges and leaving no scheduled task artefact.

Process Watchdog

Watchdog Initialization

Solaris has an embedded secondary binary - a dedicated watchdog component - stored RC4-encrypted within its data section and decrypted at runtime using a hardcoded key. This component is responsible for maintaining Solaris's presence within the infected host by injecting into legitimate running processes.

After decrypting the watchdog payload, Solaris enumerates running processes and targets a list of ten commonly present and legitimate ones:

• explorer.exe,
• taskhostw.exe,
• SearchProtocolHost.exe,
• sihost.exe,
• RuntimeBroker.exe,
• ctfmon.exe,
• conhost.exe,
• smartscreen.exe,
• Telegram.exe,
• cmd.exe.

Before injecting into any process candidate, it checks for a named mutex Global\SystemTry_<Process PID> to avoid re-injecting into an already-compromised process.

Injection is performed entirely in memory using a reflective loading technique: the watchdog locates the payload's ReflectiveLoader export, allocates memory in the target process via VirtualAllocEx, writes the payload with WriteProcessMemory, and triggers execution via CreateRemoteThread - leaving no artefacts on disk.

Watchdog Component

Once injected, the watchdog registers its presence by creating a named mutex Global\SystemTry_<PID> tied to the host process, preventing duplicate instances. It then enters an infinite loop, sleeping 10 seconds between iterations, checking for Solaris's own mutex - a Global\<random_hex> string - to determine whether the main implant is still running. If that mutex is absent, the watchdog concludes Solaris has been terminated and initiates recovery: it retrieves the registry-backed copy of Solaris stored in ICtrlData, reverses the XOR encoding, verifies the MZ PE header, drops it under a randomly-named executable in %TEMP%, and spawns it as a hidden process via CreateProcessW - completing the self-healing persistence loop.

Crypto Clipper

Versions 1.5.0 through to 1.6.8 of Solaris deployed a clipboard hijacker as a dedicated thread, targeting cryptocurrency wallet addresses across multiple networks. This functionality was removed starting with version 1.6.9.

Before entering the polling loop, it loads the attacker-controlled replacement wallets by reading the ICtrlCLP registry value under HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced - the same value populated via CMD 5. The value is XOR-decoded using a single-byte key and parsed as a comma-delimited list of wallet addresses.

If the registry value is absent or unreadable, the hijacker falls back to a set of hardcoded wallet addresses embedded in the binary, allowing the clipper to remain functional even without a C2-issued update. This design also enables the operator to rotate wallet addresses remotely via CMD 5 without redeploying the implant.

The hijacker then enters a polling loop, checking at a fixed interval to detect clipboard changes without registering a clipboard listener. When a change is detected, it inspects the clipboard contents against a set of prefix and length heuristics to identify wallet addresses across the following networks:

• Ethereum: prefix 0x, 42 characters

• TRON: prefix T, 34 characters

• Litecoin: prefix ltc1 (43 characters), or L/M (34 characters)

• Bitcoin SegWit: prefix bc1, 42 or 62 characters

• Bitcoin Legacy: prefix 1 or 3, 26--35 characters

If a match is found and the address differs from the attacker's substitution wallet, the clipboard contents are silently replaced via EmptyClipboard and SetClipboardData, redirecting any outgoing cryptocurrency transaction to an attacker-controlled wallet without the victim's knowledge.

Network communication

Solaris embeds multiple botnet C2 addresses directly in its configuration. Early versions carry two hardcoded botnet C2 endpoints, while later samples increase this to three. However, C2 emulation confirms that only one endpoint actively responds to the Solaris protocol - the remaining addresses belong to infrastructure associated with other malware families, including StealC and Amadey, as corroborated by sandbox detonations and internal telemetry. Whether these represent deliberate misdirection or shared infrastructure reuse by the same actor remains unclear. If anyone has visibility into this, we'd welcome any insight to help determine which it is.

After establishing persistence and deploying the watchdog, Solaris spawns three threads: a persistence monitor that is responsible for maintaining the registry-backed copy as described above, and two threads dedicated to C2 communication: a beacon and a task poller. Both of these threads identify the infected host using a Unique Identifier (UID) derived by FNV-hashing the DigitalProductId and InstallDate registry values separately, formatting the result as a %08X%08X hex string, and both target the same endpoint on the remote server.

In both cases, outgoing requests are XOR-encrypted with a single-byte constant, while server responses are XOR-decrypted using the same constant before processing.

As mentioned, the first thread acts as a beacon, periodically registering the host by performing a POST request with the body containing a system fingerprint including the UID, username, computer name, OS version, total RAM, and administrator status at a fixed interval.

The second thread acts as a task poller, querying the C2 at a shorter fixed interval for pending commands by performing a POST request with the body set to the string task:<uid>, and dispatching any non-empty response to the command handler. Upon completing a command, the handler reports the outcome back to the C2 via a POST request with the body taskid=%u&uid=%s&status=%d&reason=%s, where status is a binary success/failure flag and reason carries a command-specific result string - such as Success: <path>, Success: In-Memory (PID: %d), Err_File_Write_Denied, or Err_Execution_Blocked.

Beacon Request

Solaris's beacon request fingerprints the infected host by POSTing the body uid=%s&user=%s&pc=%s&os=%s&ver=%s&ram=%u&adm=%d, populated as follows:

• uid: workstation UID as described above

• user: username retrieved via GetUserNameW

• pc: computer name retrieved via GetComputerNameW

• os: OS version obtained via RtlGetVersion, mapped internally to human-readable strings (e.g. Windows 11, Windows Server 2019)

• ver: implant version, decrypted at runtime

• ram: total physical memory in MB, derived from GlobalMemoryStatusEx

• adm: boolean administrator flag obtained via GetTokenInformation with TokenElevation

Notably, the server's response to the beacon is decrypted but otherwise discarded, suggesting the beacon serves purely as a registration/check-in mechanism with no tasking role.

Task Poller

The task poller POSTs task:<uid> to a url and expects a pipe-delimited response in the format command_id|task_id|data, where the third field is either a URL pointing to a payload to be downloaded or raw data to be processed directly, depending on the command. Where a command involves a payload, it is downloaded from the C2-supplied URL using the same User-Agent as all other requests.

A full breakdown of supported commands and their behavior is provided in the table below for the latest version 1.8.2.

While commands 1, 2, 3, 6, and 7 use the third field as a URL, from which the payload is downloaded, command 4 treats it differently: the field carries the C2 configuration data directly, which is XOR-encoded and written straight to the registry without a download step.

Across versions, the command set evolved considerably as detailed below:

• 1.2.0 implements five commands (1--5). Command 3 performs self-hollowing - spawning a suspended copy of the malware's own process and injecting a downloaded PE into it. The self-update (cmd 2) is rudimentary, lacking the .old rename and registry persistence seen in later versions. The C2 update (cmd 4) XORs with a single byte key and uses a hardcoded Seed value name with no UID fallback.

• 1.5.0 expands to seven commands, introducing the clipboard hijacker (cmd 5), which XOR-encodes wallet substitution data with single byte key and stores it in ICtrlCLP under HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced. Command 3 becomes a stub as it ACKs back to the C2 but performs no action, suggesting the self-hollowing was dropped between 1.2.0 and 1.5.0.

• 1.6.8 retains the seven-command structure. The self-update gains .old renaming and registry-backed persistence.

• 1.6.9 drops the clipboard hijacker entirely, reducing the active command set to five. Whether the clipper functionality was removed or migrated to a standalone module loaded via cmd 6 remains unconfirmed.

• 1.8.1 reintroduces command 3, now implemented as section-mapped hollowing into a suspended notepad.exe instance via NtCreateSection/NtMapViewOfSection - a significant upgrade over the crude self-hollowing of 1.2.0

Versioning & Evolution

Solaris shows clear signs of active development, with at least 10 distinct versions identified in our dataset spanning from 1.2.0 to 1.8.2, alongside two named variants tentatively placed between 1.6.7 and 1.6.8.

Version 1.2.0 establishes the core implant: a five-command protocol delivering execution, self-update, process hollowing, C2 configuration update, and DLL loading capabilities over POST /post.php with a generic Windows 10 User-Agent. By version 1.5.0 the command set had grown to seven, adding a clipboard hijacker component and a more robust payload execution path with MZ header validation.

The intervening versions reflect iterative refinement rather than architectural overhaul as beaconing endpoints shifted from /post.php to /debug.php and eventually /api.php, a second and later third C2 were introduced, and the User-Agent was updated to a full Chrome 120 string. The pace and nature of these changes suggest an actor actively maintaining and operationally deploying the implant rather than episodic development.

IOC

SolarisLoader IOCs (botnet C2 servers):
https://threatfox.abuse.ch/browse/tag/SolarisLoader/

SolarisLoader malware samples:
https://bazaar.abuse.ch/browse/tag/SolarisLoader/

SolarisLoader configs are available:
https://github.com/spamhaus/CTI/tree/main/solarisloader

Interested in shaping the next generation of CTI tooling?

Nik discovered Solaris. He's pretty awesome (he didn't tell us to write that, honestly). He's also, by his own admission, pretty frustrated with the tools available to do this kind of work.

"The tools we have are either too limited to run at the scale we require, or they give us results so noisy it's hard to find what we need - there's very little out there that closes the loop from a YARA match to something you could actually act on.

We have all the data you'd need for it: spam traps, our own research and additional feeds. Most platforms can identify a match, the harder problem is to understand what it means. Being able to move from a YARA hit to a fully contextualised investigation in a single workflow dramatically shortens that journey."

He and Roman Hüssy (founder of abuse.ch) got tired of waiting for someone else to fix this problem. So, together with the Spamhaus CTI FU, they're building it, and you can be part of this journey.

They're looking for YARA rule authors and researchers undertaking investigations who want to help shape what it becomes. Small group, early stage, real influence on the direction. More here →.

References

[1] ↩ https://github.com/S12cybersecurity/WinDefenderKiller

[2] ↩ C:\Users\vboxuser\Desktop\BypassUAC-master\WinDefenderKiller-main\CombinedWindowsDefKiller\x64\Release\CombinedWindowsDefKiller.pdb

[3] ↩ https://github.com/rasta-mouse/AmsiScanBufferBypass/blob/main/AmsiBypass.cs#L30