Attackers Pushed a Backdoor Through AOMEI Backupper's Own Update Servers

AOMEI Backupper is Windows backup and disk-cloning software. It also keeps a background service that polls AOMEI Technology's servers for update notices and pop-up content. Between May and July 2026, attackers changed what those servers returned during short windows, and any installed copy that checked in during one of them downloaded and ran a backdoor.

Related reading: Brevo Supply-Chain Attack Injected ClickFix Malware via a Stolen Cloudflare Key · Attackers Used ConnectWise Cloud Backup's App Identity to Sign Into Microsoft 365 Tenants.

Google Threat Intelligence Group and Mandiant, working with ManageEngine's Threat Analysis Lab, disclosed the campaign in the week of 13 October 2026. The Hacker News and ManageEngine published detailed accounts on 16 October.

The reports do not say how the attackers obtained write access to AOMEI's infrastructure. They do show what that access bought: a supply-chain compromise that required no phishing message, no lookalike download site and no flaw in the backup program. The software did what it was built to do, and the payload arrived through the vendor's own update channel.

Three windows, and probably more

GTIG and Mandiant confirmed three tampering windows. The first ran for 10 minutes on 28 May 2026, from 05:40 to 05:50 UTC. The second lasted six minutes on 16 July, from 08:33 to 08:39 UTC. The third lasted five minutes on 20 July, from 10:35 to 10:40 UTC. ManageEngine's monitoring independently caught the 16 July change while it was happening.

The researchers said more windows probably occurred, with tampering dating back to April 2026. That estimate matters more than the three confirmed dates. A campaign built on windows this short does not need many attempts to reach a lot of machines, because the target is whoever happens to run an update check while the file is altered.

GTIG identified affected organisations in IT services, telecommunications and higher education across 11 countries: Australia, Brazil, India, Pakistan, Portugal, Singapore, South Africa, Spain, Switzerland, Türkiye and the United States. It gave no total and said the real number is likely higher. Neither report attributes the campaign to a state or names an actor. GTIG tracks the group as UNC7017.

The update path trusted itself

Backupper's update flow uses two configuration files, down_html.ini and Notifycfg.ini. They are not signed. They tell the program what to download and which pop-up content to display, and neither is cryptographically authenticated. The checksum used to verify a download is declared inside the same unauthenticated file that names the download, so an attacker who can change the file can also change the value meant to prove it is genuine.

HTTPS protected the transfer. It did not protect the content, because the content came from AOMEI's own hosts and was served over a valid connection. This is the part of the story that matters beyond this malware family. Transport security answers whether a server is who it claims to be. It says nothing about whether the file that server is handing out should be trusted.

GTIG described the campaign as the first Windows supply-chain compromise it has seen built on tampering windows this short. The report said the approach effectively evaded point-in-time triage and automated file scanning. A file that is malicious for six minutes and genuine afterwards leaves little for a scanner that looks once.

The same update flow is used by AnyViewer, AOMEI's remote-desktop tool, and GTIG names AnyViewer as also targeted. The reports focus on Backupper, so the number of AnyViewer installations that checked in during a tampering window is not known.

From a notification to a scheduled task

The 20 July chain shows how far the tampering reached. The altered notification file pointed the in-app pop-up at a bundled executable called upgrade-now.exe. The file carried AOMEI publisher metadata but was unsigned, and its product string read “AOMEI Update Compent,” with “component” misspelled.

Running it installed a genuine, signed Radmin Server from Famatech. Next to the signed Radmin launcher, FamItrfc.exe, the dropper placed an attacker-built DLL called BlkScrDl.dll. The signed launcher loaded the DLL from its own folder, a classic sideload. That DLL loaded the implant, RuntimeComponent.dll, the backdoor GTIG calls SHINYROAD. The implant registered itself as a COM server inside the signed dllhost.exe surrogate and carried an embedded, encrypted PocketPy payload. Persistence came from a scheduled task named RadminComponentRuntime, set to run every three hours.

The malicious parts were the unsigned dropper, the sideloaded DLL and the implant. Everything they touched was signed or a legitimate Windows process. That is why the activity is hard to catch with a file reputation check alone.

ManageEngine tracks the dropper as CROSSROAD. It deleted itself after use, checked the host's public IP address and stopped if it geolocated to China or if geolocation failed, and stopped if it found certain endpoint security agents. Those checks point to a careful, targeted operation rather than a broad, indiscriminate campaign. They also mean a machine outside the target set may never have run the payload even if it fetched the dropper.

The implant connected to one hard-coded command-and-control endpoint, 8.218.65.184 on port 41397, with no fallback. The address is decrypted only at runtime, so it does not appear in the file at rest. That single endpoint is a weakness in the implant's design: blocking outbound traffic to it severs the only control channel the researchers found. Addresses are volatile, and this one comes from the researchers' analysis rather than from AOMEI.

During the 20 July window, GTIG also found the notification file changed to open an invisible one-pixel pop-up. The pop-up pointed at a remote file over a WebDAV or UNC path. Rendering it could make Windows send the logged-in user's NetNTLMv2 authentication material to the attacker, with nothing visible on screen and no program executed.

That second path matters because it bypasses the usual assumption that a supply-chain attack has to deliver code. A credential leak of that kind can be used later, from another network and another tool, against systems that never ran the backdoor. The researchers present it as a capability they observed in the tampered file, not as proof that credentials were taken from every affected network.

What AOMEI knew, and when

ManageEngine's endpoint software flagged the activity on 28 May 2026, the day of the first confirmed window. A customer raised it on 7 June, and ManageEngine notified AOMEI the same day.

AOMEI's first explanation was that the content had been intercepted in transit. ManageEngine said the evidence did not support that, because both endpoints fetched the files over HTTPS from AOMEI-owned hosts in different countries. Mandiant notified AOMEI on 17 July. AOMEI replied on 29 July that its servers were secured.

AOMEI has not published its own account beyond reporting corrective action. That leaves the root cause open. The reports describe the tampering in detail and do not describe how the attackers got in, so the question of whether the same access route is closed rests on the vendor's assurance rather than on public evidence.

The product side is also unresolved. AOMEI's changelog for Backupper, checked on 16 October 2026, listed no change to how the program verifies updates through the current release, 8.5.0, published on 9 October. The affected version range is not fully documented either. ManageEngine examined version 8.3.0 and said it observed 8.3.0 and later. If the update files still cannot be authenticated independently, a future server compromise would have the same path to the same result.

Why a clean scan proves little

The defensive lesson runs against the instinct to check a file and move on. An endpoint that fetched the dropper during a five-minute window and ran it can pass a scan taken a week later, because the local update file it left behind was restored to the genuine version. The evidence that remains is behavioural: a scheduled task, a Radmin installation nobody asked for, a DLL sitting beside a signed binary, a process talking to one unusual address.

That is the case for retaining and searching endpoint telemetry rather than relying on point-in-time reputation. It is also the case for treating an update server as part of the attack surface. A vendor that signs its configuration files and delivers checksums through a separate, authenticated channel removes the specific weakness used here. Short-lived signed manifests would narrow the window further, because a file altered on the server would fail verification on the client.

None of that helps a network that already ran the payload. The practical advice that follows is to hunt for the chain's components, block the command-and-control address at the perimeter, and treat a clean antivirus result as the start of an investigation rather than the end of one.

“Effectively evading traditional point-in-time triage and automated file scanning.” — Google Threat Intelligence Group, on UNC7017, 16 October 2026

What to watch

Three things are still open. The first is AOMEI's own account of the intrusion, which would say how the servers were reached and whether update verification has changed. The second is independent confirmation that the servers are clean; the only statement so far is the vendor's. The third is the affected count. 11 countries is a floor assembled from GTIG's visibility.

For defenders, the useful question is whether any machine in the estate ran an update check during one of the windows, and whether the telemetry to answer that still exists. Most organisations probably do not keep six months of process and network data. The ones that do can tell an infection from a coincidence.

The technique does not depend on AOMEI. Any updater that trusts an unsigned manifest from the same server it fetches from has the same exposure. The next report may involve different software.

Cover image: "Toshiba 1 TB External USB Hard Drive.jpg" by Editor182, public domain, via Wikimedia Commons.