ZeroQlik Returns: Exploiting N-Days Still Pays Off

The Cactus Comparison

The investigation began with the same suspicious process sequence on Qlik Sense servers across multiple customer environments. At first glance, this attack appeared very similar in nature to the Cactus Ransomware attack in 2023 where the threat actor abused a RCE vulnerability on Qlik Sense. The original Qlik exploit chain combined CVE-2023-41266, a path traversal that bypassed access checks, with CVE-2023-41265, an HTTP request-tunneling flaw. CVE-2023-48365, also called DoubleQlik, bypassed the original fix and again enabled unauthenticated execution through external program tasks [4]. Exploiting this weakness allows the threat actor to run commands under the scheduler.exe process in a Qlik Sense server, just like the process tree we observed in the current attack:

[Figure 1] Qlik Process Tree

PowerShell Access

Decoding the first PowerShell layer revealed two operations. A WebClient request supplied the computer name and username to an HTTP endpoint. A separate hidden PowerShell process then started the reverse shell. The registration request was wrapped in an empty catch block, allowing execution to continue if it failed. However, Cynet blocked the script from executing, preventing the reverse shell process from being launched.

The registration call used DownloadString, but the supplied launcher did not execute the returned text. Its purpose was to contact the endpoint with host identifiers. The nested payload creates a Net.Sockets.TCPClient, reads incoming commands on the socket, and passes them to Invoke-Expression for execution. It sends command output and a PowerShell-style working-directory prompt back through the TCP socket.

The initial reverse shell closely matches Nishang’s Invoke-PowerShellTcpOneLine.ps1 [5]. The observed variant shortens variable and type names, changes the destination, and omits the explicit stream Flush and client Close calls present in Nishang’s one-liner, perhaps to evade signatures designed to detect this well-known reverse shell command.

[Figure 2] Infection Chain

The Staging Server

The same IP hosted an HTTP directory on port 8012. File reports and recovered directory contents exposed Windows agents, several Linux architectures, scripts for persistence, an OpenSSH archive, three ActiveMQ XML payloads, and Veeam exploit-development artifacts. When we tested the reverse shell to observe what commands were executed, we received a command resembling the persist.ps1 script.

[Figure 3] Staging Directory

The Go Agent

Static analysis identified wsvc.exe and wsvc_old.exe as two compiler builds of the same Windows Go reverse shell. The newer sample was compiled with Go 1.22.2; the older used Go 1.20.14. Both retained the source path /tmp/opencode/agent/agent.go.

The Windows agent connects to 45[.]115[.]26[.]23:4456 with a 20-second dial timeout, in contrast to our PowerShell reverse shell which connected to port 4455. It announces the hostname and platform, then reads commands supplied by the controller. Each line is executed through C:\Windows\System32\cmd.exe /c. The command exit terminates the session, errors use an ERR prefix, and responses end with a DONE delimiter. Following a disconnect, the agent waits approximately 30 seconds before attempting another connection.

The file wsvc_win_v2.exe was UPX-packed version of wsvc.exe. Upon decompressing the binary, the code matched that of wsvc.exe.

[Figure 4] Go Reverse Shell Command Loop

Persistence

After the threat actor sent the discovery commands, they ran a base64 encoded version of persist.ps1. The script added an Ed25519 public key to C:\ProgramData\ssh\administrators_authorized_keys. It removed inherited permissions and granted full control to Administrators and SYSTEM.

The script attempted to install OpenSSH through Windows capabilities. If sshd remained unavailable, it downloaded OpenSSH-Win64.zip from the staging server, extracted it, and ran install-sshd.ps1. It set sshd to automatic startup, started the service, and added an inbound firewall rule for TCP 22. The archive was a legitimate OpenSSH package reused by the operator.

For a second access mechanism, the script wrote the PowerShell reverse shell to C:\ProgramData\ssh\winc.ps1 and created the WinUpdCheck scheduled task at five-minute intervals. It first requested SYSTEM execution and included a fallback task-creation attempt.

The script’s PERSIST_OK_BEACON status was emitted after a successful task query. That string alone does not verify a completed callback. Separately, VirusTotal behavior for persist.ps1 samples showed agent downloads to C:\Windows\Temp\wsvc.exe and attempts to create an automatically starting wsvc service with the display name Windows Service Controller. These are related persistence paths, not proof that every mechanism succeeded on customer systems.

[Figure 5] Variant of persist.ps1 received from the PowerShell reverse shell

The Exploit Toolkit

While the attack we observed began with a Qlik Sense exploit, we did not find any tools related to the exploit on the open directory or in any of our threat hunts. Instead, we discovered artifacts related to the exploitation of ActiveMQ and Veeam.

The open directory hosted poc_amq.xml, poc_amq2.xml, and poc_amq3.xml, identified during the investigation as ActiveMQ exploit material. The associated vulnerability, CVE-2023-46604, permits remote code execution through unsafe class instantiation in Java OpenWire processing [2]. The lab controller’s explicit ActiveMQ process, directory, and port checks fit that targeting interest. We did not observe any customers that were successfully exploited through ActiveMQ.

[Figure 6] ActiveMQ beans configuration for CVE-2023-46604

The recovered ysosrc.tgz archive contained a modified copy of watchTowr’s public CVE-2024-40711 toolchain [3], built on ysoserial.net, the open-source .NET deserialization payload generator [6]. The source included a Veeam-specific generator and used the ObjRef generator to construct the nested callback object. VeeamGenerator.cs retained the CVE banner and upstream credits; Program.cs exposed a target-Veeam argument. The generator targeted the Mount Service remoting endpoint at tcp://<target>:6170/PermanentSessionService.

The threat actor’s changes included a logger writing to C:\veebam_lab\exp40711\Exp\tool.log, exception logging, a 30-second delay, and additional console output. These changes are consistent with local testing and troubleshooting.

Static parsing of payload.raw revealed an outer Veeam.Backup.Model.CDbCryptoKeyInfo object. Its RepairRecs array contained a second serialized stream using a System.Exception record with the ClassName System.Runtime.Remoting.ObjRef. The embedded callback was hxxp://127[.]0[.]0[.]1:8005/trigger. Because that address is loopback, this artifact reflects a local test configuration, as opposed to a tool actively used in a campaign.

The file deser.cs was the local harness that loaded Veeam.Backup.Model.dll and deserialized payload.raw. It was not the remote sender, providing an additional indication that this staging server contains that were not ready for campaign use. The generator source referenced CODE WHITE’s RogueRemotingServer for serving the wrapped SOAP payload [7] and James Forshaw’s ExploitRemotingService for sending the remoting trigger [8]. Those executables and exploit.soapformatter were absent from the recovered directory. The missing SOAP second stage prevents reconstruction of the final command from these files.

[Figure 7] watchTowr Exploit