Skip to content

AOMEI Backupper update servers hijacked to push a backdoor

GTIG and ManageEngine say attackers tampered with AOMEI Backupper's update files in minutes-long windows from May to July 2026, delivering the SHINYROAD backdoor. No fixed version yet.

Published 4 min read

Attackers repeatedly tampered with the update files that AOMEI Backupper — a Windows backup and disk-cloning tool — pulls from its vendor's servers, delivering a backdoor to any copy that happened to check for updates during short tampering windows between May and July 2026. No vulnerability was exploited: AOMEI's updater does not cryptographically verify what it downloads. If you run AOMEI Backupper (or AnyViewer, which shares the update flow), assume you may have been served a malicious update and hunt accordingly — a server-side cleanup does not clean an already-infected host.

The findings come from Google Threat Intelligence Group (GTIG) / Mandiant and ManageEngine's Threat Analysis Lab, reported by The Hacker News.

How the compromise worked

The program fetches two files over HTTPS — down_html.ini (names the update package and its checksum) and Notifycfg.ini (controls the pop-up service and what it runs). Neither is signed, and the checksum sits inside the same unsigned file that names the download. By swapping those files for minutes at a time, the attacker served malware to any client that updated during the window; clients that checked outside it got genuine files.

The chain, per GTIG:

  • CROSSROAD — a downloader that unpacked a bundle into a local Radmin folder, created a scheduled task running every three hours, and deleted itself.
  • A malicious DLL side-loaded by a genuine, signed copy of Radmin, which in turn loaded SHINYROAD — an implant giving a remote shell and arbitrary code execution over a single hard-coded C2 address.
  • On some hosts, Adaptix C2 was pushed on top of SHINYROAD, disguised as Nitro PDF software.
  • A July 20 variant opened an invisible pop-up pointing at an attacker WebDAV server, leaking a user's NetNTLMv2 response without running any program.

Timeline and scope

GTIG and ManageEngine confirmed three tampering windows and said more likely occurred unseen:

  • May 28, 2026, 05:40–05:50 UTC (10 min)
  • July 16, 2026, 08:33–08:39 UTC (6 min)
  • July 20, 2026, 10:35–10:40 UTC (5 min)

ManageEngine first caught it on May 28 when its endpoint software saw AOMEI Backupper installing Radmin on two unrelated customers; Mandiant notified AOMEI on July 17, and AOMEI reported corrective server-side action on July 29. GTIG found affected organizations in IT services, telecoms, and higher education across 11 countries and said the real number is likely higher. Notably, neither report lists an affected or fixed Backupper version — AOMEI's changelog through 8.5.0 (October 9) shows no change to update verification. Treat the tracked actor, UNC7017, as unattributed; GTIG names no country and describes the targeting as opportunistic.

Indicators (per GTIG / ManageEngine, via The Hacker News)

Domains:          storage-data[.]com
                  promotion.storage-data[.]com
                  aomei.storage-data[.]com
IPs:              8.210.84[.]56
                  8.218.65[.]184
                  47.239.60[.]117
Scheduled tasks:  RadminComponentRuntime
                  NitroRuntime
Files/paths:      unsigned upgrade-now.exe carrying AOMEI publisher details;
                  attacker files staged under the local Radmin app-data folder

GTIG published YARA and ManageEngine published Sigma rules in their reports; pull those verbatim from the source rather than any paraphrase.

What to do today

  1. Hunt April–July 2026. The reports recommend a hunt window wider than the confirmed tampering, because infected hosts look normal — the downloader restored the genuine update file after running.
  2. Check for the artifacts above. The RadminComponentRuntime/NitroRuntime scheduled tasks and the listed domains/IPs are the highest-signal indicators.
  3. Block egress. Block the listed domains and IPs, and block outbound SMB (TCP 445) and external WebDAV to neutralize the July 20 credential-leak trick.
  4. Preserve, don't wipe first. Keep cached files in the program's folders and network logs for what was served when an alert fired before remediating.
  5. Reconsider the updater. Until AOMEI ships verified updates, the update channel itself is the risk. Isolate or remove the software on sensitive hosts.

Context

This is update-channel tampering, not a package-registry poisoning — the same shape as the 3CX and SolarWinds compromises, where trusted auto-update was the delivery mechanism. It lands amid a steady run of supply-chain intrusions we've tracked, including the recent Laravel Lang credential stealer. The recurring failure here is specific and fixable: an updater that ships an unsigned manifest with a self-referential checksum is trusting the network it should be verifying against.

Related stories