AOMEI Backupper and AnyViewer users could receive an attacker-controlled update while their applications checked the vendor’s servers. Google Threat Intelligence Group (GTIG) and Mandiant traced a campaign in which UNC7017 changed two server-side configuration files for just five to ten minutes at a time between April and July 2026, then restored the originals. A machine that checked during a changed window could download and run malware; the same URL checked later would return the normal file.
GTIG identified affected organizations across IT services, telecommunications, higher education and related sectors in Australia, Brazil, India, Pakistan, Portugal, Singapore, South Africa, Spain, Switzerland, Türkiye and the United States. Its investigation began with late-May endpoint detections shared by ManageEngine Threat Analysis Lab (METAL). AOMEI told the researchers on July 29 that it had taken corrective action on its distribution servers. Those server changes leave earlier endpoint infections to find and remove.
Two settings files carried the attack
AOMEI’s background update flow gets instructions over HTTPS. down_html.ini tells the client the update version, expected MD5 checksum and download location for upgrade-now.zip. Notifycfg.ini tells its notification process, ABNotify.exe, what to display and which local programs to launch. UNC7017 altered both files on the origin servers. The first sent clients to a weaponized archive; the second drove execution of the extracted upgrade-now.exe from the local html/ directory.
In the July 16 wave, the attacker incremented the thrid minor version field, changed the MD5 value to match the malicious archive and inserted more than 35,000 lines of repetitive [dummy_XXXXXX] sections into Notifycfg.ini. GTIG says this configuration bloat overrode the ordinary version check and forced an immediate update. The checksum matched the substituted download because the attacker could edit the instruction carrying that checksum too. GTIG’s advice for software vendors is to sign the configuration and verify update signatures on the client, rather than trust HTTPS and a checksum delivered by the same server.
On July 20, UNC7017 switched the initial archive delivery to an abused public Google Cloud Storage bucket. The legitimate storage.googleapis.com hostname could pass a proxy rule that blocks newly registered domains, while the downloader still contacted attacker infrastructure for later components. That same day’s notification file replaced a promotional banner with an invisible 1×1 window. It pointed at a remote file:// WebDAV resource on 8[.]210[.]84[.]56, creating a second route for outbound NetNTLMv2 authentication. MITRE ATT&CK’s forced-authentication entry describes how SMB and WebDAV resource loads can send credential material to a remote server; WebDAV can use 80 or 443 even where outbound SMB is blocked.
Five minutes changed the evidence
GTIG directly confirmed a ten-minute window on May 28, a six-minute window on July 16 and a five-minute window on July 20: May 28 05:40–05:50 UTC, July 16 08:33–08:39 UTC and July 20 10:35–10:40 UTC. At the end of each, the server configuration was authentic again. GTIG says additional short windows probably escaped observation; search updater activity throughout April through July as well as at these confirmed times. One client polling inside the window and another polling just afterward would see different instructions. GTIG put it plainly: “Systems checking for updates during an active window received malicious instructions, while systems checking before or after received clean, authentic files.”
The downloaded CROSSROAD loader could extract a second archive into %LOCALAPPDATA%\Radmin\ and create a RadminComponentRuntime scheduled task that ran a signed Radmin binary, FamItrfc.exe, every three hours with --runtimechk. An unsigned BlkScrDl.dll beside it sideloaded SHINYROAD through that legitimate binary. GTIG also observed later Adaptix tooling masquerading as Nitro PDF software with a NitroRuntime task and Eztwain4.dll. The signed Radmin utility belongs in this triage only when the task launch and adjacent unsigned DLL fit the chain.
The loader also reset its local update configuration and deleted itself. A live request to AOMEI’s update URL or a current copy of the local .ini file can look ordinary after the window; the scheduled tasks, DLLs, cached files and historical process or proxy records carry the useful history.
Hunt endpoints before clearing alerts
Start with Windows hosts that ran AOMEI Backupper or AnyViewer during April through July. Correlate updater or notification process trees with downloads, unsigned child executables and outbound traffic at the alert’s exact timestamp. GTIG recommends preserving cached configuration under %PROGRAMFILES(X86)%\AOMEI\*\Tmphtml\ and checking the application’s html\ directory for upgrade-now.zip or upgrade-now.exe. A file match warrants analysis. Use historical endpoint and proxy records to resolve an alert from the short server-tampering window.
Look for the RadminComponentRuntime and NitroRuntime scheduled tasks. In %LOCALAPPDATA%\Radmin\, examine BlkScrDl.dll, csvc\RuntimeComponent.dll, config.zip and metadata.dat alongside the signed FamItrfc.exe; in %LOCALAPPDATA%\Nitro Pro\, examine Eztwain4.dll and inspect the NitroRuntime launch command for %TEMP%\NitroPromotion.exe. GTIG publishes a SHA-256 for the July 16 CROSSROAD loader, 9a58e8f49edf5644e5728f74cf36f560d3d486fa51db4db69d927963c7aca450, and one for BlkScrDl.dll, 5837bc26a73cfb46ffd466cf889f03ce2f6a48f1f3fd42ec8be22189d51cab1e. Compare observed files to the full indicator and YARA lists in its report before deciding whether a legitimate administration component belongs to this chain.
Search proxy and firewall history for promotion[.]storage-data[.]com, aomei[.]storage-data[.]com, storage-data[.]com and the actor-linked IPs 8[.]210[.]84[.]56, 47[.]239[.]60[.]117 and 8[.]218[.]65[.]184; block those actor destinations. GTIG also identifies serv.oss-cn-hongkong.aliyuncs.com and storage.googleapis.com as legitimate shared services abused for staging, so match their reported AOMEI download context rather than blocking the entire services. For NTLM exposure, restrict outbound SMB on 139 and 445 and external WebDAV over HTTP(S) according to approved destinations; check outbound authentication telemetry for contacts with 8[.]210[.]84[.]56. MITRE describes the egress filtering that addresses this forced-authentication path.
Verify the endpoints and egress
Remove unauthorized tasks and malicious components on confirmed affected hosts through incident response, then verify the tasks stay absent and the corresponding updater-launched processes and outbound actor contacts stop. Preserve the time-matched endpoint and network records first: the short server changes and the loader’s cleanup can erase the apparent entry point. For organizations shipping desktop updaters, sign and validate remote configuration and downloaded packages on the client, pin permitted update destinations, and reject external file:// or UNC resources in notification handlers. AOMEI’s server correction addresses the delivery route; the endpoint hunt addresses what ran during those minutes.