Hackers have reportedly breached the servers of **AOMEI**, a prominent backup software vendor, to inject malware into its popular **AOMEI Backupper** application. This sophisticated supply chain attack, active between April and July 2026, manipulated the software's update and notification systems to distribute malicious payloads. Researchers at **ManageEngine's Threat Analysis Lab (METAL)**, in collaboration with **Google's Threat Intelligence Group (GTIG)** and **Mandiant**, uncovered and investigated the campaign. The threat actor, identified as **UNC7017**, utilized the compromised infrastructure to push a new malware downloader named **CROSSROAD** and a backdoor dubbed **SHINYROAD**. Organizations in the United States, Australia, India, Singapore, Spain, and Switzerland, spanning IT services, telecommunications, and higher education, were among those affected. **Google** has cautioned that the attacks were opportunistic, potentially impacting any organization that checked for software updates during the brief windows of compromise.  ## Ephemeral Tampering Evades Detection The attacks were first detected on May 28 when **ManageEngine**'s endpoint security software flagged suspicious activity: **AOMEI Backupper** installing the legitimate remote administration tool **Radmin** on systems in two unrelated companies. This behavior was unusual as it was initiated by **AOMEI**'s promotional processes, typically reserved for delivering legitimate content. Initial attempts by researchers to reproduce the attack failed, as the software downloaded legitimate configuration files from **AOMEI**'s servers. Further investigation revealed the attackers' stealthy tactic: they briefly modified two critical configuration files, `down_html.ini` and `Notifycfg.ini`, used by the promotion and notification systems, before quickly restoring them to their original state. - `down_html.ini`: Dictates where **AOMEI Backupper** downloads update packages. - `Notifycfg.ini`: Controls notifications and can trigger content execution on the user's computer. By altering these files, attackers redirected the software to download a malicious ZIP archive and then leveraged the notification mechanism to execute the malware without user interaction. **Google** researchers independently confirmed this execution flow.  Continuous monitoring by **ManageEngine** eventually captured the malicious modifications in real-time on July 16, confirming the compromise. The attackers also manipulated the expected checksums in the update configuration, allowing the malicious archives to bypass the software's file verification checks. Three distinct exposure windows were identified where malicious configuration files were served by **AOMEI**'s systems: * 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) During these brief periods, the **CROSSROAD** downloader and **SHINYROAD** backdoor were installed. **CROSSROAD** performed reconnaissance, downloaded additional components, and established persistence via a scheduled task. **SHINYROAD**, a backdoor leveraging legitimate **Radmin** components, loaded malicious code and established C2 communication, enabling further command execution. During the July 20 attack, **Google** also observed an attempt to steal Windows authentication hashes by forcing the notification system to access an attacker-controlled WebDAV resource through an invisible popup, potentially exposing NTLM hashes for cracking. Attack infrastructure identified included IP address `8.210.84[.]56`, `serv.oss-cn-hongkong[.]aliyuncs.com`, hostnames under `storage-data[.]com`, and the legitimate **Google Cloud Storage** endpoint `storage.googleapis.com`. ## AOMEI's Response and Ongoing Concerns **ManageEngine** first alerted **AOMEI** to suspicious activity on June 7. Initially, **AOMEI** suggested an in-transit interception, which researchers refuted based on evidence of server-side compromise. Upon capturing another attack on July 16, **ManageEngine** provided **AOMEI** with detailed evidence, including file hashes and differences. **AOMEI**'s initial internal review did not find evidence of a breach, but the company indicated plans to migrate affected configuration files to new infrastructure with enhanced logging. **ManageEngine** advised preserving existing evidence and brought in **Mandiant** to assist with the investigation. **AOMEI** later informed researchers that its technical team had upgraded servers, patched potential vulnerabilities, and verified file integrity. **Google** confirmed **Mandiant**'s notification to **AOMEI** on July 17, with a response on July 29 confirming corrective actions. When contacted, **AOMEI** stated its CTO is leading a high-priority internal investigation. However, the company has not confirmed how attackers gained access or if the compromise is fully resolved. **ManageEngine** warns that server-side fixes prevent new infections but do not remove malware already installed on customer machines. Organizations using **AOMEI Backupper** are strongly advised to review indicators of compromise provided by **Google** and **ManageEngine**, looking for suspicious scheduled tasks, unexpected executables in **AOMEI** directories, and connections to attacker-controlled infrastructure.