Your Backup Server Let Them In. They Never Left.

Backup servers exist for the worst day of your life — the day everything else is gone. Attackers know that. And in October, according to research from Huntress, an unknown threat actor broke into backup servers on purpose, using two zero-day flaws in AhsayCBS, and then stayed to mine cryptocurrency, plant backdoors, and steal the credentials those servers hold.

The flaws are CVE-2026-105133 and CVE-2026-105134, a chain that bypasses authentication and runs arbitrary commands on AhsayCBS — backup software that manages backups for organizations. Huntress assesses both were weaponized as zero-days before Ahsay Backup released patches in mid-October 2026. The activity was observed in October, and what started as a smash-and-grab turned into something far more patient.

“However, this incident reflects a much larger intrusion with more patience; the operator planted shells in several places, ran two different miners, staged tunneling tools, and installed a custom implant, all on servers whose job is to hold backups,” Huntress researcher Jonathan Semon said.

Five web shells, two miners, one backdoor

The intrusion left five families of JSP web shells behind — each one a different tool for the same job: staying in, and doing whatever the operator wanted.

One, nsmind.jsp, is a signed API with command execution and file transfer built in. Another, AhsayCBS.jsp, hides encrypted payloads inside the pixel data of PNG images and runs them from memory — disguised as an internal image preview service, down to a comment block describing a watermark endpoint. A third compares a hard-coded key before running commands through cmd.exe. A fourth adds the ability to write Base64-decoded bytes to any path the service account can reach. The fifth family uses random six-letter names, like st_jgaejj.jsp, runs commands, recursively deletes any path it is given, and then deletes itself.

Diagram of the AhsayCBS attack: auth bypass flaws lead to web shells, then miners and a backdoor, then stolen credentials
Two flaws in, five shells planted, and a backdoor that refuses to run anywhere but its target.

Alongside the shells, the attackers ran two XMRig cryptocurrency miners — one masquerading as Microsoft Edge, the other, kvm-agent.exe, restarting every minute through a SYSTEM scheduled task, each using a different wallet and mining pool. The miners were the noise. The Python backdoor, main.py, was the signal: it computes the SHA-256 hash of the host’s MachineGuid, looks for a marker file with the same name, and only then runs an embedded x64 DLL in memory that contacts a command-and-control server. It is designed to run only on the host it was staged on — never in a sandbox, never on an analyst’s machine.

The attack chain also configured Microsoft Defender exclusions, staged tunneling tools (GOST and Chisel), and installed legitimate remote access software — AnyDesk, Atera, and Splashtop — to keep persistent access through tools that look ordinary.

The real prize was the credentials

Backup software is a skeleton key. It holds credentials for hypervisors, repositories, and domain accounts, because it needs them to back everything up. The attackers understood that. On a related Veeam server in the same environment, Huntress saw a PowerShell script — apparently launched remotely through WMI — query the VeeamBackup PostgreSQL database for stored credentials and decrypt them with DPAPI, consistent with NetExec’s Veeam credential-theft module.

“Backup software holds credentials for hypervisors, repositories and domain accounts. We cannot say how many of those credentials were retrieved, but the pairing of an Ahsay foothold with a Veeam credential query suggested the operator was interested in backup infrastructure on purpose, not by accident,” Semon said.

That is the pattern worth remembering. Storage devices are not just targets — four flaws opened a single door into QNAP NAS devices the same way, and a backdoor hidden in a control panel showed how server software can be turned against its owner. Backup infrastructure sits at the center of the network’s trust, and it is often patched last.

What to do now

Diagram of the defense steps: apply October patches, hunt for JSP shells, check Defender exclusions, rotate stored credentials
Four steps — starting with the October patches that close the two flaws.

Four steps for anyone running AhsayCBS — or any backup platform:

  • Apply the October patches. Ahsay fixed both flaws in mid-October. If your AhsayCBS is unpatched, the door this attacker used is still open. Patch first, ask questions later.
  • Hunt for JSP shells. Look for unfamiliar .jsp files in web directories — especially ones with random six-letter names, image-preview disguises, or files that appeared in October. The shells were planted in several places, so a single clean directory is not enough.
  • Check Defender exclusions. The attackers configured exclusions to hide their tools. Review every exclusion on backup servers and remove anything you did not add yourself. An exclusion you cannot explain is evidence, not configuration.
  • Rotate stored credentials. Assume every credential the backup system held is compromised — hypervisor accounts, repository logins, domain accounts, Veeam-stored passwords. Rotate them, and check the Veeam database access logs for queries you did not run.

The attacker chose backup servers because they hold everything and get patched last. The fix is to treat them like what they are: the keys to the whole network, sitting in a box most organizations forget to lock.

Comments

This site uses Akismet to reduce spam. Learn how your comment data is processed.