AOMEI Backupper Backdoor: Update Servers Tampered With for Minutes at a Time

For roughly ten minutes on 28 May 2026, the update files that AOMEI Backupper fetches from AOMEI’s own servers were not the files AOMEI had put there. Any copy of the Windows backup program that checked for an update in that window downloaded a backdoor. Then the files reverted. That is the AOMEI Backupper backdoor story in one paragraph, and the timing is the clever part.

How the AOMEI Backupper backdoor worked

No software flaw was exploited. According to Google Threat Intelligence Group and Mandiant, the attackers changed two configuration files on the vendor’s update servers: down_html.ini, which tells the program which package to download, and Notifycfg.ini, which controls the pop-up content and what runs.

The program trusted both. The checksum that was meant to protect the download sat inside the same unauthenticated file it was supposed to validate. Change the file, change the checksum, and the installed software accepts the lot.

The confirmed windows were short:

• 28 May: 05:40 to 05:50 UTC, about ten minutes.
• 16 July: 08:33 to 08:39 UTC, about six minutes.
• 20 July: 10:35 to 10:40 UTC, about five minutes.

Google says tampering reached back to April and that other windows probably went unseen. It described the technique as “effectively evading traditional point-in-time triage and automated file scanning.”

Why a few minutes is enough

Backup software runs on a schedule. It sits on many machines and often has high privileges. Across a few hundred installs, a handful will check for updates in any given five-minute slice. That is all an opportunistic attacker needs.

It also breaks the usual response. If your security tool flags something and an analyst opens the vendor’s download page to check, they see clean files. ManageEngine’s Threat Analysis Lab warns against exactly that. The evidence only exists in the logs from the moment of the alert.

What landed on the machines

The chain starts with an unsigned dropper called upgrade-now.exe. It carries AOMEI publisher details, and its product string is misspelled “AOMEI Update Compent”. It runs from the program’s html folder, which a normal update would never use.

From there, ManageEngine found a genuine copy of the Radmin remote administration tool installed with no configured credential. A scheduled task called RadminComponentRuntime reruns the chain every three hours. A signed Radmin file then side-loads a malicious DLL that hosts the implant, which Google calls SHINYROAD. It gives the operator a remote shell and can fetch more code.

Google also saw the open-source Adaptix framework pushed to some machines, disguised as Nitro PDF software. The loader skips machines in China and halts if certain security agents are present.

The 20 July twist

The third window used a different trick. The notification file was edited to open an invisible one-pixel pop-up that pointed at an attacker-controlled WebDAV share. A Windows machine that follows that path can hand over a NetNTLMv2 authentication response without running any program at all. Those responses can be cracked offline or relayed.

Who was hit

The AOMEI Backupper backdoor hit victims in IT services, telecommunications and higher education across 11 countries, including Spain, Portugal, Switzerland and the United States. The UK is not on the list, but the list is a floor. Google says the real number is likely higher, and it described the targeting as opportunistic. The actor is tracked as UNC7017, with no country attributed.

The timeline is uncomfortable. ManageEngine’s endpoint software first flagged the Radmin install on 28 May and notified AOMEI on 7 June. Mandiant contacted AOMEI on 17 July. AOMEI told Mandiant on 29 July that it had taken corrective action. ManageEngine has not independently confirmed that the servers are clean, and neither report says how the attackers got access to them.

What to check this week

If you run AOMEI Backupper, treat each machine as a hunting target for April to July. The same goes for AnyViewer, which Google says uses the same update flow. A server-side fix does not clean a machine that already took the payload.

• Look for the scheduled tasks RadminComponentRuntime and NitroRuntime.
• Search for unsigned executables inside the program’s html folder.
• Block outbound SMB (TCP 445) and WebDAV to the internet. That alone defeats the credential trick.
• Block the published indicators, including the three storage-data domains listed in Google’s write-up.
• Check that endpoint policies are enforcing, not only alerting. ManageEngine says the affected environments were in audit mode and logged the activity without stopping it.

The bigger point is about trust, and the AOMEI Backupper backdoor is a clean example. Plenty of business software updates itself from a vendor server without proof of who wrote the file. A software supply chain attack checklist should include a plain question for every tool: what stops a bad update being accepted? A penetration test that covers your endpoint tooling and outbound filtering will show quickly which answers are guesses.