Hackers briefly hijacked AOMEI Backupper's update infrastructure between April and July 2026, using a promotional-content feature to push malware onto machines running the backup tool. For any UK organisation relying on AOMEI, this is a backup supply chain attack that demands immediate, methodical verification — not just a patch.
View the data behind this chart
| 28 May | 16 Jul | 20 Jul | |
|---|---|---|---|
| Exposure window | minutes10 | minutes6 | minutes5 |
What actually happened
According to BleepingComputer's reporting, researchers at ManageEngine's Threat Analysis Lab (METAL), working with Google's Threat Intelligence Group and Mandiant, identified a threat actor tracked as UNC7017 tampering with two configuration files hosted on AOMEI's own servers — down_html.ini, which tells AOMEI Backupper where to fetch updates, and Notifycfg.ini, which controls pop-up notifications and can trigger content execution.
Rather than permanently compromising files, the attackers altered them for short windows, then restored the originals — a technique designed specifically to defeat routine vendor checks. Google and ManageEngine confirmed three confirmed exposure windows: 28 May (10 minutes), 16 July (6 minutes) and 20 July (5 minutes), each used to serve a malicious ZIP archive with a spoofed checksum in place of a genuine update.
Why this is a backup supply chain problem, not just a malware alert
This is exactly the scenario that makes backup and disaster recovery solutions procurement decisions so consequential: the compromise didn't exploit a vulnerability in the backup logic itself, it exploited the trust relationship between the software and its own update mechanism. A tool organisations installed specifically to protect data integrity became, for a handful of minutes at a time, the delivery vehicle for a downloader (CROSSROAD) and a backdoor (SHINYROAD) that abused legitimate Radmin remote-access components to open outbound command-and-control connections.
Affected organisations spanned IT services, telecommunications and higher education across the US, Australia, India, Singapore, Spain and Switzerland. Google explicitly warned the campaign was opportunistic — any organisation checking for updates during those brief windows could have been caught, regardless of sector or location, which means UK AOMEI users cannot assume absence from the named country list equals safety.
The second technique UK buyers should take seriously
During the 20 July window, Google observed a separate technique in which AOMEI's notification system was forced to reach an attacker-controlled WebDAV resource through an invisible pop-up — a method capable of harvesting Windows NTLM authentication hashes for later offline cracking. For enterprises and MSPs managing domain-joined endpoints, this raises the stakes beyond a single infected machine: a stolen hash can become a foothold for lateral movement well after the original malicious file has been removed.
Immediate actions for UK MSPs and enterprises running AOMEI
- •Check AOMEI Backupper deployment logs for unexpected installations of Radmin, particularly around 28 May, 16 July and 20 July 2026 (UTC timestamps 05:40–05:50, 08:33–08:39 and 10:35–10:40 respectively).
- •Hunt for outbound connections to the indicators named in the research: 8.210.84[.]56, serv.oss-cn-hongkong[.]aliyuncs.com, and hostnames under storage-data[.]com; note that storage.googleapis.com is a legitimate Google Cloud Storage endpoint and traffic there is not automatically malicious.
- •Treat any machine with suspicious activity as potentially compromised beyond the original infection — a server-side fix from AOMEI does not retroactively remove malware already delivered to endpoints, per ManageEngine's warning.
- •Rotate credentials for any domain accounts active on endpoints during the exposure windows, given the NTLM hash-theft technique observed on 20 July.
- •Engage incident response services if evidence of compromise is found, rather than relying solely on removing the malicious binary.
The wider lesson: don't let one vendor become a single point of failure
AOMEI's own handling of this incident is instructive for procurement teams. ManageEngine says it first flagged suspicious activity on 7 June, more than a month before researchers directly captured malicious files being served, and that AOMEI's initial response pointed to interception in transit — an explanation the researchers say the evidence did not support, since content was altered within the vendor-hosted delivery path itself, not en route. AOMEI has since said its CTO is leading a dedicated investigation and describes the matter as high priority, but has not confirmed how attackers gained access or whether the compromise is fully resolved.
That gap between first notification and public confirmation is the real takeaway for buyers: resilience planning cannot depend on a vendor's self-reported assurance alone. Architectures built around the 3-2-1-1-0 backup rule and immutable backups limit the blast radius when a backup vendor itself becomes the attack vector, because a compromised update channel cannot alter data already locked in an immutable, offline, or air-gapped copy. Organisations weighing whether to consolidate around a single backup platform should use a backup and DR sizing calculator to model recovery options that don't hinge on one vendor's update infrastructure staying clean, and compare platforms such as Veeam on how update integrity and verification are handled.
What to watch next
BleepingComputer notes AOMEI has not yet confirmed the initial access vector or whether remediation is complete, and says it will update as AOMEI's CTO provides further detail. UK buyers should treat this as an open investigation, keep monitoring for indicators, and avoid assuming the threat ended when the configuration files were restored — the exposure windows were brief, but the backdoors they delivered were built for persistence.