Recent threat intelligence highlights a sophisticated Weaxor Ransomware deployment strategy utilizing high-privilege application abuse and layered in-memory evasion. While post-exploitation actions deliberately cleared critical operating system and application log telemetry to obscure the initial access vector, deep forensic reconstruction of telemetry data and process monitoring logs reveals a heavily obfuscated execution chain.

The adversary relied extensively on Microsoft SQL Server exploitation, multi-layered PowerShell Deobfuscation, Cobalt Strike Beacon execution. This analysis provides an exhaustive technical breakdown of the evasion mechanics and structural execution steps discovered within the payload chain.

Threat Background: The Evolution from Mallox to Weaxor

First appearing in mid-2021 under labels like “TargetCompany”, the threat group behind Weaxor originally operating as the notorious Mallox ransomware family has matured from a rudimentary threat into a sophisticated ransomware-as-a-service (RaaS) operation.

By late 2024, the group underwent a tactical rebranding, shifting their payload name from Mallox to Weaxor to evade security detection profiles and confuse defenders. Despite the new branding, Weaxor maintains Mallox’s highly specific, core target demographic: enterprise database servers, with an overwhelming focus on vulnerable Microsoft SQL (MS-SQL) Server deployments. However, the modern Weaxor variant builds upon its predecessor’s foundation by introducing advanced, multi-layered payload loaders and sharper evasion techniques

The Shift to Database Targets

Database servers represent the soft underbelly of corporate infrastructure. They are frequently misconfigured with weak administrative passwords, exposed directly to the public internet to facilitate remote access. For ransomware groups, compromising an SQL database provides immediate control over the victim’s most critical data assets, accounting records, user directories, and proprietary data maximizing extortion leverage right out of the gate.

Historically, Weaxor campaigns relied on brute-forcing administrative accounts (sa) or exploiting old unpatched remote code execution vulnerabilities to gain a foothold. Once inside, they typically executed primitive batch scripts and downloaded standard binaries directly to disk. The intrusion chain analyzed below marks a significant leap in sophistication, moving away from loud, disk-heavy deployment methods toward memory-resident execution pipelines and native administrative tool abuse.

Phase 1: High-Privilege Database Abuse & Process Lineage

One of the most notable indicators recovered from our telemetry during the forensic analysis was the parent-child process relationship originating from the database engine.

Under normal operating conditions, a database daemon rarely, if ever, spawns a Windows command interpreter. In enterprise environments, this specific parent-child lineage is an immediate red flag. During our investigation, we confirmed that the attacker enabled xp_cmdshell and OLE Automation Procedures, allowing SQL Server to execute operating system commands. Although other SQL Server abuse techniques—such as SQL Agent Jobs, CLR assemblies, or SQL Injection—can also lead to OS command execution.          

In this case, the adversary leveraged the high privileges already granted to the sqlservr.exe service account to drop into a system command context.

Phase 2: PowerShell Loader & Deobfuscation Mechanics

The initial payload launched from the hijacked database process was a densely obfuscated, single-line command block captured in PowerShell Script Block Logging (Event ID 4104):

A) Deconstructing the Obfuscated Download Cradle

The deconstructed components and their purposes of the powershell script are summarized below:

1. The Core Custom Decryption Routine (AJW): The function defines a basic bitwise XOR (-bxor) decryption engine. It accepts a byte array (${YZ}) and a static key variable (${WL}).
2. Byte Arrays (${YZ}): The raw payload strings are passed entirely as dense byte arrays ([System.Byte[]]@(0x4A, 0x46, …)), preventing basic endpoint security mechanisms or EDR solutions from triggering on plain-text signature detection strings.
3. The Staging Vector: When evaluated dynamically in-memory, the loop processes the ciphertext bytes against the XOR key, feeding the resulting string back into the PowerShell engine via Invoke-Expression (IEX).

B) Reversing the Antimalware Scan Interface (AMSI) Bypass & Secondary Stager Delivery

To hinder static analysis, the PowerShell loader dynamically constructs .NET class and method names at runtime using PowerShell’s -f string formatting operator. The function performs two operations on the targeted byte array:

1. Array Reversal: It flips the structure of the data array backward ($v.Count – $X – 1).
2. Caesar Cipher Shift: It adds a static scalar offset of 3 to each individual byte value.

To read the absolute payload, we mirror the script’s core architecture by creating a decoder script that runs the mathematical inverse: subtracting 3 from each byte value and reversing the array across three sequential iterations.

The three arrays stored within variables ${c}, ${d}, and ${e} uncovers the plaintext strings driving the next execution phases.

• Variable ${d} Decodes To: AmsiContext
• Variable ${e} Decodes To: amsiInitFailed
• Variable ${c} Decodes To the Stage 2 Download Cradle

The first structural command executed by the decrypted loader script targets the built-in Windows Antimalware Scan Interface (AMSI):

The script uses SetValue($null, $true) to modify an internal AMSI flag, causing PowerShell to treat AMSI as unavailable and skip script scanning for the remainder of the session. It then creates a System.Net.WebClient object to download a second-stage payload (update.exe). 

Phase 3: Cobalt Strike Beacon Execution

The loader drops an intermediate component (update.exe) into the user’s temporary directory ($env:temp) and executes it. This binary functions as a lightweight stager whose primary purpose is to inject and execute a Cobalt Strike Beacon directly in memory while minimizing forensic artifacts on disk. 

The Beacon executes this dynamic tracking routine using the following assembly sequence:

The Threat Actor’s Purpose for Custom PEB Traversal

Standard applications interact with operating system features by referencing the Import Address Table (IAT), which links external functions located in system libraries like Kernal32.dll. However, security products constantly inspect the IAT of running binaries for suspicious combinations of functions (such as VirtualAlloc paired with networking routines).

It utilizes custom Process Environment Block (PEB) Traversal to dynamically discover and map out Windows functions on the fly while operating inside system memory

The ROR13 API Hashing Loop

To resolve specific Windows APIs without embedding readable strings such as LoadLibraryA or VirtualAlloc, the Beacon implements the well-known ROR13 API hashing algorithm commonly associated with Cobalt Strike and other offensive frameworks. 

The Beacon compares the resulting hash value against its internal list of pre-calculated target hashes (e.g., 0x072C8407 for LoadLibraryA). Once it locates a match, it extracts the exact memory offset for that function, allowing it to safely execute the routine.

Network Stack Abuse via WinINet

Once the Beacon maps out basic system functions, it forces the host process to load the specialized Windows Internet library by pushing the string value 0x0074656E696E6977 (“wininet\0”) onto the active stack:

The loader intentionally selects WinINet over lower-level socket APIs (like Winsock/ws2_32.dll) for two strategic reasons:

1. Traffic Blending: WinINet automatically constructs full HTTP/HTTPS request structures, ensuring the resulting traffic mirrors standard browser activity and blends into normal network noise.
2. Proxy Inheritance: WinINet natively reads and inherits proxy configurations, authentication details, and firewalls already established on the enterprise host. This allows the payload to pass through network security boundaries that typically block raw TCP sockets.

The network request incorporates an explicitly chosen, older User-Agent signature:

User-Agent: Mozilla/5.0 (Windows NT 5.1; WOW64) AppleWebKit/537.36 … Chrome/46.0.2490.80

This specific configuration strings together references to legacy architectures (Windows XP / Chrome 46). By mimicking a legacy client browser, the network traffic is designed to blend into automated background noise.

Phase 4: Memory-Resident Staging & Evasion

Once the network connection is established via WinINet, the Beacon moves into the final deployment phase, pulling the payload down from the remote staging node at 154.201.236.197.

By requesting PAGE_EXECUTE_READWRITE (RWX) permissions, the loader builds a flexible environment where it can simultaneously write incoming binary data stream chunks and execute them on the fly.

The stager enters a continuous loop utilizing InternetReadFile, streaming the raw binary payload directly into the newly allocated memory space. Once the transfer wraps up, the stager uses a direct JMP or CALL assembly instruction to transfer control straight to the start of the memory buffer.

Phase 5: Ransomware Execution Mechanics & Masquerading

The final memory stage initiates an injection mechanism to transition processing control out of the ephemeral loader space and into an active target runtime environment.

Step 1: Binary Masquerading via SQLPS

The in-memory stager utilizes process remote thread creation to target the system command interpreter utility:

C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\SQLPS.exe

By passing execution control into a legitimate, digitally signed Microsoft SQL administration component (SQLPS.exe), the malware successfully masks anomalous processing behaviours behind trusted administrative actions.

Step 2: Payload Detonation

SQLPS.exe subsequently executes the primary ransomware binary payload disguised inside the system space:

C:\Windows\System32\<RandomString>.exe 

Reversing the Ransomware Encryption Engine 

After initialization, the ransomware begins encrypting victim files entirely in memory using the ChaCha20 stream cipher. Analysis via x64dbg combined with IDA and Ghidra revealed that the payload implements a ChaCha20 stream cipher engine rather than directly invoking Windows encryption APIs for file encryption.

File Processing

Files are opened with CreateFile(), read via ReadFile(), and processed in fixed-size blocks  each transformed in memory and written back via WriteFile(). Successfully encrypted files are renamed with a .weax extension via MoveFile(). Breakpoints on ReadFile() confirmed the plaintext buffer feeds directly into the encryption routine.

ReadFile() → Generate Keystream → XOR Plaintext with Keystream → WriteFile() → MoveFile(“.weax”)

Encryption Controller

The primary encryption routine (sub_14002FE18) controls the complete encryption workflow. It accepts the encryption context, source buffer, destination buffer, and buffer length as input. The function processes files in 64-byte blocks, generating a new ChaCha20  keystream whenever the previous block has been exhausted. For files whose size is not a multiple of 64 bytes, the remaining bytes are encrypted using a final partial keystream block.

ChaCha20 Keystream Generation 

The routine (sub_14002FB10) initializes a 512-bit ChaCha20 state comprising the standard ChaCha20 constants (“expand 32-byte k”). The function then executes the ChaCha20 quarter-round operations for 20 rounds, repeatedly performing modular additions, XOR operations, and fixed-distance left rotations (16, 12, 8, and 7 bits) on the internal state.

After completing all rounds, the transformed working state is added back to the original state to produce a 64-byte keystream block, which is subsequently passed to the buffer transformation routine for encrypting the plaintext.

.

Buffer Encryption

The generated keystream is passed to (sub_14002F930), which performs the actual buffer transformation Ciphertext = Plaintext XOR ChaCha20 Keystream, confirmed via memory breakpoint on the plaintext buffer.The function processes aligned buffers in 8-byte chunks (mov/xor/mov on 64-bit registers).

For unaligned buffers or trailing bytes, the routine automatically switches to byte-wise processing until the entire buffer has been encrypted.

Finalization 

Ciphertext is flushed to disk, the file is renamed with .weax extension via MoveFile().The same workflow is repeated for every targeted file during directory traversal. 

. 

In addition to encryption, Ransomware leverages wevtapi.dll to invoke Windows Event Log APIs and clear event logs, removing valuable forensic evidence and making post-incident investigation significantly more difficult.

CONCLUSION

This investigation demonstrates how modern ransomware operations increasingly rely on trusted administrative components and memory-resident execution rather than simple drop-and-run techniques. By abusing Microsoft SQL Server as the execution context, employing heavily obfuscated PowerShell loaders, dynamically resolving Windows APIs through the Cobalt Strike Beacon, and staging payloads in memory before ultimately launching the ransomware from disk, the attackers significantly reduced their forensic footprint. Although the deliberate clearing of Windows and SQL Server logs prevented definitive attribution of the initial access vector, correlating process lineage, PowerShell telemetry, reverse engineering, and endpoint artifacts enabled a near-complete reconstruction of the intrusion. This case highlights the importance of comprehensive logging, PowerShell auditing, SQL Server hardening, and behavioural detection to identify and disrupt sophisticated ransomware activity before encryption occurs. Organizations can further strengthen their defenses by deploying K7 Security products. K7’s behavioural protection, anti-ransomware protection, memory attack detection, script and PowerShell monitoring, and continuous endpoint telemetry can help detect and block malicious activities including fileless execution, suspicious PowerShell abuse and in-memory payload staging before ransomware is able to execute and encrypt critical assets. We have also outlined the recommended mitigation steps in our previous blog. We encourage organizations to refer to these recommendations to strengthen their defenses and protect against similar threats. 

MITRE ATTACK Mapping

The observed tactics, techniques, and procedures (TTPs) deployed throughout this intrusion chain map to the following MITRE ATT&CK matrices:

Structural Stage	MITRE Technique Identifier	Technical Classification	Contextual Application within Chain
Initial Execution	T1059.003	Windows Command Shell	sqlservr.exe spawns a high-privilege cmd.exe instance.
Script Evasion	T1059.001	PowerShell Core	Executes inline code strings via the SQLPS cmdlet framework.
Antivirus Subversion	T1562.001	Impair Defenses: Disable Tools	Modifies amsiInitFailed via .NET reflection to disable scanning.
Obfuscation Evasion	T1027	Obfuscated Files or Information	Uses character tokenization and a 3-pass custom mathematical loop.
Discovery Evasion	T1027 / T1620	Dynamic API Resolution / Reflective Injection	Bypasses IAT scanning by utilizing a custom ROR13 PEB lookup.
Memory Evasion	T1620	Reflective Code Loading	Allocates RWX memory blocks to stream payloads via WinINet.
Masquerading	T1036.005	Masquerading: Match Legitimate Name	Spawns the trusted SQLPS.exe utility to host injected code.
Data Impact	T1486	Data Encrypted for Impact	Encrypts production volumes and network shares with a .weax extension.

IOCs

Hash (Win64.Weaxor)	B76DD9D7A576D3653B52D9C4DF177A78
IP(Stage1)	182.167.106.182
IP(Stage2)	193.124.114.18
IP(Stage3)	154.201.236.197