A trusted updater became a delivery route
A backup utility should not become the reason you need an incident-response plan. Yet that is the risk raised by reports that attackers briefly modified configuration files on AOMEI-operated servers used by Backupper and AnyViewer. Clients checking those files during the tampering windows could be redirected to malicious downloads and prompted to execute content through the software’s own notification mechanism. BleepingComputer
The distinction matters. This was reported as abuse of the update path, not a newly discovered software vulnerability. Cloud Security Alliance’s account says the client trusted unsigned configuration files, and the checksum used to validate the download was carried in the same unsigned configuration. HTTPS can protect a connection to a server; it cannot establish that the server itself is serving trustworthy content. CSA
Short windows, persistent consequences
The chronology needs to be read carefully. Google’s threat-intelligence reporting, as described by BleepingComputer and summarized by CSA, identified three periods in 2025 when malicious configuration was served: May 28, 05:40–05:50 UTC; July 16, 08:33–08:39 UTC; and July 20, 10:35–10:40 UTC. The reported durations were ten, six, and five minutes, respectively. The files were restored within minutes, so a later check of the same URLs could show only legitimate content. BleepingComputer CSA
That is not a reason to treat the incident as minor. It is a reason to distrust a clean snapshot taken after the event. A client that polled in one of those windows could receive a malicious archive, and the altered checksum could allow it through the product’s file-verification check. A server-side correction prevents further delivery through the same tampered files; it does not remove software already installed on customer systems. BleepingComputer CSA
What the reported chain did
The two configuration files served different purposes. BleepingComputer reports that down_html.ini directed Backupper to update packages, while Notifycfg.ini controlled notifications and could trigger content to run. The attackers reportedly changed both: the first redirected the download, and the second supplied a notification path that caused execution without a user clicking through a conventional installer prompt. BleepingComputer
CSA’s technical account describes the downloaded chain as a downloader called CROSSROAD, followed by a backdoor named SHINYROAD delivered inside a trojanized copy of Radmin. The report says SHINYROAD could provide an interactive remote shell. Its persistence depended on a scheduled task created by the earlier stage; the backdoor itself did not provide persistence. That nuance is useful during hunting: looking only for a persistent malware service would miss the reported mechanism. CSA
The reports also describe different activity during the July 20 window, including a WebDAV-based authentication coercion technique. That is a reason to examine outbound connections and authentication events, not to assume every affected client followed an identical path. The details available in the reporting should guide investigation, but they do not establish that every polling device was infected or that every infected device received the same follow-on activity. CSA
Detection came from watching the channel
The short duration helps explain why continuous observation mattered. BleepingComputer says ManageEngine began monitoring AOMEI’s delivery servers after its initial analysis failed to reproduce the activity. That monitoring captured the July 16 modification as it happened. Google subsequently confirmed the execution flow in its own testing and reported that Mandiant notified AOMEI on July 17. BleepingComputer
CSA reports that AOMEI told Mandiant on July 29, 2025 that it had taken corrective action to secure its servers. BleepingComputer also quotes AOMEI describing the matter as high priority and saying its CTO was leading an internal investigation. The public reporting does not establish how the attackers gained write access to the infrastructure. Nor should the server response date be confused with the earlier 2025 exposure windows: stopping a route and determining what happened on endpoints are separate jobs. CSA BleepingComputer
What defenders should check now
Start by identifying every system running Backupper or AnyViewer, including installations outside the managed software inventory. Then use the indicators and detection guidance published by Google and ManageEngine, as reported by BleepingComputer, and the technical artifacts described by CSA. The reports call attention to unexpected scheduled tasks and files associated with the Radmin and Nitro directories, suspicious unsigned DLLs alongside signed executables, and AOMEI update artifacts such as upgrade-now.exe or upgrade-now.zip. Preserve relevant evidence before cleanup; cached configuration files may help reconstruct what a client received. BleepingComputer CSA
Review endpoint, DNS, and proxy records covering all three verified 2025 periods, not just the day the report became public. Search for unexpected child processes, newly created scheduled tasks, suspicious DLL loads, and connections matching the published indicators. If logs show an affected host communicating with the reported WebDAV infrastructure, investigate authentication attempts and accounts that may have supplied credentials. The cited reports recommend reviewing and resetting credentials where appropriate; treat confirmed compromise as more than a stray file to delete. CSA
A server-side fix is not endpoint remediation. For confirmed infections, follow incident-response procedures to preserve evidence, contain the host, assess credentials and repositories it could reach, and rebuild from known-good media where warranted. Backup software can hold privileged access to data and repositories, so its compromise deserves a hard look at the surrounding environment. BleepingComputer CSA
Make the update mechanism part of the review
The practical lesson is not to stop using every updater. It is to ask what the updater actually trusts. Where feasible, route third-party updates through managed distribution, restrict unnecessary outbound access, and alert when signed programs load unsigned libraries from user-writable locations or create scheduled tasks from update directories. Retain proxy and endpoint telemetry long enough to investigate brief substitutions after the vendor’s servers have returned to normal. These are sensible controls for the reported failure mode, not proof that any one control would have prevented this specific incident. CSA
Vendor assessments should ask whether update manifests and configuration are signed, whether signing keys are protected separately from web hosting, and how vendors detect short-lived changes. A valid encrypted connection is not the same thing as an authenticated update manifest. And a product’s reputation, however deserved, is not a substitute for evidence that its update chain resists server-side tampering.
For this incident, chronology is a defensive detail, not trivia: the reported exposure periods were in May and July 2025, while later discovery and response reporting described what happened afterward. Keep those dates straight, investigate the right telemetry window, and do not assume that a repaired server means every client is clean.
