It is a software supply chain compromise: no flaw in the program was used. Google Threat Intelligence Group and Mandiant say each window lasted only 5 to 10 minutes, and they track the actor as UNC7017.
What happened
ManageEngine’s Threat Analysis Lab says its tools saw AOMEI Backupper install Radmin remote administration software on a customer computer on 28 May 2026. A second customer in another country showed the same chain. Together with Google Threat Intelligence Group and Mandiant it traced the cause to the backup program’s own update settings.
Google and Mandiant say attackers changed those settings on the vendor’s servers three times that they saw directly: on 28 May, 16 July and 20 July 2026. Each window lasted 5 to 10 minutes before the files went back to their real versions. Any copy of the program that checked for updates in that time could be sent to attacker files. Google says it is the first time it has met a software supply chain compromise with such short windows.
Google also reports that on 20 July the attackers added a hidden pop-up that could make computers send network login material to a server they controlled. Impacted organizations, it says, were in IT services, telecommunications and higher education across Australia, Brazil, India, Pakistan, Portugal, Singapore, South Africa, Spain, Switzerland, Türkiye and the United States.
Timeline
- April 2026
Google and Mandiant say the tampering dates back to this month.
- 28 May 2026
Tampering window of about 10 minutes. ManageEngine's tools see Radmin installed by AOMEI Backupper on a customer computer.
- 7 June 2026
ManageEngine raises the alert with AOMEI.
- 16 July 2026
Window of about 6 minutes, caught live by ManageEngine's monitor.
- 17 July 2026
Mandiant notifies AOMEI and shares indicators.
- 20 July 2026
Window of about 5 minutes. The attackers add a hidden pop-up that can send network login material to their server.
- 29 July 2026
Google says AOMEI replied that it had taken corrective action.
- 15 October 2026
Google Threat Intelligence Group and Mandiant publish their report.
- 16 October 2026
ManageEngine's Threat Analysis Lab publishes its report.
How the attack worked
This is a compromise of the software supply chain (T1195.002). No flaw in the program was used. Both researchers say the problem is that the update settings files were not cryptographically checked, and that the checksum that should prove a download is genuine sat in the same unsigned file as the download address.
- During a window, the attacker changed the settings so that the update pointed to a package on attacker-controlled hosting.
- The backup program fetched the package and ran an unsigned program with AOMEI-looking details, the CROSSROAD downloader.
- CROSSROAD checked the computer’s location and security tools, installed Radmin software and created a scheduled task that ran every three hours (T1053).
- The task started the signed Radmin launcher, which loaded a harmful library placed beside it (DLL hijacking, T1574.001). That library started the SHINYROAD backdoor.
- At the end of each window the settings went back to normal, which Google says makes later checks by the vendor harder.
A separate October 2026 case reached customers through stolen remote management keys: see the UpdraftCentral key compromise, where Patchstack reported backdoor plugins installed on connected WordPress sites.
ATT&CK techniques
- Technique Compromise Software Supply Chain Compromise Software Supply Chain is a way for attackers to reach many computers through software they already trust. T1195.002 · Initial Access
- Technique DLL DLL hijacking is when an attacker abuses the shared library files (DLLs) that Windows programs load. T1574.001 · Stealth, Execution
- Technique Ingress Tool Transfer Ingress Tool Transfer is a technique where attackers bring tools or other files from outside into a network they have already broken into. T1105 · Command and Control
- Technique Scheduled Task/Job Scheduled Task/Job is a technique where an attacker uses the task scheduling feature built into an operating system. T1053 · Execution, Persistence, Privilege Escalation
Who says who was behind it
Attributed by Google Threat Intelligence Group and Mandiant, 15 October 2026: they track the activity as UNC7017, a cluster that is not tied to a named group or country. ManageEngine's Threat Analysis Lab, which first found the activity, uses the same names in its report of 16 October 2026.
No government body has attributed or described these attacks in the sources we opened.
AOMEI has published no security notice that we could find. Its changelog (version 8.5.0 listed on 19 October 2026) and the pages we tried say nothing about the incident. What we know about its reaction comes from the researchers: Google says Mandiant told AOMEI on 17 July and AOMEI replied on 29 July that it had taken corrective action. ManageEngine says that on 7 June AOMEI first explained that the content had been intercepted and changed in transit, which the researchers say the evidence did not support, and that it has not verified AOMEI's fix.
This case is separate from CVE-2026-12780, a local driver flaw in the same product family.
Malware and vulnerabilities used
- Malware CROSSROAD downloader CROSSROAD is the name Google Threat Intelligence Group and Mandiant give to a downloader used in a 2026 tampering of AOMEI Backupper updates. Loader · Since 2026 · Windows
- Malware SHINYROAD backdoor SHINYROAD is the name Google Threat Intelligence Group and Mandiant give to a backdoor installed after a tampered AOMEI Backupper update in 2026. Remote access trojan · Since 2026 · Windows
Impact
The number of affected computers has not been published. Google says the targeting was opportunistic because every computer that checked for updates in a window was exposed, and that the real reach "likely extends more broadly" than the organizations it saw. ManageEngine says the backdoor could run commands and new code, but it saw no live session. Credential material may have leaked through the pop-up even on computers where the backdoor did not run.
Government and regulator response
- Researchers: ManageEngine told AOMEI on 7 June 2026. Mandiant told AOMEI on 17 July and shared indicators.
- Vendor: Google says AOMEI replied on 29 July 2026 that it had taken corrective action. AOMEI has published no security notice that we could find.
- Both reports: they warn that fixing the servers does not clean computers that already ran the file, so each one needs checking.
Lessons
-
A clean check proves little
The vendor address returned real files most of the time. Testing an alert later said nothing about what was delivered earlier.
-
Updates need signatures
The settings files and their checksum came from the same unsigned place. Both researchers advise signing configuration files, not only programs.
-
Marketing and updates should be apart
The pop-up system let remote content start programs. Google advises keeping promotional pop-ups away from core updates.
-
Vendor fixes do not clean computers
Computers that ran the file keep their scheduled task and backdoor until someone removes them.
What to check in your own organization
-
Scheduled task
Check whether any computer has a scheduled task named RadminComponentRuntime.
-
Unexpected Radmin
Check for Radmin software that nobody installed, and for unsigned libraries beside its launcher.
-
Look-back window
Review proxy and firewall logs from April to July 2026 for AOMEI Backupper update traffic to unusual hosts.
-
Outbound SMB and WebDAV
Check that file-sharing traffic (port 445) and WebDAV to outside addresses is blocked at the edge.
-
Credential reset
Where the credential pop-up may have run, reset passwords for accounts used on those computers.
-
Update allow list
Check which hosts each of your backup and remote tools may fetch updates from.
Frequently Asked Questions
What happened to AOMEI Backupper?
Google Threat Intelligence Group and Mandiant say attackers changed its update settings for 5 to 10 minutes at a time between April and July 2026, so that the program fetched a backdoor.
Did the attackers use a flaw in the software?
No. ManageEngine and Google say the update settings were not cryptographically checked, so no flaw was needed.
Has AOMEI made a public statement?
We found none. Google says AOMEI told Mandiant on 29 July 2026 that it had taken corrective action.
Is this the same as CVE-2026-12780?
No. That is a separate local driver flaw. The update tampering used no vulnerability.
Am I safe now that the servers are fixed?
Not necessarily. Google says a computer that ran the file can keep the backdoor, so check for the scheduled task and unexpected Radmin software.
Sources
- Investigating Ephemeral Supply Chain Tampering (15 October 2026)Google Threat Intelligence Group and Mandiant
- AOMEI Backupper Supply-Chain Compromise (16 October 2026)ManageEngine Threat Analysis Lab
- Supply Chain Compromise: Compromise Software Supply Chain, T1195.002MITRE ATT&CK
- AOMEI Backupper changelogAOMEI Technology
