AhsayCBS: The Backup Server That Mined for the Attacker

I have a house rule that the backup server gets the same hardening review as the production fleet, and this week's Huntress report on AhsayCBS is the cleanest argument I have ever had for it. The machine holding every restore point became, in at least five organisations, a webshell drop zone and a cryptocurrency miner running as SYSTEM.

The facts below come from Huntress's rapid-response write-up and BleepingComputer's reporting of 9 October, with the exploitation window opening on 7 October.

What Huntress actually saw

Two flaws, chained. CVE-2026-105133 is an authentication bypass in the checkSysPwd function; CVE-2026-105134 is an unauthenticated remote code execution flaw in the Replication Receiver component, reachable at the UpdateReceivers endpoint, which hands the attacker NT AUTHORITY/SYSTEM. The actor bypasses auth with the first, configures a malicious replication receiver with the second, and drops a JSP webshell into the directory the CBS application serves. That is the foothold.

What follows is the part I keep re-reading, because it is pure tradecraft aimed at the one thing defenders do casually: glance at the process list. The miner is XMRig renamed edge.exe. The persistence binary msedge.exe is a modified copy of NSSM, the legitimate service wrapper, running under a service named MicrosoftEdgeUpdateSvc. Nothing in Task Manager looks wrong, because everything in Task Manager is a name you trust.

Then the detail that made me sit up: a PowerShell script Huntress assesses as AI-assisted, Taskgmr.ps1, which watches for Task Manager itself. Open Task Manager and the miner service stops. Close it and the miner restarts. It also terminates Task Manager at 6 pm local time, or if the window stays open more than an hour overnight. The malware is not hiding from a scan; it is hiding from a human eyeball, which is the monitoring most backup servers actually get.

In one case the actor also pulled WinRing0x64.sys, a vulnerable kernel driver, via certutil, to give the miner kernel-level hardware access. The pool connection goes out on port 8029.

The fix that was not a fix

Here is the sentence that should change how you read patch notes. The two CVEs were reported as fixed in AhsayCBS 10.3.2. Huntress, after further investigation, determined that 10.3.4, the current latest at time of reporting, is also affected, and no verified patch existed when BleepingComputer published. Five organisations targeted, SYSTEM access, and the remediation advice is restrict the management interface and re-image compromised hosts, because you cannot patch your way out of it yet.

Backup infrastructure sits in a trust category of its own. It holds copies of everything, it is rarely restarted, it is almost never covered by the same detection stack as production, and its management interface tends to be reachable from exactly the networks an MSP works from. I have written before about restores that were never tested in backups you have never restored; this is the mirror image, a backup platform that was never treated as an attack surface until it became one.

Why the backup box is the softest machine you own

Think about what a backup server is, operationally. It is always on, because backups arrive at night. It accepts connections from every machine it protects, because that is the job. Its management interface stays reachable from the networks staff work from, because restores are urgent and humans hate VPNs at 2 am. Its telemetry is thin, because nobody wants an alerting bill on infrastructure that only stores files. For an MSP, one Ahsay box can see dozens of customer estates, so a single foothold is not one compromised machine, it is a directory of tenants.

The miner is the polite outcome. A foothold with SYSTEM on the backup layer is also the perfect place to stage encryption of the restores themselves, which turns the safety net into the hostage list before anyone knows there is a fire. Huntress's guidance to re-image rather than clean is the acknowledgement that a webshelled backup server cannot be trusted to hand back clean copies of anything it touched.

And the economics explain the restraint. Ransomware on a backup server is loud, brings incident responders and law enforcement, and ends the access. A miner is quiet revenue for as long as nobody looks. The AI-assisted Task Manager dodge is exactly the investment you make when your entire business model is not being noticed, and it is why the process list, the one screen every admin glances at, got a dedicated countermeasure while the egress to port 8029 sat there doing the real work.

The part that should change your checklist

If you run AhsayCBS, the immediate moves from Huntress are restrict the management interface to trusted IPs or VPN now, hunt the indicators (edge.exe that is not Edge, msedge.exe, MicrosoftEdgeUpdateSvc, Taskgmr.ps1, WinRing0x64.sys, egress to port 8029), and re-image anything confirmed, because a webshelled backup server can quietly poison the thing you would restore from.

More generally, the masquerade works because process names are treated as evidence. They are not. The service name is input from whoever installed it, which is the same lesson as the reboot loop that was an attack, where the visible symptom was a plausible story and the truth was in the provenance.

Egress filtering belongs on the backup VLAN as well. A backup server has no business speaking to mining pools, and port 8029 to an unknown host is the one alert in this whole story that would have fired in the first hour, long before anyone opened Task Manager.

What I now do

Backup servers join the production tier for patch review, detection coverage and egress filtering, and the management interface gets the same question as any admin panel: who can reach this, and what proves they are them. A restore point is only as clean as the machine it sits on, and this month that machine mined for somebody else.