Attackers hijacked AOMEI’s own update servers and turned a trusted backup tool into a malware delivery channel. The total exposure adds up to just 21 minutes: three confirmed tampering windows of 10, 6, and 5 minutes in May and July, during a campaign researchers date to April–July 2026, during which any copy of AOMEI Backupper that checked in for updates was quietly pointed at a malicious package instead of legitimate content. The public did not hear about it until October 20, which is 135 days after researchers first warned the vendor.
That combination is what makes this attack unusual. Most supply-chain attacks are loud and long. This one was brief, repeated, and self-concealing: the attackers altered two configuration files on AOMEI’s servers, served their payload, and then restored the originals, leaving almost no trace for anyone who checked later. The campaign ran between April and July 2026, according to research by ManageEngine’s Threat Analysis Lab together with Google Threat Intelligence Group (including its Mandiant team). Related malware samples circulated from late April, though the three confirmed tampering windows fall in May and July, and researchers believe other windows may have gone unseen. Google tracks the actor as UNC7017 and has not linked it to any country or known group.
How a trusted update became a backdoor
AOMEI Backupper periodically fetches instructions from AOMEI’s servers through its update and promotional pop-up mechanism. The attackers tampered with two files in that mechanism. One file told the software which package to download and which checksum to expect, and the attackers pointed it at locations they controlled while supplying a matching checksum, so the malicious package passed validation. The other file controls pop-up notifications, and the attackers set it to open a page in an invisible window. That page launched a previously unknown downloader Google calls CROSSROAD.
CROSSROAD stopped if the machine was located in China, if it could not determine the machine’s location, or if certain security products were present. On machines that passed those checks, it installed genuine Radmin Server, a legitimate remote-administration tool, along with a backdoor dubbed SHINYROAD. It set up a scheduled task to launch the backdoor every three hours, then deleted itself. The activity was observed on AOMEI Backupper version 8.3.0 and later. In the July 20 window, the attackers added a second technique: forcing machines to authenticate to an attacker-controlled WebDAV server through the pop-up channel, leaking the logged-in user’s NetNTLMv2 password hash. Because that trick needed no malicious code to run, machines where the dropper itself was blocked may still have exposed credentials.
Malwarebytes has published consumer verification steps that make the hunt concrete: open Windows Task Scheduler and look in the Task Scheduler Library for a task named RadminComponentRuntime; look in Backupper’s installation folder, particularly its version-specific html and Tmphtml folders, for an unsigned upgrade-now.exe or an unexpected upgrade-now.zip; and watch for outgoing traffic to storage-data.com domains or the published attacker addresses, including 8.210.84.56 and 8.218.65.184. The dropper deletes itself after staging the next payload, so absence of the file does not mean the machine is clean.
Who was hit, and who might still not know
Confirmed victim organizations span 11 countries: Australia, Brazil, India, Pakistan, Portugal, Singapore, South Africa, Spain, Switzerland, Türkiye, and the United States, across IT services, telecommunications, and higher education. Google warns the attack was opportunistic, and organizations that polled for updates during the windows may also be affected beyond the ones directly identified. No confirmed count of affected users exists, which is itself a consequence of the short windows: only machines that happened to check in during those 21 minutes could have received the payload, and many of them may never know.
Researchers also say AOMEI AnyViewer, which relies on the same update mechanism, was targeted, so its users should check as well. That detail matters because it widens the exposed population beyond backup software alone. AOMEI markets Backupper with download figures in the tens of millions, but those are vendor marketing numbers for downloads, not counts of active users, and they say nothing about how many machines polled during the three windows. We are not repeating any of them as a victim count.
What to do if you run AOMEI Backupper
A server-side fix stops new infections. It does not remove a backdoor already installed. ManageEngine said exactly that, and it is the reason checking your own machine matters more than waiting for a vendor update. The same applies to AOMEI’s 8.5.1 update below: it prevents future abuse, it does not clean an infected machine.
- Check your Backupper version first: researchers observed the attack on version 8.3.0 and later builds.
- Look for a scheduled task named RadminComponentRuntime launching Radmin every three hours, and treat it as compromise.
- Change your Windows password if you ran Backupper between April and July, without waiting to confirm a July 20 poll.
- Upgrade to Backupper 8.5.1, whose release notes describe disabling the promotional pop-up update channel and encrypting remote configuration files.
- Check AOMEI AnyViewer too, since researchers say it uses the same update mechanism and was also targeted.
- Look in your Backupper installation folders for unsigned upgrade-now.exe files, following Malwarebytes’ published verification steps.
If the machine is domain-joined, treat this as an organization-level incident and notify your IT or Active Directory team: a leaked NetNTLMv2 hash can enable relay attacks and lateral movement across the domain, which a single password change does not fix.
If you find signs of compromise, treat it as a full incident, not a cleanup job: the backdoor had remote access, a scheduled persistence mechanism, and in the July 20 case possibly your Windows credentials. Our general guide to what to do when personal information leaks covers the identity-protection steps that apply alongside the technical cleanup. The same class of trusted-update abuse showed up in the UpdraftCentral key compromise, where stolen platform keys turned into backdoors on sites whose owners never knew they were connected.
The 135-day gap
Reconstructing the disclosure timeline from the researchers’ reports gives a 135-day gap between first warning and public disclosure. ManageEngine’s software first recorded the attack on May 28, when it logged Backupper installing Radmin on two unrelated customer machines in different countries. ManageEngine is a security vendor, and its endpoint product was the tool that first logged the attack; Google’s researchers independently corroborated the findings. Both environments were running in audit mode, so the activity was logged but not blocked. One customer raised the alert on June 7, and ManageEngine notified AOMEI the same day. That was the first day the vendor knew. Researchers caught a second tampering window on July 16 and shared the evidence; AOMEI’s initial review found no evidence of a breach. Google’s Mandiant team notified AOMEI on July 17, and AOMEI said on July 29 that it had taken corrective action. Public disclosure came on October 20. June 7 to October 20 is 135 days.
AOMEI’s first explanation was that content had been tampered with in transit. ManageEngine disagreed, with evidence that is difficult to argue against: both affected endpoints retrieved the content over HTTPS from AOMEI-owned hostnames, across different countries and unrelated network paths, and the executable arrived through the application’s own extraction sequence rather than being written to disk by an external process. The content had been altered before it reached either endpoint, inside the vendor-hosted delivery path. AOMEI now says it treats the matter as high priority, its CTO is leading an internal investigation, and it has upgraded servers, patched potential vulnerabilities, and verified hosted files. How the attackers first gained access to the update infrastructure has not been disclosed, and AOMEI has not confirmed whether the compromise is fully resolved. AOMEI has published no standalone incident advisory. Its public response consists of statements to BleepingComputer and the 8.5.1 release notes, which describe disabling the promotional pop-up update channel, encrypting remote configuration files, dropping the www2.aomeisoftware.com update domain, and restricting updates to official AOMEI websites.
We are tracking this case in our Data Breach Tracker. The practical consequence is direct: a fix on the vendor’s servers protects the next person who checks for updates. It does nothing for the machine that already checked in during those 21 minutes. If you ran Backupper between April and July, the check is yours to do.
Sources: Help Net Security, October 20, 2026; BleepingComputer, October 20, 2026; Malwarebytes, October 19, 2026; ManageEngine Threat Analysis Lab and Google Threat Intelligence Group research, via Help Net Security and BleepingComputer.
