AOMEI’s Recovery Gap
Google and Mandiant’s 15 October investigation describes April-July 2026 tampering with AOMEI Backupper/AnyViewer configurations. Instructions lasted five to ten minutes before authentic files returned, delivering CROSSROAD and SHINYROAD. The remote configuration files lacked independent signatures.
Observed UTC windows included 28 May, 05:40-05:50; 16 July, 08:33-08:39; and 20 July, 10:35-10:40. This is not exhaustive.
METAL’s 16 October account shows why later clean downloads did not refute earlier telemetry. Scheduled tasks could outlast server repair. WebDAV could expose NetNTLMv2 material without payload execution.
The reports prescribe April-July hunts: inspect updater-launched unsigned processes, cached configurations and RadminComponentRuntime/NitroRuntime tasks. Use their complete indicators and rules, not today’s download alone.
Google relays AOMEI’s 29 July server-correction response; METAL had not independently verified containment. Neither establishes a victim total, universally affected release or origin-server entry method.
Separate the decisions
Our proposed handover is a decision record, not a green status badge. Give each conclusion a named approver, an evidence reference, a time range and an unanswered question. Keep ‘investigated’, ‘contained’ and ‘accepted for service’ as separate decisions. Do not write ‘clean’ where the underlying record only says ‘not checked’.
At sign-off, ask one colleague to read the conclusion without its attachments. Ask another to reconstruct it from the references alone. Record any disagreement before approval. This is our suggested documentation exercise, not a researcher-prescribed remediation step or a test we performed. It cannot validate a host or replace incident response.
Sources: Google/Mandiant; METAL.
