Hackers Hijack AOMEI Updates for Just 5 Minutes to Secretly Install Backdoors

A brief change to AOMEI’s software update system allowed attackers to deliver malware through a trusted update channel.

Google Cloud’s Threat Intelligence Group (GTIG) together with Mandiant discovered that threat actors repeatedly modified AOMEI’s update configuration for short periods between April and July 2026.

Any machine running AOMEI Backupper that checked for updates during those brief windows could receive a malicious download instead of a legitimate update.

The intrusion did not exploit a client-side software vulnerability nor require users to open a suspicious file. Instead, attackers altered two configuration files on AOMEI’s distribution servers, redirecting the updater to attacker-controlled content and using the updater’s notification mechanism to execute the payload.

Victims were observed across multiple sectors and countries, including India, although the total number of affected systems remains unknown.

GTIG and Mandiant tracked the malware chain under the names CROSSROAD and SHINYROAD and attributed the activity to a cluster they call UNC7017.

Initial detection was enabled by telemetry shared from ManageEngine’s Threat Analysis Lab, which noted suspicious behavior in late May. AOMEI told Google it took corrective steps to secure its distribution infrastructure.

Hackers hijack AOMEI software updates

AOMEI’s updater relies on a file named down_html.ini to provide package versioning, checksums and download URLs. A separate file, Notifycfg.ini, controls the notification service and which local programs are launched.

During the observed tampering windows, attackers modified both files so the updater would accept and execute a malicious ZIP archive.

Researchers observed three specific tampering windows: a ten-minute period on May 28, a six-minute period on July 16, and a five-minute period on July 20. After each window the attacker-restored files were returned to their original state.

Because the attacker’s changes were temporary, later inspections of the live update server would often only see the legitimate files, complicating post-incident investigation.

This technique differs from compromises that target software build systems or release artifacts; it is more similar to incidents where attackers tamper with the delivery channel for trusted software releases, such as the Notepad++ update compromise.

Even though the malicious configuration changes were short-lived, any machine that received and executed the altered instructions could remain infected after AOMEI repaired its servers.

In July the attackers also varied their delivery infrastructure: one download was served from a public Google Cloud Storage bucket, earlier deliveries used Alibaba Cloud storage and domains designed to look associated with AOMEI. That shifting delivery topology reduces the effectiveness of simple domain-blocking defenses.

How the malware chain worked

The first-stage component, tracked as CROSSROAD, was distributed as upgrade-now.exe. That loader performed environment checks, could retrieve additional components, created a scheduled task and then removed its own executable.

The scheduled task launched a legitimate Radmin binary every three hours. The Radmin process was started in a folder containing an attacker-supplied DLL named BlkScrDl.dll, which the Radmin executable loaded at startup.

That DLL helped deploy SHINYROAD, a backdoor capable of communicating with attacker-controlled infrastructure. Later activity also involved ADAPTAGENT, a client of the Adaptix command-and-control framework, which was disguised as Nitro PDF software.

Using legitimate administration tools and recognizable product names helps make malicious processes harder to spot among normal activity.

On July 20 the attackers added another capability: they used an invisible one-pixel notification window to force an AOMEI client to request a remote file over WebDAV.

That WebDAV request could cause Windows to send NetNTLMv2 authentication data to an attacker-controlled server without presenting a visible credential prompt to the user. This is a form of credential coercion, where the victim system is induced to authenticate to a remote host.

AOMEI’s server-side fix does not remove malicious files already present on compromised systems. Organizations using AOMEI products should review endpoint and network logs for the campaign period, looking for unusual updater child processes, unexpected scheduled tasks related to Radmin or Nitro, and connections to the indicators listed below.

Investigators should also check cached copies of AOMEI configuration files and proxy or firewall logs, since the live server may now be returning legitimate settings and no longer show the earlier tampering.

The incident highlights a design weakness for update mechanisms: serving an unsigned configuration file that points to HTTPS URLs and including a checksum is not sufficient assurance that an update is authentic.

Google recommends vendors use signed configuration files, cryptographic verification of downloaded payloads, and strict allowlists of domains an updater may contact. Separating promotional or notification pop-ups from code-execution paths can also reduce the risk that a promotional feature is abused to run arbitrary code.

This case mirrors other short-lived supply-chain compromises — for example, a limited-time compromise of a LiteLLM package — and demonstrates that even brief exposure windows can leave a prolonged incident-response workload: identify affected hosts, determine what executed, and evaluate whether credentials or other access were exposed.

Indicators of compromise (IoCs)

Malicious file hashes

Other file and configuration hashes

Network and host indicators

Note: IP addresses and domains are intentionally defanged (for example, [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat-intelligence platforms such as MISP, VirusTotal, or your SIEM.

Update defenses against new malware as soon as it appears. Integrate TI Feeds with data from 16K SOCs.