Hackers Attack Qlik Sense Servers: Reverse Shells and Preparing Exploits for ActiveMQ and Veeam

In October 2026, Cynet researchers (the CyOps and Research teams) recorded a series of attacks on Qlik Sense Enterprise for Windows servers at several European companies. All incidents fit into a very narrow window — just over three minutes. The most interesting part isn't the intrusion attempt itself but what the attackers were preparing next: on the same infrastructure server, researchers found exploits for Apache ActiveMQ and Veeam Backup & Replication. This means the Qlik Sense attack is only the first stage of a broader campaign still unfolding.

The attacks so far were unsuccessful: Cynet's defenses blocked the reverse-shell launch. But the very fact that attackers keep a ready arsenal for several known vulnerabilities on a staging server should put any organization using BI platforms, message queues, and backup systems on alert.

This story is another confirmation of an alarming trend specialists call "n-day exploitation": attackers increasingly skip new 0-days and methodically use vulnerabilities for which patches shipped months or years ago but were never installed. The payoff is obvious — a ready, proven exploit costs far less than developing a new one.

What the attack looks like: a reverse shell under scheduler.exe

The key sign of the attack is a suspicious parent-to-child process chain on Qlik Sense servers. The scheduler.exe process (Qlik Sense's scheduler service) spawned cmd.exe, which in turn launched hidden PowerShell with a reverse-connection command:

scheduler.exe → cmd.exe /c → powershell -nop -w hidden -enc <base64>

The shell itself is a well-known public one-liner, Invoke-PowerShellTcpOneLine from the Nishang set. It established a TCP connection to the command-and-control server 45.115.26.23 on port 4455. Such a pattern — "a legitimate service launches an interactive shell" — is almost never normal behavior, which is exactly why it fired as the main detection signal.

After decoding the first PowerShell layer, Cynet saw two stages. First the script sent machine identifiers — computer name and username — to an HTTP endpoint via WebClient (the victim "registration"). Then a separate hidden PowerShell process launched the reverse shell itself. The registration request was wrapped in an empty error-handling block so execution would continue even on failure.

The control server's commands are separated by F1, F2, F3 markers — how the attackers simplify reading output. On Windows they ran classic reconnaissance: whoami & hostname & ver, searching "OS Name" in systeminfo, searching for java activemq wrapper processes, then netstat filtered for ports 61616, 8161, 22, and 3389. In the Linux shell variant (analyzed in the CAPE sandbox), the attackers collected user IDs, kernel version, uptime, PID 1 info, searched for ActiveMQ processes and install paths, listed listening ports, read /etc/shadow and /etc/passwd, gathered OpenWrt-device and ARP-table data, plus disk and memory info.

Besides the PowerShell shell, the arsenal included a Go backdoor for Windows connecting to the same server on port 4456. Per Joe Sandbox, its reconnaissance commands nearly match the PowerShell version, with one notable difference — the Go backdoor searched more actively for ActiveMQ: among running processes and ports 61616 and 8161.

An echo of the 2023 Cactus campaign

The attack pattern strongly resembles the Cactus ransomware campaign documented by Arctic Wolf in November 2023. Then attackers likewise abused the Qlik Sense scheduler service to run arbitrary processes.

Known Qlik Sense vulnerabilities in this context:

• CVE-2023-41265 — a restriction bypass via HTTP request tunneling;
• CVE-2023-41266 — path traversal allowing access-check bypasses;
• CVE-2023-48365 (DoubleQlik) — a bypass of the incomplete fix for CVE-2023-41265 that reopened unauthorized code execution via external program tasks.

In the Cactus campaign, exploiting these flaws enabled command execution under the scheduler.exe process — exactly matching the process tree Cynet observed in 2026. However, researchers emphasize: which specific vulnerability was used for initial access this time is unknown, and no Qlik exploitation tools were found on the staging server.

Who's behind the attack

There's currently no official attribution, and Cynet stresses the link to the 2023 Cactus campaign is only partial. Shared is the use of the Qlik Sense scheduler service to launch shells, but who specifically operates in 2026 is unknown. Researchers didn't publish file hashes for the new campaign, and attempts to match the C2 address against other campaigns came up empty.

The main initial-access question also remains open: which exact Qlik Sense vulnerability was used. Researchers hypothesize a combination of CVE-2023-41266 and CVE-2023-41265, or the later CVE-2023-48365 (DoubleQlik), but this can't be confirmed yet. The absence of Qlik exploitation tools on the staging server only deepens the uncertainty.

The staging server: an arsenal for the next attacks

The infrastructure server 45.115.26.23 proved a treasure trove for researchers. Port 8012 exposed an HTTP directory whose contents tie the Qlik attack to a far broader set of access tools:

• A Go backdoor for Windows (wsvc.exe) and builds for several Linux architectures and embedded systems;
• Persistence scripts (persist.ps1) that add a public Ed25519 key to C:\ProgramData\ssh\administrators_authorized_keys, strip inherited permissions, and grant full control to administrators and SYSTEM;
• OpenSSH installation: if the sshd service is unavailable, the script downloads the legitimate OpenSSH-Win64.zip archive from the staging server, unpacks it, runs the installer, configures autostart, and adds a firewall rule for TCP 22;
• A scheduled task WinUpdCheck that every five minutes launches a reverse shell from C:\ProgramData\ssh\winc.ps1.

In the lab, Cynet ran the reverse shell to see what commands the control server sends. These were classic reconnaissance: whoami, hostname, systeminfo, listing java/activemq/wrapper processes, and netstat looking for open ports 61616, 8161, 22, and 3389. On Linux systems, attackers gathered kernel and system data, searched for ActiveMQ processes, listed /opt, /usr/local, /www/wwwroot, tried reading /etc/shadow and /etc/passwd, and checked for SmarterMail directories.

ActiveMQ (CVE-2023-46604): the next target

Attackers showed separate interest in Apache ActiveMQ. The open directory held three XML payloads (poc_amq.xml, poc_amq2.xml, poc_amq3.xml) that Cynet identified as exploit material for CVE-2023-46604.

This vulnerability enables remote code execution through unsafe class instantiation during OpenWire protocol processing in Java. In October–November 2023 it was mass-exploited, including for ransomware deployment. Fixes appeared in ActiveMQ 5.15.16, 5.16.7, 5.17.6, and 5.18.3.

Notably, the reconnaissance commands on Windows machines explicitly searched for running ActiveMQ processes and ports 61616 and 8161 — typical broker ports. At the same time, Cynet notes no successful ActiveMQ exploitation was observed at clients, and the tools appear still in a testing stage.

Veeam (CVE-2024-40711): a strike at backups

Perhaps the most alarming find is the ysosrc.tgz archive containing a modified copy of watchTowr's public toolkit for CVE-2024-40711, built on ysoserial.net (a .NET deserialization-payload generator).

CVE-2024-40711 is an unauthorized remote code execution vulnerability in Veeam Backup & Replication affecting versions 12.1.2.172 and earlier, fixed in build 12.2.0.334. It has two components: an improper authorization flaw and a deserialization issue. The generator in the found source (VeeamGenerator.cs) targets the Mount Service remoting endpoint at tcp://:6170/PermanentSessionService.

A key nuance: the payload's built-in callback pointed at 127.0.0.1:8005/trigger — a local address. This suggests the artifact reflects local testing rather than a tool already used in a live campaign. Researchers conclude the ActiveMQ and Veeam exploits aren't yet ready for use — attackers are likely only preparing the ground for broader attacks.

Why this matters specifically for Veeam: backups are the last line of defense against ransomware. Successfully compromising the backup system lets an attacker destroy or encrypt backups, effectively denying the victim any recovery path without paying a ransom. That's why attackers hunt Veeam infrastructure so actively.

How to protect yourself: practical steps

Even though the active phase against Veeam and ActiveMQ isn't confirmed, the preparation deserves attention. Cynet recommends:

1. Patch Qlik Sense Enterprise for Windows to a version closing CVE-2023-41265, CVE-2023-41266, and CVE-2023-48365, and don't expose Qlik Sense servers to the open internet without need.
2. Update Apache ActiveMQ to 5.18.3 or newer (or 5.15.16 / 5.16.7 / 5.17.6 for older branches) to close CVE-2023-46604.
3. Update Veeam Backup & Replication to build 12.2.0.334 or newer to address CVE-2024-40711.
4. Block the compromise indicator — IP 45.115.26.23 (notably ports 4455, 4456, and 8012) on the firewall and in monitoring.
5. Configure behavioral detection: watch for cases where scheduler.exe (or other legitimate services) spawns cmd.exe or powershell — the anomaly that fired here.
6. Check whether a server is compromised: if attack signs are found, remove the added SSH key, the WinUpdCheck scheduled task, and the wsvc service, then change all credentials stored on that machine.
7. Isolate backup infrastructure: the Veeam server shouldn't be freely reachable from primary systems; use separate accounts and follow the 3-2-1 rule (three copies, two different media, one offline). Immutable storage complicates backup encryption even after network compromise.

Additionally, check whether company credentials appeared in public leak databases — for example, via our data-breach check service.

Conclusion

The Qlik Sense story is a reminder that "old" vulnerabilities don't die: attackers actively use 2023–2024 n-day exploits because many organizations still haven't closed them. The main lesson — don't postpone updates. The attack scheme shows the classic sequence: initial access through a known BI-platform flaw, reconnaissance, persistence via SSH and a scheduled task, then movement toward more valuable targets like a message broker and the backup system.

So far the attacks were blocked, and the ActiveMQ and Veeam tools look unfinished. But it's only a matter of time: the arsenal is already on the staging server, and testing, judging by the artifacts, continues. For Ukrainian companies that actively use Veeam for backup, this is a signal to check software versions and close known vulnerabilities before they're used against you.