The miner switches off when you open Task Manager

On 8 October Huntress published the details of an intrusion, and inside it there was one small piece that is unlike the rest: a PowerShell script that watches for Task Manager. When you open it, the script stops the service running the miner. When you close it, it starts it again. And at six in the evening, machine local time, it closes Task Manager by itself. The compromised machine was a backup console. What the attacker modelled was not the antivirus: it was the working hours of whoever looks.

What happened, and when

On 4 October 2026 the NVD published two AhsayCBS vulnerabilities. AhsayCBS is the console used to manage backup policies, storage and users in Ahsay's backup product. It is provider software: whoever runs it is usually a managed service provider or a systems integrator, and behind that console sit the backups of all their customers. The first, CVE-2026-105133, is in the checkSysPwd function of com/ahsay/obs/api/ApiStructsAction.java and is an authentication flaw. The second, CVE-2026-105134, is in the /rps/api/json/UpdateReceivers.do component and allows operating system command injection.

The second sits in the Replication Receiver component, and the attack uses it by configuring a malicious receiver. The record scores that command injection 10.0 out of 10 under CVSS 3.1 and the authentication flaw 7.3; under CVSS 4.0 they drop to 9.3 and 5.5, which is why you will see the second one labelled medium in some places and high in others. That is one record read with two versions of the metric, not two opinions. BleepingComputer adds the detail that genuinely changes the urgency: the authentication flaw has a public exploit. And what nobody disputes is the chain: first the authentication is bypassed, then code runs as NT AUTHORITY\SYSTEM.

Huntress saw the first exploitation on 7 October at 23:20:15 UTC, three days after the NVD publication. By 8 October it counted five organisations hit. The entry signal was a process belonging to the application itself, cbssvcX64.exe, spawning child processes it had no business spawning. And there is a version detail that deserves its own line, because it is the most uncomfortable thing in the whole case: the NVD record lists versions 10.3.0 to 10.3.2 as affected, marks 10.3.4 as not affected, and links that version's release notes as the fix. Huntress says 10.3.4, which is the latest and dates from August, is the one being exploited. The version the record points to as the patch is the one they are coming in through. If your inventory says "up to date", it is not answering the question.

The script knows your working hours

The file is called Taskgmr.ps1. Look at the letters: it is taskmgr with two of them swapped, the name of the Windows Task Manager. There is a design decision right there. It does three things, and the Huntress report describes them without ambiguity: it stops the miner service when Task Manager opens, starts it again when Task Manager closes, and terminates Task Manager at six in the evening, or if it has been left open for more than an hour overnight. It takes the time from the machine's local clock, not from UTC.

The first two behaviours are concealment, and they surprise nobody. The third is the one that makes this worth writing about. Shutting Task Manager at six in the evening is a bet about us: by then nobody is in front of the screen, and a window that has been open for an hour at three in the morning is open because somebody left it there, not because somebody is watching it. It is a hypothesis about administrator behaviour, written into code, and it is correct. Huntress adds its own assessment that the script looks AI-assisted; that cannot be verified from outside and is not the point either. The point is that this piece no longer takes any effort to write.

That is where the thesis comes from, and it is uncomfortable because it describes almost everybody's procedure: log into the machine, open the process viewer, look at the CPU, say "this is fine". Opening the process viewer is a query against a channel the attacker can close, and in this case does close. On a backup server it is twice as bad, because high consumption in the small hours is exactly what is expected of it: the nightly window justifies any figure, and the only way to tell a backup from a miner is to know what time the backup finished.

The disguises are built for a human reader

Look at the rest of the kit with that idea in mind. The Monero miner, XMRig, is called edge.exe. The manager keeping it alive is called msedge.exe and is a modified copy of NSSM, a legitimate utility that turns any executable into a Windows service. The service is called MicrosoftEdgeUpdateSvc, runs out of the Temp folder with SYSTEM privileges and restarts the miner if it crashes. And a JSP webshell was left in the backup application's directory. All that naming work is there so that, read in a process list by someone in a hurry, it adds up. An Edge update service running as SYSTEM is the most ordinary thing in the world.

What does not add up is not visible to the eye, it is visible in the record. The path a binary claiming to be named after a browser runs from. Who created that service, at what time and under which account. What the parent process is, because a Microsoft service is not born out of the backup application. And, above all, the traffic. These are two distinct indicators and they should not be blurred: the miner was talking to a Monero pool, xmr.kryptex[.]network on port 8029, while the tooling had earlier been downloaded from an object storage bucket on Alibaba Cloud. A backup server conversing with a mining pool on a non-standard port is, of the whole list, the hardest thing to mistake for legitimate work.

The published indicators are four lines and can be hunted today, so here they are rather than described:

• xmr.kryptex[.]network:8029 and 51.195.127[.]124:8029 — the mining pool, with user krxYMRN97D/creativejs.
• imagefiles-backup.oss-ap-southeast-7.aliyuncs[.]com — the download bucket, with the files under /javas/Office/win/.
• SHA256 of edge.exe: 4dcb0202fe8b2d4d7b183764e38184cd6ed50132786cc7e7d1f7f4bce1dd6f3d.
• SHA256 of msedge.exe: 05f69ae6b2b89c1c4dcf836bff032232f11bf0109f2b498e2345045d06139034, and of Taskgmr.ps1: 481728a7c9c4c02be07051d9c1958d902ea6397ebb8952ab83944818e3d25d21.

A reading of our own on that second line, and we flag it as ours because it is not in the report: the bucket the tooling was downloaded from has the word "backup" in its name. In the proxy log of a backup server, a destination with that word in it attracts nobody's attention.

The driver again, but for another reason

On one of the hosts the attacker dropped WinRing0x64.sys, a legitimate signed kernel driver that grants low-level hardware access and that carries a vulnerability known since 2020. Four days ago we took apart the mechanics of the Windows blocked driver list and we are not repeating them here: it is all in that post, including the small print that applying the policy does not evict what is already loaded from memory, and that the attack surface reduction rule prevents writing the driver, not loading one that is already there.

What this case adds is the motive. Loading a vulnerable driver usually serves to blind the EDR, which is why a driver load event is almost always read as the prelude to something being blinded. Here Huntress says it plainly: the driver gave the miner kernel-level access to the underlying hardware, with the broadest possible control and performance. The same event, a different intention, and none of the signals that usually come with it. If your procedure only looks at driver loads when the EDR complains, you would not have seen this one.

A miner is the kind version

This needs saying bluntly. On the list of things that can happen to the machine managing the backup policies, the storage and the users of an entire customer portfolio, having your electricity stolen to mine Monero is the best possible outcome. What got in was code execution as SYSTEM; the miner is only what the attacker decided to do with that, and that decision changes tomorrow without touching the chain. We already argued this in August with a different product and a different mechanism — they came in through port 5900 and left with root, and the miner was just as much of a footnote — so here we take it as given and go to the specific consequence.

It is the same matter we covered on 7 October about a different product: the backup console is privileged infrastructure, and the permission model inside it is worth whatever the door leading to it is worth. If somebody is running as SYSTEM on that server, the next question is whether your backups can be deleted from there. The answer should be no, and if it is yes, immutability and credential separation stop being a budget line and become the only thing you have left.

And the honesty in the other direction: five organisations on 8 October is not an epidemic. We have not found a reliable public figure for how many instances of this console are published on the internet, so we are not putting one here. The only thing that can be stated about exposure is the obvious: for this to happen, the management interface has to be reachable from wherever the attacker is.

The observer test

This is not something you buy. It is a question about the past, and it can be answered today in ten minutes. Pick a server you care about and one specific hour from last week: a Tuesday at nine in the evening, say. Now answer these four things without logging into that machine, using only what is already stored somewhere else:

• Was any new service created on that host during that week? Which one, at exactly what time, and under which account.
• Did any kernel driver load that was not loading the month before?
• Which processes opened connections out to the internet that night, and to what destinations?
• Who logged in, from what address, and what time did the backup window finish?

If answering means logging in now and looking, your detection is interactive. It has exactly the Task Manager blind spot — it exists while you are sitting in front of it — and on top of that it keeps office hours. If all four can be answered from the record, without touching the machine, the six-in-the-evening trick does not affect you: your channel does not close because nobody is awake.

That leaves the second half of the exercise, which we argued eleven days ago and will not rebuild here: storing the data is no use if nobody ever queries it.

What we do, without the smoke

Our managed EDR/MDR exists for this: a service being created, a driver being loaded, a binary with a well-known program name running from a path that is not its own, an outbound connection that does not match that machine's job. These are events that get recorded and that somebody reads on shift, not things you discover by opening a window. On top we put Zabbix for the symptoms, and the useful one here is easy to describe: consumption that never comes back down once the backup window has finished. Zabbix does not tell us "you have a miner". It tells us "this is not the usual pattern", and that is enough to go and look.

Now the part that does not look good in a brochure: an EDR is not an oracle. Eleven days ago we wrote about a published injection technique that four EDRs did not see, and what we said then holds today: defence consists of having more than one channel and making sure none of them depends on somebody watching. That is why the 24x7 shift matters here: the channel does not switch off at six.

And the single most effective measure in this whole case cannot be bought: not having the backup console published on the internet. That is exactly what Huntress recommends while there is no fixed version — restricting access to the management interface to trusted addresses or via VPN — and it takes no budget, only deciding that a system's management plane is not a web page.

There is no patch, and that does not close the conversation

Huntress puts it literally: until a patch is available, restrict access and hunt for signs of compromise. A patching policy that can only conjugate the verb "to patch" has nothing to say in a week like this one; we wrote about that eight days ago and this case is the textbook example. Until there is a fixed version, what you have is this: the interface reachable only from where it has to be, an active hunt for the known indicators — the service named after the Edge updater, browser binaries outside the browser's path, the script whose name is almost the Task Manager's, the hardware driver — and, if anything turns up, rebuilding the server from scratch from a trusted backup. That is Huntress's literal recommendation, and it cuts both ways here: the trusted backup is held by the compromised machine. On a server where code has run as SYSTEM, cleaning up what you found only proves that you found something; their justification is that the attackers have been able to hide secondary backdoors.

The usual line: failure is inevitable, an outage is a design decision. This case adds a variant we had not written down yet, and it is the one we are taking away. Blindness is a design decision too. The miner was not hiding from your antivirus: it was hiding from you. And if the only way you have of knowing what is happening on a machine is to log in and look, you already know what time your security stops working.

Sources: the Huntress blog post "Threat Actors Exploit Critical AhsayCBS Flaws to Drop Webshells and XMRig Cryptominer", consulted on 10 October 2026. It is the source of the two code references (the checkSysPwd function in com/ahsay/obs/api/ApiStructsAction.java and the Replication Receiver component at /rps/api/json/UpdateReceivers.do), the first observed exploitation on 7 October at 23:20:15 UTC, the five organisations affected as of 8 October, the child processes of cbssvcX64.exe, the three behaviours of Taskgmr.ps1 — stopping MicrosoftEdgeUpdateSvc when Task Manager opens, restarting it when it closes, and killing Task Manager at 18:00 or if it is left open for more than an hour overnight, with the time taken from the local clock — the assessment that the script looks AI-assisted, the file names and hashes, the MicrosoftEdgeUpdateSvc service running out of Temp with SYSTEM privileges, the JSP webshell, the mining pool and the download bucket from the indicator list, the statement about the kernel-level access the driver gave the miner, and the two literal recommendations: restrict access to the management interface until there is a patch, and "a full host re-image from a trusted backup" if any indicator appears. The CVSS scores (10.0 and 7.3 under 3.1; 9.3 and 5.5 under 4.0), the affected versions 10.3.0 to 10.3.2 and the fact that the record marks 10.3.4 as not affected and links its release notes as the fix come from the NVD entry, consulted on 10 October 2026. From BleepingComputer, "Unpatched AhsayCBS flaws exploited to deploy webshells, mine crypto", we take a single item: that CVE-2026-105133 has a public exploit. SecurityWeek, "Unpatched AhsayCBS Vulnerabilities Exploited in the Wild", for the product description and its common use among managed service providers and integrators. The reference to CVE-2020-14979 (CVSS 7.8) is ours and not from the coverage of this case: it was issued in 2020 against WinRing0.sys/WinRing0x64.sys 1.2.0 as shipped with EVGA Precision X1, not against "WinRing0" in the abstract. The mechanics of the Windows driver blocklist are cited in detail in our 6 October post, drawn from Microsoft documentation. Nothing we say about our own operation — managed EDR/MDR, a 24x7 shift, Zabbix for monitoring, backups with Proxmox Backup Server and Veeam — includes customer data, and we have put no figures from our own incidents in here because they are not public. The reading about the download bucket's name and the one about the script's schedule are ours, and are marked as such in the text. Cover photograph: "A view of the server room at The National Archives", The National Archives (UK), CC BY 3.0.