For a few minutes at a time between April and July, attackers swapped the update instructions behind AOMEI Backupper and pushed a backdoor to anyone whose copy happened to check in. A server that looked clean when analysts checked it may have led SOC teams to close genuine alerts, so a look-back hunt is now the priority.
What happened
Google’s threat intelligence team and its Mandiant unit published research on 15 October 2026 on a supply chain campaign against AOMEI Technology, the maker of the AOMEI Backupper backup tool and the AnyViewer remote desktop product. ManageEngine’s Threat Analysis Lab (METAL), part of Zoho, published its own write-up on 16 October. Google tracks the operators as UNC7017 and has not linked them to a country or a known group.
The attackers did not change AOMEI’s software. Instead, they briefly edited the configuration files that installed clients download to decide what to update and which pop-ups to show. Three windows are confirmed: ten minutes on 28 May, six on 16 July and five on 20 July, with related malware seen from late April and probably other windows nobody caught. Clients polling during a window were told to fetch and run a malicious package; those checking minutes either side got genuine files.
METAL’s EDR first caught the chain in late May, and it alerted AOMEI on 7 June after a customer escalation. AOMEI initially blamed interception in transit, a theory METAL says its evidence did not back. Mandiant shared indicators with AOMEI on 17 July, and on 29 July AOMEI said it had taken corrective action. Neither report explains how UNC7017 got write access to the servers. The Hacker News notes that the Backupper 8.5.0 changelog (9 October) shows no change to update verification.
GTIG found victims in 11 countries, among them Australia, Spain, Switzerland and the United States, including telecoms, higher education and IT services. The UK is not named, but GTIG stresses the targeting was opportunistic and the true spread is probably wider.
The technical picture
The weakness was in AOMEI’s update design. Two plain-text files drive the process: one names the update package and gives its MD5 checksum, and the other controls the notification service and what it runs. Neither file is signed. Because the checksum sits inside the same unprotected file as the download address, an attacker who can edit one can edit both, so the integrity check proves nothing. During each window, UNC7017 pointed clients to an archive on its own infrastructure and bumped the build number. In July it also filled the notification file with more than 35,000 lines of junk sections, which made clients update whatever version they were running.
The first stage, CROSSROAD, posed as an AOMEI updater, complete with a misspelt product name in its metadata. It checked the host’s location, stopped its main routine on Chinese hosts, avoided certain security agents, reset the local AOMEI configuration to the legitimate values, created a scheduled task named RadminComponentRuntime that runs every three hours, and then deleted itself.
The task starts a genuine signed Radmin binary that side-loads an attacker DLL, which in turn runs SHINYROAD: a backdoor whose logic executes in an embedded PocketPy interpreter and which contacts a hard-coded IP address, avoiding DNS entirely. SHINYROAD provides a remote shell and can pull in new code. From mid-July GTIG also saw the Adaptix C2 agent deployed under a Nitro PDF disguise, with its own scheduled task named NitroRuntime.
The 20 July window added two refinements. The first download came from a public Google Cloud Storage bucket, which GTIG says let it slip past proxies that block newly registered domains. The pop-up file was also changed to render an invisible one-pixel window that pointed at a WebDAV share on an attacker server. Simply rendering it could leak the logged-on user’s NetNTLMv2 challenge response, even if no executable was ever allowed to run.
Why it matters for UK organisations
AOMEI’s tools are cheap and popular, which is exactly why they turn up on small business file servers, office PCs and managed service provider estates across the UK. In my experience, backup and remote support utilities are installed once, forgotten, run with high privileges and rarely appear in a software inventory. Payloads inherit the rights of the AOMEI process that launched them, and METAL notes that this process may have been running elevated or as a service.
The bigger lesson is about how alerts get triaged. GTIG says the short windows were effective at “evading traditional point-in-time triage”. An analyst who saw a suspicious AOMEI child process and then checked the vendor’s update file would usually have found it clean, and could reasonably have closed the ticket as a false positive. METAL adds that behavioural policies in the affected environments were only logging, not blocking. Both failings are common in UK SOCs and MSPs.
Expert view
We rightly tell organisations to keep software updated, but every auto-updater is also a remote code execution channel run by a third party. When that channel relies on unsigned text files and a checksum the attacker controls, the vendor’s server becomes a single point of failure for every customer. This case did not need a zero-day. It needed minutes of write access.
It also shows why behaviour beats indicators. The dropper deletes itself, the remote files revert, and the backdoor runs inside signed binaries. Hash lists will catch very little of that. What does stand out is structure: a backup product launching unsigned programs from its pop-up folders, a Radmin install with no server address or account configured, and scheduled tasks that nobody created on purpose.
What to do now
- Find every copy. Search software inventory, EDR and RMM data for AOMEI Backupper and AnyViewer, including installs on servers and in client estates you manage. Remove unneeded copies (Cyber Essentials: secure configuration).
- Hunt back to April 2026. AOMEI’s server fix does not clean endpoints. Look for programs launched from the AOMEI html and Tmphtml folders, unexpected Radmin files in users’ local application data, and the RadminComponentRuntime and NitroRuntime scheduled tasks. Reopen any AOMEI-related alerts closed between April and July.
- Use the published detection content. GTIG has released YARA rules and indicators, and METAL has published behavioural Sigma rules. Test them in your tooling first.
- Block the infrastructure and the leak paths. Block the domains and IP addresses both reports list. Stop outbound SMB and WebDAV to the internet at the firewall, which also cuts off the credential leak trick (Cyber Essentials: firewalls).
- Treat any hit as an incident. Preserve the cached update files and match the alert time against proxy and firewall logs. Reset credentials for users who were logged on to affected hosts, and check for wider remote access.
- Move EDR from audit to block for behavioural rules where it is safe to do so, and document exceptions (Cyber Essentials: malware protection).
Bottom line
UNC7017 showed that a supply chain attack can last just minutes and still reach many organisations, because nobody was watching the update channel itself. If AOMEI software is anywhere in your estate, assume nothing about the past six months until you have hunted for it.
