Skip to main content
Emerging ThreatsMalware & Ransomware

Hackers Breach AOMEI Servers to Spread Malware via Software Updates

Laptop screen shows software update in progress with cityscape visible through window.

Attackers altered AOMEI’s update and notification configuration files for just 21 minutes in three brief windows — May 28, July 16 and July 20, 2026 — but during those short intervals they used the vendor’s own promotion mechanism to deliver malware to customers worldwide.

How the update and notification files were weaponized

Researchers from ManageEngine's Threat Analysis Lab (METAL), Google’s Threat Intelligence Group (GTIG), and Mandiant say the campaign abused two AOMEI configuration files that control update and notification behavior:

  • https://www2.aomeisoftware.com/download/abpopup/down_html.ini — the file that tells AOMEI Backupper where to download update packages
  • https://account.aomeitech.com/Notifycfg.ini — the file that controls notifications and can trigger content to run on the computer

By briefly modifying those files on AOMEI-hosted infrastructure, the attackers redirected the client to download a malicious ZIP archive and then used the notification mechanism to execute the malware without requiring user interaction. The researchers also say the attackers altered the expected checksum in the update configuration so the malicious archive would pass the software’s built-in file verification checks. After each modification the files were restored to their original state within minutes, making the compromise difficult to spot.

The malware: CROSSROAD downloader and SHINYROAD backdoor

Google and ManageEngine attribute the delivered payloads to a threat actor tracked as UNC7017. During the exposure windows AOMEI-hosted configuration files were used to install two families of malicious software:

  • CROSSROAD — a previously unknown downloader. When launched, CROSSROAD performed reconnaissance on the infected host, pulled additional components, and established persistence through a scheduled task.
  • SHINYROAD — a backdoor that leaned on legitimate Radmin components to load malicious code and establish an outbound connection to an attacker-controlled command-and-control server, giving operators the ability to run additional commands and payloads on compromised machines.

On July 20 researchers also observed an additional technique that attempted to expose Windows authentication hashes by forcing the notification system to access an attacker-controlled WebDAV resource through an invisible popup — a technique capable of leaking NTLM hashes to an external collector.

Discovery timeline and the detection chain

ManageEngine first detected anomalous behavior on May 28, 2026, when its endpoint security software observed AOMEI Backupper suddenly installing the legitimate remote administration tool Radmin on two unrelated companies. Initial reproduction attempts by researchers returned only the legitimate configuration files, leading ManageEngine to begin continuous monitoring of AOMEI’s servers.

ManageEngine told BleepingComputer it notified AOMEI about suspicious activity on June 7. When researchers captured a live modification on July 16 they provided AOMEI with original and modified file hashes, file differences, and the altered files. Mandiant notified AOMEI on July 17, and Google’s reporting records that AOMEI responded on July 29 saying it had taken corrective action. The three captured exposure windows identified by the researchers were:

  • May 28: 10-minute window (05:40 – 05:50 UTC)
  • July 16: 6-minute window (08:33 – 08:39 UTC)
  • July 20: 5-minute window (10:35 – 10:40 UTC)

Affected organizations, indicators, and infrastructure

Google and ManageEngine say they identified impacted organizations in the United States, Australia, India, Singapore, Spain, and Switzerland across sectors such as IT services, telecommunications, and higher education. They warned the activity was opportunistic and “could have affected additional organizations that checked for software updates during the brief periods when malicious files were being distributed.”

Researchers published technical indicators including IP addresses and hostnames used during the campaign, among them 8.210.84[.]56, serv.oss-cn-hongkong[.]aliyuncs.com, hostnames under storage-data[.]com, and storage.googleapis.com (a legitimate Google Cloud Storage endpoint). ManageEngine and Google advised organizations using AOMEI Backupper to review published indicators of compromise — including suspicious scheduled tasks, unexpected executables in AOMEI installation directories, and connections to attacker-controlled infrastructure.

AOMEI’s actions and remaining risks

AOMEI told BleepingComputer that its chief technology officer was leading an internal investigation and that the company treated the matter as high priority. The vendor said its technical team upgraded servers, patched potential vulnerabilities, and verified that files hosted on its infrastructure were correct; AOMEI later stated it had taken corrective action. ManageEngine says it connected AOMEI with Mandiant to assist the investigation and advised the vendor to preserve existing evidence before making infrastructure changes.

ManageEngine also emphasized the limits of a server-side fix: “A server-side fix stops new infections; it does not remove the backdoor from machines that received it during an earlier window.” AOMEI did not immediately confirm how attackers gained access to its update infrastructure or whether the reported compromise had been fully resolved.

The campaign’s pattern is notable for its surgical brevity: attackers modified vendor-hosted configuration files just long enough to deliver CROSSROAD and SHINYROAD, then reverted the files. That approach narrowed the exposure windows but left a realistic chance that any customer checking for updates during those minutes received and executed malicious code. Organizations that used AOMEI Backupper are left with specific tasks documented by the investigators: hunt for the published indicators of compromise, look for the persistence artefacts described by researchers, and preserve forensic evidence if tampering is suspected.

Original reporting