Hunt AhsayCBS: the edge.exe on your backup server

Inception Security

20 hours ago

9 min read

Picture an MSP technician checking the backup server on a Thursday morning because the fans are loud. Task Manager opens, CPU looks normal, and the window closes. An hour later the box is pinned again. The process doing the work is called edge.exe, it lives in a Temp folder, and the service that keeps it alive is called MicrosoftEdgeUpdateSvc. Nobody on the team installed Edge on that server.

On 8 October 2026, Huntress reported threat actors chaining two AhsayCBS flaws, CVE-2026-105133 and CVE-2026-105134, to run code as NT AUTHORITY\SYSTEM on the Cloud Backup Server. Huntress first saw exploitation at 23:20:15 UTC on 7 October (4:20 PM PT) and, as of 8 October, had seen five organizations targeted. No actor is named, and the Huntress report does not describe data theft.

Why this one is different

AhsayCBS is the management console for Ahsay backup, used mostly by MSPs and system integrators to create users, set policies, and run backup operations. It's the server you'd be counting on to restore everything else.

The first thing you'll see is a noisy, cheap Monero miner using Edge's name. What matters more is how it got there: command execution as SYSTEM on the server that holds your recovery plan, and in some incidents a web shell in the CBS application directory.

That edge.exe isn't Edge. If someone could plant a miner on your backup server, they can use the same access to do something worse.

Before you start, find out which processes your AhsayCBS service normally starts and whether anyone would notice a new .jsp file in its web directory.

How the AhsayCBS chain turns a backup console into a miner

checkSysPwd() lets a random token stand in

CVE-2026-105133 sits in the checkSysPwd function of com/ahsay/obs/api/ApiStructsAction.java. Huntress describes it as a medium severity flaw that can lead to improper authentication, and NVD says it is triggered by manipulating an argument named random.

UpdateReceivers.do runs commands as SYSTEM

CVE-2026-105134 is in /rps/api/json/UpdateReceivers.do, part of the Replication Receiver component, and NVD describes it as OS command injection. Huntress calls it critical: unauthenticated remote code execution as SYSTEM, through an API whose authentication bypass lets a random token substitute for valid credentials. The observed chain uses 105133 to get past authentication, then 105134 to execute. After exploitation, the actors configured a malicious receiver.

JSP web shells and payloads from Alibaba OSS

In some incidents, a .jsp web shell landed in the directory the CBS application serves, right after exploitation. Because the CBS web app runs inside the service process, Huntress notes that commands from the shell appear as direct children of cbssvcX64.exe or cbssvcX86.exe. In several other incidents, cbssvcX64.exe spawned commands, including curl, that dropped Taskgmr.ps1, msedge.exe, edge.exe, and config.json into %TEMP% or AppData\Local\Temp from imagefiles-backup.oss-ap-southeast-7.aliyuncs[.]com.

edge.exe, msedge.exe, and a fake Edge update service

edge.exe is XMRig. It connected on port 8029 to 51.195.127[.]124 and xmr.kryptex[.]network. PowerShell edited config.json, then the actors created MicrosoftEdgeUpdateSvc to run msedge.exe from Temp as SYSTEM. The real Edge updater service is edgeupdate. Huntress found msedge.exe is a modified copy of NSSM, the service wrapper, likely used to keep the miner running through crashes and reboots.

Taskgmr.ps1 and WinRing0x64.sys

Taskgmr.ps1, which Huntress says "appears to be" AI-assisted, watches for Task Manager. When it opens, the script stops the service; when it closes, the service comes back. It also kills Task Manager at 18:00, or if it stays open more than an hour overnight, using the host's local Get-Date time. In one incident, certutil.exe fetched WinRing0x64.sys, a legitimate but vulnerable driver, to give the miner kernel level hardware access.

What Huntress and Ahsay published, and how the patch story changed

Huntress published the chain, a timeline, an IOC table with hashes, and four Sigma rules in its threat-intel repository under 2026/2026-10/AhsayCBS_XMRig_Miner. We haven't copied the hashes here, so use the Huntress table for those. The hunts below use only its domains, IPs, port, file names, and paths.

In an 8 October update at 6 PM ET, Huntress said 10.3.4 "is also affected" and that it had contacted Ahsay. Until a fix landed, its advice was to restrict the management interface and investigate.

Ahsay pushed back the next day. Both CVEs, it said, were "addressed in AhsayCBS v10.3.4.0, released on 4 August 2026," so partners on that version "are no longer affected." NVD's entries lined up with Ahsay at the time, listing versions up to 10.3.2.

Then on 10 October Ahsay reversed itself. A new alert says the previous patch, 10.3.4.0, "did not fully address" either CVE, and asks partners on affected v10 versions to apply the AhsayCBS v10.3.4.45 hotfix from its partner portal, then reboot. Its 9 October note still stands on one point: upgrading does not undo an intrusion that happened before the upgrade.

Huntress turned out to be right, so we'd treat any internet-facing server that ran 10.3.4.0 as exposed until the hotfix is on and the hunts come back clean.

What to change this week

Restrict web access to the AhsayCBS management interface to trusted IP addresses or a VPN. Huntress says the exploit targets the externally accessible web app service.
Apply the AhsayCBS v10.3.4.45 hotfix and reboot, per Ahsay's 10 October alert. Keep step 1 in place regardless, since Ahsay's earlier fix did not hold.
Run the hunts below on every AhsayCBS host, including ones already on 10.3.4.0 or the hotfix. Per Ahsay, an upgrade does not clean a server that was already entered.
If any IOC hits, follow Huntress: re-image the host fully from a trusted backup, because the actors can hide secondary backdoors. Make sure that backup predates the earliest suspicious activity your hunts find, and do not treat any date as a safe cutoff on its own.
List the AhsayCBS service's normal children now, so an unexpected one stands out.

Four hunts to run (test first)

These are our own hunts, broader than Huntress's and built from the behavior and IOCs it published, so test them in your environment before relying on them. Huntress's four Sigma rules are the reference logic, and the Splunk hunt also covers its Task Manager script block rule. The table under the hunts, "Interpret before you escalate", says what is benign and what is not.

Hunt in Splunk: children of the CBS service and Edge names in Temp (test first)

index=YOUR_WINDOWS_INDEX ((source="*Sysmon*" EventCode IN (1, 3, 11, 22)) OR EventCode IN (7045, 4104))
| eval img=lower(coalesce(Image,"")), pimg=lower(coalesce(ParentImage,"")), cmd=lower(coalesce(CommandLine,"")), tf=lower(coalesce(TargetFilename,"")), qn=lower(coalesce(QueryName,"")), ofn=lower(coalesce(OriginalFileName,"")), sb=lower(coalesce(ScriptBlockText,"")), svc=lower(coalesce(ServiceName,Service_Name,""))
| eval signals=mvappend(
    if(EventCode=1 AND match(pimg, "\\\\cbssvcx(64|86)\\.exe$"), "cbs_service_child", null()),
    if(EventCode=1 AND match(img, "\\\\(edge|msedge)\\.exe$") AND match(img, "\\\\(temp|systemtemp|appdata\\\\local\\\\temp)\\\\"), "edge_name_in_temp", null()),
    if(EventCode=1 AND match(img, "\\\\(edge|msedge)\\.exe$") AND (match(cmd, "--daemonized") OR ofn="msedge_exe"), "edge_name_daemonized_or_orig", null()),
    if(EventCode=4104 AND match(sb, "taskmgr") AND match(sb, "(stop|start)-service"), "taskmgr_aware_service_control", null()),
    if(EventCode=1 AND match(cmd, "winring0") AND match(cmd, "https?://"), "winring0_download", null()),
    if(EventCode=11 AND match(tf, "\\.jsp$") AND match(tf, "ahsay"), "new_jsp_in_cbs_path", null()),
    if(EventCode=11 AND match(tf, "\\\\temp\\\\(taskgmr\\.ps1|winring0x64\\.sys|edge\\.exe|msedge\\.exe|config\\.json)$"), "huntress_file_in_temp", null()),
    if(EventCode=7045 AND svc="microsoftedgeupdatesvc", "fake_edge_service", null()),
    if(EventCode=22 AND match(qn, "(imagefiles-backup\\.oss-ap-southeast-7\\.aliyuncs\\.com|xmr\\.kryptex\\.network)$"), "huntress_dns", null()),
    if(EventCode=3 AND (DestinationPort=8029 OR in(DestinationIp, "51.195.127.124","177.4.12.11","38.60.252.110","107.191.47.199","185.220.236.49","104.234.26.10","123.202.208.37") OR in(SourceIp, "51.195.127.124","177.4.12.11","38.60.252.110","107.191.47.199","185.220.236.49","104.234.26.10","123.202.208.37")), "huntress_network", null()))
| where isnotnull(signals)
| stats min(_time) as first_seen, max(_time) as last_seen, values(signals) as signals, values(Image) as images, values(CommandLine) as cmds by host
| convert ctime(first_seen) ctime(last_seen)
| sort 0 first_seen

Field mapping: Sysmon via the Splunk add-on, System log 7045 (ServiceName in XML rendering, Service_Name in classic), and PowerShell 4104 script block logging. Huntress does not label the role of its six infrastructure IPs, so both directions are checked. The .jsp check assumes "ahsay" is in your install path; replace it with yours.

Expect noise from AhsayCBS maintenance commands and any real NSSM deployment. If nothing comes back, confirm Sysmon file and DNS events reach the index.

Hunt in Kibana: service children, new JSP files, and the receiver API (test first)

Search 1: endpoint (EQL)

any where
  (event.category == "process" and process.parent.name : ("cbssvcX64.exe", "cbssvcX86.exe")) or
  (event.category == "process" and process.name : ("edge.exe", "msedge.exe") and process.executable : ("?:\\Users\\*\\AppData\\Local\\Temp\\*", "?:\\Windows\\Temp\\*", "?:\\Windows\\SystemTemp\\*")) or
  (event.category == "process" and process.name : ("edge.exe", "msedge.exe") and (process.command_line : "*--daemonized*" or ?process.pe.original_file_name : "msedge_exe")) or
  (event.category == "process" and process.command_line : "*WinRing0*" and process.command_line : "*http*") or
  (event.category == "file" and event.type == "creation" and file.extension : "jsp" and file.path : "*YOUR_AHSAYCBS_WEBAPP_PATH*") or
  (event.category == "registry" and registry.path : "*\\Services\\MicrosoftEdgeUpdateSvc*") or
  ?dns.question.name : ("imagefiles-backup.oss-ap-southeast-7.aliyuncs.com", "xmr.kryptex.network") or
  ?destination.port == 8029 or
  cidrMatch(?destination.ip, "51.195.127.124/32", "177.4.12.11/32", "38.60.252.110/32", "107.191.47.199/32", "185.220.236.49/32", "104.234.26.10/32", "123.202.208.37/32") or
  cidrMatch(?source.ip, "51.195.127.124/32", "177.4.12.11/32", "38.60.252.110/32", "107.191.47.199/32", "185.220.236.49/32", "104.234.26.10/32", "123.202.208.37/32")

Search 2: requests to the Replication Receiver API from outside your allowlist

FROM logs-*
| WHERE TO_LOWER(url.path) LIKE "*/rps/api/json/updatereceivers.do*"
| WHERE NOT CIDR_MATCH(source.ip, "YOUR_ADMIN_CIDR")
| STATS Events = COUNT(*), first_seen = MIN(@timestamp) BY source.ip, host.name, http.request.method
| SORT first_seen ASC

Field mapping: EQL over Elastic Defend or Sysmon, then ES|QL over whatever logs the CBS web front end or proxy. Replace YOUR_AHSAYCBS_WEBAPP_PATH with your install's web app path and YOUR_ADMIN_CIDR with your admin network before you run it. Behind a proxy, make sure source.ip is the real client, not the proxy. If a field is unmapped in your index, drop that branch or mark it optional with ?.

Real replication partners posting to the receiver API will show up in Search 2. If nothing logs HTTP to AhsayCBS, Search 2 cannot see the exploit, so lean on Search 1.

Hunt in Falcon CQL: what the backup service spawned (test first)

#event_simpleName=/^(ProcessRollup2|DnsRequest|NetworkConnectIP4|NetworkReceiveAcceptIP4)$/
| case {
    #event_simpleName=ProcessRollup2 ParentBaseFileName=/^cbssvcX(64|86)\.exe$/i | signal := "cbs_service_child" ;
    #event_simpleName=ProcessRollup2 ImageFileName=/\\(AppData\\Local\\Temp|Windows\\(System)?Temp)\\(edge|msedge)\.exe$/i | signal := "edge_name_in_temp" ;
    #event_simpleName=ProcessRollup2 ImageFileName=/\\(edge|msedge)\.exe$/i CommandLine=/--daemonized/i | signal := "edge_name_daemonized" ;
    #event_simpleName=ProcessRollup2 CommandLine=/certutil.*(urlcache|verifyctl|https?:\/\/)/i | signal := "certutil_download" ;
    #event_simpleName=ProcessRollup2 CommandLine=/WinRing0/i CommandLine=/https?:\/\//i | signal := "winring0_download" ;
    #event_simpleName=DnsRequest DomainName=/(imagefiles-backup\.oss-ap-southeast-7\.aliyuncs\.com|xmr\.kryptex\.network)$/i | signal := "huntress_dns" ;
    #event_simpleName=NetworkConnectIP4 RemotePort=8029 | signal := "port_8029" ;
    #event_simpleName=/^Network(ConnectIP4|ReceiveAcceptIP4)$/ RemoteAddressIP4=/^(51\.195\.127\.124|177\.4\.12\.11|38\.60\.252\.110|107\.191\.47\.199|185\.220\.236\.49|104\.234\.26\.10|123\.202\.208\.37)$/ | signal := "huntress_ip" ;
    * | signal := "" ;
  }
| signal != ""
| groupBy([aid, ComputerName, signal], function=[min(@timestamp, as=first_seen), max(@timestamp, as=last_seen), collect([ImageFileName, CommandLine, DomainName, RemoteAddressIP4], limit=10), count()])
| sort(first_seen, order=asc)

Field mapping: Falcon sensor events in Next-Gen SIEM. ParentBaseFileName is our assumption; if it is empty, join on the parent process id. If ComputerName is empty on these events, group by aid and join host details.

Admins using certutil for certificate work will trip the certutil branch. If nothing comes back, confirm the backup server has an active sensor and that its events reach Next-Gen SIEM.

Hunt in KQL: the AhsayCBS host in Defender XDR (test first)

let Lookback = 30d;
let HuntressIps = dynamic(["51.195.127.124","177.4.12.11","38.60.252.110","107.191.47.199","185.220.236.49","104.234.26.10","123.202.208.37"]);
let HuntressDomains = dynamic(["imagefiles-backup.oss-ap-southeast-7.aliyuncs.com","xmr.kryptex.network"]);
let Children = DeviceProcessEvents
| where Timestamp > ago(Lookback)
| where InitiatingProcessFileName in~ ("cbssvcX64.exe","cbssvcX86.exe")
| project Timestamp, DeviceName, Signal = "cbs_service_child", Detail = ProcessCommandLine;
let EdgeTemp = DeviceProcessEvents
| where Timestamp > ago(Lookback)
| where FileName in~ ("edge.exe","msedge.exe") and (FolderPath contains @"\AppData\Local\Temp\" or FolderPath contains @"\Windows\Temp\" or FolderPath contains @"\Windows\SystemTemp\")
| project Timestamp, DeviceName, Signal = "edge_name_in_temp", Detail = strcat(FolderPath, " ", ProcessCommandLine);
let EdgeFlag = DeviceProcessEvents
| where Timestamp > ago(Lookback)
| where FileName in~ ("edge.exe","msedge.exe") and (ProcessCommandLine contains "--daemonized" or ProcessVersionInfoOriginalFileName =~ "msedge_exe")
| project Timestamp, DeviceName, Signal = "edge_name_daemonized_or_orig", Detail = strcat(FolderPath, " ", ProcessCommandLine);
let Files = DeviceFileEvents
| where Timestamp > ago(Lookback)
| where ActionType == "FileCreated"
| where (FileName in~ ("WinRing0x64.sys","Taskgmr.ps1","edge.exe","msedge.exe","config.json") and FolderPath contains @"\Temp\") or (FileName endswith ".jsp" and (InitiatingProcessFileName in~ ("cbssvcX64.exe","cbssvcX86.exe") or InitiatingProcessParentFileName in~ ("cbssvcX64.exe","cbssvcX86.exe") or FolderPath contains "YOUR_AHSAYCBS_WEBAPP_PATH"))
| project Timestamp, DeviceName, Signal = "huntress_file", Detail = FolderPath;
let Svc = DeviceRegistryEvents
| where Timestamp > ago(Lookback)
| where RegistryKey endswith @"\Services\MicrosoftEdgeUpdateSvc" or RegistryKey contains @"\Services\MicrosoftEdgeUpdateSvc\"
| project Timestamp, DeviceName, Signal = "fake_edge_service", Detail = RegistryValueData;
let Net = DeviceNetworkEvents
| where Timestamp > ago(Lookback)
| where RemotePort == 8029 or RemoteIP in (HuntressIps) or RemoteUrl has_any (HuntressDomains)
| project Timestamp, DeviceName, Signal = "huntress_network", Detail = strcat(RemoteUrl, " ", RemoteIP, ":", RemotePort);
union Children, EdgeTemp, EdgeFlag, Files, Svc, Net
| summarize FirstSeen = min(Timestamp), LastSeen = max(Timestamp), Signals = make_set(Signal), Details = make_set(Detail, 10) by DeviceName
| order by FirstSeen asc

Field mapping: Defender for Endpoint advanced hunting, or the same tables in Sentinel with TimeGenerated. Replace YOUR_AHSAYCBS_WEBAPP_PATH as in the Kibana hunt.

AhsayCBS upgrades and scheduled maintenance will spawn children too. If nothing comes back, confirm the backup server is onboarded to Defender for Endpoint.

Interpret before you escalate

Finding	Benign read	Escalate when
Child of cbssvcX64.exe or cbssvcX86.exe	Service startup or maintenance	curl, certutil, PowerShell, or cmd fetching from the internet
New .jsp in the CBS web directory	Vendor upgrade files	No upgrade at that time, or it appears right after a receiver API POST
edge.exe or msedge.exe in Temp	A browser installer unpacking	Runs as SYSTEM, carries --daemonized, has original file name msedge_exe, or is NSSM by file details
MicrosoftEdgeUpdateSvc service	None we know of; Edge uses edgeupdate	Any hit, especially pointing at Temp
WinRing0x64.sys in Temp	Hardware monitoring tool	Fetched by certutil from a URL
Traffic on port 8029, or to or from a Huntress IP or domain	Address reassigned	Repeat sessions from the backup server
Request to UpdateReceivers.do	Known replication partner	Source outside your allowlist
Empty results	Nothing matched	No sensor, Sysmon, or web logs on the backup server, so fix coverage first

Sources

Huntress, Threat Actors Exploit Critical AhsayCBS Flaws to Drop Webshells and XMRig Cryptominer, 8 October 2026 (updated 8 October, 6 PM ET; IOC table with file hashes): https://www.huntress.com/blog/ahsaycbs-flaws-exploit
NVD, CVE-2026-105133 and CVE-2026-105134, 4 October 2026: https://nvd.nist.gov/vuln/detail/CVE-2026-105133 and https://nvd.nist.gov/vuln/detail/CVE-2026-105134
Ahsay, Clarification on AhsayCBS v10.3.4.0 vulnerabilities, 9 October 2026: https://www.ahsay.com/en/company/announcements/clarification-v10.3.4.0-cve
Ahsay, Critical Security Alert: Immediate Action Required for CVE-2026-105133 and CVE-2026-105134, 10 October 2026: https://www.ahsay.com/en/company/announcements/patch-cve-105133-105134

What This Means for Your Team

Treat the backup console as tier zero. In practice that means taking its management interface off the open internet, applying the 10.3.4.45 hotfix, putting a sensor on it, learning what its service normally starts, and then running the four hunts. If one of them turns up an edge.exe in Temp, start there.

Inception Protection

Inception Protection is our managed detection and response service, and it works with the Microsoft licenses you already have. A chain like this lands on a server most teams rarely watch, so we pull Defender signals from those hosts into the same investigation as the rest of your environment and act on the host quickly. Decisions stay with you.

Inception Foresight

If you want to see how well your Microsoft environment would surface activity like this, try the free Inception Foresight M365 Assessment: https://www.inceptionsecurity.com/m365assessment. You can also follow Inception Security on LinkedIn and @inceptionsec on X.

LATEST PROJECTS

Experiencing a Cyber Incident? +1 (888) 427-2937

INCEPTION