AOMEI Backupper's update servers handed out a backdoor a few minutes at a time

On 16 July 2026, between 08:33 and 08:39 UTC, AOMEI's update server offered AOMEI Backupper customers a release the company had never shipped. A few minutes later it was serving the genuine files again, and anyone checking it then found no sign of tampering.

Google Threat Intelligence Group (GTIG) and Mandiant documented at least three such episodes between May and July in research published in mid-October, carried out alongside ManageEngine's METAL team. Google tracks the operators as UNC7017 and does not tie them to any country. They used AOMEI Backupper's update channel to push a chain of programs ending in a backdoor. GTIG notes that AnyViewer, the vendor's remote desktop tool, relies on the same update mechanism.

The victims identified so far are spread across 11 countries, Spain and Portugal among them, in IT services, telecommunications and higher education. GTIG calls the targeting opportunistic and expects the true footprint to be wider than what it could document. On 19 October AOMEI released Backupper 8.5.1 and AnyViewer 5.8.1 for Windows with changes to the update channel, although neither release cleans machines that are already compromised.

How does a legitimate updater start shipping malware without a single exploit?

Neither of the reports published in October 2026 describes a vulnerability. METAL states that there was no CVE, no memory corruption and no unpatched component, and that the attackers leaned on the design of the update flow, which rests on unsigned remote configuration files. METAL observed the chain on Backupper 8.3.0 and later.

Which configuration files did UNC7017 tamper with?

GTIG explains that AOMEI clients periodically fetch two text files from the vendor's servers over HTTPS. down_html.ini names the latest version, its MD5 hash and the download location, and Notifycfg.ini drives the pop-up notifications and the commands those notifications run. Neither file carried a cryptographic signature. The hash meant to validate the package travels inside the very file that says where to fetch it, so whoever can edit that file chooses both the payload and the value it will be checked against.

During each window UNC7017 bumped the version number, redirected the download to packages of its choosing and set the hash to match. GTIG describes three hosting phases: Alibaba Cloud OSS in Hong Kong in April and May, lookalike storage domains (storage-data[.]com) in early July, and a public Google Cloud Storage bucket on 20 July. How the group gained write access to the files on the origin server is not explained in either report.

How long did the tampering windows last?

The three windows confirmed by GTIG lasted five to ten minutes each. They fell on 28 May (05:40 to 05:50 UTC), 16 July (08:33 to 08:39) and 20 July (10:35 to 10:40). Only machines that happened to poll during those minutes were served malicious instructions, and anything checking a little earlier or later received the genuine files. GTIG says it is the first time it has seen supply chain tampering conducted in windows this short, and both Google and The Hacker News consider further windows outside their visibility likely.

Why could the invisible pop-up leak NetNTLMv2 credentials?

During the 20 July window, the notification file opened a 1x1-pixel window, invisible to the user, pointing at a WebDAV network path on an attacker-controlled IP address. When Windows tries to reach such a path it may hand over the user's NetNTLMv2 authentication response, which can then be brute-forced offline or relayed to other services. No attacker program has to run on the machine for this to work.

What did the malware chain install next?

The first-stage downloader, which Google names CROSSROAD, checked whether it was running from an AOMEI folder and, if not, scheduled its own deletion while carrying on regardless. It also looked up the machine's location and, in some execution branches, abandoned its main payload if the country was China. METAL adds that it stopped when the geolocation lookup failed and that it looked for particular security agents.

If it carried on, it installed Radmin, a commercial remote administration tool, created a scheduled task and deleted itself. METAL describes a genuine, signed Famatech installer, whereas GTIG refers to a modified version of Radmin Server.

The backdoor, SHINYROAD, arrived through DLL side-loading (a legitimate, signed executable, FamItrfc.exe, unwittingly loads an attacker-supplied library, BlkScrDl.dll, placed beside it). On some machines, since at least early July, the Adaptix C2 post-exploitation framework followed, dressed up as Nitro PDF components.

How was the campaign discovered, and how did AOMEI respond?

According to METAL's report, its EDR recorded on 28 May 2026 that AOMEI Backupper was installing Radmin on two machines at two organisations which shared no infrastructure, administrators or suppliers. One of those customers escalated on 7 June. By then the installer had deleted itself and its hash returned no results on VirusTotal, which is why the campaign went weeks without a name.

METAL notified AOMEI on that same day, 7 June. The vendor suggested the content had been intercepted and modified in transit, an explanation METAL rejected. The team replayed the download in a lab and got clean content back, so it began watching AOMEI's download locations continuously. On 16 July it caught a tampered package that reverted to its authentic state within minutes. The 20 July window was spotted by GTIG and Mandiant while METAL's monitoring happened to be offline.

Mandiant alerted AOMEI on 17 July and handed over indicators. On 29 July the company replied that it had taken corrective action to secure its distribution servers, without saying what that involved. When METAL published its report it had not yet been able to confirm independently that the intrusion was contained.

The Hacker News checked the public changelog on 16 October and found no change to update verification up to and including release 8.5.0, dated 9 October. Three days later the AOMEI Backupper changelog listed version 8.5.1, which adds asymmetric encryption to remote configuration files, drops the previous update domain and separates software updates from marketing notifications. It also restricts downloads to official AOMEI websites and disables automatic updates from within the application.

AOMEI told BleepingComputer that it has classified the matter as high priority and that its chief technology officer is leading the investigation. As of 20 October it has not explained how the attackers reached its servers.

Why did the usual checks come back clean?

In this campaign, the questions an analyst would normally ask of an alert all had reassuring answers. The parent process was the vendor's updater. Radmin is signed commercial software, and the executable that loaded the malicious DLL was signed too. The loader also rolled the machine's local down_html.ini back to legitimate values, so a later look at the endpoint showed no tampered version number.

Analysts who opened the vendor URL to verify an alert were served clean files, because the tampering window had already closed. The Hacker News warns that this kind of check can lead teams to dismiss authentic detections as false positives.

METAL points to an organisational factor as well. At affected customers, its behavioural policies were running in audit-only mode, flagging without blocking, and the report asks teams to revisit that setting or at least make the choice deliberately.

Where does the campaign leave traces between April and July 2026?

Both GTIG and METAL call for retrospective threat hunting across the whole campaign, which GTIG dates back to April 2026 even though the first confirmed window fell on 28 May. The most useful signals do not hinge on the hash of any single file.

• Executables launched from AOMEI's html\ or Tmphtml\ folders, especially an unsigned upgrade-now.exe whose parent is Backupper.exe or ABNotify.exe.
• Scheduled tasks named RadminComponentRuntime or NitroRuntime. METAL notes the former ran every three hours.
• A Radmin Server installed in C:\Program Files (x86)\rserver30 with no listener, registry configuration or users, the state METAL describes.
• The contents of component.zip unpacked into %LOCALAPPDATA%\Radmin\, with FamItrfc.exe loading an unsigned BlkScrDl.dll, according to GTIG.
• The files NitroPromotion.exe or Eztwain4.dll under %LOCALAPPDATA%\Nitro Pro\ on machines where nobody uses Nitro PDF.
• Outbound connections to ports 41397 or 6800, cited by GTIG, with no preceding DNS lookup according to METAL. Later SHINYROAD variants used port 443 to 8.218.65[.]184, so that connection can only be caught by IP.
• The user agents Anyviewer-loader/1.0 and Anyviewer-ipcheck/1.0 in proxy logs, and SMB (TCP 445) or WebDAV traffic heading for internet addresses.

The network indicators of compromise cited are the domain storage-data[.]com and its subdomains, plus the IP addresses 8.210.84[.]56, 8.218.65[.]184 and 47.239.60[.]117. GTIG also lists 96.126.191[.]98, which appears as an allowlisted address in the malware's configuration and not as a command-and-control server. The GTIG article carries the SHA-256 hashes and YARA rules, and METAL publishes two Sigma rules.

Advanced hunting in Microsoft Defender XDR keeps only 30 days of data, so looking back to April means the telemetry must already sit in Microsoft Sentinel or another SIEM. With the 90 days of retention included with Sentinel, a query run on 20 October barely reaches late July. Covering April requires around seven months of retention or a search of the archive tier. Where the Defender for Endpoint tables reach Sentinel, a first KQL pass could look like this.

DeviceProcessEvents
| where TimeGenerated between (datetime(2026-04-01) .. datetime(2026-08-01))
| where InitiatingProcessFileName in~ ("Backupper.exe", "ABNotify.exe")
| where FolderPath has_any (@"\html\", @"\Tmphtml\")
| project TimeGenerated, DeviceName, InitiatingProcessFileName, FileName, FolderPath, ProcessCommandLine, SHA256, ProcessVersionInfoCompanyName

A second query covers scheduled tasks, their command lines and outbound connections. In the Defender portal the time column is Timestamp instead of TimeGenerated, and port 6800 on its own can be noisy because other download tools use it.

let start = datetime(2026-04-01);
let end = datetime(2026-08-01);
union
(DeviceEvents
| where TimeGenerated between (start .. end)
| where ActionType == "ScheduledTaskCreated"
| where tostring(AdditionalFields) has_any ("RadminComponentRuntime", "NitroRuntime")),
(DeviceProcessEvents
| where TimeGenerated between (start .. end)
| where ProcessCommandLine has_any ("RadminComponentRuntime", "NitroRuntime")),
(DeviceNetworkEvents
| where TimeGenerated between (start .. end)
| where RemoteIP in ("8.210.84.56", "8.218.65.184", "47.239.60.117", "96.126.191.98")
or RemotePort in (41397, 6800)
or RemoteUrl has_any ("storage-data.com", "serv.oss-cn-hongkong.aliyuncs.com", "storage.googleapis.com/aomeiupdate"))
| project TimeGenerated, DeviceName, ActionType, InitiatingProcessFileName, ProcessCommandLine, RemoteIP, RemotePort, RemoteUrl, AdditionalFields

When an alert does fire, GTIG advises preserving the contents of the AOMEI Tmphtml folder before touching anything and lining up proxy and firewall logs against the exact second of the alert. METAL likewise recommends preserving the download directories and reviewing network telemetry.

What should you do if AOMEI turns up in your estate?

Start by finding out where it is installed. Backup, disk-cloning and remote access utilities often arrive with technicians who need them for a one-off migration, and they do not always pass through the approved software catalogue. An inventory built only from that catalogue may miss them. Where the tools stay in use, move Backupper to 8.5.1 and AnyViewer to 5.8.1.

If the hunt finds traces, handle it as a full security incident with a proper investigation. GTIG stresses that server-side remediation does not clean machines that have already pulled the payload, because the scheduled task is still there. The usual response is to isolate the machine, collect evidence, rebuild it from a known-good image and reset the credentials of anyone who used it, given the possible NetNTLMv2 exposure. An incident response service with forensic experience can shorten that work.

Even if the hunt comes back clean, some controls reduce exposure to similar attacks.

• Block outbound SMB and WebDAV to the internet at the perimeter. That makes the 20 July credential leak much harder (blocking WebDAV means looking at outbound web traffic too, not just port 445) and fits into a plan to retire NTLM without breaking the network.
• Enable the Defender ASR rule that blocks executables unless they meet a prevalence, age or trusted-list criterion, which depends on cloud-delivered protection. It may stop a never-seen, unsigned installer such as upgrade-now.exe, though it is unlikely to catch the signed links in the chain.
• Alert on unsigned child processes of every updater, not only AOMEI's, much as you would for living-off-the-land binaries.

For third-party risk management, the reports' recommendations turn into questions for the makers of software running on critical machines. Ask whether remote configuration files are cryptographically protected and whether the package hash arrives by a different route from the download address. Ask too whether the client accepts downloads only from pinned domains, whether marketing notifications are kept apart from the logic that launches programs, and whether those notifications reject file:// and UNC paths.

Which design flaw did UNC7017 exploit?

The GTIG and METAL reports show that the integrity of AOMEI's updates rested on whatever the server said at a given moment, so controlling a few minutes was enough for the attacker. In late August a BGP hijack delivered a trojanised Virtualizor update under a valid TLS certificate, another case where an encrypted channel said little about where the content came from.

The known engineering fix is to sign what gets executed and also what decides what gets executed, and to verify it on the client with a key the download server does not hold. AOMEI describes its 8.5.1 change as asymmetric encryption, without saying whether the client verifies a signature. Operationally, an alert about trusted software should be closed using the telemetry from the moment it fired, not by reloading the vendor's URL, a mistake UNC7017's supply chain attacks took advantage of.

Sources and attribution: this analysis draws on the public reports from Google Threat Intelligence Group and Mandiant and from ManageEngine's METAL team, on AOMEI's changelog and on coverage by The Hacker News and BleepingComputer, as available on 20 October 2026. AOMEI is named because its distribution infrastructure was the vector described, and the reports do not attribute the incident to a vulnerability in its products. The attribution to UNC7017 is Google's and may change.

Disclaimer: the KQL queries, indicators and configuration recommendations are for guidance only and must be adapted to each environment and tested before production use. Indicators come from third parties, can go stale and should always be checked against the original sources.