Hackers Hijacked AOMEI Update Servers to Push a Windows Backdoor

Between April and July 2026, attackers repeatedly took over the update channel behind AOMEI Backupper and AnyViewer, two Windows utilities from AOMEI Technology, and used it to push a backdoor to some users. Google's Threat Intelligence Group and Mandiant published the findings on October 15, and they track the actor as UNC7017. The attack did not depend on a software vulnerability and carried no CVE, which is why it slipped past many routine checks.

If you are asking whether AOMEI Backupper malware is a live risk, the answer depends on when and where you ran the software. The researchers have not published which Backupper versions were affected, so the safe move is to review every Windows machine that ran either product during the campaign period. AOMEI told Mandiant on July 29 that it had taken corrective action on its servers. That fix does not clean machines that already received the payload.

What happened on AOMEI's update servers

According to Google's write-up, the attackers changed only the update configuration on AOMEI's infrastructure. They altered two configuration files so that installs pointed to a malicious ZIP package instead of legitimate updates. Each change lasted only five to ten minutes. Then the files were restored to clean content, so a later look at the vendor's live files would often show nothing wrong.

The documented tampering windows were 10 minutes on May 28, 6 minutes on July 16 and 5 minutes on July 20. The timeline below pulls the key dates together from the research and the vendor's responses.

The timeline also shows how slowly the case moved. Roughly ten days passed between ManageEngine's first flag and its notice to AOMEI. Mandiant did not contact the vendor until July 17, and the public research did not appear until October.

Why short tampering windows evaded scanners

Most supply chain attacks that make headlines involve trojanized source code or compromised build pipelines. The SolarWinds and 3CX cases both distributed malicious software components, and they remain useful reference points. This campaign works differently. It changed the settings that tell the client where to fetch software, not the software itself, and Google calls that a lower-overhead, higher-stealth option. Google also says it had not seen a supply chain compromise built on windows this short.

Tyler McLellan, principal threat analyst at Google Mandiant, described the approach in terms of detection. The campaign was built for "effectively evading traditional point-in-time triage and automated file scanning," as BankInfoSecurity reported. A scan that runs once a day, or even once an hour, can easily miss a file that exists for five minutes and then disappears.

The weakness behind the design is not a conventional bug. The client did not authenticate its remote configuration files, and neither file was cryptographically signed. The checksum sat in the same file as the download address, so an attacker who changed the address could change the checksum to match. A signature verified against a key stored elsewhere would make that swap much harder, although AOMEI would have to decide whether to add one.

Which files and tools the attackers used

Two configuration files did most of the work. The first, down_html.ini, sets the package location and checksum. The second, Notifycfg.ini, controls the pop-up notification and what it executes. Changing both let the attacker control where the update came from and what ran afterward.

The malicious chain used CROSSROAD, a downloader, and SHINYROAD, a backdoor that gives the operator a remote shell and can fetch more code. Aardwolf Security's analysis reports that the backdoor ran through a legitimate Radmin remote-administration component, and that a scheduled task reran the chain every three hours. Using a legitimate admin tool helps an intruder blend in, which makes that installation a useful artifact to check.

Google also reported an attempt to capture Windows NTLM hashes through a notification-triggered WebDAV request. A later step used Adaptix C2 disguised as Nitro PDF tooling. Credential material like NTLM hashes or saved tokens can open doors well beyond the infected PC, which is why the reset advice below covers more than Windows. Researchers also say the implant skipped machines in China and halted when certain security agents were present. Those checks are a common way to avoid analysts, though the reports do not explain the choice.

Who was targeted and where the US fits

Victims were in IT services, telecommunications and higher education. Google said the United States was among the 11 countries with confirmed victims. Google also says its figures are likely incomplete, and the full victim count and the number of US organizations remain unknown.

The targeting appears opportunistic. Google said any system that polled the servers during a window could receive the malware, so the victim list reflects who happened to check for updates at the wrong moment. That clustering still matters. An IT service provider or a university IT team may manage many machines, so one infected admin workstation can carry the backdoor well past the first victim.

Attribution is not established. Google says no country or known actor has been named for UNC7017, and the initial access method used to tamper with the servers remains unclear. Other recent cases show attackers going after infrastructure that sits close to many machines. In a separate case, an AhsayCBS vulnerability chain let attackers seize backup servers, but that attack required a flaw to exploit. The AOMEI campaign needed none. Meanwhile, PEERSTITCH malware reached 500 FortiGate firewalls through a FortiOS flaw, a reminder that patch status and exposure both shape the damage.

How to check AOMEI Backupper and AnyViewer for the backdoor

Work through this list on every Windows machine that ran either product during the campaign period.

1. Inventory first. List each machine with AOMEI Backupper or AnyViewer installed, including servers and admin workstations, and record version numbers. Because affected versions are unpublished, treat installs from April through July as suspect.
2. Look for the malware. Check for CROSSROAD and SHINYROAD files, a Radmin installation nobody deployed, and a scheduled task that reruns a chain every three hours. FdayTalk's guide walks through a similar check.
3. Hunt across the network. Security teams are being urged to search for the published indicators of compromise, not just the machines they already suspect.
4. Rebuild rather than patch. The vendor fix does not clean machines that were already infected, so isolate affected systems and rebuild them from known-good media.
5. Reset credentials from a clean device. Change Windows passwords, email passwords and any NAS or cloud credentials saved in Backupper. Whether credentials were exposed in July remains to be confirmed, so reset them anyway.
6. Pause automatic update checks until the picture is clear. One consumer guide recommends turning off automatic update checks in both apps until affected versions are confirmed. When the vendor names safe versions, update manually from its official download pages.

Several details in this story come from secondary coverage of the researchers' reports, including TechInformed's and SecurityOnline's summaries. Read the full Google and ManageEngine write-ups before acting on version-specific guidance, since those are the primary sources for indicators.

What comes next for AOMEI users

The most useful next signal is an AOMEI advisory that names affected versions and describes a verified update path. Watch whether Google's victim figures grow, whether the WebDAV token theft reached further than reported, and whether any credentials were exposed in July. The broader question is whether other update clients that fetch configuration at runtime get the same scrutiny. A vendor that signs its installers still leaves room for an attacker who can change where the client looks, so the lesson that matters is verifying what gets loaded, not only what gets installed.