Proprietary · · 53 days
AOMEI update configuration redirected clients to malicious archives
Attackers briefly modified AOMEI update and notification settings, then restored them. Clients polling during the observed windows downloaded and executed payloads leading to the CROSSROAD downloader and SHINYROAD backdoor.
The first attempts to reproduce a suspicious AOMEI update found nothing wrong: the vendor's servers were serving clean content again. ManageEngine's Threat Analysis Lab had already recorded the software launching an unexpected executable on unrelated customers' machines. That mismatch led investigators to watch the delivery service continuously, uncovering an attacker who changed its instructions for minutes at a time and then restored them.
AOMEI Backupper provided backup and disk-cloning functions, while its update and notification components periodically fetched configuration from vendor-controlled addresses. One file specified an archive and its checksum; another controlled what the notification process displayed or executed. METAL's endpoint records showed the normal software extracting content into its own directories before ABNotify.exe launched upgrade-now.exe. The attacker had used the product's trusted delivery sequence to introduce an executable where presentation resources ordinarily belonged.
Continuous monitoring caught a six-minute substitution on July 16. Google Threat Intelligence Group and Mandiant subsequently documented another five-minute window on July 20 and a ten-minute window on May 28. Their investigation attributed the activity to UNC7017 and traced malicious update delivery through the CROSSROAD downloader to the SHINYROAD backdoor. Related malware observations extended into April, but those observations did not establish an April configuration-tampering window.
Google said it notified potentially affected organizations and shared findings with AOMEI, which reported securing its distribution servers. The investigators observed affected organizations across multiple countries and sectors, while acknowledging that their visibility was incomplete. A clean response from the update server after an incident could not establish what an earlier client had received. In this case, endpoint records and captures taken during the short substitutions supplied evidence that a later spot check could not.
Notes
- Disclosed October 15. April is the earliest reported related malware activity; directly observed configuration tampering occurred May 28, July 16, and July 20. Component hashes do not identify the complete update ZIP.
Appendix · Affected releases
References
- Investigating Ephemeral Supply Chain Tamperingcloud.google.com
- AOMEI Backupper supply chain attack — METAL investigationmanageengine.com
Source record: proprietary/aomei-updates/meta.yaml