The server you expect to restore the business can become the machine an attacker controls. In the AhsayCBS case, the first visible payout was cryptocurrency mining. The more consequential question is whether the organization can still trust the system coordinating its backups.

Huntress observed exploitation beginning October 7, 2026, and reported five targeted organizations as of October 8. Attackers chained CVE-2026-105133, an authentication bypass, with CVE-2026-105134, a command-injection flaw, to obtain remote execution on exposed AhsayCBS hosts. Its Windows observations included SYSTEM-level execution and JSP webshells. Huntress research

A JavaServer Pages webshell is server-side code that gives an attacker a continuing way to issue commands through the application’s web service. Removing a miner while leaving that access in place would address the symptom and preserve the intrusion.

The Version That Changed the Response

Huntress found that version 10.3.4 remained vulnerable despite earlier reporting suggesting otherwise. Its October 12 update says it independently verified that hotfix 10.3.4.45 mitigates the initial entry point. That finding matters more than a release label that merely looks newer. Huntress update

Ahsay’s October 13 status report gives the current vendor path:

DeploymentVendor-directed correction
AhsayCBS v10Apply hotfix 10.3.4.45.
AhsayCBS v9Apply hotfix 9.15.2.70.
AhsayCBS v7 or v8Upgrade to v9.15.0.0, then apply 9.15.2.70.

Ahsay dates the v10 hotfix to October 10 and the v9 hotfix to October 12. It states that both hotfixes fully address the two CVEs. Keep the evidence scopes separate: the vendor makes the broader remediation claim; Huntress’s published independent verification concerns the v10 chain’s entry point. Ahsay status report

The backup-platform owner should obtain the relevant fix through Ahsay’s official support channel, follow its installation instructions, and retain evidence of the installed hotfix on every serving instance. A version screenshot from the wrong node is not closure. For a managed service provider, the same check must cover each customer deployment the provider operates.

After the change, test a representative backup, replication workflow, and restoration into an isolated destination. Successful jobs show that the service still works. The installed-hotfix record answers the different question of whether the vendor’s correction was applied.

Read the Process Tree, Not the Edge Icon

Huntress describes an XMRig miner named edge.exe and a renamed NSSM service utility called msedge.exe, downloaded into temporary directories. A service named MicrosoftEdgeUpdateSvc supplied persistence. A PowerShell script stopped mining while Task Manager was open and restarted it afterward. Huntress observations

The analytical lesson is that a reassuring name says little about a process’s role. Ask which executable launched it, where it resides, which service points to it, and what it does next. A browser-looking binary launched by backup software deserves a different review from a browser launched by a user.

Huntress has published an experimental Sigma rule for unexpected children of cbssvcX64.exe or cbssvcX86.exe, with exclusions for expected activity. The rule requires process-creation telemetry containing parent and child information. Review it against your installation’s maintenance behavior before enabling alerts; its status does not imply validation in your environment. Published detection rule

An operational hunt should join several sources rather than depend on a filename:

EvidenceQuestion for the investigator
Backup-service process treeDid the service launch command interpreters, download tools, or executables outside its baseline?
Windows service inventoryDoes a recently created service point into a temporary directory? Who created it?
Application files and configurationWhich files, administrator accounts, or replication receivers appeared without a corresponding change record?
Network and endpoint historyCan a suspicious download be linked to the process, persistence, and subsequent activity?

This is an investigation plan, not a claim that every listed behavior occurred in every case. Preserve timestamps and central telemetry before cleanup. If endpoint logging was absent, write that limitation into the assessment rather than treating the empty search as reassuring evidence.

Restrict the Reachable Service Without Breaking Backups

Huntress recommends limiting management-interface access to trusted addresses or a VPN. Huntress mitigation guidance

The network and platform owners should first map which clients, replication partners, and administrators need the service. Apply access restrictions at the actual exposed application path, then test from an unauthorized network that it is unreachable. Separately verify that approved backup and replication traffic still succeeds. Do not assume hiding the login page also hides every application API, or close ports blindly on a shared service.

This restriction reduces opportunities to reach the vulnerable application. It is useful during remediation and as a continuing exposure control. It does not replace the hotfix, and it does not evict a webshell already on the host. MFA on an ordinary login flow likewise cannot be assumed to block an authentication-bypass vulnerability.

A Patched Server Can Still Be Compromised

Ahsay identifies unexplained JSP files under %CBS%\webapps, unauthorized replication receivers, and unauthorized administrator accounts as compromise indicators. It recommends rebuilding affected servers, reinstalling the platform with the appropriate hotfix, and recovering a configuration that predates the intrusion. Ahsay recovery guidance

Before rebuilding, the incident-response owner should preserve the relevant evidence and scope the compromise. Coordinate isolation with the backup owner so containment does not accidentally destroy the only available restoration path. Do not restore a configuration merely because its timestamp precedes the first file you noticed: the earliest visible artifact may be later than initial access.

The recovery decision should answer three questions:

  1. What could this host access? Inventory its service identities, storage permissions, replication relationships, and customer boundaries. Review credentials and sessions within that actual scope.
  2. What state can be trusted? Compare configuration and accounts with earlier records. Establish why the selected rebuild and configuration sources predate compromise.
  3. Can critical data be restored independently? Restore a representative workload into an isolated environment and verify its contents and usability, not just the existence of backup objects.

These are additional operational recommendations. They do not establish that attackers stole backup contents, deleted recovery points, or crossed into every customer environment in the observed campaign. The published evidence reviewed here does not support those conclusions. Those outcomes are questions to investigate based on permissions and activity.

A miner proves that someone used the server for an unauthorized purpose. It does not define the full extent of access. Close the incident when the service is corrected, persistence is addressed, reachable privileges are reviewed, and recovery works from a state the investigation can defend.

Sources

Research checked October 14, 2026. Version guidance reflects the sources available at that time.