AOMEI Backupper Update Channel Compromised: Hunt CROSSROAD, SHINYROAD and NTLM Hash Theft

The trick was simple and effective. The attackers did not plant a backdoor in AOMEI's code or tamper with a build pipeline. They edited two remote configuration files on AOMEI's servers, waited a few minutes, then put the clean versions back. Any machine that checked in during those minutes got a backdoor. Any machine that checked before or after got normal promotional content. Anyone who looked at the server later, which includes most incident responders, saw nothing wrong.

What happened, in brief​

• Product: AOMEI Backupper on Windows. ManageEngine says it observed the activity on v8.3.0 and later versions. Google's report says AnyViewer, AOMEI's remote desktop tool, uses the same background update and notification system, and METAL notes that GTIG documented attacks on AnyViewer as well as Backupper.
• Method: Two configuration files on AOMEI's own servers were altered for brief periods: down_html.ini on www2.aomeisoftware.com and Notifycfg.ini on account.aomeitech.com.
• Payloads: A downloader GTIG calls CROSSROAD, a backdoor it calls SHINYROAD, and, on July 20, an attempt to capture NTLM authentication hashes.
• Confirmed exposure windows (all UTC): May 28, 05:40–05:50; July 16, 08:33–08:39; July 20, 10:35–10:40.
• Victims: Google's telemetry found affected organizations in Australia, Brazil, India, Pakistan, Portugal, Singapore, South Africa, Spain, Switzerland, Türkiye and the United States, mostly in IT services, telecoms and higher education. Google warns the real victim list is probably longer.

One note on dates, because coverage differs. Some summaries say the campaign ran from May to July. That matches the confirmed tampering windows, but Google says related malware samples were circulating from late April and that other tampering windows probably went unseen. If you're hunting, cover April through July.

How a promo pop-up became a malware launcher​

Backupper runs background processes, Backupper.exe and ABNotify.exe, that regularly contact AOMEI over HTTPS to fetch update notices and promotional pop-ups. Each configuration file handles one half of that system:

The weak point is the hash. METAL found that these files were not cryptographically verified by the AOMEI Backupper software, and the MD5 used to check the download sat in the same unsigned file as the download URL. Whoever could change the URL could also change the hash it was checked against. METAL puts it plainly: the file verification passed because the attacker controlled the value it was comparing against.

The July 16 change shows the attackers paid attention to detail. In down_html.ini, the minor build field went from thrid=5 to thrid=6 and the MD5 was swapped. During the same window, the attackers also injected over 35,000 dummy lines into Notifycfg.ini to bypass local version checks and force immediate execution. METAL describes the rest of the chain: Notifycfg.ini loaded a local upgrade-now.html page inside a one-pixel WebView window, and a script in that page launched the executable bundled beside it. The user didn't have to click anything. The application only had to be running.

METAL's verdict is blunt. There was no CVE, no memory corruption and no unpatched component. The software worked exactly as designed, and the design was the problem. (At least one industry brief described the credential-theft step as exploiting a "WebDAV vulnerability." Both primary reports describe it as abuse of the notification feature, not a software flaw.)

Why the brief windows mattered​

Google calls this the first software supply chain compromise it has seen that used windows this short. The effect, in a blog post by NetManageIT's Daniel Bender: a client that checked before or after the interval received authentic content, while a client polling during the interval could receive the malicious archive. This timing undermined point-in-time scanning, live URL checks, and retrospective review of the vendor's files.

The attackers also kept changing where the payload was hosted:

• April–May: Alibaba Cloud storage (serv.oss-cn-hongkong.aliyuncs.com).
• July 1–7: Their own vendor-themed domains: storage-data.com, promotion.storage-data.com and aomei.storage-data.com.
• July 20: The initial download came from a public Google Cloud Storage bucket (storage.googleapis.com/aomeiupdate/upgrade-now.zip). Google says this got past proxies that block newly registered domains, while later stages still used storage-data.com.

Blocking domains alone wouldn't have stopped this. You can't block storage.googleapis.com without breaking a lot of legitimate traffic.

The malware: CROSSROAD, SHINYROAD and what came after​

CROSSROAD (upgrade-now.exe) is a 64-bit Windows downloader written in C. Its version information reads "AOMEI Update Compent." The misspelling helped METAL find a matching sample on VirusTotal. Once launched, CROSSROAD checked the victim's external IP address and halted execution if the machine resolved to China. For all other targets, the loader restored the local configuration files to hide its tracks and deleted itself from the disk. METAL adds that it looked for specific endpoint security products and stopped if it found one. Google says it also faked its compile timestamps to show 2024 dates.

Before deleting itself, CROSSROAD unpacked a Radmin bundle into %LOCALAPPDATA%\Radmin\ and created a scheduled task called RadminComponentRuntime that runs FamItrfc.exe --runtimechk every three hours.

SHINYROAD sits inside that bundle. It used a legitimate, digitally signed Radmin executable to load a malicious DLL. Its capabilities included remote shell commands and receiving additional code at runtime. The malicious DLL is BlkScrDl.dll, named to look like Radmin's "blank screen" driver. Google says it decrypts compiled Python bytecode and runs it in an embedded PocketPy interpreter, which connects to 8.218.65.184 on port 443 (earlier versions used port 41397).

Later stages: Google says that from mid-July some victims also received ADAPTAGENT, the client for the Adaptix C2 framework, disguised as Nitro PDF software (NitroPromotion.exe) with a scheduled task named \NitroRuntime.

The Radmin detail matters for triage​

The two research teams emphasize slightly different things here. METAL says although Radmin Server was installed, they found no evidence that it was running. Remote access instead depended on the implant's outbound connection to the C2 server. That has two consequences:

• Finding legitimate Radmin on a machine doesn't prove anyone used it to connect. METAL warns that an unconfigured Radmin install shouldn't be dismissed either, because in this campaign the credential arrived only after the implant checked in.
• Because remote access depends on the implant connecting out, blocking outbound communication to the C2 cuts off the chain's only control channel. The implant cannot check in, and the operator has no other way in.

METAL also points out that the dropper runs with the same privileges as the AOMEI process that launches it. Because AOMEI's processes sit under a service (ABService.exe), the malware may have started with elevated rights without needing to escalate privileges itself.

July 20: credential theft without running any code​

The most worrying detail came on July 20. Google says the attackers replaced a legitimate 400×380 "World Cup Deals" banner with an invisible 1×1-pixel pop-up set to maximum priority. The pop-up pointed the client at a WebDAV path on 8.210.84.56. Requesting that resource could make Windows send the logged-in user's NetNTLMv2 authentication data to the attacker's server, where it could be cracked offline or relayed.

METAL highlights why this matters for scoping: no binary had to run. A machine whose security tools blocked CROSSROAD, or where the dropper's own checks made it quit, could still have leaked credentials just by having Backupper open during that window. Researchers describe this as attempted hash capture. Nobody has publicly confirmed that any captured hashes were cracked or used.

AOMEI's response: slow, then "high priority"​

The disclosure timeline is uncomfortable reading:

• June 7: METAL notified AOMEI. According to ManageEngine, AOMEI first suggested the content had been intercepted and altered in transit. METAL rejected that: two endpoints in different countries, on unrelated networks, had fetched the content over HTTPS from AOMEI-owned hostnames.
• July 16: METAL's continuous monitoring caught the tampering live and sent AOMEI the original and modified hashes and files. AOMEI told METAL its initial review found no evidence of a breach.
• July 17: Mandiant notified AOMEI.
• July 20: The attackers struck again, and GTIG captured that window.
• July 29: Google says AOMEI responded that it had taken corrective action. AOMEI also told METAL it had upgraded its servers, patched potential vulnerabilities and verified its hosted files.
• October: AOMEI told BleepingComputer its CTO was leading a high-priority internal investigation. It has not said how the attackers got in or confirmed that the problem is fully resolved.

METAL's own status line is worth remembering: "As of publication, we have not independently verified that the compromise has been contained."

To be fair to AOMEI, the attack was designed to look like nothing happened, and a vendor checking its servers would most likely have found clean files, just as METAL did when it first tried to reproduce the attack. But a vendor saying it has fixed its servers is not the same as independent confirmation, and neither one cleans the endpoints.

What Windows admins should do now​

The most important point from the research: a server-side fix stops new infections but does nothing for machines already compromised. Here's a practical hunt list built from the Google and METAL indicators. Treat each item as a lead to investigate, not proof of infection.

• Check for the scheduled tasks. Look for RadminComponentRuntime and \NitroRuntime. On a single machine, schtasks /query /tn "RadminComponentRuntime" will tell you whether the first exists. Across a fleet, use your EDR or management tooling.
• Inspect the file system. Look in %LOCALAPPDATA%\Radmin\, especially for FamItrfc.exe or FamItrf2.exe alongside BlkScrDl.dll, RuntimeComponent.dll and config.zip. METAL also saw a Radmin Server install under C:\Program Files (x86)\rserver30.
• Check AOMEI's own folders. METAL says an executable inside Backupper's tmphtml\ staging directory or html\ directory (for example ...\<version>\html\upgrade-now\) is highly unusual, because those folders should only hold rendering files. Google advises preserving the cached configuration files under %PROGRAMFILES(X86)%\AOMEI\*\Tmphtml\ before anyone cleans up.
• Hunt process lineage. Flag unsigned child processes started by Backupper.exe or ABNotify.exe, particularly ones that carry AOMEI publisher details but no signature. Also flag rsetup64.exe /intsetup launched by an unsigned parent.
• Search network logs from April to July for 8.218.65.184, 8.210.84.56, storage-data.com and its subdomains, serv.oss-cn-hongkong.aliyuncs.com, and the storage.googleapis.com/aomeiupdate/ path. Pay extra attention to the three confirmed windows, but don't stop there.
• Assume credentials may be exposed on any machine that ran Backupper around July 20 and reached out over WebDAV or SMB to 8.210.84.56. Resetting passwords for the users signed in at the time is a reasonable precaution.
• Don't trust a live URL check. Google calls this the triage trap: an analyst gets an alert, checks the vendor URL, finds clean files and closes the alert as a false positive. METAL's original detections came from behavioral policies running in audit mode, so the activity was logged but not blocked. Know which of your own policies are set to detect only.

From general industry practice rather than the reports themselves: blocking outbound SMB and WebDAV at the network edge, and limiting outgoing NTLM through the "Restrict NTLM: Outgoing NTLM traffic to remote servers" Group Policy setting, reduce exposure to this kind of coercion from any application. Test before rolling either out widely, because both can break legacy workflows.

Hash indicators include the CROSSROAD sample 9a58e8f49edf5644e5728f74cf36f560d3d486fa51db4db69d927963c7aca450 (Google) the tampered Notifycfg.ini 2e3b4bfb86224f079b8762ce78bb7ff10afdbf8421b08b23e96429f2e1ee7b50 (METAL), and the May 28 endpoint dropper upgrade-now.exe 130c3970f1c900191615b99d8be522d6a488a3d3b73938896ed937092007d96a (METAL). METAL cautions that hashes are a weak defense against payloads that delete themselves and change between waves. Process behavior is the more reliable signal.

Why this goes beyond AOMEI​

SolarWinds and 3CX trained defenders to look for poisoned builds. This campaign never touched a build. It used something most security reviews ignore: the promotional pop-up and notification channel built into consumer and prosumer utilities.

METAL argues that the weakness applies to any desktop application that takes download instructions from a remote file without independently verifying that file. Google's recommendations for vendors follow from that:

• Sign configuration files with public-key cryptography.
• Verify Authenticode signatures on every downloaded executable before extracting or running it.
• Restrict downloads to approved vendor domains.
• Block file:// and UNC/WebDAV paths in embedded web views.

For IT teams, this is a reason to ask what else in their software inventory pulls instructions from a remote server and acts on them. Backup tools, PDF utilities, driver updaters and "free" system optimizers often run with high privileges, check in often, and include ad channels nobody audits. Two cheap steps help: turn off in-app promotions wherever the software allows it, and treat updater child processes as suspicious by default.

Backup software is supposed to be the last line of defense. In this case, its pop-up channel let attackers in.

Correction (October 19, 2026): an earlier version of the hunt list mislabeled the SHA-256 hash 2e3b4bfb86224f079b8762ce78bb7ff10afdbf8421b08b23e96429f2e1ee7b50 as the May 28 endpoint dropper. Per METAL's published indicators, that hash belongs to the tampered Notifycfg.ini; the May 28 endpoint upgrade-now.exe hash is 130c3970f1c900191615b99d8be522d6a488a3d3b73938896ed937092007d96a.