Attackers reportedly compromised AOMEI's update infrastructure and used a built-in promotional feature in its backup software to distribute malware to end users, as BleepingComputer reported. Crucially, no installer binaries appear to have been altered — the intrusion instead targeted server-side configuration files that govern what the software fetches, and from where.
That distinction matters. Because the tampering was confined to configuration, routine code-signing checks and file-integrity verification on the downloaded executables would likely have passed. Whether any signing material was compromised remains unconfirmed; on the available reporting, the manipulation appears limited to server-side configuration, though the full scope is still under scrutiny.
A deliberately short window
The attackers also moved to cover their tracks: after serving the malicious configuration, they restored the files to their original state. The effect was to shrink the period during which defenders could detect the tampering by comparing stored configuration against live server responses. Post-incident file-integrity checks alone may therefore find nothing wrong — a reminder that "the file hashes all match" is not the same as "nothing happened."
The compromised component is a promotional feature — a channel the software uses to surface offers or additional content — rather than the update mechanism for the core product itself. That is precisely what makes it dangerous: a routine, low-scrutiny feature was repurposed into a malware delivery pipeline, inheriting the trust already granted to the application.
Why backup software amplifies the risk
Backup and recovery tools occupy a privileged position in most environments. They run with elevated privileges, touch broad sets of business data, and are installed on trusted systems precisely because they are trusted. When such an application downloads content from a vendor-controlled endpoint, that traffic rarely receives the same scrutiny as, say, an email attachment.
The malware family delivered through the compromised channel, the affected release range, and the precise infection window remain unconfirmed in the available reporting. AOMEI had not published a detailed account as of writing, so administrators should treat all three as open questions.
A practical checklist for administrators
For IT teams running AOMEI or similar backup products:
- Inventory and hunt. List every machine with AOMEI backup software installed and record its version number, then audit proxy, DNS, and firewall logs for unusual connections initiated by the backup agent, and search EDR and AV logs for detections or quarantined files originating from its process tree during the suspected infection window.
- Isolate and reimage on suspicion. Given elevated privileges, treat any confirmed or likely compromise as a potential foothold for lateral movement, not a contained endpoint issue.
- Verify against IOCs. Once indicators of compromise are published — hash lists, domains, or C2 infrastructure — correlate them against logs before declaring systems clean.
The broader lesson
Vendor security reviews typically assess code-signing practices and patch cadence. Rarely do they ask a more pointed question: what else does this application download, from where, and how often? That gap is exactly where this attack lived. Third-party risk assessments should extend beyond the vendor's release pipeline to every network channel the software maintains after installation: update servers, content-fetch endpoints, and promotional modules are all part of the trusted surface — and, as this incident suggests, all potentially live attack surfaces in their own right.
據 BleepingComputer 報道，有黑客入侵 AOMEI 的更新基礎設施，並利用其備份軟件內建的推廣功能，向最終用戶散播惡意軟件。關鍵在於，安裝程序的 binary 似乎並未被改動——入侵針對的是伺服器端的配置檔案，這些檔案決定軟件會下載甚麼內容，以及從哪裡下載。
這個區別十分重要。由於篡改僅限於配置層面，日常的 code-signing 檢查及下載 executable 的檔案完整性驗證很可能會順利通過。是否有任何簽署材料被盜用仍未確認；就目前報道所見，篡改似乎僅限於伺服器端配置，但完整影響範圍仍在調查中。
蓄意縮短的偵測窗口
黑客亦試圖掩蓋痕跡：在投放惡意配置之後，他們已將檔案還原至原本狀態。此舉縮短了防禦人員透過比對儲存配置與伺服器即時回應來偵測篡改的時間窗口。事後單靠檔案完整性檢查可能查不出任何異常——這提醒我們，「檔案雜湊值全部吻合」並不等於「甚麼都沒有發生過」。
遭入侵的組件並非核心產品本身的更新機制，而是一項推廣功能——即軟件用來展示優惠或額外內容的渠道。這正是其危險之處：一項日常運作、鮮受審視的功能被改造成惡意軟件投放 pipeline，並繼承了應用程式本身已獲得的信任。
備份軟件如何加劇風險
備份及還原工具在大多數環境中佔有特殊地位。它們以提升權限運行，接觸範圍廣泛的業務數據，而且正因為受到信任才安裝在受信任的系統上。當此類應用程式從廠商控制的端點下載內容時，該流量很少會獲得與電郵附件同等程度的審查。
就目前報道所見，透過遭入侵渠道投放的惡意軟件家族、受影響的版本範圍，以及準確的感染時段，均未獲確認。截至截稿時，AOMEI 尚未發表詳細說明，因此管理員應將此三者視為未解問題。
管理員實用清單
對於運行 AOMEI 或類似備份產品的 IT 團隊：
- 盤點及搜尋。 列出所有安裝 AOMEI 備份軟件的機器並記錄其版本號，然後審核 proxy、DNS 及 firewall 日誌，查找備份 agent 發起的異常連接，並在懷疑感染時段內，於 EDR 及 AV 日誌中搜尋源自其 process tree 的偵測記錄或被隔離檔案。
- 一有懷疑即隔離並重灌系統。 鑑於該軟件擁有提升權限，任何已確認或可能的入侵都應視為橫向移動（lateral movement）的潛在落腳點，而非局限於單一端點的問題。
- 比對 IOC。 一旦威脅指標（indicators of compromise）獲公布——無論是 hash 清單、域名還是 C2 基礎設施——應先與日誌進行關聯分析，方可宣告系統乾淨。
更廣泛的教訓
廠商安全審核通常只評估 code-signing 做法及 patch 節奏。很少會提出一個更尖銳的問題：這個應用程式還會下載甚麼、從哪裡下載、下載頻率如何？這個盲點正是本次攻擊的藏身之處。第三方風險評估應超越廠商的 release pipeline，涵蓋軟件安裝後維持的每一條網絡渠道：更新伺服器、內容下載端點及推廣模組，全部都屬於受信任範圍——而正如本次事故所示，它們本身也全都是潛在的攻擊面。