When the Backup Server Becomes the Way In

From 7 October 2026, attackers broke into AhsayCBS backup consoles that were reachable from the internet and took full control of the server without a password. Fixed versions exist: 10.3.4.45 for v10 and 9.15.2.70 for older lines. The broader lesson is simple: the screen that manages your backups should never be open to the whole internet.

AhsayCBS is the management console of Ahsay's backup software, used mostly by IT providers that look after backups for many client companies. This article covers what happened, why a backup console is a prize target, and what to check this week whether you run the software yourself or pay someone else to.

What happened between 4 and 14 October?

Two flaws were published on 4 October. Three days later, security firm Huntress saw them being used in the wild. Within a week the US cyber agency CISA added both to its Known Exploited Vulnerabilities list, the catalogue of flaws confirmed to be under attack.

Horizon3.ai rates the two flaws 7.3 and 10.0 on CVSS, the industry's 0–10 severity scale. A 10.0 is the top of the scale: no account needed, full control afterwards.

The 12 October correction matters most. Anyone who patched promptly after the first advisory still had an open door. If your team marked this as done before 12 October, check the version number again.

How did attackers get in without a password?

The first flaw works like a staff entrance that opens for anyone who says "I'm from inside". Horizon3.ai found that the console skips its password check whenever a request carries one particular marker ("FromServlet":"Y"). The attacker simply adds the marker.

The second flaw sits in the replication receiver, the feature that accepts copies from another backup server. Once past the login, an attacker can use it to drop a file into the folder the console serves as web pages. That file runs as SYSTEM, the most powerful account on a Windows machine.

The second step only works on servers set up or licensed to receive replicated copies. Many provider setups are, because a second site for backups is exactly what customers pay for.

What did the attackers do once inside?

The cases Huntress documented share a pattern:

• a web shell, a hidden web page that lets the attacker send commands to the server at any time, planted in the console's web folder;
• a cryptocurrency miner disguised as Microsoft Edge (edge.exe), kept alive by a fake Windows service named MicrosoftEdgeUpdateSvc;
• a PowerShell script that pauses the miner while Task Manager is open and closes Task Manager if it stays open too long.

A miner is close to the best outcome here. It burns electricity and CPU, but it leaves the data alone. The same SYSTEM access could just as easily delete backup sets, change retention so old copies quietly expire, or copy client data out.

Why do attackers go after backups first?

Because backups decide whether a victim can recover without paying. Veeam's 2023 Ransomware Trends Report, a survey of 1,200 IT leaders, found that attackers targeted backup repositories in 93% of ransomware incidents, and 75% of victims lost at least some of their backups along the way.

A backup console is also unusually rich. It knows which machines exist, where the copies live, and when jobs run. On a provider's console it holds all of that for every client at once. One break-in reaches many businesses, the same pattern we saw with remote support tools in September.

Does this affect businesses in Indonesia?

Directly, only if AhsayCBS runs somewhere in your backup chain. Ahsay sells mainly through partners and providers, so a local "cloud backup" package may run on it without the name appearing on your invoice. You cannot tell from the outside. Ask your provider which software runs the backup console and where that console is reachable from.

Indirectly, the lesson applies to every backup product and storage device with a web admin screen. The specific flaw changes from year to year; an admin screen exposed to the internet is the recurring mistake.

What should you do this week?

If you run AhsayCBS yourself:

If someone else manages your backups:

1. Ask which software runs the backup console and whether it is reachable from the internet.
2. Ask for the installed version and the date it was patched, in writing.
3. Ask whether at least one copy of your data cannot be deleted from that console, even by an administrator.
4. Ask when they last restored your data as a test, and how long it took.

The third question is the one that separates a nuisance from a disaster.

How do you design backups that survive a stolen console?

Assume the console will be compromised one day, then make sure that day is survivable.

• Keep the admin screen off the internet. Agents on client machines may need to reach the backup server; the admin interface does not. Put it behind a VPN.
• Keep one copy out of the console's reach. That can be an offline disk, or immutable storage, which refuses to change or delete a copy until a set date, even when the request comes from an administrator. This is the extra "1" in the 3-2-1-1 rule: three copies, two media types, one off-site, one that cannot be altered.
• Use separate credentials. The backup system should not share a login with the domain or the servers it protects.
• Test the restore, not the job. A green "backup succeeded" only proves a file was written. We covered this in verifying Postgres backups, and why disk redundancy is no substitute in RAID is not a backup.

None of this needs new software in most setups. It is placement and permissions, and it costs far less than finding out on the day of a ransomware attack that the backups went first.

If you want a second opinion on where your backup console sits and what can reach it, I review this as part of system architecture consulting.