AOMEI Update Channel Hijacked in Minutes-Long Windows to Drop Backdoors

Attackers did not need a vulnerability or a phishing email to compromise AOMEI Backupper users this year. They borrowed the vendor's own update channel for a few minutes at a time, and any machine that checked for updates during one of those windows downloaded malware.

What happened

Google Threat Intelligence Group (GTIG) and Mandiant tracked the activity to a cluster they call UNC7017. Between April and July 2026, the attackers repeatedly changed two configuration files on AOMEI's distribution servers, then put the originals back:

• down_html.ini tells the client which version is current, what checksum to expect and where to download it from.
• Notifycfg.ini controls the notification feature, including which local programs it launches.

During each window, the tampered files pointed clients to a malicious ZIP archive and used the notification mechanism to run it. The confirmed windows were short: about ten minutes on May 28, six minutes on July 16 and five minutes on July 20. ManageEngine's Threat Analysis Lab first flagged suspicious behaviour in its telemetry in late May. AOMEI has told Google it took corrective action to secure its distribution servers.

Victims were reported across several sectors and countries, including India. The total number of affected systems is not known.

How the chain worked

• CROSSROAD (first stage, delivered as upgrade-now.exe) profiles the host, halts on systems whose public IP geolocates to China, restores the clean vendor configuration to cover its tracks, pulls further files, registers a scheduled task and deletes itself.
• The scheduled task starts a legitimate Radmin binary every three hours. A malicious BlkScrDl.dll placed next to it is side-loaded at startup.
• That DLL loads SHINYROAD, a backdoor that talks to attacker infrastructure.
• Later activity added ADAPTAGENT, a client for the Adaptix command-and-control framework, disguised as Nitro PDF software.
• On July 20 the attackers also used an invisible one-pixel notification window to make the AOMEI client fetch a remote file over WebDAV. That can cause Windows to send NetNTLMv2 authentication material to an attacker-controlled host.

Payload hosting moved over time, from Alibaba Cloud storage and look-alike AOMEI domains to a public Google Cloud Storage bucket in July. That makes simple domain blocklists unreliable.

Why it matters

Two details make this campaign hard to deal with:

1. The evidence disappears from the server, but the infection stays on the endpoint. Anyone who inspects the update server afterwards sees only clean files. A host that pulled the payload during a five-minute window stays compromised until someone cleans it.
2. HTTPS plus a checksum is not proof of authenticity. If the checksum comes from an unsigned configuration file the attacker can edit, the updater will check the malicious package against the attacker's own value and accept it.

The approach resembles other recent supply-chain incidents: compromise the trusted delivery path instead of the product itself, and keep the exposure window short.

What to do

• Find AOMEI installs. Inventory AOMEI Backupper and related AOMEI tools across your fleet, servers included.
• Hunt in historical telemetry, not only on the live server. For April–July 2026, look for unusual child processes of the AOMEI updater and notifier (Backupper.exe, ABNotify.exe), files named upgrade-now.exe / upgrade-now.zip, and unexpected scheduled tasks that launch Radmin or Nitro-named binaries.
• Check for DLL side-loading. Look for BlkScrDl.dll or other unsigned DLLs next to legitimate Radmin or Nitro binaries in user-writable paths.
• Review cached config and network logs. Compare cached down_html.ini / Notifycfg.ini copies on endpoints with known-good versions. Check proxy and firewall logs for update downloads from cloud storage buckets, and for outbound WebDAV/SMB authentication to the internet.
• Treat credentials as exposed on any confirmed host. Rotate them, and block outbound NTLM to external destinations where you can.
• Match against the published IoCs. GTIG/Mandiant have released file hashes and network indicators. Load them into your EDR and SIEM.
• Vendors: sign update configuration files as well as binaries, verify signatures on downloaded packages, pin updater egress to a short allow-list of domains, and keep promotional or notification features separate from anything that can execute code.

For software you build and ship yourself, these flaws are best caught in review before release: an unsigned config file that controls where updates come from, or a notifier that can launch arbitrary programs. 4tify's AI-assisted code review looks for that class of trust-boundary weakness in update and distribution logic before attackers find it.

Research credit: Google Threat Intelligence Group (GTIG) and Mandiant. Reported by Cyber Security News.