A Clean Update Page Cannot Prove Your PC Stayed Clean

The backup program looked after copies of the important files. It checked its maker’s server over an encrypted connection. If somebody opened the same update address later, the files looked genuine. Those are three facts most of us would normally accept as reassuring.

In this case, they are the reason a bad update could arrive quietly.

On 15 October 2026, Google Threat Intelligence Group and Mandiant described an attack on update and notification systems used by AOMEI Technology. The researchers say an attacker changed two small instruction files on AOMEI’s servers for bursts of five to ten minutes between April and July. A Windows PC that asked for an update during one of those bursts could receive malware. Before or after the burst, the same address served the proper file again (Google Threat Intelligence Group and Mandiant, 15 October 2026).

AOMEI told Mandiant in July that it had taken corrective action on its servers. That closes one door, if the repair holds. It does not remove a backdoor already placed on a customer’s computer. Nor does a clean download today prove that the computer received a clean download in May or July.

That is the useful lesson for anyone who runs AOMEI Backupper, the company’s Windows backup and disk-copying program. Do not stare at today’s download page and try to decide whether the past was safe. Check the computer for the things the bad update left behind. If you find them, stop treating the machine as trustworthy and get help with recovery.

What the researchers found

The public account names three confirmed periods when the server instructions were altered: ten minutes on 28 May, six minutes on 16 July, and five minutes on 20 July 2026. Google says related malicious files appeared from late April and that other short periods may have escaped observation. It has not published a total number of infected computers.

The known affected organisations were spread across eleven countries and several sectors, including education, telecommunications, and IT services. Google calls the delivery opportunistic. In plain English, the attacker did not have to choose each recipient in advance. A machine became a candidate if its copy of the software happened to check in while the false instructions were present.

Independent accounts agree on the important boundaries. The Hacker News reported on 16 October that a computer checking outside those short periods received authentic files, that AOMEI’s server repair would not clean an already infected PC, and that neither the attack’s initial route into AOMEI nor a complete affected-version list had been disclosed. Malwarebytes reported on 19 October that the delivered program established lasting remote access and gave readers a short set of checks for the scheduled task, program folders, and known network addresses.

The incident is narrower than “every AOMEI customer was hacked.” Only a machine that fetched the changed instructions during an active period could receive this package through the route the researchers documented. Google does not say that all AOMEI installations did so. Its report also mentions AnyViewer, an AOMEI remote-support product that uses the same general update flow, but Malwarebytes notes that the published research does not separately identify confirmed AnyViewer infections.

There is no public evidence here that every backup has been stolen, every password on an affected PC has been taken, or every current AOMEI download is malicious. There is evidence of successful infections, a remote-access backdoor, and later activity on some systems. That is enough to justify a proper check without turning uncertainty into a universal catastrophe.

The researchers track the operator under the temporary name UNC7017. They have not publicly attached a country, government, or familiar criminal brand to it. The name is a case label, not an attribution. The initial way the attacker gained permission to change AOMEI’s server files also remains undisclosed as of 20 October.

Those gaps matter because a calm response begins with what is known. The server instructions changed briefly. Some clients accepted and ran the replacement package. The replacement created a recurring task and a remote foothold. The attacker then tried to erase some of the evidence that explained how it arrived.

How two small files became an installation order

AOMEI Backupper did not need to download a complete new installer every time it checked for news. According to Google’s analysis, its background services periodically fetched two small text files over HTTPS.

One file told the program which update package to download, what version number to expect, and which MD5 checksum should match that package. A checksum is a short value calculated from a file. If the downloaded file changes, its checksum normally changes too. The second file controlled notifications and promotional pop-ups, including instructions that could launch a program already placed in the application’s folder.

That arrangement contains a circular trust problem. The checksum and the download address sat in the same unsigned instruction file. An attacker able to edit that file could replace the address and replace the expected checksum beside it. The program would then confirm that the attacker-controlled package matched the attacker-controlled expectation.

It is like finding a parcel at the door with a note saying, “This package is genuine because its label reads 2847.” If the same person supplied the parcel, the label, and the note, the number proves only that the three items agree. It does not prove that the shop sent any of them.

The encrypted HTTPS connection did a different job. It protected the trip between the PC and the server. It could tell the PC that it had reached the server named in the web address and that somebody on the local network had not casually altered the reply in transit. It could not tell the PC that an authorised person had written the file currently sitting on that server.

A sealed delivery van can stop a stranger changing a parcel on the road. It cannot detect that the wrong parcel was loaded at the warehouse.

During the confirmed windows, the attacker changed the update instruction to point at a weaponised ZIP file and changed the version and checksum so the client would accept it. The notification instruction was also altered so the downloaded program would run. No click on a fake email was required. The user’s ordinary software supplied the trust, the route, and the execution.

Google calls the first malicious program CROSSROAD. It checked the environment, downloaded more components, and created a Windows scheduled task named RadminComponentRuntime. That task launched every three hours. The later package used genuine components from Radmin, a legitimate remote-administration product, alongside an attacker-made file. The genuine program then loaded the nearby malicious component, which Google calls SHINYROAD.

SHINYROAD provided a remote command channel and the ability to run more code. Google later observed another command-and-control tool disguised with Nitro PDF names on some systems. A signed, legitimate program appearing in this chain does not clear the surrounding folder. Criminals can place their own component beside a real executable and rely on the real program to load it.

The first downloader also cleaned up after itself. It restored the local instruction to its ordinary value and deleted its own program after arranging the recurring task. That behaviour is central to this story. The thing that caused the infection could disappear while the access it created remained.

Why checking the website now answers the wrong question

Suppose a security program raised an alert at 08:36 UTC on 16 July. Six hours later, somebody opened the vendor’s update address. It served the correct file. An online scanner found nothing wrong with that current file. The website used HTTPS and the domain belonged to the vendor.

None of those observations tells us what the PC received at 08:36.

Google says the 16 July change lasted from 08:33 to 08:39 UTC. The attacker then restored the authentic server files. Most visitors, automated scanners, and support staff would see the honest version because it occupied almost the entire day. A later check could therefore become false reassurance, not because the checker made a technical mistake, but because it measured the wrong moment.

The same problem appears on the computer. The first program deleted itself. It put the ordinary update location back into the local configuration. The later backdoor used a legitimate remote-administration executable as part of its launch path. Looking only for a suspicious current installer or an obviously fake application can miss the recurring task and the added component.

This is the difference between a snapshot and a history. A snapshot asks, “What is at this address now?” A history asks, “What did this process download and run at that time, and what survived?” Both are useful, but only the second question can clear an earlier event.

You already use this distinction outside computing. A clean kitchen at closing time does not prove every lunch was prepared safely. It proves that the surfaces are clean now. To investigate a complaint from noon, a restaurant needs temperature records, delivery records, and the food-handling sequence from noon.

On a home PC, the history is less complete. Most people do not retain months of network records or process logs. That does not make the check pointless. The scheduled task and staged folders are durable clues. A current security scan can recognise known files. Windows may hold event records, and a workplace security team may have richer endpoint and network history.

It does mean one weak check cannot carry too much weight. “The vendor page is clean” is not an all-clear. “I cannot find the original downloader” is not an all-clear because the downloader was built to remove itself. Even “my files still open” says little about a backdoor designed to remain quiet.

A good check follows the persistence, not merely the delivery file.

Who should act, and how urgently

Start with scope. This article concerns Windows systems that had AOMEI Backupper installed during the April-to-July 2026 campaign period. An organisation using AOMEI products should also include AnyViewer in its inventory because Google’s report says the products relied on the associated update flow, while keeping the published distinction that confirmed AnyViewer infections were not separately identified.

If you never installed either product, this particular route does not give you a reason to scan random folders or delete unrelated backup software. Keep your normal security updates current and move on.

If you installed AOMEI Backupper only after July, the documented windows predate that installation. That lowers the relevance of this campaign to your machine, although it does not answer every possible security question about the product. Confirm the installation date rather than relying on when you first remember using it.

If the program was present between April and July, make time for the check even if you never clicked an update button. The research concerns background checks and notifications. “I did not manually update” does not exclude the documented path.

Urgency depends on what you find. A known malicious task, folder, file, or network connection deserves immediate containment. Disconnect that PC from Wi-Fi or unplug its network cable, leave it powered on if a professional is about to examine it, and contact the person who supports the machine. On a work device, stop there and call the organisation’s IT or security team. Do not begin deleting evidence or experimenting with commands.

No known indicator and a clean security scan are reassuring, but the meaning depends on how much history is available. A home PC with no retained logs may not be able to prove a negative months later. An organisation with endpoint monitoring, proxy records, and the detection rules in Google’s report can make a stronger judgment.

Without a published total, assuming infection would be as unsound as assuming safety. Avoid invented odds. We know the delivery periods were brief, and we know more periods may have gone unseen. The responsible answer for an in-scope machine is a bounded examination, not a percentage guessed from the number of AOMEI customers.

A careful check for a home Windows PC

Before changing anything, record what you have. Photograph the AOMEI product name and version, the Windows edition, and the current date. Note whether this is a personal machine, a work machine, or a computer managed by somebody else. If it belongs to an employer, school, or client, use their reporting route instead of conducting your own investigation.

Then work through these steps.

1. Update the security tool you already trust and run a full scan. Use Windows Security or the reputable security product already installed. Fetch its current detection updates first. A quick scan is designed for speed; choose the full or complete scan for this check. Save or photograph the result rather than relying on memory. Malwarebytes says its current product recognises the initial upgrade-now.exe, but installing a second scanner is not mandatory if doing so would conflict with managed workplace software.

2. Look for the named scheduled tasks without running them. Open the Start menu, search for “Task Scheduler,” and open the built-in Windows application. Select “Task Scheduler Library” in the left pane. Look for RadminComponentRuntime and NitroRuntime. Do not click Run. If either name is present, photograph the General, Triggers, and Actions tabs. A task with the first name was a persistence mechanism in the reported chain; the second was associated with later tooling.

3. Check the relevant folders as evidence, not as a cleanup exercise. In File Explorer, enter %LOCALAPPDATA% in the address bar. Look for folders named Radmin and Nitro Pro. Their names alone require care: Radmin and Nitro are also names used by legitimate software. An unexpected folder on a PC where nobody installed those products, combined with the named task or an alert, is more meaningful than a familiar brand name by itself. Do not open unfamiliar executable files to “see what they do.”

4. Inspect AOMEI’s own installation area. The researchers direct defenders to the product’s html and Tmphtml folders. Look for an unexpected upgrade-now.zip or an unsigned upgrade-now.exe. The downloader may already have deleted itself, so an empty folder cannot settle the question. Preserve anything your security tool flags and let the tool quarantine it; do not email suspicious files or upload private backup data to a public analysis site.

5. Treat a strong match as a compromise, not a nuisance to delete. Disconnect the machine from the network. On another known-good device, contact a trusted technician or the organisation’s security team. Tell them this concerns the AOMEI update compromise disclosed by Google on 15 October 2026, and provide the task name, folder path, scan result, and photographs. That description is more useful than “I think I have a virus.”

A search result by itself can mislead. Typing an indicator into the web can lead to fake cleanup utilities and aggressive sales pages. Use the primary Google report for the technical list and the support route of a security product or technician you selected independently.

If nothing appears, record that too: full scan completed, date, product used, tasks absent, folders checked. A written result prevents the household from repeating half the work and forgetting which parts were actually examined.

What to do when a match appears

Do not use the possibly affected PC to change every important password. A machine with remote access or credential-stealing activity is the wrong place to type new secrets. Use a different, updated device that you have reason to trust.

Begin with email because it can reset many other accounts. Give it a unique password and enable a strong second step, preferably a passkey or authenticator application where available. Then address banking, password management, cloud storage, work access, and any account whose credentials were stored or used on the affected computer during or after the campaign period.

Changing passwords is not a substitute for cleaning or rebuilding the PC. It reduces the value of credentials already exposed. If the backdoor remains and you sign in again from the same machine, the new credential can be put at risk too.

A professional may recommend rebuilding Windows from known-good installation media rather than trying to remove a list of named files. That is reasonable for a confirmed remote-access backdoor. Once an outsider can run commands, the visible components do not define everything they may have changed. Deleting one task can stop one launch route without restoring confidence in the rest of the system.

Backups now need thought, not destruction. Disconnect backup drives from the suspect PC so they cannot be changed while the investigation continues. Do not erase the only copies. A backup of documents can still be valuable even when the computer that made it needs rebuilding. Programs and system images from the affected period deserve more caution because restoring a full machine image can also restore unwanted software or configuration.

Ask the technician to separate data recovery from system recovery. Personal documents, photos, and ordinary media can be scanned and restored to a clean system. Applications should come from verified sources again. Browser extensions, scripts, and executable archives need individual judgment. A clean reinstall followed by restoration of selected data is slower than deleting a folder, but it produces a clearer trust boundary.

If the machine handled work, customer, health, legal, or financial information, the owner of that information may have reporting and evidence obligations. Do not make that decision alone. Notify the responsible organisation promptly, provide the facts you observed, and preserve dates. A quiet backdoor can matter even when no ransom note or obvious theft appears.

Keep receipts for the response: scan reports, task screenshots, support case numbers, rebuild date, and the source of installation media. This modest record lets you know later which computer was examined, what was found, what was replaced, and when new credentials became safe to use.

What will not provide an all-clear

Downloading today’s AOMEI installer and scanning it can tell you something about today’s installer. It does not reconstruct what a PC received during a five-minute window months ago.

Uninstalling AOMEI also does not necessarily remove components placed elsewhere or a scheduled task created by the downloader. Uninstallation may be part of a recovery plan, but it is not the investigation.

Finding a clean down_html.ini file is expected after this campaign. Google says the attacker restored the server copies at the end of each burst, and the downloader restored a local value as part of its cleanup. The ordinary file can sit beside evidence of the earlier compromise.

Seeing a valid signature on a Radmin executable is not enough either. The reported chain used a real signed program to load an attacker-controlled file placed nearby. A signature identifies the signed file; it does not bless every file in the folder or every instruction that launches it.

Changing the AOMEI account password alone does not address the mechanism described by the researchers. The attack did not depend on guessing an individual customer’s password. It changed what a trusted background process was told to download and run.

A factory reset performed without a plan can destroy useful evidence and, in some vendor recovery arrangements, restore an old system image. For a confirmed match, decide the recovery source with somebody who understands Windows incident response. “Reset this PC” is a feature, not a guarantee that every route and recovery partition involved is known-good.

Finally, do not cancel every backup. AOMEI Backupper is one product, and this report concerns a particular delivery campaign. The wider lesson is not that backup software is bad. Losing reliable backups would make ransomware, disk failure, theft, and ordinary mistakes more damaging. The answer is to keep backups while reducing the trust given to any one updater and keeping at least one copy disconnected or otherwise protected from the everyday computer.

The update channel deserves its own security question

People usually ask whether software comes from the official website. That remains a good question. This incident adds another: how does the program know that an instruction from its official server was authorised by the software maker?

Those are not the same test. A web connection can authenticate the server and protect traffic in transit. A digital signature checked by the application can authenticate the update instructions or package. When the signing key is kept separately from the web server, somebody who gains permission to edit the server cannot automatically produce a valid signed instruction.

Google recommends that software vendors sign remote configuration files, verify the publisher’s signature on downloaded programs, restrict updates to approved destinations, forbid dangerous address types in notification windows, and separate marketing messages from core updates. The final point is less technical than it sounds. A channel able to show a sale banner should not also possess an easy route to launch a local program.

As a buyer, you may not be able to inspect an updater’s design. You can still look for signs of care. Does the vendor publish security notices? Does it state how long a product receives updates? Can it name a repaired version after an incident? Does it explain whether update packages and manifests are digitally signed? Does it provide a way to verify an installer independently?

For a small business, keep an inventory of backup, remote-support, printer, motherboard, driver, and device-management utilities. These background tools are easy to forget because they are not opened every day. They often retain broad access and permission to contact the internet. Record the product, version, machines, owner, and update method. When a report arrives, the inventory turns “we might use that somewhere” into a finite check.

The Digital Fortress is built around a similar domestic principle: the useful boundary is the one you can inspect after something goes wrong. In this case, the boundary comes from a record of which machines run the updater, a security tool that keeps history, and a backup arrangement that does not give one Windows installation the power to rewrite every copy. Nobody can promise that every update will always be safe.

Home users can borrow the simplest part. Keep one backup copy disconnected after it finishes, or use a service with protected version history. Test that a few files can be restored. Write down the backup program and installation date. An offline copy will not diagnose a compromised updater, but it can stop one compromised computer from becoming the only authority over both the live files and their copies.

A clean present needs a receipt for the past

Timing made this campaign effective, not a loud piece of malware. The false instructions appeared for minutes, reached whichever machines happened to ask, and then gave way to genuine files. A later visitor saw exactly what they expected to see.

That makes today’s clean page a poor witness for July.

If AOMEI Backupper was on a Windows PC during the April-to-July 2026 period, run the full security scan, inspect the two named tasks, and check the relevant folders. Record the result. A known match means disconnecting the machine and getting help, not deleting one file and carrying on. No match is useful evidence, especially when a workplace can pair it with older endpoint and network records.

Then keep the lesson proportionate. Official servers are valuable trust anchors, but they are not magic. HTTPS protects a journey, not every decision made at the destination. A checksum supplied by the same editable file it is meant to police cannot settle who authorised the update. A server repair can protect the next download without undoing the last one.

The right question is not “Does the website look clean?” It is “What did this computer run, what remained, and what evidence do I have?” That question takes a little longer. It also produces an answer worth trusting.

Sources

• Google Threat Intelligence Group and Mandiant: Investigating Ephemeral Supply Chain Tampering, published 15 October 2026. Primary investigation covering the AOMEI update flow, confirmed tampering windows, malware chain, affected telemetry, vendor response, indicators, and defensive guidance.
• The Hacker News: Attackers Tampered with AOMEI Backupper’s Update Servers for Minutes to Deliver a Backdoor, published 16 October 2026. Independent reporting on the time windows, affected-product uncertainty, persistence, AOMEI notification timeline, and limits of a present-day server check.
• Cloud Security Alliance: AOMEI Backupper Update Tampering: Minute-Long Windows, Persistent Backdoor, published 17 October 2026. Independent technical review of the update design, endpoint evidence, credential-coercion route, and response priorities.
• Malwarebytes: AOMEI Backupper update servers hijacked to push malware: Check your PC, published 19 October 2026. Independent consumer-focused account and practical checks for the scheduled task, installation folders, and known network indicators.

If calm, practical security guidance is useful to you, the newsletter sends one email per month. The signup lives here on Cyber Security in Plain English.