- Google's threat team reports an attacker altered AOMEI update files for five to ten minutes at a time, then restored them.
- Checks that look at a server after an incident can miss this, so teams need records of what update servers actually served.
- Ask which software on your endpoints trusts a vendor's update server, and whether you log that traffic.
A server that looks clean is not proof it was clean
Most security checks ask one question: is this file safe right now? Google's threat team describes an attack built to exploit that habit. The files were altered for a few minutes. Then they were put back.
Google Threat Intelligence Group (GTIG) and Mandiant studied an attack on the servers that send updates to AOMEI's software. AOMEI makes Backupper, a backup tool, and AnyViewer, a remote-desktop tool. The attack ran from April to July 2026.
GTIG says this is the first supply chain compromise it has seen with windows this short.
The lesson here is that a file is only trustworthy at a given moment. A vendor's server can be honest one minute and deliver malware the next.
How the trick worked
AOMEI's software checks in with the vendor's servers on a schedule. Each time, it reads two small settings files.
The first is down_html.ini. It names the update package to download. It also holds the package's fingerprint, which the software uses to confirm the file is genuine.
The second is Notifycfg.ini. It controls pop-up messages. It can also tell the software to run programs stored in its local folder.
GTIG says an attacker, tracked as UNC7017, changed both files for a few minutes. The first file pointed the software to a malicious ZIP archive on attacker-controlled servers. The attacker also changed the fingerprint and raised the version number. That way, the software accepted the package.
The second file told the software to run the unpacked program at once.
No software flaw was needed. The attacker used the update process as designed.
Any computer that checked in during a window got the malicious instructions. Computers that checked before or after got clean files.
One July window shows the effort involved. GTIG says the attacker packed the notification file with more than 35,000 lines of filler. The researchers say this forced the software to run the update, whatever version it had.
Why checks after the fact struggle
GTIG confirmed three windows. They fell on May 28 (10 minutes), July 16 (6 minutes) and July 20 (5 minutes). GTIG adds that more tampering probably happened out of its sight.
When each window closed, the attacker restored both files. GTIG says this hinders the vendor's later audits. It also gives defenders less time to capture a live malicious response. An investigator who checks the server afterward sees genuine files.
The malware also covered its tracks. GTIG says the first-stage downloader, called CROSSROAD, reset the local update settings to AOMEI's real servers. Then it deleted itself from disk.
The attacker also changed where it kept its payload. Early on, it used Alibaba Cloud storage. In July, it moved to look-alike domains. On July 20, the first download came from a public Google Cloud Storage bucket.
GTIG says this let the download slip past proxies that block newly registered domains. Later stages still used the attacker's own domain.
Who was hit
GTIG's data shows victims in IT services, telecommunications and higher education. The report names eleven countries, including India, Brazil, Spain and the United States.
The researchers call the targeting opportunistic. Anyone who checked for updates during a window could be hit. They say the true number of victims likely goes beyond those they identified.
The ManageEngine Threat Analysis Lab, part of Zoho, first spotted the activity in late May. Its endpoint detection data showed it across several customers. GTIG told affected organizations and shared its findings with AOMEI. AOMEI reported taking corrective action on its distribution servers.
What the malware left behind
GTIG reports that CROSSROAD created a scheduled task named RadminComponentRuntime. The task runs a file at %LOCALAPPDATA%\Radmin\FamItrfc.exe every three hours.
The bundle is built around Radmin, a remote administration tool. It delivers a backdoor that GTIG calls SHINYROAD.
On July 20, the attacker also changed the notification file to open a hidden 1-pixel window. GTIG says this made the software request a remote file over WebDAV, a file-sharing protocol. The researchers say this could make a computer send scrambled Windows login proofs, called NetNTLMv2 hashes, to an address the attacker controlled.
Questions to put to your team
First, which products on your endpoints fetch and run updates from a vendor server? Backup and remote-access tools deserve a close look.
Second, do you record what update servers sent to your machines? Or do you only see what sits on the server today? Your own network logs can show what your machines received.
Third, can your team search for the scheduled task and folder named above?
Fourth, does your blocking of newly registered domains assume attackers avoid trusted cloud storage? In this campaign, the attacker used it.
Last, ask your vendors how they spot changes to update files, and how fast. A clean server tomorrow does not prove a clean server this morning.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Google Threat Intelligence Group.
