Full Report
Attackers repeatedly changed the files that AOMEI Backupper fetches from the vendor's own update servers, in windows of five to ten minutes at a time between May and July 2026, so that any copy of the Windows backup program that checked for an update during one of those windows would download and run a backdoor. Google Threat Intelligence Group, Mandiant, and ManageEngine's Threat Analysis
Analysis Summary
# Incident Report: AOMEI Backupper Update Server Tampering Delivers Backdoor
## Executive Summary
Attackers repeatedly altered the update metadata that AOMEI Backupper fetches from the vendor's own servers, in windows of 5 to 10 minutes between May and July 2026. Any installed copy that checked for updates during those windows downloaded and executed a multi-stage backdoor (CROSSROAD, SHINYROAD) with the privileges of the AOMEI process. AOMEI reports it has fixed its servers, but the fix does not remove the backdoor from machines already affected.
## Incident Details
- **Discovery Date:** Disclosed the week of October 16, 2026 by Google Threat Intelligence Group (GTIG), Mandiant, and ManageEngine's Threat Analysis Lab. The source does not say when the activity was first detected internally.
- **Incident Date:** May 28, 2026 through July 20, 2026 (three confirmed tampering windows; GTIG believes others occurred unobserved).
- **Affected Organization:** Not disclosed. The affected organizations were not named.
- **Sector:** IT services, telecommunications, and higher education.
- **Geography:** 11 countries: Australia, Brazil, India, Pakistan, Portugal, Singapore, South Africa, Spain, Switzerland, Türkiye, and the United States. GTIG says the true number is likely higher. The vendor, AOMEI Technology, is registered in Hong Kong.
## Timeline of Events
### Initial Access
- **Date/Time:**
- May 28, 2026, 05:40–05:50 UTC (10-minute window)
- July 16, 2026, 08:33–08:39 UTC (6-minute window)
- July 20, 2026, 10:35–10:40 UTC (5-minute window)
- **Vector:** Supply chain compromise through tampering with update configuration files hosted on the vendor's update servers. No software vulnerability was exploited, and no user action beyond running the program was required.
- **Details:** Two unsigned, unverified text files control the update and pop-up services:
- `down_html.ini` names the update package to download and the checksum used to verify it. Because the checksum is stored in the same unsigned file, it provides no integrity protection.
- `Notifycfg.ini` controls what the pop-up service displays and what it runs.
Attackers changed these files for a few minutes at a time. Copies that checked in during a window downloaded the attacker's package into the AOMEI folder, and the notification configuration then launched it. Copies that checked outside the windows received clean files, which made the activity hard to detect. Targeting appears opportunistic.
### Lateral Movement
- The visible portion of the source does not describe lateral movement. The article is truncated at the point where it begins discussing which machines passed CROSSROAD's environment checks.
### Data Exfiltration/Impact
- **Impact:** A backdoor was installed across the system. ManageEngine's lab said that on the machines it examined, the malicious payload could install software system-wide, though elevation depended on how the AOMEI service was configured.
- **Data theft:** The visible text does not report data exfiltration. Further details may appear in the truncated portion.
### Detection & Response
- **Detection:** GTIG and Mandiant confirmed the tampering windows from telemetry. ManageEngine's Threat Analysis Lab analyzed the payload. GTIG described the technique as "effectively evading traditional point-in-time triage and automated file scanning."
- **Response:** AOMEI reported fixing its update servers. The source notes that this does not clean already-compromised machines.
## Attack Methodology
- **Initial Access:** Tampering with unsigned update configuration files (`down_html.ini`, `Notifycfg.ini`) on the vendor's update servers during short windows.
- **Persistence:** A scheduled task runs every three hours and launches a signed copy of Radmin, which loads an attacker-built DLL placed beside it. That DLL loads the SHINYROAD implant. The downloader (CROSSROAD) deletes itself after setup.
- **Privilege Escalation:** The payload runs with the privileges of the AOMEI process that launched it. Depending on how the AOMEI service runs, this can allow system-wide installation.
- **Defense Evasion:**
- Time-limited tampering that avoids point-in-time checks.
- Self-deletion of the downloader.
- Abuse of a legitimately signed remote-administration binary (Radmin).
- DLL side-loading through the attacker-built DLL placed beside Radmin.
- Environment checks: CROSSROAD stops if the host is located in China or if particular security agents are present.
- Radmin is staged but not enabled, with no listener, configuration, or new account, so the remote-access path relies on SHINYROAD.
- **Credential Access:** Not described in the visible text.
- **Discovery:** Not described in the visible text.
- **Lateral Movement:** Not described in the visible text.
- **Collection:** Not described in the visible text.
- **Exfiltration:** Not described in the visible text.
- **Impact:** Backdoor installation enabling remote shell access and arbitrary code execution. SHINYROAD can fetch and run new code on command.
## Impact Assessment
- **Financial:** Not disclosed.
- **Data Breach:** Not confirmed in the visible text.
- **Operational:** Compromised systems in IT services, telecom, and higher education were under attacker control. The extent of disruption is not stated.
- **Reputational:** The attack affected a widely used commercial backup product from a single vendor. The campaign was first made public by three security organizations in October 2026. Affected organizations have not been named.
## Indicators of Compromise
- **Network Indicators:**
- SHINYROAD communicates with a single hard-coded address that has no fallback. The address is not included in the visible text. Blocking it cuts off attacker control. Obtain it from the ManageEngine or GTIG reports before blocking.
- Vendor update endpoints: consult the vendor's and researchers' advisories for current details.
- **File Indicators:**
- `down_html.ini` and `Notifycfg.ini` in AOMEI Backupper directories, especially if they reference unexpected packages or commands.
- A local Radmin folder containing a signed Radmin binary alongside an unexpected DLL.
- Malware family names: CROSSROAD (downloader), SHINYROAD (implant). The actor is tracked by GTIG as UNC7017.
- **Behavioral Indicators:**
- AOMEI processes spawning unexpected child processes, especially Radmin.
- Scheduled tasks created in the Radmin folder that run every three hours.
- Radmin loading a DLL from outside its normal installation path.
- Outbound HTTPS to unfamiliar hosts from AOMEI components.
## Response Actions
- **Containment:**
- Identify all systems running AOMEI Backupper, including AnyViewer, which GTIG says uses the same update flow.
- Block the SHINYROAD C2 address once it is obtained from the vendor reports.
- Isolate systems with the indicators above.
- **Eradication:**
- Remove the scheduled task, Radmin folder contents, attacker DLL, and SHINYROAD implant.
- Reinstall AOMEI Backupper from a verified source, or remove it.
- Because AOMEI's server fix does not clean infected hosts, cleanup must be done on each machine.
- **Recovery:**
- Rebuild systems where compromise cannot be ruled out, since the payload ran with elevated privileges.
- Rotate credentials that were present on affected systems.
## Lessons Learned
- **Key Takeaways:**
- Unsigned update metadata with a checksum stored in the same file provides no integrity guarantee.
- Short-lived tampering can evade snapshot-based scanning. Monitoring only at fixed points in time will miss it.
- Legitimately signed tools (Radmin) can carry malicious payloads through side-loading.
- Software with broad system privileges that auto-updates is a high-value supply chain target.
- **What Could Have Been Done Better:**
- Verifying update packages with a cryptographic signature independent of the update manifest would have blocked the payload.
- Restricting the privileges of the update and notification processes would have limited the impact.
- Monitoring for unexpected binaries and scheduled tasks created by backup software would have helped detect the activity sooner.
## Recommendations
- **Software vendors:** Sign update manifests and packages with keys not stored in the update channel. Verify signatures on the client before execution.
- **Endpoint administrators:**
- Inventory AOMEI Backupper and AnyViewer installations and check them against the IOCs above.
- Alert on scheduled tasks that run signed remote-administration tools, and on those tools loading DLLs from unexpected paths.
- Restrict the privileges that third-party updaters run with.
- Apply application allowlisting where feasible.
- **Network defenders:** Monitor and restrict outbound HTTPS from backup and utility software to known vendor destinations, and block the SHINYROAD C2 address once it is available.
- **Incident response:** Hunt across the fleet for the three tampering windows' timeframes using endpoint logs. Treat any system that checked for updates during those windows as potentially compromised, regardless of current file state.