AOMEI Backupper's checksum was rewritten with the file in three confirmed 10, 6 and 5 minute windows, 28 May to 20 July

Three windows, 21 minutes in all, and a checksum that came with the file

Google says attackers tampered with AOMEI's update infrastructure in three windows that it confirmed: 10 minutes on 28 May, 6 minutes on 16 July and 5 minutes on 20 July 2026. That is 21 minutes in all (derived), or 0.03 per cent of the 53 days and 5 hours between the first window opening and the last one closing (derived). ManageEngine's account is that the software did what it was built to do and that its integrity check passed. ManageEngine's Threat Analysis Lab, which found the activity, gives the reason in one sentence: "Every check passed because the party controlling the configuration could control what each check was asked to verify." The checksum the client used to validate the downloaded archive was declared inside the same unauthenticated file that named the download, and Google reports that the actor changed that expected value along with the address in each window.

That is the fact this briefing rests on, and it is narrow. A checksum compares what arrived with a value the client was handed. ManageEngine says so directly: a checksum "cannot establish that the value itself came from the vendor". Google's advice to software vendors says the same thing from the other side: update clients "should never rely solely on transport-layer HTTPS or remote checksums".

What the record does not establish is most of what a reader needs. Google says more windows probably happened that it did not see, so 21 minutes is the confirmed part, not a measure of exposure. Neither report gives a count of victims or machines. Neither says how the actor reached AOMEI's servers. Google lists eleven countries where it saw victims and no UK organisation is among them, which is a list of where it saw activity, not a boundary. UNC7017 is Google's tracking label for the actor. The post gives no nation, no motive and no confidence level, and calls the targeting opportunistic. The vendor's statements found are the changelog entries of 19 October and, per BleepingComputer, a short reply to that site.

This briefing is built from Google's blog post (15 October 2026), ManageEngine's report (16 October), AOMEI's own changelogs and product pages for AOMEI Backupper, AOMEI Partition Assistant and AnyViewer, and UK government and regulator pages. All were read in full between 11:46 and 12:12 BST on Tuesday 20 October 2026. BleepingComputer (19 October) and The Hacker News (16 October) were read as secondary reporting; where they differ from the primaries, the primaries are followed and the differences are in a table below. No indicators are reproduced here: the two reports carry them. Both reporters sell security products and services, ManageEngine through an endpoint product whose telemetry made the first detection, and AOMEI sells the backup software and wrote its own changelog entries. Pages can change within hours.

Stated and not stated: what Google, ManageEngine and AOMEI say

Google's post is the account of the campaign. ManageEngine's report is the account of the first detection and the investigation. The table sets what they and AOMEI's pages state against what none of them states. "Not stated" means not found in the pages read in full. It does not mean the information does not exist.

What the Google post (15 October 2026), the ManageEngine report (16 October 2026) and AOMEI's changelogs (19 October 2026) state, and what they do not. Quotations are exact.

The question	Stated	Not stated
What was tampered with?	Two remote configuration files that the software polls over HTTPS. One gives the version, the expected checksum and the download address of the update package. The other tells the notification process what to show and which local programs to run (Google).	How the actor gained the ability to change them. Neither report says, and BleepingComputer says AOMEI did not confirm it.
When?	Three observed windows, in UTC: 28 May 05:40 to 05:50, 16 July 08:33 to 08:39 and 20 July 10:35 to 10:40. Each "remained active for only five to ten minutes" (Google).	Any other window. Google: "it is probable that additional tampering occurred throughout the campaign that remained outside our visibility". Whether tampering stopped after 20 July.
How many victims?	Organisations in IT services, telecommunications and higher education "and related entities" in eleven countries: Australia, Brazil, India, Pakistan, Portugal, Singapore, South Africa, Spain, Switzerland, Türkiye and the United States (Google). Two unrelated customers in different countries on 28 May (ManageEngine).	A count of organisations or machines. The United Kingdom is not in the list. Google says the real number "likely extends more broadly".
Who is behind it?	A cluster Google tracks as UNC7017, using a downloader it names CROSSROAD and a backdoor it names SHINYROAD. Google calls the victim pattern opportunistic.	A nation, a motive, a link to a named group, or a confidence level.
Which software versions?	ManageEngine's summary says the software was "observed on v8.3.0 and later versions", and it reconstructed the chain on 8.3.0.	A list of affected versions, or whether earlier versions fetch the same files. Google's post gives none.
Is it fixed?	Google: AOMEI "reported that they took corrective action to secure their distribution servers", and responded on 29 July that corrective actions had been taken. ManageEngine: "we have not independently verified that the compromise has been contained". AOMEI's changelog of 19 October says Backupper 8.5.1 "has addressed" the risks identified in the incident.	How the files were changed, whether tampering stopped after 20 July, who verified the fix, or any AOMEI incident notice. No such notice was found on the AOMEI pages read.
Does a fix clean machines that were hit?	No. Google: "server-side remediation does not clean endpoints that downloaded malicious updates during earlier tampering windows". ManageEngine says the same.	How many machines received the payload, and whether 8.5.1 removes anything: its changelog does not claim to.
Was a vulnerability exploited?	ManageEngine: "There was no CVE, no memory corruption, and no unpatched component."	A CVE or a severity score. None exists, which matters for patch deadlines written around vulnerabilities (see the UK section).

The windows to scale, and the days around them

On a line from 1 April to 19 October, the three windows together are 0.007 per cent of the 201 days (derived), far narrower than a pixel at any size this page can show. The diagram draws them 3 units wide so that they can be seen. In UK time the windows opened at 06:40 BST on Thursday 28 May, 09:33 BST on Thursday 16 July and 11:35 BST on Monday 20 July (derived), so two of the three fell inside a UK working morning.

Intervals computed from the dates in the two reports and AOMEI's changelog. All derived: calendar days, UTC.

From	To	Interval (derived)
First window opens, 28 May 05:40 UTC (Google)	First detection by ManageEngine's endpoint product, 28 May (ManageEngine)	0 days: the same date. The time of the detection is not stated.
An early version of the downloader is submitted to a public scanning service, 20 May (Google)	First detection, 28 May	8 days
First detection, 28 May	ManageEngine tells AOMEI, 7 June	10 days
First detection, 28 May	ManageEngine's monitor catches a window live, 16 July	49 days
ManageEngine tells AOMEI, 7 June	Third window, 20 July	43 days
Live capture, 16 July	Third window, 20 July	4 days
Mandiant tells AOMEI, 17 July	Third window, 20 July	3 days
Third window, 20 July	AOMEI responds that it has acted, 29 July (Google)	9 days
Third window, 20 July	Google's post, 15 October	87 days (ManageEngine's report, 16 October: 88. BleepingComputer, 19 October: 91)
First detection, 28 May	Google's post, 15 October	140 days
AOMEI responds that it has acted, 29 July (Google)	AOMEI's Backupper 8.5.1 changelog date, 19 October	82 days
First detection, 28 May	Backupper 8.5.1, 19 October	144 days

Four readings follow. First, the first confirmed window and the first detection share a date, so the gap between them is zero. The detection came from endpoint behaviour, and nobody saw the server change until ManageEngine's monitor caught a window 49 days later. In the meantime ManageEngine could not reproduce the delivery: its test copy fetched clean content, and in its words "No executable arrived." Second, ManageEngine told AOMEI on 7 June and the third window opened 43 days later, 4 days after the live capture and 3 days after Mandiant's notice. That does not show that AOMEI ignored the warning. BleepingComputer, quoting ManageEngine, says AOMEI engaged and reviewed. It does show that being told did not stop the windows. Third, a machine that polled during the last window could have held the scheduled payload for up to 87 days before the first public report (derived, and only if nothing removed it). Fourth, AOMEI's version 8.5.1 is dated 82 days after AOMEI's reply of 29 July (derived), and 4 days after Google's post.

"Briefly" and "restored" are evasion steps, not reassurance. Google says the short windows were "effectively evading traditional point-in-time triage and automated file scanning", and that an analyst who checks the vendor's download address after an alert will usually see clean files and may dismiss a real detection. ManageEngine puts it this way: "A clean point-in-time reputation check is weak evidence against a supply-chain compromise." Both advise using what the endpoint recorded it received, and the network record for the second the alert fired.

What each confirmed window carried, as Google describes it in its post of 15 October 2026. Times in UTC with BST in brackets (derived).

Window	Length (derived)	What Google says it carried
28 May, 05:40 to 05:50 (06:40 to 06:50 BST)	10 minutes	The first confirmed window. A downloader that installed a modified version of a commercial remote administration tool, Radmin Server. ManageEngine's endpoint product saw this on two unrelated customers. Early staging was on a cloud storage service.
16 July, 08:33 to 08:39 (09:33 to 09:39 BST)	6 minutes	The update settings file pointed to the actor's own domain, with a raised version number and a matching checksum. The notification file was heavily padded so that the client ran the update whatever version it held. ManageEngine's monitor saw this window live.
20 July, 10:35 to 10:40 (11:35 to 11:40 BST)	5 minutes	The first download came from a public cloud storage bucket instead of the actor's domain, which Google says let it pass proxies that block newly registered domains. The notification file also carried an invisible one pixel pop-up that pointed at a remote file share, which can make Windows send the user's hashed credential without any program running. Seen by Google and Mandiant while ManageEngine's monitor was down.

The checksum, and the other labels that did the work

AOMEI Backupper polls AOMEI's servers in the background for update and promotional content. ManageEngine describes the design plainly. The client reads the package address and the expected checksum from a remote settings file, downloads the archive, validates it against the declared checksum, extracts it into a staging folder and moves it into its own resource folder. A second process reads a separate notification file and follows its instructions. ManageEngine's conclusion is that nothing was exploited: the application "performed as designed", and the adversary "used AOMEI Backupper's promotional content channel exactly as it was designed to work".

The check was real. It compared two things that the same party supplied. ManageEngine adds that the folder the archive ended up in "exists for rendering assets, not executables", and that "Nothing in the application's normal operation would place a binary there." A channel built to show promotions had a route to running code, and that route ran through the same trusted folders as the product's own content. Each comforting label below was true of something and did the work of a control.

Labels that did the work of controls in this incident. The middle column is what the sources say; the right column is what the label does not establish.

The label	What it was doing here	What it does not establish
Checksum verified	The client compared the archive with an expected value. The value sat in the same unauthenticated file that named the download, and the actor changed it with the address.	That the archive came from the vendor. ManageEngine: a checksum "cannot establish that the value itself came from the vendor".
Fetched over HTTPS from the vendor's own hostnames	AOMEI's first explanation was interception in transit. ManageEngine rejected it: both endpoints used HTTPS from AOMEI hostnames and the content "had been altered before it reached either endpoint".	That the vendor's server was serving what the vendor intended. HTTPS protects the connection, not the origin.
Built in updater, promotional content	A channel meant for pop-ups could cause a local program to run. Google advises vendors to decouple core updates from marketing channels.	That a marketing channel is low risk. Here it was the route to code execution.
Signed	The processes that fetched and launched the content were signed. The downloader was unsigned but carried AOMEI's publisher details and a misspelt product name. The remote administration binary was a genuine signed one.	That every program in the chain was trustworthy. A signed program loaded an attacker's unsigned library.
Legitimate remote administration tool	Radmin is a commercial product. ManageEngine says the installer was genuine, arrived without a server address or credential, and found no listener and no new account. Remote access came from a separate implant that connected outward.	That the tool was harmless. An updater installed it where IT had not, and Google describes the actor blending commercial remote management with hidden modules.
Briefly, then restored	The actor reverted both files within minutes, and the downloader restored the local update file to its genuine contents.	That nothing happened. A restored server and a restored local file leave the scheduled payload in place.
Server side fix	AOMEI responded on 29 July that it had acted, and its changelog says 8.5.1 addressed the risks.	That any machine is clean. Google: "server-side remediation does not clean endpoints". ManageEngine has not verified containment.
Asymmetric encryption (AOMEI's 8.5.1 line)	AOMEI's changelog says it "Added asymmetric encryption for remote configuration files".	That the client verifies who wrote a file. Both reports ask for signing, which proves origin. The changelog says encryption. Whether a signature is checked is not stated.
Automatic updates	8.5.1 "Disabled in-app entry points for promotional pop-up content updates and automatic software updates."	That an update path exists. The fix for an automatic updater was to remove it, so unless AOMEI says otherwise, later versions reach a machine only if an administrator installs them (inference).

The pattern is not confined to desktop software. On 19 October this site covered Rank Math PRO, where Rank Math says PRO downloads in an 11 hour 10 minute window carried malware and the customer's version check could not tell an affected copy from a clean one. An earlier briefing covered a genuine, signed MSP360 installer that installed a second remote tool: the signature was true and still was not approval. In each case the customer's check ran against something the same party controlled or something the same party had signed.

What ran on the machine, and what the reports do not say it did

Both reports describe the same chain at a level a defender can use. A downloader, CROSSROAD in Google's naming, checked the machine before going further. It created a scheduled task that runs a payload every three hours, and it then deleted itself. The payload bundle held a genuine, signed Radmin binary and an attacker-built library that the signed binary loaded, and that library brought in the implant, SHINYROAD, which Google calls a modular backdoor. ManageEngine decrypted the implant in a lab and found it could take a remote shell and receive and run new code. It warned that the observed capabilities "should therefore be treated as a floor, not a ceiling". In mid-July Google saw a second tool, the client of a post exploitation framework, pushed on top of SHINYROAD and disguised as PDF software.

Three properties matter to a defender. The chain is selective: ManageEngine says the downloader stopped if the host's address geolocated to China, if the location lookup failed, or if it found particular security agents, and Google reports the country check. A machine that polled in a window and shows no payload may therefore have been exposed and passed over (inference). The chain inherits privilege: it ran with the privileges of the AOMEI process that launched it, and ManageEngine says "The installation paths suggest elevated execution." And the credential route on 20 July needed no program to run. ManageEngine: an endpoint "protected against the execution chain" may still have leaked credentials through the notification path.

A backup tool is a good place for an attacker to be. It is installed on the machines whose data matters, usually runs with high privilege, and is allowed to read everything it backs up (inference; neither report discusses this). What the reports do not say is that any data was read, copied or altered, that any backup was changed, or that any credential was collected.

AOMEI's side: what it was told, what it said, and what 8.5.1 lists

ManageEngine says a customer raised the activity on 7 June and that it told AOMEI the same day. AOMEI's first explanation, per ManageEngine, was interception in transit. Mandiant notified AOMEI on 17 July and AOMEI replied on 29 July that it had taken corrective action (Google). BleepingComputer, quoting ManageEngine, adds that AOMEI's own review "had not found evidence of a breach" at first, and that AOMEI later said it had upgraded its servers, patched potential vulnerabilities and verified its files. Those three statements rest on BleepingComputer alone. On 19 October BleepingComputer reported AOMEI saying its chief technology officer was leading a dedicated investigation, and that AOMEI had not confirmed how the attackers got in or whether the matter was resolved.

On 19 October AOMEI published changelog entries with the same wording for AOMEI Backupper 8.5.1, AOMEI Partition Assistant 10.12.2 and AnyViewer 5.8.1. Each says the product "has addressed the software distribution and notification security risks identified in the recently reported ephemeral supply-chain tampering incident" and that users are "strongly recommended" to upgrade. Neither report names Partition Assistant as affected. Google names AnyViewer as using the same update flow. The Hacker News checked the Backupper changelog on 16 October and found no change to update verification through 8.5.0, dated 9 October. The 8.5.1 entry is newer than that check.

The five changes AOMEI lists for AOMEI Backupper 8.5.1 (changelog dated 19 October 2026), with a reading of each and what each line does not say. Quotations are exact. The Partition Assistant and AnyViewer entries list the same five.

AOMEI's line	What it suggests (a reading)	What the line does not say
"Disabled in-app entry points for promotional pop-up content updates and automatic software updates."	The promotional channel and in-app automatic updating are switched off.	How a user gets later updates, and whether the settings can be turned back on.
"Added asymmetric encryption for remote configuration files"	Remote settings files are protected with a public key technique.	Whether the client verifies a signature. Encryption hides contents. A signature proves origin.
"Stopped using the previous update service domain"	The host the update settings came from is retired.	Whether the old host still answers, and what replaced it.
"Isolated software updates from marketing notification configurations and download resources."	Updates no longer share settings with the promotional channel.	Whether the notification channel can still launch local programs.
"Enforced strict download validation, permitting update files to be retrieved exclusively from official AOMEI websites."	A destination check: the client fetches only from AOMEI hosts. That would have blocked the redirects described in the windows (inference).	That a file on an official host is authentic. Google and ManageEngine both ask for signing as well as pinning.

None of the AOMEI pages read says what happened, when, to how many users, or which earlier versions were affected. Google and ManageEngine tell customers to hunt across April to July. AOMEI's pages say to upgrade. That is a different instruction, and for a machine that already holds a payload it is the wrong first step, because the upgrade does not claim to remove one (a reading).

Where the coverage and the reports differ

Each difference below was checked against the primary page. Where a news report and a primary disagree, the primary is followed. A difference is not an accusation: reports are written fast and primaries are updated.

Differences between the secondary reporting, the two primary reports and AOMEI's pages, as read on 20 October 2026.

The point	What the pages say	How this briefing handles it
Countries	BleepingComputer lists six: the United States, Australia, India, Singapore, Spain and Switzerland. The Hacker News and Google list eleven.	Follows Google: eleven. The other five are Brazil, Pakistan, Portugal, South Africa and Türkiye.
Date of the reports	Google's post is dated 15 October 2026 in its page data. ManageEngine's report is dated 16 October. The Hacker News is dated 16 October. BleepingComputer is dated 19 October.	Intervals to the first public report use 15 October.
April to July	Google confirms three windows, the first on 28 May, and reports malware samples in the wild "starting in late April". ManageEngine's summary says Google's report "documents tampering windows dating back to April 2026". The Google post lists none before 28 May.	April is the start of the period to hunt across, not a confirmed window.
AnyViewer	ManageEngine's summary says Google covers "targeting of AOMEI AnyViewer alongside Backupper". Google's post names AnyViewer as using the same update flow, and its detections involve Backupper. AOMEI's AnyViewer changelog carries the same security entry.	AnyViewer is in scope for inventory and hunting. No separate window is attributed to it.
The remote administration tool	Google says a "modified version" of Radmin Server was installed. ManageEngine says a "genuine Famatech installer" ran and arrived without a server address or credential. BleepingComputer says "legitimate".	Each is quoted as stated. The difference may be the missing configuration (inference).
Who saw which window	BleepingComputer says Google and ManageEngine identified three windows. ManageEngine's own monitor caught the 16 July window, and Google and Mandiant captured the 20 July window while that monitor was down.	Three windows confirmed. ManageEngine itself observed the first by telemetry and the second live.
Affected versions	The Hacker News says neither report lists affected versions. ManageEngine's summary says "observed on v8.3.0 and later versions".	ManageEngine's wording is quoted. It is an observation, not a list.
The fix	The Hacker News (16 October) found no verification change through 8.5.0. AOMEI's changelog now lists 8.5.1 (19 October).	The changelog as read on 20 October is followed.

The UK: what the guidance says and where it stops

No UK organisation is named in Google's list of eleven countries or in ManageEngine's report, and neither report mentions the UK. That is not evidence that no UK machine polled in a window. Google's list is where it saw activity, and AOMEI Backupper has a free edition that home users and small firms may run with no vendor relationship to prompt a notice (inference). UK clocks were on BST throughout: the windows opened at 06:40, 09:33 and 11:35 BST. The table gives what each UK page says, as read on 20 October 2026, and where it stops.

UK guidance and regulator pages as read on 20 October 2026, with where each stops. Quotations are exact.

UK source	What it says	Where it stops
NCSC, "Put in place a policy to update by default" (published 12 February 2024, reviewed 1 May 2026, version 2.1)	Apply updates "as soon as possible, and ideally automatically". Applications: automatically, within 7 days. On trust: "You should also ensure the updates come from trusted sources, usually the vendor support website. You may be able to confirm the hash or checksum before installation." For an actively exploited vulnerability it lists isolating and replacing the system, or erasing and rebuilding it.	Nothing on a vendor whose own server supplies both the file and the hash. The page says "may", and does not say where a hash should come from. A fix that switches the automatic updater off, as 8.5.1 does, leaves "ideally automatically" to your own tooling (inference).
NCSC, supply chain security guidance, "Third party software providers" (published 31 July 2019, reviewed 22 October 2025)	"Compromised software is very difficult to detect if it has been altered at the source", which "places great reliance on the supplier".	The example is trojanised industrial control software, and the page is written for large organisations, the public sector and security professionals. It gives no steps for a configuration file altered for minutes.
NCSC blog, "Software supply chain attacks: check your dependencies" (4 June 2026)	"Pause automatic dependency updates where compromise may be present." "Avoid automatically adopting new dependency versions without review."	About open source packages and developer pipelines. It does not mention desktop updaters or backup software.
DSIT, Software Security Code of Practice (voluntary, updated 15 January 2026) and the NCSC implementation guidance (7 May 2025)	Principle 3.1: "Distribute software securely to customers." The guidance: "Tampering with or spoofing software (and its updates) can occur at various stages of the distribution process." "Code integrity/provenance must be verified". 3.5: "Updates should be signed and thoroughly tested." 4.3: "Make information available to customers about notable incidents that may cause significant impact to customer organisations."	Voluntary, and framed for business to business sales of proprietary software. Whether a vendor with a free personal edition is in scope is not stated. A vendor that followed 3.1 and 3.5 as written would have signed updates (inference). AOMEI's pages do not say whether it does.
Cyber Essentials requirements for IT infrastructure v3.3 (April 2026)	Software in scope must have "automatic updates enabled where possible" and fixes for critical or high risk issues within 14 days, including where "there are no details of the level of vulnerabilities that the update fixes provided by the vendor". One malware protection option: "Only approved applications, restricted by code signing, are allowed to execute on devices."	The words checksum, hash, integrity, provenance and supply chain do not appear in the document. Allow listing is one of two options, so a certified organisation may have none. A certificate says nothing about a poisoned vendor.
ICO, personal data breach reporting and "Personal data breaches: a guide"	Report a notifiable breach "within 72 hours of becoming aware of it", with details to follow if needed. Access by an unauthorised third party is a personal data breach. A processor must inform the controller without undue delay. The reporting page says it is under review after the Data (Use and Access) Act.	Does not say when a customer of a compromised vendor becomes aware. It points to EU guidelines for that, which were not read here.

A reading, not advice. The NCSC's page asks for applications to be updated within 7 days. For 8.5.1, dated 19 October, 7 days ends on 26 October and Cyber Essentials' 14 days on 2 November (derived). Whether the Cyber Essentials rule applies at all is unclear. It is written around vulnerabilities, ManageEngine says there was none, and AOMEI's entry states no level. The third case, where the vendor gives no details of the level, is the nearest fit (reading). The sensible order for any organisation is to hunt first and upgrade second, because the hunt needs the evidence the machine still holds and because upgrading does not claim to remove a payload.

The ICO's 72 hours runs from becoming aware, and a backup tool can reach personal data by design (inference). If a hunt finds the payload on a machine that could reach personal data, awareness arrives with that finding, not with Google's post (a reading, not legal advice). A managed service provider that deploys these products on clients' machines may be a processor, which depends on its contract, and the ICO's guide says a processor must tell the controller without undue delay. The NIS Regulations are not covered: no record read ties this incident to a listed essential service.

What to do, in the order worth doing

Everything below rests on the two reports, AOMEI's pages or the UK pages above. The indicators and detection rules are in the Google and ManageEngine reports and are deliberately not reproduced here. Items 10 and 11 are this briefing's suggestions, not guidance from the NCSC.

What could not be verified

• AOMEI's own account. Only its changelogs and product pages were found. No incident notice or press statement was found. The statements attributed to AOMEI about its review, its servers and its investigation rest on BleepingComputer, quoting ManageEngine and AOMEI.
• What 8.5.1 changes inside the product. Only AOMEI's five lines were read. No installer was downloaded and no binary was examined.
• Whether tampering stopped after 20 July. Neither report says. ManageEngine has not verified containment.
• How many windows, victims or machines. Not stated. Google says more windows probably happened.
• UK exposure. No UK organisation is named, and exposure cannot be ruled out.
• The indicators and rules. Not tested or reproduced here. The Hacker News also did not test them.
• How the actor reached the files. Not stated by either report or by AOMEI.
• Time-stamped. The primaries and AOMEI's pages were read between 11:46 and 12:12 BST on 20 October 2026, and re-read at 12:11 BST with no change in their text. BleepingComputer said it would update its article if AOMEI sent a fuller response. Any of this can change within hours.

The question that exposes the gap

When your backup tool checks for an update, who decides what "correct" means: a signing key the vendor keeps off its web server, or whoever last edited a file on it, and has your vendor ever told you which?

Key facts