Adversaries gained unauthorized access to AOMEI's infrastructure and leveraged a promotional feature embedded in AOMEI Backupper to deliver malware, according to findings from ManageEngine's Threat Analysis Lab (METAL), Google's Threat Intelligence Group (GTIG), and Mandiant. The attackers modified configuration files temporarily, then restored them to evade detection.
The intrusions spanned from April through July 2026 and centered on the update and notification mechanisms powering AOMEI Backupper, a Windows tool designed for data backup, disk cloning, and system recovery. Researchers attribute the campaign to UNC7017, a tracked threat actor who deployed two previously undocumented pieces of malware: the CROSSROAD downloader and the SHINYROAD backdoor.
Victim organizations span the United States, Australia, India, Singapore, Spain, and Switzerland across IT services, telecommunications, and higher education sectors. Google cautioned that the nature of the attacks—opportunistic in scope—means additional organizations may have been compromised during the windows when malicious files were available for download.
Attack mechanics
ManageEngine's endpoint security tools first flagged the campaign on May 28 after observing AOMEI Backupper unexpectedly installing the legitimate remote administration utility Radmin across machines at two separate organizations in different countries. The installation originated from AOMEI's promotion subsystem, which ordinarily manages promotional downloads and on-screen notifications.
When researchers attempted to replicate the suspicious behavior in controlled environments, they encountered no malicious activity. The software queried AOMEI's servers and retrieved a legitimate configuration file instead. Deeper investigation revealed that attackers had not permanently altered files on AOMEI's infrastructure; rather, they made transient modifications to two configuration files governing the promotion and notification workflows:
https://www2.aomeisoftware.com/download/abpopup/down_html.ini https://account.aomeitech.com/Notifycfg.ini
The down_html.ini file specifies where AOMEI Backupper retrieves update packages. The Notifycfg.ini file manages notifications and possesses the capability to trigger code execution on target systems. By tampering with these files, the threat actors redirected the software toward a malicious ZIP file and exploited the notification mechanism to run the malware without user involvement.
Google researchers independently validated this execution pathway through their own testing. After initial reproduction attempts failed, ManageEngine deployed continuous surveillance of AOMEI's servers. On July 16, this monitoring successfully captured the malicious file modifications in real time, confirming that AOMEI's infrastructure was distributing compromised content.
The attackers also altered the expected checksum value in the update configuration, enabling the malicious archive to bypass the software's built-in file integrity verification.
Google and ManageEngine documented three distinct time windows during which AOMEI's servers delivered the malicious configuration:
- May 28: 10-minute exposure (05:40 – 05:50 UTC)
- July 16: 6-minute exposure (08:33 – 08:39 UTC)
- July 20: 5-minute exposure (10:35 – 10:40 UTC)
The attackers restored the configuration files to their unmodified state within minutes, complicating forensic detection. During these brief windows, the malicious configuration distributed CROSSROAD and SHINYROAD.
Upon execution, CROSSROAD performed reconnaissance on the infected system, fetched additional components, and established persistence via a scheduled task. SHINYROAD functions as a backdoor that leverages legitimate Radmin components to load malicious code and initiate outbound connections to attacker infrastructure, granting the adversary the ability to execute commands and deploy additional payloads on compromised machines.
During the July 20 intrusion, Google also detected a secondary technique aimed at harvesting Windows authentication hashes. The attackers forced AOMEI's notification system to contact an attacker-controlled WebDAV endpoint through a hidden popup window, potentially exposing NTLM hashes that could be collected and later cracked.
Researchers catalogued multiple IP addresses and hostnames leveraged in the attacks: 8.210.84[.]56, serv.oss-cn-hongkong[.]aliyuncs.com, hostnames under storage-data[.]com, and storage.googleapis.com, a legitimate Google Cloud Storage service.
AOMEI's response and investigation
ManageEngine notified AOMEI of the suspicious activity on June 7, more than a month before researchers directly observed malicious files being served from AOMEI's servers. Initially, AOMEI proposed that the content had been intercepted and altered during transit—a theory the researchers rejected.
The evidence did not support AOMEI's explanation of interception in transit. Both endpoints had retrieved the content over HTTPS from AOMEI-owned hostnames, across different countries and unrelated network paths, and the executable had arrived through the application's own extraction sequence rather than being written directly to disk by an external process. The content had been altered before it reached either endpoint, within the vendor-hosted delivery path.
ManageEngine's report
When ManageEngine captured a second attack on July 16, it immediately furnished AOMEI with the original and modified file hashes, file differences, and the altered files themselves. AOMEI engaged with the findings and conducted its own review, subsequently informing ManageEngine that its initial examination uncovered no evidence of a breach.
AOMEI indicated plans to migrate the affected configuration files to fresh infrastructure with enhanced logging capabilities. ManageEngine advised AOMEI to preserve existing evidence prior to those changes and to engage incident-response specialists, facilitating a connection with Mandiant to support the investigation.
AOMEI later reported that its technical team had upgraded its servers, patched potential vulnerabilities, and confirmed the integrity of files hosted on its systems. Google's report notes that Mandiant notified AOMEI about the configuration file tampering on July 17, and the company responded on July 29th, confirming it had implemented corrective measures.
When BleepingComputer reached out to AOMEI regarding the research findings, the company characterized the matter as high priority with its chief technology officer spearheading an internal investigation. "We have also internally detected this report and have classified it as a high-priority matter. Our CTO is currently leading a dedicated investigation to ensure accurate issue identification," AOMEI stated.
AOMEI committed to providing a more comprehensive response about the incident and investigation status, with BleepingComputer pledging to update coverage upon receipt of additional details. The company has not yet disclosed how attackers obtained access to its update infrastructure or whether the compromise has been fully remediated.
Despite AOMEI's assertion that its servers are now secure, ManageEngine emphasized that server-side remediation does not eliminate malware already installed on customer systems. "A server-side fix stops new infections; it does not remove the backdoor from machines that received it during an earlier window," ManageEngine cautioned.
Organizations deploying AOMEI Backupper should examine the indicators of compromise disclosed by Google and ManageEngine, which include suspicious scheduled tasks, unexpected executable files within AOMEI installation directories, and communications directed toward attacker-controlled servers.