Beyond the Backup Server: Inside an AhsayCBS Cryptomining Playbook

Recovered operator notes show how a miner campaign tried to turn backup-server access into access to neighbouring Windows hosts.

The first stage of the recent AhsayCBS attacks is already well documented. Huntress observed attackers exploiting flaws in exposed backup servers, dropping Java Server Page (JSP) web shells and installing XMRig miners disguised as Microsoft Edge components. The question that follows is what an operator does after gaining that access.

Huntback recovered a playbook, scripts and an operator-written results report from an exposed staging host. Together, they describe an attempt to use AhsayCBS web shells as starting points for cryptominer deployment on neighbouring Windows machines. The operator's report says 87 starting points were processed, none met its definition of a complete deployment, and one neighbouring machine was brought online. A separate log on the same staging host records a successful check against that neighbour. These are valuable operational clues, but they are not independent endpoint telemetry or confirmation from the affected organisations.

That distinction is central to this case. The recovered files show a structured plan, real deployment code and the operator's account of its results. They do not prove the claimed size of the compromised fleet, identify every victim or show that the one miner was still running when we found the files.

Infrastructure addresses, credentials, private hostnames and victim identifiers found in the material are omitted from this article.

The public context: from AhsayCBS exploitation to mining

AhsayCBS is the management server for Ahsay backup environments. Its position makes a compromise consequential: the server has its own administrative surface and may have routes to systems that depend on it. That does not mean every AhsayCBS installation has broad internal access, but the recovered operator inventory in this case explicitly sought nearby SMB targets and usable credentials. Ahsay describes the product's backup-server and management roles.

Huntress reported exploitation of CVE-2026-105133 and CVE-2026-105134 beginning on 7 October 2026. Its endpoint observations included JSP web shells, edge.exe used as a miner, an Edge-like persistence service and connections to xmr.kryptex[.]network on port 8029. Huntress also published detections for unusual child processes of the AhsayCBS service and the disguised miner components. Huntress's investigation is the primary public source for that initial-access and host-level activity.

This was not only scanning. Huntress reported post-exploitation activity across affected endpoints and said it had seen five organisations targeted as of 8 October. Ahsay later said partners had reported unauthorised access to their AhsayCBS environments. Those sources establish that company environments were compromised in the wider incident; they do not identify every affected company or verify the operator's much larger fleet claim in the files we recovered.

The Huntback material overlaps with several distinctive details in that reporting: AhsayCBS JSP access, an edge.exe miner, an Edge-like persistence name, the same pool and port, and the mining identifier krxYMRN97D. The overlap is strong evidence that these artefacts relate to the same mining configuration or activity cluster. A shared miner identifier alone cannot establish that one person controlled every intrusion, and we have not reconstructed the initial exploit from the recovered files.

The vendor's 13 October status update says it began receiving partner reports of unauthorised access on 9 October and released hotfixes for v10 and v9 over the following days. Its 22 October advisory recommends further security hardening. The vendor's notices should be checked for the current package and recovery instructions before making a change; a patch does not remove a web shell or miner already present on a compromised machine.

What Huntback recovered

Huntback fetched the playbook and final report on 23 October 2026 at approximately 23:37 UTC. The report itself says it was generated on 14 October. The collection is therefore newly recovered evidence of an earlier operation, not proof that these lateral attempts began in the last 24 hours.

Our review used the file names, hashes, collection timestamps and bounded previews returned by Huntback. We did not run the recovered code, contact its targets, validate the listed credentials, or obtain endpoint logs from the named organisations. The preview limit also means we do not claim to have audited every line of the larger files.

The playbook's claim of 261 web shells should not be read as 261 confirmed organisations or 261 independently verified compromises. We saw the claim in a recovered document, not a validated fleet inventory. The 87 starting points are likewise the operator's count of entries processed in its report. We do not extrapolate either figure to the wider AhsayCBS user base.

How the lateral phase was meant to work

The files expose a sequence of dependencies. They do not prove that every branch ran on every host.

This is a meaningful extension of the public story. Huntress showed the miner running on exploited backup servers. The recovered playbook shows an operator trying to use those servers as launch points for additional installations. That turns an application compromise into a potential internal propagation problem.

The scripts were organised for repetition. The deployment orchestrator reads a manifest, selects candidates, records results and skips failures. Other recovered scripts handle staging, execution and checking. This is more than a loose collection of payloads: the code encodes a workflow for working through many starting points while keeping a record of the outcome. At the same time, code that can automate a task is not evidence that the task succeeded at scale.

The one reported success, and the many barriers

The most concrete outcome in the collection is also narrow. FINAL_REPORT.md says that, of the 87 starting points it processed, none achieved a complete deployment. It describes one partial success: a miner on one neighbouring Windows host. rescue3.log records a follow-up check that found an installation marker and reported the host online. Both records come from the exposed operator workspace, so they reinforce each other only to the extent that the workspace accurately reflects events on the endpoint.

The reported route was not frictionless. The operator says it could authenticate to the neighbour but remote scheduled-task creation failed. It then changed to a different Windows management path to start the installation. The neighbour-side script created its own startup task after execution. This distinction matters: failure of one remote administration technique did not, in the operator's account, end the attempt once another path remained open.

The report also describes several limits on wider spread:

• credentials that did not authenticate to neighbouring machines;
• successful authentication without usable administrative shares or remote procedure calls;
• web-shell channels that could not reliably start longer commands; and
• channels that stopped responding before a result could be collected.

Those failures are part of the finding. They show why a claimed inventory of web shells cannot be treated as a count of machines successfully mined or moved through. Network segmentation, credential boundaries and broken execution paths appear to have constrained this operator's lateral phase. The recovered report does not let us measure how often each barrier would hold in another environment.

What connects this material to Huntress's findings

The common mining identifier is unusually specific. Huntress listed krxYMRN97D/creativejs in its public indicators. The recovered playbook and neighbour installer use the same krxYMRN97D prefix with per-host rig naming, and the same xmr.kryptex[.]network:8029 destination. Both sources describe a miner presented as edge.exe and persistence made to resemble Microsoft Edge updating. Huntress's indicator and behaviour list provides the public comparison.

That is enough to link the recovered workflow to the reported cryptomining activity at the level of tooling and configuration. It is not enough to assign a named threat actor, prove that the recovered operator controlled every IP in Huntress's dataset, or conclude that every listed AhsayCBS web shell resulted from the same vulnerability chain. The compromised server may have been reached through the reported CVEs, but this collection begins after access was already available.

Some recovered paths and comments refer to an execution playbook for a “sub-agent.” That language may reflect an AI-assisted workflow, a human's task notation or copied material. We have not used it as evidence of autonomous AI-driven exploitation. The measurable story here is the attempted lateral deployment and the operator's reported result.

Why backup-server compromise deserves a wider hunt

It is tempting to treat an unwanted miner as a contained performance issue. In this case, the operator's plan used an AhsayCBS foothold to look for credentials and SMB-reachable neighbours. A backup server that can reach administrative interfaces, shares or adjacent Windows systems gives an intruder options beyond consuming its own CPU.

The recovered material does not show backup data being deleted, encrypted or stolen. It does not establish that restoration was impaired. The risk it does demonstrate is that an application server with SYSTEM-level code execution can become an internal staging point. A response confined to removing edge.exe from the AhsayCBS host would miss the neighbour the operator claimed to reach, and any other foothold not visible in this particular collection.

For defenders, the priority is to investigate the path out of the backup server: which accounts it used, which internal systems it contacted, whether those systems accepted authentication, and whether they show new tasks, services, processes or miner connections. The operator's failures provide useful boundary checks; the one claimed success shows why those checks must be made rather than assumed.

Practical hunting and response steps

1. Confirm the vendor fix and assess compromise separately. Apply the current AhsayCBS package and hotfix from Ahsay's partner guidance, then inspect for web shells, unauthorised replication receivers and unexpected administrator accounts. Ahsay's status update lists concrete compromise signs and recommends a full rebuild from a known-clean point when they are present. Its 22 October hardening notice should be checked for the latest package; that notice itself lists two different v10 build strings, so confirm the current version with Ahsay before deployment.
2. Hunt from the AhsayCBS service outward. Review child processes of cbssvcX64.exe and cbssvcX86.exe, unexpected JSP files, newly created tasks or services, payload downloads and outbound miner connections. Huntress's published detections cover several host-level behaviours.
3. Look at neighbouring Windows hosts. Examine SMB authentication, administrative-share access, remote task or management activity, and new processes associated with the backup server's accounts and IPs. The recovered neighbour installer used a temporary msedge-named directory, edge.exe, a miner configuration and an Edge-like startup task. Treat those names as leads requiring context, not as stand-alone proof.
4. Scope credential exposure. If an AhsayCBS host was compromised, determine which local, service and domain credentials were present or used from it. Rotate affected secrets after containing the foothold, and investigate any successful authentication from the host to other machines.
5. Rebuild when compromise is confirmed. Removing one miner or applying a hotfix cannot establish that a web shell and persistence are gone. Ahsay recommends rebuilding affected servers and restoring configuration from before the compromise. Extend the investigation to any neighbouring host with corroborating execution or persistence evidence.

Evidence and limits

The strongest supported conclusion is that an operator prepared and attempted a repeatable lateral cryptomining workflow from AhsayCBS web-shell access, and its own records claim one neighbouring installation. The code supports the capability; the report and log support the operator's account of the outcome. They do not independently verify the claimed fleet size or persistence on the neighbour.

The investigation has several specific limits:

• Huntback supplied bounded file previews and metadata, not full forensic images of the staging host or affected endpoints.
• The playbook and report were written by the operator. Their counts and success claims are not neutral measurements.
• The report is dated 14 October; Huntback's retrieval on 23 October does not make the described actions newly executed on that date.
• We did not validate the identities or status of hosts named in the files, or test exposed credentials.
• We have not independently confirmed a breach of any named company appearing in the recovered files, and do not publish those names as victims.
• Shared miner identifiers connect the material to Huntress's public cluster, but do not provide individual attribution or prove the initial-access method for each host.

These limits do not diminish the practical lesson. The public AhsayCBS case already showed miners on compromised backup servers. The recovered workflow shows the next question responders should ask: did the backup server become a route to other machines? In the operator's own account, the answer was yes for one neighbour and no for many others. That is precisely the kind of distinction a careful hunt can resolve in a real environment.

Indicators: recovered artefact references

The following Huntback identifiers and SHA-256 hashes document the principal files used in this analysis. They are provided without live staging URLs, credentials or victim details.

Public sources

• Huntress: Threat Actors Exploit Critical AhsayCBS Flaws to Drop Webshells and XMRig Cryptominer
• Ahsay: AhsayCBS Vulnerability Status Update, 13 October 2026
• Ahsay: Security Hardening Update, 22 October 2026

Related research

• PHP2Shell probes reached decoys hours before the security release 2026-10-23
• A Week After Censys: Coruna Infrastructure Moved, and Its Staging Host Exposed a Second Offensive Workspace 2026-10-15
• The botnet crew that served its own /root 2026-10-14

Live data

• Live finds: malware, C2 and open directories on the network now
• CVE intelligence: what is being exploited on the decoys