AOMEI Backupper Supply-Chain Incident: Evidence and Response

Google Threat Intelligence Group (GTIG) and Mandiant documented a 2026 campaign that abused AOMEI Backupper's update and promotional-content delivery paths; ManageEngine's endpoint investigation independently reconstructed the delivery process. The activity did not rely on a reported memory-corruption flaw or a CVE. Instead, attackers briefly altered configuration served from the vendor's update infrastructure so that clients checking during the window could be directed to attacker-controlled content.

GTIG directly observed three tampering windows: May 28, July 16, and July 20. Each lasted approximately five to ten minutes. A clean response outside those windows therefore does not prove that a particular endpoint was never exposed. GTIG tracked the activity as UNC7017 and described the payload chain as CROSSROAD and SHINYROAD. ManageEngine's endpoint telemetry and follow-up monitoring independently helped reconstruct the delivery process.

How the trusted update path was abused

AOMEI background components periodically retrieve configuration for updates and promotional content. GTIG describes down_html.ini as controlling package version, checksum, and download URL, while Notifycfg.ini provides notification instructions used by another component. During an observed window, altered configuration redirected a package request and instructed the client to process content through its normal local workflow. The threat actor's short-lived changes were then reverted.

ManageEngine reported observing Backupper 8.3.0 on affected endpoint telemetry and described the checksum as being specified in the same configuration file as the package URL. GTIG's broader campaign reporting includes other identified systems and dates. These are observations, not a complete affected-version range. The public sources do not establish that every Backupper installation, version, or update check was affected.

The delivery chain was followed by a downloader and backdoor activity, including use of CROSSROAD and SHINYROAD in GTIG's analysis. AOMEI's July 29 response to Mandiant said it had taken corrective action to secure distribution servers. That vendor remediation does not remove code already delivered to an endpoint. The sources do not provide a complete public victim count or prove that every machine polling during a window received a malicious package.

Why the short window changes investigation

Point-in-time checks and routine file reputation scans are poorly suited to a configuration that is malicious for minutes and then restored. A later request can return authentic content. A vendor endpoint may look clean after the fact, while a system that fetched content during the exposure interval may retain a scheduled task, unsigned binary, or other persistence. Conversely, a normal Backupper installation alone is not evidence of compromise.

This case also illustrates an integrity-design principle: a digest only proves that bytes match the digest value being checked. If an unauthenticated configuration can change both the download location and the expected digest, the digest does not independently prove publisher authenticity. Signed metadata, separately protected trust roots, tamper-resistant update channels, and reproducible provenance provide stronger integrity boundaries.

Defensive actions

Check the vendor's current advisory and supported release guidance. Apply the vendor's verified corrective update or instructions; do not infer that updating alone cleans an endpoint that may already have run a payload.
Search endpoint and EDR telemetry for the observed periods. Prioritize Windows systems using Backupper, especially telemetry around May 28, July 16, and July 20, 2026. Confirm local time-zone conversion before filtering.
Review process lineage and execution context. Investigate unexpected unsigned children or executables launched from application content or temporary directories, especially when followed by remote-administration components or scheduled tasks. Validate artifacts against GTIG/METAL's technical reports rather than treating one filename as conclusive.
Preserve evidence before cleanup. Export EDR process, file, network, and task records; record file hashes and timestamps; then isolate affected systems according to incident-response policy. Do not delete artifacts before forensic collection.
Rebuild from trusted media where execution is confirmed. Rotate credentials that may have been accessible on the endpoint and verify that persistence and lateral access have been addressed. Reinstalling the application is not a substitute for checking system integrity.
Harden software distribution. Authenticate update metadata independently of the download URL, protect signing keys, prevent promotional content from launching executables, and monitor deviations from expected publisher, path, process tree, and network behavior.

Evidence, scope, and uncertainty

Claim	Status in primary reporting
AOMEI update infrastructure was tampered with in short windows	Reported by GTIG/Mandiant and supported by continuous monitoring described by ManageEngine.
Campaign used trusted AOMEI content paths to deliver malicious files	Described by both investigations.
Backupper 8.3.0 appeared in endpoint evidence	ManageEngine observation; not a statement that only 8.3.0 was affected.
Every user who opened or installed Backupper was compromised	Not established. Exposure depended on timing and endpoint activity.
Vendor corrected server-side controls	GTIG says AOMEI reported corrective action by July 29, 2026. Endpoint remediation remains a separate task.
CVE exists for the delivery event	The cited incident reports do not assign a CVE; this was described as infrastructure/configuration tampering, not a product-code exploit.

This analysis reflects public reporting available on October 18, 2026. GTIG reported that AOMEI said corrective action had been taken by July 29; the full affected population, complete window history, and later vendor updates remain subject to change. The reports do not assign a CVE to this infrastructure/configuration tampering event.

Build an exposure timeline before deciding who is affected

The short server-side windows make time correlation more useful than a broad “Backupper installed” search. Start with a complete inventory of endpoints that had the product during the reported periods. Then compare the device's update checks with endpoint and network telemetry. The report dates identify when investigators observed tampering; they are not a complete list of every possible exposure interval.

Evidence to collect	Question it answers	Caution
Product version, installation path, and update history	Was the application present and checking for updates in the relevant period?	Version alone does not show whether a malicious response was received.
Process tree and file-creation records	Did an update or application process create or launch an unexpected child or binary?	A filename or unsigned status alone is not a verdict; compare publisher, hash, parent process, and time.
Network and DNS telemetry	Did the endpoint contact destinations inconsistent with its normal update activity?	Use the source reports' validated indicators and your baseline; do not block unrelated infrastructure based on a loose match.
Scheduled tasks, services, and persistence records	Did the host retain activity after the update window ended?	Check the full endpoint timeline; later server responses may already be clean.

Prioritize systems with evidence of execution, unexpected outbound connections, or persistence. Keep a separate list of systems that only had the application installed and systems for which logs are incomplete. That distinction prevents an investigation from treating potential exposure as confirmed compromise or from closing the case because the vendor server now returns clean content.

What a trustworthy updater should verify

An update client should authenticate the metadata that names the release and its download location, not simply compare a downloaded file with a digest delivered beside the URL. A stronger design verifies signed metadata against a trust root stored separately from the update response, rejects stale or rolled-back metadata, and records which release was offered and installed. These controls reduce the chance that one changed configuration response can redirect both the artifact and the value used to validate it.

For defenders, the operational question is whether the product's update trust chain remained intact during the relevant interval. Review vendor guidance and the available host evidence; do not infer that a later clean update response repairs an endpoint that may already have executed a payload.

Questions about the AOMEI Backupper incident

Does this report mean every Backupper user was compromised? No. The sources describe short tampering windows and do not establish that every installation or update check received a malicious package.

Does a clean update check today clear an endpoint? No. A later response can be clean after the server-side change was reverted. Review historical endpoint evidence for the observed dates.