Weaxor ransomware turns SQL Server into its launchpad

A ransomware crew is using the database server itself as the launch point for its attacks, running nearly every stage in memory so that little of it ever lands on disk. Researcher Praveen Babu of K7 Labs reconstructed the intrusion chain in a detailed technical breakdown, piecing it together from process telemetry after the attackers cleared the Windows and SQL Server logs that would have shown how they first got in.

Who is behind it

Weaxor is the current name of the operation that began in mid-2021 as TargetCompany and became better known as Mallox. K7 says the group renamed its payload in late 2024 to shake off detection profiles built around the old name, but kept the same target list: enterprise database servers, above all Microsoft SQL Server. Those machines are attractive precisely because they are often exposed to the internet with weak administrator passwords, and because encrypting them hits the victim's most valuable records straight away. Internet-facing SQL servers are a standing target for other crews too, as in the campaign that turned hacked SQL servers into mining rigs and VPN relays.

How the attack works

The first red flag in the telemetry was the database service, sqlservr.exe, spawning a Windows command shell, something a database engine has almost no legitimate reason to do. The attacker had switched on xp_cmdshell and OLE Automation Procedures, two SQL Server features that let database queries execute operating system commands, and inherited the high privileges of the SQL service account.

From there the chain went memory-resident. A single dense line of PowerShell carried its payload as raw byte arrays scrambled with XOR, which keeps recognisable text out of reach of signature-based scanning, and rebuilt itself at runtime. The decoded script then disabled the Antimalware Scan Interface, the Windows component that lets security products inspect scripts before they run, by flipping an internal flag through .NET reflection. With script scanning out of the way it downloaded a small stager, update.exe, into the user's temp directory.

That stager loaded a Cobalt Strike Beacon straight into memory. K7 notes the Beacon resolved Windows functions by walking process structures and hashing API names rather than importing them normally, which defeats security tools that inspect a binary's import table, and used the Windows WinINet library so its traffic looked like ordinary browser requests and automatically inherited the host's proxy settings. Its requests carried a deliberately dated user agent string advertising Windows XP and Chrome 46. The final payload was streamed from 154[.]201[.]236[.]197 into a block of memory marked writable and executable at the same time.

The last step is the neatest. Rather than run the encryptor from the loader, the code injects into SQLPS.exe, a legitimate signed Microsoft SQL administration tool, so the ransomware detonates under a trusted process name. The encryptor implements the ChaCha20 stream cipher itself instead of calling Windows crypto APIs, processes files in 64-byte blocks, renames each one with a .weax extension, and then clears the Windows event logs.

What you should do

K7's own advice is the right starting point: keep xp_cmdshell and OLE Automation Procedures disabled, run SQL Server under a least-privilege account, and do not expose database ports to the internet. Turn on PowerShell script block logging (event ID 4104), which is what exposed the obfuscated loader here, and alert on any database process spawning cmd.exe or powershell.exe. Because the logs get wiped at the end, forward them off the host. Indicators from the report include the payload hash B76DD9D7A576D3653B52D9C4DF177A78 and the staging addresses 182[.]167[.]106[.]182, 193[.]124[.]114[.]18 and 154[.]201[.]236[.]197. Memory-only Cobalt Strike delivery is a recurring pattern worth hunting for in its own right, as in the SharkLoader campaign against diplomats and governments.

This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.

Detection coverage

Read the full analysis on IntelFusions