Canalul de actualizări AOMEI, deturnat pentru câteva minute ca să instaleze backdoor-uri

Anul acesta, atacatorii nu au avut nevoie de o vulnerabilitate sau de un e-mail de phishing ca să compromită utilizatorii AOMEI Backupper. Au preluat canalul oficial de actualizări al producătorului doar câteva minute o dată. Orice calculator care a căutat actualizări într-una dintre aceste ferestre a descărcat malware.

Ce s-a întâmplat

Google Threat Intelligence Group (GTIG) și Mandiant au asociat activitatea cu un grup pe care îl numesc UNC7017. Între aprilie și iulie 2026, atacatorii au modificat de mai multe ori două fișiere de configurare de pe serverele de distribuție AOMEI, apoi au pus la loc originalele:

• down_html.ini spune aplicației care este versiunea curentă, ce sumă de control (checksum) să aștepte și de unde să descarce pachetul.
• Notifycfg.ini controlează funcția de notificări, inclusiv ce programe locale lansează.

În fiecare fereastră, fișierele modificate trimiteau aplicația către o arhivă ZIP malițioasă, iar mecanismul de notificări o executa. Ferestrele confirmate au fost scurte: circa zece minute pe 28 mai, șase minute pe 16 iulie și cinci minute pe 20 iulie. Threat Analysis Lab de la ManageEngine a semnalat primul comportamentul suspect în telemetria sa, la sfârșitul lui mai. AOMEI a transmis Google că a luat măsuri pentru securizarea serverelor de distribuție.

Au fost raportate victime în mai multe sectoare și țări, inclusiv în India. Numărul total al sistemelor afectate nu este cunoscut.

Cum a funcționat lanțul de infectare

• CROSSROAD (prima etapă, livrată ca upgrade-now.exe) analizează sistemul și se oprește dacă IP-ul public este localizat în China. Restaurează configurația curată a producătorului ca să-și acopere urmele, descarcă alte fișiere, creează un task programat și se șterge singur.
• Task-ul programat pornește un executabil Radmin legitim la fiecare trei ore. Lângă el este plasat un BlkScrDl.dll malițios, care este încărcat la pornire (DLL side-loading).
• DLL-ul încarcă SHINYROAD, un backdoor care comunică cu infrastructura atacatorilor.
• Ulterior a apărut și ADAPTAGENT, un client pentru framework-ul de comandă și control Adaptix, deghizat în software Nitro PDF.
• Pe 20 iulie, atacatorii au folosit și o fereastră de notificare invizibilă, de un pixel, ca aplicația AOMEI să ceară un fișier de la distanță prin WebDAV. Asta poate face ca Windows să trimită date de autentificare NetNTLMv2 către un server controlat de atacatori.

Găzduirea payload-urilor s-a schimbat în timp, de la stocare Alibaba Cloud și domenii care imitau AOMEI la un bucket public Google Cloud Storage în iulie. Din acest motiv, simpla blocare a unor domenii nu este suficientă.

De ce contează

Două detalii fac această campanie greu de gestionat:

1. Dovezile dispar de pe server, dar infecția rămâne pe stație. Cine verifică ulterior serverul de actualizări vede doar fișiere curate. Un sistem care a descărcat payload-ul într-o fereastră de cinci minute rămâne compromis până când este curățat.
2. HTTPS plus checksum nu dovedesc autenticitatea. Dacă suma de control vine dintr-un fișier de configurare nesemnat, pe care atacatorul îl poate edita, aplicația verifică pachetul malițios cu valoarea pusă chiar de atacator și îl acceptă.

Metoda seamănă cu alte incidente recente de tip supply-chain: atacatorii compromit canalul de livrare în care utilizatorii au încredere, nu produsul în sine, și păstrează fereastra de expunere scurtă.

Ce trebuie să faceți

• Identificați instalările AOMEI. Inventariați AOMEI Backupper și celelalte unelte AOMEI din organizație, inclusiv de pe servere.
• Căutați în telemetria istorică, nu doar pe serverul live. Pentru aprilie–iulie 2026, căutați procese copil neobișnuite ale componentelor de actualizare și notificare (Backupper.exe, ABNotify.exe), fișiere upgrade-now.exe / upgrade-now.zip și task-uri programate neașteptate care lansează executabile Radmin sau cu nume Nitro.
• Verificați DLL side-loading. Căutați BlkScrDl.dll sau alte DLL-uri nesemnate lângă executabile Radmin ori Nitro legitime, în directoare în care utilizatorul poate scrie.
• Analizați configurațiile din cache și logurile de rețea. Comparați copiile down_html.ini / Notifycfg.ini de pe stații cu versiuni cunoscute ca fiind curate. Verificați în logurile de proxy și firewall descărcările de actualizări din bucket-uri cloud, precum și autentificările WebDAV/SMB către internet.
• Considerați credențialele expuse pe orice sistem confirmat ca infectat. Schimbați-le și blocați, unde se poate, traficul NTLM către destinații externe.
• Comparați cu indicatorii de compromitere (IoC) publicați. GTIG/Mandiant au publicat hash-uri de fișiere și indicatori de rețea. Încărcați-i în EDR și SIEM.
• Producătorii de software ar trebui să semneze și fișierele de configurare ale actualizărilor, nu doar executabilele, să verifice semnătura pachetelor descărcate, să limiteze actualizatorul la o listă scurtă de domenii permise și să separe funcțiile promoționale sau de notificare de orice componentă care poate executa cod.

Pentru software-ul pe care îl dezvoltați și îl distribuiți, aceste probleme se depistează cel mai bine la review, înainte de lansare: un fișier de configurare nesemnat care stabilește de unde vin actualizările sau un modul de notificări care poate lansa orice program. Code review-ul asistat de AI de la 4tify caută acest tip de slăbiciuni de încredere în logica de actualizare și distribuție înainte să le găsească atacatorii.

Credit cercetare: Google Threat Intelligence Group (GTIG) și Mandiant. Relatat de Cyber Security News.