Security Operations

Follow-up: AhsayCBS hack left webshells, C2 implant, Veeam probe

Huntress finds AhsayCBS backup servers held five webshell families, a C2 implant and a Veeam credential query. Patching alone will not clean them.

Illustration of a compromised backup server with the headline Backup servers hid webshells and implant

Huntress has published a second, far more detailed look at the AhsayCBS intrusions it first flagged in October, and the picture has moved well beyond opportunistic cryptomining. Any MSP or business that ran an exposed AhsayCBS console before the hotfixes should not assume that patching alone has cleaned it up.

What happened

When exploitation of two AhsayCBS flaws first came to light in early October, CVE-2026-105133, which skips authentication, and CVE-2026-105134, which runs commands as SYSTEM without logging in, the visible payload was an XMRig miner masquerading as Microsoft Edge. Huntress said that first wave targeted at least five organisations within days of exploit code going public.

On 9 November Huntress researcher Jonathan Semon released a follow-up based on three AhsayCBS servers inside a single organisation, all compromised between 8 and 11 October, before Ahsay shipped its fixes. The new material is the story here. Rather than a quick smash and grab, the operator left five distinct webshell families, a second miner with its own persistence, a custom Python implant that talks to a command-and-control server, tunnelling utilities, three commercial remote access tools, a Mimikatz package and sweeping Microsoft Defender exclusions. Investigators also found that a linked Veeam server had been hit with what looks like NetExec’s Veeam module, querying the backup database for stored passwords.

Huntress is careful about the limits of what it saw. It has not established that any backup data was taken, has not identified the implant’s malware family and could not say how many Veeam credentials were recovered.

The technical picture

The webshells are the most instructive part for defenders because they show deliberate effort to defeat the obvious hunts. One simple family returns an ordinary 404 page unless the caller supplies the right key, so an unauthenticated scanner sees nothing of interest. Another family, named with status_ and st_ prefixes, can delete itself after use, which means a clean directory today proves very little about last month.

Two shells stand out. nsmind.jsp behaves like a small signed API, demanding an HMAC signature, timestamp and single-use nonce, and offering command execution plus chunked upload and download of files up to 4 GB. Huntress flags that download function as a ready-made exfiltration route on a backup server. AhsayCBS.jsp, by contrast, poses as an image preview service: it pulls AES-encrypted Java code out of the least significant bits of uploaded PNG pixels, runs it in memory and returns results inside another image. In the access logs, that looks like image traffic, with no tell-tale command parameter to grep for.

The exploit also dropped copies of shells into Linux-style paths such as C:\opt, C:\usr and C:\home on Windows hosts, suggesting it simply tried every plausible install location. Those stray folders probably cannot work as shells, but Huntress says they are a reliable indicator.

Persistence was layered. The second miner, kvm-agent.exe, uses a different wallet and pool from the October campaign and is revived every minute by a SYSTEM scheduled task whose start date was backdated. The Python implant sits in an embedded interpreter under the SYSTEM profile, launched from a Run key, and refuses to execute unless a marker file named after the hash of the host’s MachineGuid is present, which is designed to stop it running in sandboxes. When it does run, it reflectively loads a stripped x64 DLL whose strings point to DNS-over-HTTPS lookups via Quad9 and Google and a hard-coded C2 domain. Huntress has not watched it run.

Flow diagram of the AhsayCBS intrusion from initial exploitation through webshells, persistence and evasion to Veeam credential targeting

Why it matters for UK organisations

AhsayCBS is a management console aimed squarely at managed service providers and system integrators, which makes it a supply chain concern rather than a niche product issue. A compromised backup console at an MSP is a foothold into the credentials, repositories and restore paths of every customer it serves. The Veeam query in this case is the detail that should concentrate minds: backup platforms routinely store accounts for hypervisors, storage and the domain, and those are exactly what a ransomware crew wants before it deletes restore points.

Managed service providers have long been an attractive route into their clients, and the way UK regulators and the Cyber Security and Resilience Bill debate treat supplier risk only increases the pressure on them to prove their own estates are clean. If a third party manages your backups, ask your provider directly whether it runs AhsayCBS, when it applied the hotfix and what it did to check for prior compromise.

Expert view

This is a textbook example of why “patched” and “clean” are different states. In my experience, organisations close the ticket once the vendor fix is applied and rarely hunt for what an intruder left behind. Backup servers sit in that blind spot: they are highly privileged, rarely monitored with the same rigour as domain controllers and often exempted from endpoint controls for performance reasons. The attacker here took advantage of exactly that by adding Defender exclusions for C:\Windows, C:\ProgramData and the AhsayCBS service itself.

The bigger lesson is the progression from a miner to patient tooling built for long-term access. When we test MSP environments, the backup tier is frequently the shortest path to domain-wide credentials, and attackers clearly know it. I would also treat the presence of AnyDesk, Atera and Splashtop as a reminder to keep a strict allow list of approved remote access tools, because a second, unapproved RMM agent is one of the most dependable signals you will get.

What to do now

  1. Confirm the hotfix. Ahsay’s fixes are 10.3.4.45 for version 10 and 9.15.2.70 covering versions 7 to 9. Huntress verified the former blocks the entry point it observed. Until confirmed, keep the management interface off the internet or behind a VPN and IP allow list (Cyber Essentials: firewalls, security update management).
  2. Hunt on anything exposed before patching. Check webapps\cbs and webapps\rps for .jsp files nobody deployed, requests to UpdateReceivers.do in access logs, stray ahsay_*, opt, usr, home or srv folders, and timestamp-named directories beside them.
  3. Audit persistence and defences. Review any scheduled tasks or services nobody on your team created, especially SYSTEM tasks repeating every minute, Run keys launching Python, and any Defender exclusions you cannot account for (Cyber Essentials: malware protection, secure configuration).
  4. Add behavioural detections. Alert on python.exe or pythonw.exe running from the SYSTEM profile, non-browser processes making DNS-over-HTTPS requests, new .jsp files in AhsayCBS web directories and cbssvcX64.exe spawning a command shell.
  5. Control remote access tooling. Inventory AnyDesk, Atera, Splashtop and similar agents and remove anything not approved; check for unknown local accounts such as wdguest (Cyber Essentials: user access control).
  6. If you find anything, rebuild and rotate. Huntress recommends re-imaging from a trusted source and rotating every credential the server held or could reach, including those held in AhsayCBS and in Veeam or other backup software on the same network.

Bottom line

The October AhsayCBS attacks looked like cryptojacking; Huntress’s latest findings show at least one operator using the same access to build durable, quiet footholds on backup infrastructure and reach for stored credentials. If your console was exposed before the hotfix, treat it as potentially compromised, hunt for the artefacts above and, if in doubt, rebuild it rather than trusting the patch.

Sources

Related Posts