What to know

  • The fresh 16 October research publication describes earlier May and July observations.
  • A present-day clean server response does not establish what an endpoint received during a brief tampering window.
  • Record telemetry coverage and ask how delivery instructions are authenticated, without assuming every installation was compromised.

A download server that looks normal during an investigation may have behaved differently when a device contacted it. ManageEngine Threat Analysis Lab's 16 October report on AOMEI Backupper gives that distinction a concrete basis. Its investigators describe short-lived modifications to a vendor-hosted content-delivery path, with legitimate content restored after the malicious window.

The new publication sets out the team's endpoint observations on 28 May and its capture of changed content on 16 July. An earlier 15 October GTIG and Mandiant report corroborates repeated brief tampering windows in the same campaign. These are retrospective research disclosures, not confirmation that a new attack started this weekend or that every Backupper installation was compromised.

Keep the time dimension in the incident question

BijliCoin's analysis is to separate three questions in an exposure review. What software and delivery path did the organization use? What did a particular endpoint receive and execute at the relevant time? What does the vendor serve now? A present-day observation can help answer the third question without settling the second.

This distinction matters when preparing an internal assurance statement. A useful record should identify the evidence period and its gaps. If telemetry was not retained for the relevant dates, say so. Absence of a retained event is different from a complete record showing that an action did not occur. Conversely, the presence of the product alone is not proof that malicious instructions reached a device.

Protect evidence before reducing the story to a patch task

ManageEngine describes abuse of the software's existing content flow rather than a conventional unpatched memory-corruption defect. Its report also notes that a checksum and download location were supplied through the same unauthenticated configuration. The practical reader question is therefore broader than whether an installed version number changed: what authenticates the instruction that authorizes a downloaded component?

An authorized security team could request the supplier's current corrective-action statement and compare it with its own retained endpoint and network records. Keep any investigation within the organization's permission and normal incident process. This article supplies no exploit procedure, malware download or conclusion about an individual installation.

For software buyers, a useful follow-up is to ask how a supplier distinguishes content delivery from permission to execute code, and how it retains enough history to explain a temporary change. Those are evaluation questions prompted by the disclosure, not a claim that BijliCoin audited the vendor's controls.

BijliCoin has not tested AOMEI, examined affected endpoints or independently verified remediation. The researchers' observations support a narrower lesson: assessment of a past delivery event needs evidence tied to that event. A clean sample fetched later is valuable context, but it cannot substitute for the missing history.

Editorial note: AI-assisted research, synthesis and illustration preparation for BijliCoin. Claims are attributed to the cited researchers. BijliCoin did not test software, inspect affected endpoints or verify remediation.

Sources & context

  1. ManageEngine METAL: AOMEI Backupper supply-chain compromise investigation ↗
  2. Google Threat Intelligence Group and Mandiant: ephemeral supply-chain tampering ↗

See our editorial policy or report a correction.